AI-এর security patch সরাসরি merge নয়—৭ ধাপে false fix ধরুন

AI-তৈরি security fix-কে সম্পন্ন সমাধান নয়, candidate patch হিসেবে নিন। Production-এ নেওয়ার আগে একই revision-এ finding পুনরুৎপাদন, বিচ্ছিন্ন পরিবেশে patch প্রয়োগ, পুনরায় scan, exploit replay, regression test, মানব পর্যালোচনা এবং পরীক্ষিত rollback—সাতটি gate-এর প্রতিটির প্রমাণ সংরক্ষণ করুন।

Merge-এর শর্ত কেবল পুরোনো finding অদৃশ্য হওয়া নয়। মূল exploit ব্যর্থ হতে হবে, পরিবর্তিত trust boundary পর্যালোচিত হতে হবে, নতুন দুর্বলতা বা functional regression থাকা যাবে না এবং deployment ব্যর্থ হলে আগের নিরাপদ artefact-এ ফেরার পথ পরীক্ষিত হতে হবে। কোনো gate ব্যর্থ হলে patch reject বা সংশোধনের জন্য ফেরত যাবে; AI নিজের fix অনুমোদন করবে না।

Scanner-এর সবুজ সংকেত কেন যথেষ্ট নয়

Static analyzer-এর finding মুছে গেলেও দুর্বলতা অন্য code path-এ থেকে যেতে পারে। আবার সংকীর্ণ fix নতুন authorization bypass, unsafe error handling বা input-validation ত্রুটি আনতে পারে। তাই target finding সরেছে কি না দেখার পাশাপাশি নতুন finding এবং মূল আক্রমণের ফল—দুটিই পরীক্ষা করা দরকার।

Python code নিয়ে করা একটি AI remediation গবেষণায় fix-এর আগে ও পরে CodeQL ও Bandit চালানো হয়েছে। চারটি Claude model ও ২৬টি LLMSecEval prompt নিয়ে ৮০টি run-এর মধ্যে Sonnet 4.6-সহ P2 configuration সর্বোচ্চ ৭৫.৪% post-remediation pass rate পেয়েছে; বিভিন্ন configuration-এ ১৫–২২% remediation অন্তত একটি নতুন finding তৈরি করেছে। এগুলো নির্দিষ্ট Python benchmark-এর ফল, সর্বজনীন failure rate নয়—তবে post-fix verification বাদ না দেওয়ার পক্ষে প্রত্যক্ষ প্রমাণ।

Tool-এর “validated” verdict-ও প্রতিষ্ঠানের release gate-এর বিকল্প নয়। Visa-র লিখিত ব্যাখ্যা উদ্ধৃত করে VentureBeat জানিয়েছে, VVAH-এর Stage 10 working copy-তে candidate fix লেখে এবং Stage 11 adversarial verdict দেয়; build, test, code review ও merge সিদ্ধান্ত দলের নিজস্ব workflow-তেই থাকে। অতএব vendor verdict-কে evidence-এর একটি অংশ ধরুন, চূড়ান্ত অনুমোদন নয়।

Candidate patch থেকে merge: সাতটি gate

1. Finding ও exploit baseline স্থির করুন। দুর্বল commit, affected component, weakness class, attack precondition, original proof-of-concept এবং দৃশ্যমান ব্যর্থ আচরণ নথিবদ্ধ করুন। নিয়ন্ত্রিত test environment-এ সমস্যাটি পুনরুৎপাদন না হলে validation থামিয়ে finding পুনরায় triage করুন; unreproducible সমস্যাকে “fixed” বলবেন না। Baseline log, test input, environment manifest ও commit SHA সংরক্ষণ করুন।
2. Candidate-কে বিচ্ছিন্ন এবং credential-কে সীমিত রাখুন। Patch disposable branch, container বা ephemeral worktree-তে চালান। Agent-এর write permission নির্দিষ্ট repository ও branch-এ সীমাবদ্ধ রাখুন; production secret, deployment credential এবং অপ্রয়োজনীয় network access দেবেন না। Permission manifest, generated diff, model ও tool version এবং exact patch hash evidence bundle-এ যোগ করুন। Scope ভাঙলে credential revoke করে workspace বাতিল করুন।
3. Build ও deterministic scan চালান। Pinned dependency এবং একই scanner configuration দিয়ে baseline ও patched revision তুলনা করুন। Build সফল, target finding অনুপস্থিত এবং ব্যাখ্যাহীন নতুন critical বা high finding শূন্য—এগুলোকে পূর্বনির্ধারিত acceptance rule করুন। কম্পাইলের আউটপুট, SAST/SCA ফলাফল এবং ব্যবহৃত query ও configuration-এর version রাখুন; suppression থাকলে কারণ, scope, approver ও expiry লিখুন।
4. Original exploit replay করুন। যে input, identity, protocol path ও configuration-এ দুর্বলতা দেখা গিয়েছিল, সেখানেই proof-of-concept আবার চালান। শুধু process crash না হওয়া যথেষ্ট নয়; প্রত্যাশিত নিরাপদ response, অপরিবর্তিত state এবং প্রয়োজনীয় audit event পরীক্ষা করুন। Encoding, boundary value, alternative route বা কম-সুবিধাপ্রাপ্ত identity দিয়ে কাছাকাছি bypass-ও খুঁজুন। মূল exploit বা সমতুল্য bypass সফল হলে patch reject করুন।
5. Regression ও security-property test চালান। পূর্ণ unit ও integration suite-এর সঙ্গে affected module, authorization boundary, error path এবং data migration-এর লক্ষ্যভিত্তিক test যোগ করুন। Fix বৈধ request বন্ধ করছে কি না, privilege বাড়াচ্ছে কি না, sensitive data log করছে কি না এবং retry বা concurrent execution-এ invariant ভাঙছে কি না পরীক্ষা করুন। ব্যাখ্যাহীন regression বা অনির্ধারিত flaky test থাকলে merge বন্ধ রাখুন।
6. মানুষকে diff ও threat context পর্যালোচনা করতে দিন। Component owner implementation দেখবেন; AppSec reviewer exploitability, trust boundary ও test coverage বিচার করবেন। OWASP Secure Code Review নির্দেশিকা manual review-কে automated SAST/DAST-এর পরিপূরক হিসেবে রাখে, বিশেষত business logic, জটিল security control ও context-specific দুর্বলতার ক্ষেত্রে। Reviewer input validation, authentication, authorization, secret handling, logging ও dependency change দেখে পরিচয়সহ verdict দেবেন।
7. Release ও rollback evidence প্রস্তুত করুন। Merge-এর আগে immutable build artefact, staged rollout বা canary plan, পর্যবেক্ষণের signal, stop condition এবং rollback owner নির্ধারণ করুন। Test environment-এ আগের নিরাপদ artefact deploy করে rollback command বা runbook rehearse করুন। Database change থাকলে backward compatibility, restore path এবং data-loss সীমা আলাদাভাবে যাচাই করুন; শুধু লেখা কিন্তু অপরীক্ষিত rollback plan gate পাস করবে না।

প্রতিটি gate-কে machine-readable করুন

CI/CD-তে সাতটি ধাপকে একটি দীর্ঘ script না বানিয়ে পৃথক required check হিসেবে প্রকাশ করুন। প্রতিটি check-এ চারটি field রাখুন: input identity—কোন commit ও artefact পরীক্ষা হয়েছে; command/config—কোন pinned tool ও policy চলেছে; result—pass, fail বা needs-review; এবং evidence location—নথি, log বা reviewer record কোথায়। এতে পুরোনো scan ফল ভুল করে নতুন patch-এর সঙ্গে যুক্ত হওয়ার ঝুঁকি কমে।

Acceptance policy repository-র version-controlled ফাইলে আগে থেকেই রাখুন। একটি শর্তসাপেক্ষ উদাহরণ হতে পারে: target exploit ব্যর্থ, নতুন critical/high SAST finding শূন্য, required regression suite pass, নির্ধারিত দুই review সম্পন্ন এবং rollback rehearsal-এর revision বর্তমান release candidate-এর সঙ্গে মেলে। এটি নমুনা মাত্র; risk tier, regulator ও application architecture অনুযায়ী threshold বদলাবে। Protected test বা policy বদলে সহজে pass করাতে না পারে বলে ওই পরিবর্তনে আলাদা human approval দিন।

Evidence bundle-এ যা থাকবে

একটি release candidate-এর evidence ছড়িয়ে না রেখে patch ID-র অধীনে immutable bundle তৈরি করুন। এতে finding record, baseline ও patched commit, complete diff, generation metadata, permission manifest, build output, pre/post scan, exploit transcript, regression ফল, reviewer verdict এবং rollback rehearsal record থাকবে। Secret বা raw customer data bundle-এ রাখবেন না; প্রয়োজন হলে redacted log এবং মূল record-এর নিয়ন্ত্রিত reference দিন।

• সব artefact একই patch hash ও environment identity নির্দেশ করে কি না;
• কোনো নথি মেয়াদোত্তীর্ণ, অসম্পূর্ণ বা অন্য branch-এর কি না;
• waiver থাকলে approver, কারণ, scope ও expiry লেখা আছে কি না;
• ব্যর্থ gate-এর পর নতুন revision-এ প্রাসঙ্গিক test আবার চলেছে কি না;
• merge ও deployment audit trail-এ অনুমোদনকারীদের আলাদাভাবে শনাক্ত করা যায় কি না।

AI দ্বিতীয় patch দিলে আগের সফল ফল পুনর্ব্যবহার করবেন না। Code বদলালে অন্তত build, scan, exploit replay এবং affected regression suite আবার চালান; trust boundary বদলালে human review ও rollback plan-ও পুনরায় অনুমোদন করুন। একই revision-এর সঙ্গে সব evidence-এর এই সংযোগই সাধারণ checklist-কে auditable control-এ পরিণত করে।

Merge সিদ্ধান্ত ও ব্যর্থতার পথ

সব required check pass এবং অনুমোদনকারীর identity যাচাই হলেই protected branch-এ merge খুলুন। “Needs review”, timeout, missing artefact বা scanner error-কে pass হিসেবে গণ্য করবেন না; এগুলো fail-closed থাকবে। জরুরি patch-এ কোনো gate সাময়িকভাবে ছাড় দিলে কে risk গ্রহণ করেছেন, ছাড়ের scope কী এবং কখন পূর্ণ validation হবে—সময়সীমাসহ waiver-এ লিখুন।

Deployment-এর পর canary signal খারাপ হলে নতুন AI fix চাওয়ার আগে পরীক্ষিত rollback চালিয়ে নিরাপদ version ফিরিয়ে আনুন। Runtime evidence সংরক্ষণ করে finding পুনরায় খুলুন এবং নতুন candidate-কে প্রথম gate থেকে চালান। AI remediation গতি দিতে পারে; vulnerability সত্যিই বন্ধ হয়েছে কি না এবং production risk গ্রহণযোগ্য কি না—সে সিদ্ধান্ত repeatable evidence ও দায়বদ্ধ মানুষের কাছেই থাকবে।