Visa-র VVAH নিজেই কোডে প্যাচ লেখে—merge-এর আগে মানুষই শেষ প্রহরী

Visa ২৭ আগস্ট ২০২৬-এ open-source Visa Vulnerability Agentic Harness বা VVAH-এর workflow সম্প্রসারণের ঘোষণা দিয়েছে। Visa-র ২৭ আগস্টের ঘোষণায় বলা হয়েছে, frameworkটি এখন দুর্বলতা শনাক্ত ও যাচাইয়ের পর candidate remediation তৈরি, সেটি adversarialভাবে validate এবং ব্যর্থ fix-এর ফল পরবর্তী চেষ্টায় ফেরত দিতে পারে।

ওই ২৭ আগস্টের সম্প্রসারণে সবচেয়ে গুরুত্বপূর্ণ সীমাটি হলো: VVAH-এর default ১১-stage flow Stage 10-এ target working copy-র source file বদলাতে পারে এবং Stage 11-এ patch যাচাই করে। তবে অফিশিয়াল repository documentation স্পষ্ট করে যে এটি build বা test চালায় না, patch-কে production-ready ঘোষণা করে না এবং merge করে না—শেষ সিদ্ধান্ত security ও engineering দলের।

১১টি stage কোথায় পড়ে, আর code write কখন হয়

VVAH-এর pipeline-কে চারটি কার্যকর সীমানায় ভাগ করা যায়: detection, write, validation এবং merge। প্রথম নয়টি stage attack surface ও threat context তৈরি, গভীর বিশ্লেষণ, সম্ভাব্য finding ছাঁটাই, exploitability যাচাই, duplicate সরানো, exploit chain গঠন এবং structured report তৈরির কাজ করে। ফলে remediation agent-এর কাছে কেবল scanner alert নয়, যাচাই করা finding ও সংশ্লিষ্ট attack path পৌঁছায়।

Write boundary শুরু হয় Stage 10-এ। verified finding, প্রয়োজনীয় credential এবং সফল remediation session থাকলে fix mode একটি ন্যূনতম candidate patch প্রস্তাব করে target source tree-তে প্রয়োগ করতে পারে। default profile-এ remediation ও validation চালু থাকায় plain scan এই পর্যায় পর্যন্ত যায়; detection-only চালাতে Stage 9-এর পরে থামানোর option ব্যবহার করতে হয়।

সব configuration অবশ্য সমানভাবে file লিখতে পারে না। write capability নির্বাচিত backend ও mode-এর ওপর নির্ভর করে; কোনো route report-only হতে পারে, আবার default remediation route working copy বদলাতে পারে। তাই “model fix প্রস্তাব করেছে” এবং “agent repository-র file সম্পাদনা করেছে”—দুটিকে আলাদা audit event হিসেবে নথিভুক্ত করা দরকার।

Stage 11 source code-এর ক্ষেত্রে read-only adversarial panel। এটি remediation artifact ও repository পড়ে fix root cause সামলেছে কি না, exploit path বন্ধ করেছে কি না এবং নতুন security weakness-এর আশঙ্কা আছে কি না বিচার করে validated, validation failed অথবা needs review verdict দেয়। validation ব্যর্থ হলে structured feedback নতুন remediation attempt-এ ফিরতে পারে; discovery পুরোপুরি নতুন করে চালানো বাধ্যতামূলক নয়।

Validated verdict কেন production-ready নয়

Stage 11-এর verdict একটি model-assisted security review, executable verification নয়। Validator target application compile করে না, unit বা integration test চালায় না, performance regression মাপে না এবং প্রতিষ্ঠানের change-control policy প্রয়োগ করে না। ফলে security reasoning-এ গ্রহণযোগ্য patch-ও syntax, dependency, runtime behavior বা business logic ভাঙতে পারে।

এই সীমাটি merge boundary-কে আলাদা করে। VVAH-এর validation report reviewer-কে root-cause coverage ও সম্ভাব্য নতুন ঝুঁকি সম্পর্কে evidence দেয়, কিন্তু CI pipeline, application test, exploit re-test, final diff review কিংবা protected-branch rule-এর বিকল্প হয় না। validated label তাই merge permission নয়; এটি মানুষের পরবর্তী সিদ্ধান্তের একটি input।

আরও একটি অনিশ্চয়তা হলো ফলের পুনরাবৃত্তিযোগ্যতা। repository-র limitations অনুযায়ী findings ও fixes LLM-generated triage candidate, দুই run-এর ফল আলাদা হতে পারে এবং VVAH-এর public precision বা recall figure এখনো প্রকাশিত হয়নি। নির্দিষ্ট model, backend, configuration ও codebase-এ ফল না মাপা পর্যন্ত সাধারণ accuracy দাবি করা তাই সমর্থনযোগ্য নয়।

মানুষের তিনটি approval gate

VentureBeat-কে দেওয়া Visa-র লিখিত জবাবে মানুষের তিনটি gate নির্দিষ্ট করা হয়েছে: tool চালানোর আগে, generated patch review করার সময় এবং কোনো পরিবর্তন merge হওয়ার আগে। এগুলো একই approval-এর পুনরাবৃত্তি নয়; প্রতিটি gate-এর authority, evidence ও ব্যর্থ হলে করণীয় আলাদা।

1. Run approval: operator নিশ্চিত করবেন target code প্রতিষ্ঠানের নিজের অথবা পরীক্ষা করার সুস্পষ্ট অনুমতি আছে। কোন repository, branch, model endpoint ও mode ব্যবহার হবে—বিশেষ করে run detection-only থাকবে নাকি source লিখতে পারবে—সেটিও এই gate-এ স্থির হবে।
2. Patch approval: AppSec ও engineering reviewer finding, exploit evidence, generated diff এবং Stage 11 verdict একসঙ্গে দেখবেন। patch attack path বন্ধ করলেও authorization logic, error handling, compatibility বা অন্য control ক্ষতিগ্রস্ত হচ্ছে কি না মানুষের বিচারেই নির্ধারিত হবে।
3. Merge approval: project-এর build, test, security re-test ও change-control শেষ হওয়ার পর স্বাভাবিক protected-branch reviewer merge অনুমোদন দেবেন। agent identity-কে এই gate অতিক্রম করার অধিকার দিলে VVAH-এর বাইরের শেষ নিয়ন্ত্রণটিই হারিয়ে যাবে।

প্রথম gate পুরো run অনুমোদন করে; Stage 10 প্রতিটি file edit-এর ঠিক আগে আলাদা মানব-অনুমোদনের জন্য থামে না। অর্থাৎ write mode চালু হলে patch review-এর আগেই working copy বদলাতে পারে। তাই title-এর “শেষ প্রহরী” মানুষ হলেও সেই প্রহরা merge-এর আগে কার্যকর; file mutation-এর আগে আলাদা বাধা চাইলে তা repository environment ও orchestration layer-এ দলকেই বসাতে হবে।

Repository scope ও credential boundary

write-capable run-এর blast radius নির্ধারণ করে agent কোন filesystem ও repository দেখতে বা বদলাতে পারে। production checkout, বহু repository-সহ developer workspace বা shared build host-এর বদলে disposable clone বা ক্ষণস্থায়ী isolated environment ব্যবহার করলে generated edit target-এর বাইরে ছড়ানোর সুযোগ কমে। service identity-র access একটি নির্দিষ্ট repository ও অস্থায়ী branch-এ সীমাবদ্ধ রাখাও একই কারণে গুরুত্বপূর্ণ।

Credential boundary আলাদা নিয়ন্ত্রণ। VVAH source context পড়ে নির্বাচিত model provider বা অনুমোদিত gateway-তে prompt data পাঠাতে পারে; একই run remediation-এর জন্য file-mutation capability-ও পেতে পারে। model credential, source-control token, cloud key ও production secret target repository-তে না রেখে approved endpoint, স্বল্পমেয়াদি credential এবং প্রয়োজনমাফিক outbound access দেওয়া সংযত পদ্ধতি।

Review package-এ target commit, configuration hash, model route, remediation record, generated diff এবং validation verdict একসঙ্গে রাখা উচিত। scan-এর পরে base branch বদলে গেলে পুরোনো verdict নতুন code-এর জন্য প্রমাণ নয়; patch rebase করে build, test ও প্রয়োজনীয় security validation আবার চালাতে হবে। এটি VVAH-এর দাবি নয়, বরং পরিবর্তিত input-এর ওপর পুরোনো ফল প্রয়োগ না করার engineering control।

ছোট দলের rollout: আগে read-only, পরে controlled write

ছোট দলের জন্য সংযত rollout শুরু হতে পারে Stage 9-এর পরে থামা detection-only pilot দিয়ে। এতে source file না বদলিয়েই finding quality, duplicate ও false positive, repository coverage, model cost এবং কোন code context অনুমোদিত endpoint-এ যাচ্ছে—এসব মূল্যায়ন করা যায়। বিদ্যমান SAST, dependency scan ও manual AppSec review-এর ফলের সঙ্গে তুলনা করলে VVAH কোথায় নতুন signal দিচ্ছে তাও বোঝা যায়।

পরের পর্যায়ে write mode একটি সীমিত repository-র disposable branch বা clone-এ চালানো যেতে পারে। non-production credential, নির্দিষ্ট patch reviewer এবং বাধ্যতামূলক CI রেখে দল generated fix-এর build-pass rate, validation failure, মানুষের patch acceptance এবং security re-test-এর ফল মাপতে পারে। ফল ভালো হলেও agent-কে protected branch-এর merge permission দেওয়ার প্রয়োজন নেই।

এখন নিশ্চিত অবস্থা হলো, ২৭ আগস্টের expanded workflow দুর্বলতা শনাক্ত থেকে candidate fix লেখা ও adversarial validation পর্যন্ত যেতে পারে, কিন্তু production-এ পৌঁছানোর প্রমাণ ও অনুমোদন VVAH-এর বাইরে থাকে। পরবর্তী গুরুত্বপূর্ণ তথ্য হবে public accuracy measurement, বিভিন্ন backend-এ পুনরাবৃত্ত ফল এবং বাস্তব repository-তে human-reviewed patch acceptance data; সেগুলো প্রকাশ না হওয়া পর্যন্ত validated verdict-কে সহায়ক evidence হিসেবেই দেখা যুক্তিসঙ্গত।