AI নিরাপত্তা পরীক্ষা কি SAST, DAST ও পেনটেস্টের বিকল্প হতে পারে?

আসল প্রশ্ন হলো, এজেন্ট কোথায় বিশ্বাস অর্জন করে। আমি এজেন্টকে বিশ্বাস করি রিভিউয়ের পরিধি বাড়াতে, বিভিন্ন ফাইলের সূত্র মিলিয়ে দেখতে, লক্ষ্যভিত্তিক পরীক্ষা তৈরি করতে এবং অস্পষ্ট স্ক্যানার ট্রেসকে ডেভেলপার বোঝেন এমন সমাধানে বদলাতে। কিন্তু শুধু রুটের নাম দেখে কোম্পানির অনুমোদনের নিয়ম অনুমান করতে, প্রতিটি টেন্যান্ট সীমা অটুট প্রমাণ করতে, অথবা অদ্ভুত আর্থিক কর্মপ্রবাহে অপব্যবহার হচ্ছে কি না মানুষের বলা নিয়ম ছাড়া ঠিক করতে আমি তাকে বিশ্বাস করি না। এজেন্টকে স্তরভিত্তিক পরীক্ষা কর্মসূচির সক্রিয় রিভিউয়ার ভাবুন, কর্মসূচিটিই নয়।

এজেন্ট রিভিউ হলো ব্যাখ্যাকারী, নতুন কোনো পরীক্ষার ধরন নয়

AI এজেন্ট প্রমাণ সংগ্রহ ও বোঝার পদ্ধতি বদলায়, প্রমাণের নতুন কোনো ধরন তৈরি করে না। অ্যাপ্লিকেশন না চালিয়ে সোর্স পড়লে সেটি নমনীয় ধরনের স্ট্যাটিক রিভিউ করছে। চলমান টার্গেটে অনুরোধ পাঠালে সেটি ডাইনামিক পরীক্ষা করছে। লক্ষ্য অনুসন্ধান করলে, কৌশল বদলালে এবং অপ্রত্যাশিত আচরণ অনুসরণ করলে এটি পেনিট্রেশন টেস্টারের মতো দেখায়, কিন্তু সেই সাদৃশ্য তাকে টেস্টারের কর্তৃত্ব বা ব্যবসায়িক প্রসঙ্গ দেয় না।

কোনো বিক্রেতা যখন বলে তার এজেন্ট «স্ক্যানারের বদলি», তখন এই পার্থক্যটি জরুরি। জিজ্ঞেস করুন, সিস্টেমটি আসলে কী দেখতে পারে। এটি কি পুরো রিপোজিটরি, জেনারেট করা কোড, বিল্ড ফ্ল্যাগ, অবকাঠামো নীতি এবং ডিপেন্ডেন্সি লকফাইল পায়? একাধিক ব্যবহারকারী হিসেবে প্রমাণীকরণ করে প্রতিটি অনুরোধের পর ডেটাবেসের অবস্থা যাচাই করতে পারে? ইন্টারফেসে অনুপস্থিত বলেই নয়, নীতিমালায় কোন কাজ নিষিদ্ধ তা জানে? সুন্দর ব্যাখ্যা অনুপস্থিত ইনপুটের ঘাটতি পূরণ করতে পারে না।

এজেন্ট দুর্বল সংকেত একত্র করতে সত্যিই ভালো। প্রচলিত একটি নিয়ম হয়তো কুয়েরি বিল্ডারে পৌঁছানো অনুরোধ প্যারামিটার চিহ্নিত করবে। এজেন্ট র‌্যাপারটি দেখে লক্ষ্য করতে পারে যে একটি কল সাইটে টেন্যান্ট প্রেডিকেট নেই, পরীক্ষার অনুরোধের খসড়া বানাতে পারে, এবং কেন আপাতদৃষ্টিতে নিরাপদ হেল্পারটি ওই পথে অনিরাপদ তা ব্যাখ্যা করতে পারে। মানটি সত্যিকার প্যারামিটারাইজড API দিয়ে গেলে প্রার্থীটিকে বাদও দিতে পারে। এটি উন্নত ট্রায়াজ, স্ট্যাটিক বা ডাইনামিক বিশ্লেষণ অচল হয়ে গেছে তার প্রমাণ নয়।

স্পষ্ট সীমারেখাটি রিভিউ ও যাচাইয়ের মধ্যে। রিভিউ প্রশ্ন করে, «আমি যে উপাদান দেখতে পাচ্ছি, তাতে এই বাস্তবায়ন কি অনিরাপদ মনে হচ্ছে?» যাচাই প্রশ্ন করে, «নির্দিষ্ট শর্তে এই অভিনেতা কি নিষিদ্ধ ফল ঘটাতে পারে?» AI দুটোতেই সাহায্য করে, তবে নিরাপত্তা গেটে কোন দাবি করা হচ্ছে তা নথিভুক্ত থাকা উচিত। সাবলীল রিভিউ পর্যবেক্ষণকে যাচাইকৃত এক্সপ্লয়েট বানালে, অথবা একবার এক্সপ্লয়েট ব্যর্থ হওয়াকে নিরাপত্তার প্রমাণ ধরলে দল ক্ষতিগ্রস্ত হয়।

মডেলের আচরণে আরেকটি পার্থক্য আছে: সক্ষমতা আর পুনরাবৃত্তিযোগ্যতা এক নয়। একবারের রানে এজেন্ট সূক্ষ্ম পথ খুঁজে পেতে পারে, আবার মডেল, প্রম্পট, রিট্রিভাল ইনডেক্স বা টুল নীতি বদলালে সেটি মিস করতে পারে। ফলটি গুরুত্বপূর্ণ হলে প্রম্পট, টুল অনুমতি, আনা ফাইল, তৈরি করা অনুরোধ এবং মডেল আইডেন্টিফায়ার সংরক্ষণ করুন। তারপর নিশ্চিত আবিষ্কারকে এমন পরীক্ষায় বদলান যার পাসের শর্ত মডেলকে নিজের ধারণা আবার আবিষ্কার করতে বাধ্য করে না।

পুনরাবৃত্তিযোগ্য সোর্স কভারেজে SAST এখনও প্রধান

বড় কোডবেসে প্রতিটি পরিবর্তনে স্থিতিশীল পরীক্ষা চালানোর সবচেয়ে কম খরচের উপায় SAST। এটি সোর্স ও সিঙ্কের তালিকা করতে, নিষিদ্ধ API প্রয়োগ করতে, ডেটা ফ্লো পরীক্ষা করতে এবং যে রিভিশন বিশ্লেষণ করেছে তা জানাতে পারে। নির্ধারক নিয়ম আগামীকালও একই ফল দেয়, আর অডিটযোগ্য কারণে রিলিজ গেটকে পাস বা ফেল করাতে হলে সেটি গুরুত্বপূর্ণ।

এজেন্ট এমন প্রসঙ্গ যোগ করে যা নিয়ম ইঞ্জিনে প্রায়ই থাকে না। এটি প্রকল্পনির্দিষ্ট র‌্যাপার অনুসরণ করতে, মন্তব্যকে সন্দেহের চোখে পড়তে, একটি হ্যান্ডলারকে পাশের হ্যান্ডলারের সঙ্গে তুলনা করতে এবং নতুন প্যাটার্নের জন্য কুয়েরি প্রস্তাব করতে পারে। নয়টি এন্ডপয়েন্ট authorizeProject() কল করলেও দশমটি সরাসরি রেকর্ড লোড করছে, এমন সন্দেহজনক বাদ পড়া বিষয়ও ধরতে পারে। জেনারেট করা কোড বা অপরিচিত ফ্রেমওয়ার্কে সাধারণ নিয়মের প্যাক ব্যর্থ হলেও এটি কাজে লাগে।

তবে এজেন্টের সোর্স কভারেজ প্রমাণ করা সাধারণত কঠিন। কনটেক্সট উইন্ডো, রিট্রিভালের র‌্যাঙ্কিং, উপেক্ষিত ফাইল, জেনারেট করা আর্টিফ্যাক্ট এবং টুল টাইমআউট কোড অপঠিত রেখে যেতে পারে। «ইনজেকশনের জন্য এই রিপোজিটরি রিভিউ করুন» বললে প্রতিটি সিঙ্কে পৌঁছানো হয়েছে, তা প্রমাণ হয় না। SAST রিপোর্ট অন্তত বলতে পারে কোন ফাইল, নিয়ম ও রিভিশন বিশ্লেষণ হয়েছে। বাধ্যতামূলক গেটের দায়িত্ব নিতে হলে এজেন্টেরও সমমানের কভারেজ লেজার দরকার।

NIST SP 800-218 এখানে বাস্তবসম্মত পরামর্শ দেয়: শুরুতেই কোড বিশ্লেষণ ব্যবহার করুন এবং নিরাপত্তা বৈশিষ্ট্য ও প্রতিরোধ ব্যবস্থা হাতে যাচাই করুন। মূল্যটি এই সমন্বয়ে। স্থিতিশীল নিয়ম প্রতি কমিটে পরিচিত ত্রুটির ধরন ধরে, আর এজেন্ট ব্যতিক্রম অনুসন্ধান করে, কেন্দ্রভিত্তিক রিগ্রেশন পরীক্ষা লেখে এবং একই প্যাটার্ন বারবার এলে নিয়ম টিউন করতে সাহায্য করে। এজেন্ট কয়েকটি বুদ্ধিদীপ্ত বাগ পেয়েছে বলে SAST সরালে, মাপা যায় এমন বিস্তৃতির বদলে চমকপ্রদ কিছু ঘটনা বেছে নেওয়া হয়।

SAST এমন কোডও দেখে যেখানে চলমান পরীক্ষা হয়তো কখনও পৌঁছাবে না: ত্রুটির পথ, ফিচার ফ্ল্যাগ, মাইগ্রেশন ইউটিলিটি, নিষ্ক্রিয় অ্যাডমিন এন্ডপয়েন্ট এবং প্ল্যাটফর্মনির্দিষ্ট শাখা। ডিপ্লয় করা পরিবেশ ওই পথগুলো চালু করে কি না, এটি বলতে পারে না। রানটাইম প্রমাণ যোগ করার কারণ এটি, স্ট্যাটিক কভারেজ বাদ দেওয়ার কারণ নয়।

ব্লক করা SAST নিয়মে কী থাকা উচিত তার সীমা আছে। নিষিদ্ধ ক্রিপ্টোগ্রাফিক প্রিমিটিভের নির্ভুল প্যাটার্ন সঙ্গে সঙ্গেই ব্লক করতে পারে। অনুমোদন পরীক্ষা «যথেষ্ট কাছাকাছি দেখায় কি না» এমন বিস্তৃত হিউরিস্টিক সাধারণত রিভিউ টাস্ক হওয়া উচিত, যতক্ষণ না দল তার নির্ভুলতা মাপে। এজেন্ট সত্য উদাহরণ, পাল্টা উদাহরণ ও কোডবেসে প্রচলিত র‌্যাপার ফাংশন সংগ্রহ করে হিউরিস্টিককে নিয়মে উন্নীত করতে সাহায্য করতে পারে। এতে গেট কঠোর থাকে, আবার ডেভেলপারদের সেটি উপেক্ষা করাও শেখায় না।

তৈরি করা সমাধানও ফাইন্ডিংয়ের মতো যাচাই চাই। মডেল ভুল স্তরে ভ্যালিডেশন যোগ করে টেইন্ট ট্রেস চুপ করাতে পারে, এক্সসেপশন ধরে ফেল-ওপেন করতে পারে, অথবা বিপজ্জনক কল বদলাতে গিয়ে আচরণ পাল্টাতে পারে। প্যাচের বিরুদ্ধে মূল প্রমাণ চালান, সাধারণ কার্যকরী পরীক্ষা চালান, এবং যেখানে আস্থা স্থাপিত হয় সেখানে নতুন নিয়ন্ত্রণ রিভিউ করুন। পরিষ্কার রিস্ক্যান শুধু বলে মূল নিয়মটি আর মেলে না।

DAST এমন আচরণ প্রমাণ করে যা রিপোজিটরি দেখাতে পারে না

DAST সত্যি চলা অ্যাপ্লিকেশন দেখে, যার মধ্যে প্রক্সি নিয়ম, হেডার, সিরিয়ালাইজেশন, অথেনটিকেশন মিডলওয়্যার, ফ্রেমওয়ার্কের ডিফল্ট ও ডিপ্লয়মেন্টের ভুলও আছে। সোর্স রিভিউ বলতে পারে একটি এন্ডপয়েন্ট সুরক্ষিত মনে হয়। ডাইনামিক পরীক্ষা দেখাতে পারে গেটওয়ে পথটি নতুন করে লেখায় প্রোডাকশন রুট মিডলওয়্যার এড়িয়ে যায়।

এখানে এজেন্ট ডাইনামিক পরীক্ষাকে অনেক কম ভোঁতা করতে পারে। তাকে API বর্ণনা, পরীক্ষার পরিচয়, অনুমোদিত স্কোপ ও ডিসপোজেবল পরিবেশ দিন, সে সাধারণ পেলোড ছড়ানোর বদলে অনুরোধের ক্রম তৈরি করতে পারে। এক প্রতিক্রিয়ার রিসোর্স আইডেন্টিফায়ার পরেরটিতে নিতে, সেশন নবায়ন করতে, দুটি ভূমিকা তুলনা করতে এবং লেখা পরের রিডে বদল এনেছে কি না দেখতে পারে। সাধারণ DAST প্রায়ই এমন স্টেটফুল ফ্লোতে দুর্বল।

তবু এজেন্টের কঠোর পরিচালন সীমা দরকার। কোনো ক্রলার জানে না ইমেল পাঠানো, শিপমেন্ট তৈরি করা বা পেইড ইন্টিগ্রেশন চালু করা নিরাপদ কি না। পরীক্ষার পরিবেশও বাস্তব সেবায় যুক্ত থাকতে পারে। অনুমোদিত হোস্ট, অ্যাকাউন্ট, অনুরোধের হার, ধ্বংসাত্মক কাজ ও থামার শর্ত মডেলের প্রম্পটের বাইরে নির্ধারণ করুন, তারপর রানারে তা প্রয়োগ করুন। «বিপজ্জনক কাজ এড়িয়ে চলুন» লেখা কোনো নিয়ন্ত্রণ নয়।

নিরাপত্তা হেডার, প্রকাশিত ফাইল, প্রতিফলিত ইনপুট, সাধারণ ইনজেকশন প্রোব ও TLS কনফিগারেশনের মতো সুপরিচিত পরীক্ষার জন্য প্রচলিত ডাইনামিক বেসলাইন রাখুন। এগুলো সস্তা, রিলিজের মধ্যে তুলনাযোগ্য এবং প্রবণতা দেখা সহজ। এজেন্টের বাজেট অনুমোদিত পথ ও যুক্ত আচরণে ব্যয় করুন। দুই সিস্টেম একই সহজ প্রোব করলে, যে সিস্টেমের প্রমাণ পরিষ্কার ও ভ্যারিয়েন্স কম, সেটিই রাখুন।

DAST কেবল যা পৌঁছেছে তা রিপোর্ট করে বলে সম্পূর্ণতার ভুল ধারণাও দিতে পারে। ফলে রুট কভারেজ, ব্যবহৃত পরিচয়, ফিচার ফ্ল্যাগ ও সিড ডেটা ফলাফলের সঙ্গে নথিভুক্ত করুন। প্রায় ফাঁকা অ্যাকাউন্টে পরিষ্কার স্ক্যান এমন অ্যাপ্লিকেশন সম্পর্কে খুব কম প্রমাণ দেয়, যার বিপজ্জনক শাখা কেবল অনুমোদন, আমন্ত্রণ, বিলিং বা ডেটা ইমপোর্টের পরে আসে।

অথেনটিকেশন সেটআপের নিজস্ব প্রমাণ দরকার। প্রতিটি সেশন কীভাবে পাওয়া হয়েছে, পরীক্ষার পরিবেশে কোন দ্বিতীয় ফ্যাক্টর বা ডিভাইস পরীক্ষা বাইপাস হয়েছে, এবং টোকেনের ক্লেইম ও মেয়াদ প্রোডাকশন টোকেনের মতো কি না লিখুন। হাতে বানানো অ্যাডমিনিস্ট্রেটর টোকেন কার্যকর কভারেজ খুলে দিতে পারে, আবার ঠিক যে সেশন ও ক্ষমতা পরিবর্তন পরীক্ষা করা দরকার তা এড়িয়ে যেতে পারে। রিপোর্টে এমন শর্টকাট দৃশ্যমান রাখুন।

ডাইনামিক পুনঃপরীক্ষা নতুন স্বয়ংক্রিয় ক্রল দিয়ে নয়, সংরক্ষিত অনুরোধের ক্রম দিয়ে শুরু করুন। প্যাচ করা বিল্ডের বিরুদ্ধে নিশ্চিত প্রমাণটি আবার চালান, নিষিদ্ধ প্রভাব থেমেছে কি না যাচাই করুন, তারপর পাশের ইনপুট বদলে সরু ফিল্টার আছে কি না দেখুন। এরপর এজেন্টকে অনুসন্ধান করতে দিন। এই ক্রম «সমাধানটি পরিচিত এক্সপ্লয়েট ঠেকায়» এবং ত্রুটির পুরো শ্রেণি সরানো হয়েছে এমন বড় দাবিকে আলাদা রাখে।

অনুমোদন পরীক্ষায় পরিচয় ও নিষিদ্ধ ফলাফল দরকার

অনুমোদন মানে «এন্ডপয়েন্ট একবার 403 দিয়েছে» নয়। কার্যকর পরীক্ষায় কে কাজ করে, কোন অবজেক্ট লক্ষ্য করে, কোন অপারেশন চেষ্টা করে এবং কোন ফল অসম্ভব থাকতে হবে তা বলা থাকে। এজেন্ট সমন্বয়গুলো তৈরি করতে পারে, কিন্তু পণ্যের মালিক ও নিরাপত্তা রিভিউয়ারকে নীতিমালা দিতে হবে।

OWASP ASVS বলে অ্যাপ্লিকেশনকে বিশ্বস্ত সার্ভিস স্তরে অ্যাক্সেস কন্ট্রোল প্রয়োগ করতে হবে এবং ফাংশন ও ডেটায় সর্বনিম্ন প্রয়োজনীয় ক্ষমতা দিতে হবে। সার্ভিস স্তরের কথাটিতে আমি একমত, কিন্তু দল প্রায়ই এটি খুব সংকীর্ণভাবে যাচাই করে। তারা দৃশ্যমান HTTP হ্যান্ডলার পরীক্ষা করে, আর ব্যাকগ্রাউন্ড জব, এক্সপোর্ট, সার্চ ইনডেক্স, ওয়েবসকেট সাবস্ক্রিপশন ও সরাসরি অবজেক্ট স্টোরেজ URL ভুলে যায়। অবজেক্টে পৌঁছানোর প্রতিটি পথে একই নীতি টিকতে হবে।

ছোট একটি এক্সিকিউটেবল ম্যাট্রিক্স «IDOR পরীক্ষা করুন» ধরনের অস্পষ্ট নির্দেশনার চেয়ে বেশি প্রকাশ করে। নিচের শেল অংশটি ডিসপোজেবল পরিবেশ, দুটি bearer token এবং ব্যবহারকারী A-এর মালিকানাধীন একটি নথি ধরে নেয়। এটি স্ট্যাটাস এবং B-এর প্রতিক্রিয়ায় A-এর গোপন চিহ্ন না থাকার বিষয়টি পরীক্ষা করে:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

প্রত্যাশিত আউটপুট হলো নীরবতা এবং শূন্য এক্সিট স্ট্যাটাস। CI ব্যর্থতায় স্ট্যাটাস, স্যানিটাইজ করা বডি, কাজ করা পরিচয়, টার্গেটের মালিক, রুট এবং বিল্ড রিভিশন রাখা উচিত। লাইভ ক্রেডেনশিয়াল বা অপ্রাসঙ্গিক প্রতিক্রিয়া ডেটা রাখবেন না।

এবার একবারে একটি মাত্রা বদলান: রিড বনাম আপডেট, সরাসরি ID বনাম সার্চ, সক্রিয় বনাম বাতিল সদস্যপদ, সাধারণ রুট বনাম এক্সপোর্ট, এবং ব্যবহারকারী টোকেন বনাম সার্ভিস টোকেন। এজেন্ট এসব কেস দক্ষতার সঙ্গে তৈরি ও চালাতে পারে। একজন মানুষকে রিভিউ করতে হবে ম্যাট্রিক্স নীতির সঙ্গে মেলে কি না এবং 404, 403, ফাঁকা ফল বা সম্পাদিত অবজেক্টের মধ্যে কোনটি প্রত্যাশিত। তা না হলে এজেন্ট এমন আচরণে সাফল্য উদযাপন করতে পারে যেটিকে ব্যবসা লঙ্ঘন বলে।

নেতিবাচক প্রমাণে সতর্কতা দরকার। অস্বীকৃত আপডেটও প্রতিক্রিয়ার সময়, ত্রুটির লেখা বা সংস্করণ কাউন্টারের মাধ্যমে অবজেক্টের অস্তিত্ব জানাতে পারে। অস্বীকৃত রিড ভিউ কাউন্ট বাড়াতে পারে বা গোপন মেটাডেটাসহ অডিট রেকর্ড লিখতে পারে। কোন পার্শ্বপ্রতিক্রিয়া অনুমোদিত তা ঠিক করুন, তারপর তা অ্যাসার্ট করুন। শুধু প্রতিক্রিয়া দেখা নিরাপত্তা পরীক্ষা কার্যকর এনিউমারেশন চ্যানেল বা ক্ষতিকর লেখা মিস করতে পারে।

সেশনের মধ্যে নীতি পরিবর্তনও পরীক্ষা করুন। কাউকে প্রকল্প থেকে সরান, মালিকানা বদলান, অ্যাকাউন্ট বন্ধ করুন বা সার্ভিস ভূমিকা সীমিত করুন, তারপর পুরনো টোকেন ও খোলা সংযোগ আবার ব্যবহার করুন। প্রত্যাশিত বাতিলের সময় পণ্যের নীতি থেকে আসতে হবে। «একসময়» পরীক্ষা করা যায় না, তাৎক্ষণিক বাতিলও সব সময় দরকার নাও হতে পারে, কিন্তু দলকে একটি সীমা বেছে নিয়ে API অনুরোধ, কিউ করা কাজ, ডাউনলোড ও লাইভ সাবস্ক্রিপশনে তা যাচাই করতে হবে।

টেন্যান্ট আইসোলেশন স্পষ্ট অনুরোধ পথের বাইরেও ভাঙে

টেন্যান্ট আইসোলেশন স্টোরেজ, ক্যাশ, কিউ, সার্চ, ফাইল, অ্যানালিটিক্স ও প্রশাসনিক সীমায় পরীক্ষা চাই। সাধারণ ব্যর্থতা প্রধান তালিকা এন্ডপয়েন্টে tenant_id না থাকা নয়। এটি এমন গৌণ পথ, যা টেন্যান্ট প্রসঙ্গ না নিয়ে ডেটা কপি, ইনডেক্স, ক্যাশ বা এক্সপোর্ট করে।

ইচ্ছাকৃতভাবে মিল আছে এমন রেকর্ড এবং প্রত্যেকটির একটিমাত্র স্পষ্ট চিহ্ন দিয়ে দুটি টেন্যান্ট শুরু করুন। আলাদা ব্যবহারকারী, আলাদা সেশন এবং আর্কিটেকচার অনুমতি দিলে আলাদা সার্ভিস ক্রেডেনশিয়াল ব্যবহার করুন। তৈরি, পড়া, আপডেট, মুছা, তালিকা, সার্চ, এক্সপোর্ট, ইমপোর্ট, অ্যাটাচমেন্ট অ্যাক্সেস, নোটিফিকেশন ডেলিভারি ও ব্যাকগ্রাউন্ড প্রসেসিং চালান। প্রতিটি কাজের পর ব্যবহারকারীর দেখা প্রতিক্রিয়া ও স্থায়ী অবস্থা পরীক্ষা করুন। প্রত্যাখ্যাত অনুরোধও যদি অন্য টেন্যান্টের জব কিউতে ঢোকায়, সেটি ব্যর্থতা।

এজেন্ট সাহায্য করে, কারণ এটি স্তরের মধ্য দিয়ে আইডেন্টিফায়ার অনুসরণ করতে এবং মানুষের কাছে ক্লান্তিকর বিভিন্ন সমন্বয় তৈরি করতে পারে। এটি লক্ষ্য করতে পারে ক্যাশ কী শুধু document_id ব্যবহার করে, অথচ ডেটাবেস কুয়েরি tenant_id ও document_id দুটোই ব্যবহার করে। ইন্টারঅ্যাকটিভ হ্যান্ডলারের সঙ্গে এক্সপোর্ট ওয়ার্কার মিলিয়ে কেন কেবল একটি রো-লেভেল প্রসঙ্গ সেট করে তা প্রশ্ন করতে পারে। এগুলো মূল্যবান রিভিউ পদক্ষেপ।

তবে তারা বিপজ্জনক একটি অনুমানও করে: নামই সীমা বোঝায়। getTenantDocument নামের ফাংশন অনুরোধ থেকে আসা যেকোনো টেন্যান্ট আর্গুমেন্ট নিতে পারে। ডেটাবেস নীতি মাইগ্রেশনে থাকতে পারে, কিন্তু নতুন টেবিলে নাও থাকতে পারে। ফল গণনার পর সার্চ ফিল্টার প্রয়োগ হতে পারে, যা অন্য টেন্যান্টের কার্যকলাপ ফাঁস করে। যাচাইয়ে প্রয়োগ করা প্রেডিকেট দেখতে হবে, তারপর টেন্যান্ট পার হয়ে রিড ও রাইটের চেষ্টা করতে হবে।

এজেন্টকে সে যে কোড পরীক্ষা করছে সেটি পড়িয়ে নিজের ওরাকল বানাতে দেবেন না। পণ্যের চাহিদার সঙ্গে রক্ষিত স্বাধীন নীতিমালা টেবিল থেকে প্রত্যাশিত অ্যাক্সেস নির্ধারণ করুন। বাস্তবায়ন ও পরীক্ষা একই নিয়ম ভুল বুঝলে, ডেটা ফাঁস করেও তারা নিখুঁতভাবে একমত হবে।

অ্যাসিঙ্ক্রোনাস পথে বিলম্বিত অ্যাসারশন দরকার। টেন্যান্ট A হিসেবে এক্সপোর্ট, নোটিফিকেশন, থাম্বনেইল বা ইনডেক্সিং জব চালু করুন, ওয়ার্কার চলার আগে মালিকানা বা সদস্যপদ বদলান, তারপর ফল কোথায় যায় দেখুন। ওয়ার্কারের অনুরোধের সময় ধরা কর্তৃত্ব ব্যবহার করা উচিত, নাকি চালানোর সময় বর্তমান কর্তৃত্ব আবার পরীক্ষা করা উচিত তা ঠিক করুন। নির্দিষ্ট কাজের জন্য দুটো সিদ্ধান্তই সঠিক হতে পারে, কিন্তু অনিচ্ছাকৃত মিশ্রণ ফাঁস ও ভাঙা অডিট ট্রেইল তৈরি করে।

প্রশাসনিক টুলের জন্য আলাদা পরিচয় ও লগিং অ্যাসারশন দরকার। সাপোর্ট অ্যাক্সেস নকশাগতভাবেই টেন্যান্ট সীমা অতিক্রম করে, তাই «ভিন্ন টেন্যান্ট হলে ব্যর্থ হবে» নিয়মটি ভুল। পরীক্ষা করুন অপারেটরের প্রয়োজনীয় ভূমিকা ও কেস প্রসঙ্গ আছে কি না, গ্রাহকের দৃশ্যমান নীতি মানা হচ্ছে কি না, অ্যাক্সেসের মেয়াদ শেষ হয় কি না, এবং অডিট ইভেন্ট অপারেটরকে চিহ্নিত করে কি না, গ্রাহকের ছদ্মবেশ নেয় কি না।

ব্যবসায়িক লজিকে অপব্যবহারের গল্প দরকার

ব্যবসায়িক-লজিক পরীক্ষা নিষিদ্ধ গল্প দিয়ে শুরু হয়: কোনো ব্যবহারকারী অবৈধ ক্রম বা সমন্বয়ে বৈধ কাজ করে এমন মূল্য, কর্তৃত্ব বা অবস্থা পায় যা তার পাওয়ার কথা নয়। সাধারণ দুর্বলতার লেবেল যথেষ্ট নয়। পরীক্ষককে জানতে হবে আমন্ত্রণ, অনুমোদন, কোটার সীমা, ফেরত, ক্রেডিট, মালিকানা হস্তান্তর ও বাতিল কীভাবে একে অপরের সঙ্গে কাজ করবে।

OWASP Web Security Testing Guide পরীক্ষককে বাদ দেওয়া কর্মপ্রবাহ ধাপ, বারবার করা ফাংশন, জাল অনুরোধ, সময়ের পরিবর্তন ও বৈধ বৈশিষ্ট্যের অপব্যবহার চেষ্টা করতে বলে। এর পুরোনো ব্যবসায়িক-লজিক পরিচিতি সরাসরি বলেছিল, স্ক্যানার অটোমেশন অ্যাপ্লিকেশননির্দিষ্ট জ্ঞান বা সৃজনশীলতা দিতে পারে না। আধুনিক এজেন্ট অটোমেশন উন্নত করে, কিন্তু জ্ঞানের ঘাটতি সরায় না। মডেল বলতে পারে কুপন পুনর্ব্যবহারযোগ্য হতে পারে, কিন্তু কেউ নিয়ম না বললে এটি প্রচার নাকি জালিয়াতি তা জানে না।

এজেন্টকে অনুমোদিত ট্রানজিশন ও ইনভেরিয়্যান্টসহ স্টেট মডেল দিন। অনুমোদন ফ্লোতে একটি ইনভেরিয়্যান্ট হতে পারে, «মালিকানা বদলের পরও অনুরোধকারী নিজের পেমেন্ট অনুমোদন করতে পারবে না।» এরপর ভূমিকা বদল, ডুপ্লিকেট অনুরোধ, বাতিল, পুনরায় চেষ্টা, সমকালীনতা ও পুরোনো সেশন জড়ানো ক্রম তৈরি করতে বলুন। মানুষ হাতে যতগুলো ক্রম চালাবে, এজেন্ট তার চেয়ে অনেক বেশি অনুসন্ধান করতে পারে।

কঠিন কেসগুলো HTTP প্রতিক্রিয়ার বাইরের পরিণতি নিয়ে। দুটি সমকালীন রিডেম্পশন অনুরোধই সফল ফিরতে পারে, পরে রিকনসিলিয়েশন একটি সরিয়ে দিতে পারে। বাতিল দৃশ্যমান জব থামাতে পারে, কিন্তু সই করা ডাউনলোড বাতিল নাও করতে পারে। আমন্ত্রণকারী অ্যাক্সেস হারানোর পর গ্রহণ করা আমন্ত্রণ অনাথ সদস্যপদ তৈরি করতে পারে। পরীক্ষায় শুধু স্ট্যাটাস কোড নয়, লেজার, কিউ, অবজেক্ট অনুমতি ও পরের অবস্থা দেখতে হবে।

মানবীয় পরীক্ষক ঘোষিত মডেলকে চ্যালেঞ্জ করে গুরুত্বপূর্ণ ভূমিকা রাখেন। তারা জিজ্ঞেস করেন সাপোর্ট কর্মী নিরীহ ফাংশন জোড়া লাগাতে পারেন কি না, অপারেটর নিজের অডিট ট্রেইলে প্রভাব ফেলতে পারেন কি না, অথবা «মেয়াদ শেষ» অবজেক্ট অন্য চ্যানেলে ব্যবহারযোগ্য থাকে কি না। এজেন্ট তাকে দেওয়া লক্ষ্য ও টুলের মধ্যেই কাজ করে। মানুষ বুঝতে পারেন ব্যবসার লক্ষ্যেই বিপজ্জনক অংশ বাদ পড়েছে।

ডিপেন্ডেন্সি ঝুঁকি শুধু দুর্বল সংস্করণ নয়

ডিপেন্ডেন্সি পরীক্ষার চারটি আলাদা প্রশ্ন আছে: কোন প্যাকেজ আছে, তাদের পরিচিত সংস্করণে রিপোর্ট করা দুর্বলতা আছে কি না, বিল্ডে প্রত্যাশিত আর্টিফ্যাক্ট এসেছে কি না, এবং অ্যাপ্লিকেশন সত্যিই দুর্বল আচরণ উন্মুক্ত করে কি না। সফটওয়্যার কম্পোজিশন অ্যানালাইসিস (SCA) ও প্রোভেন্যান্স নিয়ন্ত্রণ কথোপকথনভিত্তিক রিভিউয়ের চেয়ে প্রথম তিনটির উত্তর বেশি নির্ভরযোগ্যভাবে দেয়।

ইনভেন্টরি হওয়ার পর এজেন্ট উপকারী। এটি ডিপেন্ডেন্সি কীভাবে কল হয় দেখতে পারে, প্রভাবিত ফাংশন রিচেবল কি না নির্ধারণ করতে পারে, ক্ষতিপূরণমূলক নিয়ন্ত্রণ খুঁজতে পারে এবং রিগ্রেশন পরীক্ষাসহ আপগ্রেড প্যাচের খসড়া বানাতে পারে। ইনস্টল স্ক্রিপ্ট নেটওয়ার্ক অ্যাক্সেস পাওয়া বা নতুন লাইব্রেরি পরিবেশে সিক্রেট পাওয়া, এমন ঝুঁকিপূর্ণ প্যাকেজ আচরণও এটি চিহ্নিত করতে পারে যার কোনো দুর্বলতা আইডেন্টিফায়ার নেই।

মডেলকে বর্তমান দুর্বলতার ডেটা মনে করতে বলবেন না। তাকে সময়চিহ্নিত অ্যাডভাইজরি সোর্স, সমাধান করা লকফাইল ও বিল্ট আর্টিফ্যাক্ট ইনভেন্টরি দিন। মডেলের স্মৃতি দুর্বলতার ডেটাবেস নয়, এবং প্যাকেজ ম্যানিফেস্ট কী পাঠানো হয়েছে তার প্রমাণ নয়। SLSA প্রোভেন্যান্স সংশ্লিষ্ট একটি পার্থক্য করে: প্রোভেন্যান্স বলে আর্টিফ্যাক্ট কোথায়, কখন ও কীভাবে তৈরি হয়েছে। এটি আর্টিফ্যাক্ট নিরাপদ বলে না।

রিচেবিলিটি ট্রায়াজের অগ্রাধিকার কমাতে পারে, কিন্তু মালিকানা মুছবে না। ফিচার ফ্ল্যাগ বদলায়, মৃত কোড ফিরে আসে, এবং পরোক্ষ ডিপেন্ডেন্সি অপ্রত্যাশিতভাবে কল হয়। কেন ফাইন্ডিং পিছিয়েছে, কোন সংস্করণ ও কল পথ মূল্যায়িত হয়েছে, এবং কোন ঘটনা তা আবার খুলবে লিখে রাখুন। এজেন্ট সেই যুক্তি বজায় রাখতে পারে, আর নির্ধারক ইনভেন্টরি ঘটনাটির জন্য নজর রাখে।

প্যাকেজের নামেও পরিচয়ের ফাঁদ আছে। প্রত্যাশিত নামের ডিপেন্ডেন্সি ভুল রেজিস্ট্রি থেকে আসতে পারে, লকফাইল পরিবর্তনযোগ্য স্থানে নির্দেশ করতে পারে, অথবা বিল্ড ধাপ ম্যানিফেস্টে না থাকা কোড ডাউনলোড করতে পারে। সমাধান করা সোর্স, হ্যাশ, ইকোসিস্টেম সমর্থন করলে সিগনেচার এবং বিল্ডের নেটওয়ার্ক অ্যাক্সেস পরীক্ষা করুন। এজেন্ট অমিল ব্যাখ্যা করতে পারে, কিন্তু কোন সোর্স গ্রহণ করবে তা বিল্ড সিস্টেমকে প্রয়োগ করতে হবে।

আপগ্রেড আপনাআপনি নিরাপদ পরিবর্তন নয়। নিরাপত্তা রিলিজ পার্সিং, অনুমোদনের ডিফল্ট বা সিরিয়ালাইজেশন এমনভাবে বদলাতে পারে যা অ্যাপ্লিকেশন ভাঙে। অ্যাডভাইজরির জন্য ন্যূনতম পুনরুৎপাদন তৈরি করুন, বিচ্ছিন্ন শাখায় আপগ্রেড প্রয়োগ করুন, তারপর নিরাপত্তার প্রমাণ ও কার্যকরী পরীক্ষা দুটোই চালান। ফলে পাওয়া প্রমাণ সিদ্ধান্তে সহায়তা করে, নতুন সংস্করণ «সামঞ্জস্যপূর্ণ হওয়ার কথা» বলে মডেলের মন্তব্য তা করে না।

ভুল পজিটিভ আসলে প্রমাণ নকশার সমস্যা

কোনো ফাইন্ডিং ডেভেলপারের সময়ের যোগ্য হয় তখনই, যখন তাতে দাবি, প্রমাণ, প্রভাব ও পুনরুৎপাদনযোগ্য পথ থাকে। AI-তৈরি রিপোর্টে প্রায়ই এই অংশগুলোর একটি না থাকলেও তা সম্পূর্ণ শোনায়। সাবলীল সমাধান লেখা দুর্বল প্রমাণ ধরা আরও কঠিন করে।

প্রতিটি এজেন্ট ফাইন্ডিংয়ে বিশ্লেষিত রিভিশন ও পরিবেশ, প্রভাবিত কম্পোনেন্ট, আক্রমণকারীর পূর্বশর্ত, অতিক্রান্ত নিরাপত্তা সীমা, দেখা বা অনুমান করা ফল, পুনরুৎপাদনের ধাপ এবং অনিশ্চয়তা চিহ্নিত করতে বলুন। অনুমানভিত্তিক সোর্স ফাইন্ডিংকে চালানো এক্সপ্লয়েটের চেয়ে আলাদাভাবে চিহ্নিত করুন। এজেন্ট অ্যাপ্লিকেশন চালাতে না পারলে ফাইন্ডিংয়েই তা বলবে, স্ক্যান স্তরের নোটে সীমাবদ্ধতা লুকাবে না।

তারপর সহজ একটি সিদ্ধান্তভাষা ব্যবহার করুন: নিশ্চিত, সম্ভাব্য, প্রসঙ্গ দরকার, পুনরুৎপাদনযোগ্য নয়, গৃহীত ঝুঁকি, বা সমাধান হয়েছে। «ভুল পজিটিভ» মানে নিরাপত্তা দাবিটি ভুল, দল তীব্রতা অপছন্দ করেছে বা কাজ পিছিয়েছে তা নয়। এসব সিদ্ধান্ত মেশালে প্রতিক্রিয়া নষ্ট হয়। প্রতিটি অনাকাঙ্ক্ষিত টিকিটে একই লেবেল দিলে এজেন্ট জানতে পারে না কোন নিয়ম ব্যর্থ হয়েছে।

AI ডুপ্লিকেট ট্রেস গুচ্ছবদ্ধ করে, স্যানিটাইজার পরীক্ষা করে এবং সমাধানের পর পুনঃপরীক্ষা চালিয়ে শব্দ কমাতে পারে। আবার একটি দুর্বল সন্দেহের দশটি বিশ্বাসযোগ্য রূপ বানিয়ে শব্দ বাড়াতেও পারে। URL দিয়ে নয়, মূল কারণ ও সীমা দিয়ে ডুপ্লিকেট সরান। আটটি এন্ডপয়েন্টে ব্যবহৃত একটি অনুপস্থিত মালিকানা পরীক্ষা আটটি এক্সপোজার পয়েন্টসহ একটি ইঞ্জিনিয়ারিং ত্রুটি।

বিভাগ ও পরীক্ষার সোর্স অনুযায়ী নির্ভুলতা ট্র্যাক করুন। এজেন্ট তৈরি করা cross-site scripting রিপোর্ট সাধারণত বৈধ হলেও race-condition দাবি খুব কম পুনরুৎপাদিত হলে, সেগুলো আলাদা পথে পাঠান। সম্পর্কহীন ত্রুটির ধরন এক স্কোরে নামিয়ে আনবেন না। গেট মডেলের আত্মবিশ্বাস বিশেষণের ভিত্তিতে নয়, প্রমাণ ও নীতিমালার ভিত্তিতে ফেল করবে।

মালিকানা চক্রটি সম্পূর্ণ করে। প্রতিটি গৃহীত ফাইন্ডিংয়ের জন্য সমাধানের দায়িত্বে একজন ব্যক্তি বা দল, প্রত্যাশিত পুনঃপরীক্ষা পদ্ধতি এবং অন্য পরীক্ষক চালাতে পারেন এমন সংরক্ষিত প্রমাণ দরকার। রিপোর্ট কেবল এজেন্টের কথোপকথনে থাকলে, কথোপকথন, মডেল বা বিক্রেতা বদলালে তা হারিয়ে যাবে। যে টুল প্রমাণ তৈরি করেছে তার বাইরেও প্রমাণ টিকে থাকলে নিরাপত্তার কাজ স্থায়ী হয়।

ট্রায়াজে গোপনীয়তাও গুরুত্বপূর্ণ। সোর্স, অনুরোধের বডি, লগ ও ডেটাবেস নমুনায় ক্রেডেনশিয়াল বা গ্রাহকের ডেটা থাকতে পারে। এজেন্ট যা পায় তা কমান, সংরক্ষিত ট্রান্সক্রিপ্ট থেকে সংবেদনশীল অংশ মুছুন, প্রোডাকশন ডেটা থেকে পরীক্ষার ডেটা আলাদা রাখুন এবং মডেল প্রদানকারী ও তার টুলে প্রতিষ্ঠানের অনুমোদিত ডেটা ব্যবহারের নিয়ম প্রয়োগ করুন। ভালো শনাক্তকরণ কোনো নিয়ন্ত্রণহীন প্রম্পটে পুরো প্রোডাকশন ইনসিডেন্ট কপি করার অনুমতি দেয় না।

মানবীয় পেনিট্রেশন টেস্ট পরীক্ষার চারপাশের অনুমানগুলো পরীক্ষা করে

দক্ষ পেনিট্রেশন টেস্টার অ্যাপ্লিকেশন ব্রিফের সঙ্গে বিরোধ করলে পরিকল্পনা বদলান। এজেন্ট এই জায়গাটি এখনও প্রতিস্থাপন করতে পারেনি। মানুষ মালিকদের সাক্ষাৎকার নেন, অস্পষ্ট নিয়ম মেটান, অপারেশনাল শর্টকাট লক্ষ্য করেন, আরেকটি পরিচয় চান এবং অদ্ভুত আচরণে দীর্ঘ পরীক্ষার শৃঙ্খল দরকার কি না ঠিক করেন।

অসম্পূর্ণ প্রমাণে বিচারবোধের দায়ও মানুষের। তারা টেকনিক্যালি সম্ভব কাজ ও বিশ্বাসযোগ্য আক্রমণপথ আলাদা করতে পারেন, যৌগিক ব্যর্থতা নির্বাহী ও প্রকৌশলীদের বোঝাতে পারেন, এবং এক্সপ্লয়েট করলে ডেটা ক্ষতি হতে পারে এমন অবস্থায় নিরাপদ প্রমাণ নিয়ে সমঝোতা করতে পারেন। স্বয়ংক্রিয় এজেন্টকে অপারেটর নির্ধারিত সীমায় থামতে হবে। নীরবে সে সীমা বাড়ালে, সেটিই আরেকটি নিরাপত্তা ঝুঁকি।

এর অর্থ প্রতিটি রিলিজে সপ্তাহব্যাপী বাহ্যিক কাজ দরকার নয়। যেখানে পরিবর্তন ও পরিণতি মেলে সেখানে মানবীয় পরীক্ষা ব্যবহার করুন: নতুন অনুমোদন মডেল, টেন্যান্ট আর্কিটেকচার, পেমেন্ট বা ক্রেডিট ফ্লো, প্রশাসনিক ক্ষেত্র, সংবেদনশীল ইন্টিগ্রেশন, বড় মাইগ্রেশন বা পাবলিক লঞ্চ। ঝুঁকি অনুযায়ী বিস্তৃত পর্যায়ক্রমিক কাজ নির্ধারণ করুন এবং গুরুতর সমাধান আবার পরীক্ষা করুন। নিয়মিত রিলিজেও স্বয়ংক্রিয় কভারেজ দরকার।

টেস্টারকে এজেন্টের আউটপুট, SAST ট্রেস, DAST কভারেজ, আর্কিটেকচার নোট, পরীক্ষার অ্যাকাউন্ট ও অমীমাংসিত অনুমান দিন। এজেন্ট রিকনেসাঁ ও পুনরাবৃত্ত ভিন্নতা সামলাতে পারে, আর টেস্টার বিস্ময়কর আচরণ অনুসরণ করেন। এতে মানুষের সময় বেশি ফলপ্রসূ হয়, কিন্তু সেটি অপ্রয়োজনীয় এমন ভান করা হয় না।

ফাইন্ডিংয়ের সংখ্যা দিয়ে মাপা «স্বয়ংক্রিয় পেনটেস্ট» দাবিতে সতর্ক থাকুন। পরিচিত ইনজেকশনের দশটি ফাইন্ডিং ভূমিকা বরাদ্দ, পুরোনো অনুমোদন ও এক্সপোর্ট স্টোরেজ পেরিয়ে দেখানো একটি পথের সমান নয়। পরীক্ষা করা সীমা, প্রমাণের মান ও চ্যালেঞ্জ করা গুরুত্বপূর্ণ অনুমান দিয়ে কাজ বিচার করুন।

কাজ শুরুর আগে পরিষ্কারের দায়িত্ব কার তা জিজ্ঞেস করুন। পরীক্ষার অ্যাকাউন্ট, আপলোড করা ফাইল, কিউ করা বার্তা, অস্থায়ী ভূমিকা ও বদলানো ফিচার ফ্ল্যাগ স্ক্যানের পরও থেকে যেতে পারে। মানবীয় লিড ধ্বংসাত্মক প্রমাণ অনুমোদন করবেন, অপারেশনের সঙ্গে যোগাযোগ রাখবেন এবং পুনরুদ্ধার যাচাই করবেন। এজেন্ট ক্লিনআপ স্ক্রিপ্ট অনুসরণ করতে পারে, কিন্তু ব্যাখ্যাহীন প্রোডাকশন অবস্থা মুছে ফেলা নিরাপদ কি না ঠিক করতে পারে না।

ভালো টেস্টার কী পরীক্ষা করা যায়নি তাও জানান। অনুপস্থিত মোবাইল বিল্ড, অপ্রাপ্য ভূমিকা, রেট সীমা, তৃতীয় পক্ষের কলব্যাক ও অস্থির পরিবেশ নিশ্চয়তা কমায়। এজেন্ট বাধা এড়িয়ে কাজ চালিয়ে যায় এবং শেষ করা পথগুলো উপস্থাপন করে। চূড়ান্ত রিপোর্টে বাদ পড়া বিষয় স্পষ্ট থাকতে হবে, যেন পরিষ্কার ফলকে সম্পূর্ণ কভারেজ মনে না করা হয়।

নানা ধরনের প্রমাণ থেকে একটি গেট তৈরি করুন

সঠিক কর্মসূচি প্রতিটি পদ্ধতিকে আলাদা কাজ দেয় এবং তাদের আউটপুট একই নিরাপত্তা চাহিদায় মিলিয়ে দেয়। নির্ধারক সোর্স প্যাটার্ন ও বিস্তৃত পরিবর্তন কভারেজে SAST ব্যবহার করুন। ডিপেন্ডেন্সি ও বিল্ডের তথ্যের জন্য SCA এবং প্রোভেন্যান্স ব্যবহার করুন। ডিপ্লয় করা আচরণ ও বেসলাইন রানটাইম পরীক্ষায় DAST ব্যবহার করুন। প্রমাণ সংযুক্ত করা, অনুমোদিত ফ্লো অনুসন্ধান, পরীক্ষা তৈরি ও ট্রায়াজ উন্নত করতে এজেন্ট ব্যবহার করুন। নীতি নির্ধারণ, ব্যবসায়িক অনুমান প্রশ্ন করা এবং গুরুতর পরিণতির পরিবর্তন অনুসন্ধানে মানুষ ব্যবহার করুন।

তারপর রিলিজ নীতি নির্দিষ্ট হতে পারে। নির্ধারক উচ্চ-তীব্রতার নিয়ম অননুমোদিত পথে মিললে, প্রয়োজনীয় অনুমোদন ইনভেরিয়্যান্ট ব্যর্থ হলে, টেন্যান্ট পার হয়ে চিহ্ন দেখা গেলে, বা নিশ্চিত এক্সপ্লয়েট খোলা থাকলে বিল্ড ব্লক করুন। অনিশ্চিত এজেন্ট ফাইন্ডিং এক্সপোজার অনুযায়ী সময়সীমাসহ রিভিউতে পাঠান। মডেলের নিজের বলা আত্মবিশ্বাসকে প্রোডাকশন পাঠানোর সিদ্ধান্ত নিতে দেবেন না।

প্রমাণ বহনযোগ্য রাখুন। ফাইন্ডিং, তৈরি করা পরীক্ষা, অনুরোধের ট্রান্সক্রিপ্ট, টুল সংস্করণ, রিভিশন, পরিচয়, কভারেজ ও সিদ্ধান্ত এমন ফরম্যাটে এক্সপোর্ট করুন যা এজেন্ট ছাড়াই দল পরীক্ষা করতে পারে। অডিট, ইনসিডেন্ট রিভিউ, বিক্রেতা বদল ও সাধারণ সেই দিনের জন্যও এটি দরকার, যেদিন মডেল আপডেটে আচরণ বদলে যায়।

চ্যাটে তৈরি অ্যাপ্লিকেশনের ক্ষেত্রেও একই বিভাজন প্রযোজ্য। Koder.ai ওয়েব, সার্ভার ও মোবাইল অ্যাপ্লিকেশন তৈরি করতে এবং তাদের সোর্স এক্সপোর্ট করতে পারে, কিন্তু তৈরি করা সফটওয়্যারেরও স্পষ্ট নিরাপত্তা চাহিদা ও ডিপ্লয় করা ফলের বিরুদ্ধে স্বাধীন পরীক্ষা দরকার। দ্রুত তৈরি হলে স্পষ্ট গেট আরও উপকারী হয়, কারণ আর্কিটেকচার ও কোড দ্রুত বদলাতে পারে।

এজেন্টকে অবিরাম চালান, তবে তার সেরা আবিষ্কারগুলোকে নির্ধারক রিগ্রেশন পরীক্ষায় উন্নীত করুন। প্রতিটি নিশ্চিত অনুমোদন বাইপাস নীতিমালার কেস হবে। প্রতিটি টেন্যান্ট ফাঁস ব্যর্থ সীমায় একটি ইনভেরিয়্যান্ট যোগ করবে। প্রতিটি শব্দপূর্ণ নিয়মে নথিভুক্ত সিদ্ধান্ত যোগ হবে। সময়ের সঙ্গে এজেন্টের উচিত তার পাওয়া পরীক্ষাব্যবস্থাকে আরও নির্ভুল করে রেখে যাওয়া।

কোন একক টুল জেতে তা জিজ্ঞেস করবেন না। জিজ্ঞেস করুন প্রতিটি গুরুত্বপূর্ণ দাবির স্বাধীন প্রমাণ আছে কি না: কোড পথ রিভিউ হয়েছে, ডিপ্লয় করা আচরণ চালানো হয়েছে, ব্যবসার নিয়ম মালিকের কাছ থেকে এসেছে, এবং ব্যর্থতা ক্ষতিকর হলে একজন মানুষ অনুমানগুলোকে প্রশ্ন করেছেন। এই লাইনগুলোর একটি ফাঁকা থাকলে AI-তৈরি «সব ঠিক আছে» তা পূরণ করে না।