GitHub AI Scan এখন API-তে—org চালু থাকলেও repo আলাদা করে বন্ধ হতে পারে
GitHub ১০ সেপ্টেম্বর ২০২৬-এ pull request-এর AI Scan চালু বা বন্ধ করার জন্য organization ও repository স্তরের REST endpoint public preview করেছে। GitHub-এর ১০ সেপ্টেম্বরের changelog অনুসারে, সুবিধাটি এখন github.com-এ GitHub Advanced Security গ্রাহকদের জন্য উপলভ্য; এই release-এ GitHub Enterprise Server সমর্থিত নয়।
GitHub AI Scan API-তে organization setting অনুমতির ঊর্ধ্বসীমা হিসেবে কাজ করে। Organization-এ scanning চালু থাকলে নির্দিষ্ট repository আলাদাভাবে তা বন্ধ করতে পারে, কিন্তু organization-এ বন্ধ থাকা AI Scan কোনো repository নিজে থেকে চালু করতে পারে না।
Organization চালু মানেই সব repository চালু নয়
Policy precedence তিনটি স্তরে বোঝা দরকার: enterprise policy, organization setting এবং repository setting। Enterprise policy AI Scan অনুমোদন না করলে organization স্তরে enable করার চেষ্টা প্রত্যাখ্যাত হবে। Organization disabled থাকলেও repository-level enable কার্যকর হবে না।
অন্যদিকে organization enabled হলে repository opt out করতে পারে। একই release নিয়ে TechTimes-এর স্বাধীন প্রতিবেদন দুই scope-এর endpoint এবং organization-disabled অবস্থাকে repository দিয়ে অতিক্রম করতে না পারার নিয়মটি নিশ্চিত করে।
এর operational অর্থ হলো, organization-এর মান দেখে সব repository-তে scanning চলছে বলে ধরে নেওয়া যাবে না। Inventory বা compliance report-এ parent policy এবং প্রতিটি repository-তে সংরক্ষিত setting আলাদা করে রাখতে হবে; তবেই অনুমোদন ও বাস্তব opt-out-এর পার্থক্য দেখা যাবে।
GET বর্তমান অবস্থা পড়ে, PATCH setting বদলায়
GitHub REST API reference organization ও repository scope-এর GET/PATCH path, pr_scan মান, প্রয়োজনীয় token permission এবং HTTP response নথিভুক্ত করেছে। Organization resource হলো /orgs/{org}/code-scanning/ai-scan; repository resource হলো /repos/{owner}/{repo}/code-scanning/ai-scan।
GET request সংশ্লিষ্ট scope-এ সংরক্ষিত setting ফেরত দেয়। PATCH body-তে pr_scan-এর মান enabled অথবা disabled পাঠিয়ে setting বদলানো যায়; সফল update-এ response body-তে বর্তমান মান ফিরে আসে। Endpointগুলো public preview হওয়ায় contract পরিবর্তনের সম্ভাবনা রয়েছে।
নমুনা request-এ Accept: application/vnd.github+json এবং X-GitHub-Api-Version: 2026-03-10 header ব্যবহৃত হয়েছে। আলাদা bulk endpoint তালিকাভুক্ত নেই। ফলে বহু repository-তে staged rollout করলে automation-কে target তালিকা, পৃথক API call এবং প্রত্যেক response নিজস্বভাবে পরিচালনা করতে হবে।
পড়ার ও বদলানোর permission এক নয়
Organization setting পড়ার জন্য fine-grained token-এ organization-level Administration: read প্রয়োজন; update-এর জন্য দরকার Administration: write। Organization endpoint ব্যবহারকারী authenticated identity-কে owner বা security manager হতে হবে। Classic personal access token ও OAuth token-এর গ্রহণযোগ্য scope ভূমিকা অনুসারে admin:org, repo অথবা write:org।
Repository endpoint-এ ব্যবধানটি আরও গুরুত্বপূর্ণ। GET-এর জন্য fine-grained token-এ repository-level Code scanning alerts: read permission লাগে, কিন্তু PATCH-এর জন্য Administration: write আবশ্যক। অর্থাৎ code-scanning alert পড়তে সক্ষম token দিয়ে repository-র AI Scan setting পরিবর্তন করা যাবে—এমন নিশ্চয়তা নেই।
Classic token দিয়ে repository update করতে private ও public repository-র জন্য repo scope, আর শুধু public repository-র জন্য public_repo scope প্রযোজ্য। Permission নাম ঠিক থাকলেও token বা GitHub App installation-কে সংশ্লিষ্ট organization বা repository-তে access দিতে হবে; rollout identity কোন target দেখতে ও বদলাতে পারে, সেটি তাই আলাদাভাবে যাচাইযোগ্য বিষয়।
403, 404 ও 422 কী নির্দেশ করে
Repository GET-এ 403 GitHub Advanced Security সক্রিয় না থাকার documented response। Repository PATCH-এ archived repository অথবা GitHub Advanced Security নিষ্ক্রিয় থাকলেও একই status আসতে পারে। Organization endpoint-এ 403 সাধারণ Forbidden response; enterprise policy AI Scan নিষিদ্ধ করলে organization enable request-ও প্রত্যাখ্যাত হয়। তাই 403 পেলেই একটিমাত্র কারণ ধরে নেওয়া নিরাপদ নয়।
404 দুই scope-এই resource not found হিসেবে তালিকাভুক্ত। এ ক্ষেত্রে organization, owner ও repository নামের পাশাপাশি token বা app installation-টির target access যাচাই করা প্রয়োজন। Documentation 404-এর জন্য এর চেয়ে নির্দিষ্ট কারণ আলাদা করে দেয় না।
Update operation-এ 422 validation failure অথবা endpoint-এ অতিরিক্ত request পাঠানোর ফল হতে পারে। Failure log-এ scope, target, চাওয়া pr_scan মান, HTTP status এবং request time রাখলে archived বা অযোগ্য repository, অনুপস্থিত resource এবং malformed request একই সমস্যার তালিকায় মিশে যাবে না।
বড় rollout-এর জন্য যাচাইয়ের ক্রম
- Enterprise policy AI Scan অনুমোদন করে কি না যাচাই করুন; নিষেধ থাকলে organization-level enable সফল হবে না।
- Organization GET দিয়ে সংরক্ষিত pr_scan মান নিন এবং automation identity owner বা security manager হিসেবে উপযুক্ত কি না মিলিয়ে দেখুন।
- Organization update-এর জন্য organization-level এবং repository update-এর জন্য repository-level Administration: write দিন; প্রয়োজনের অতিরিক্ত permission যোগ করবেন না।
- Repository GET দিয়ে baseline তৈরি করুন। 403 পাওয়া অযোগ্য target এবং 404 পাওয়া resource আলাদা failure queue-তে রাখুন।
- Organization enabled করার পর সীমিত repository batch-এ PATCH পাঠান। যেসব repository-তে scanning প্রয়োজন নেই, সেগুলোর pr_scan disabled রাখুন।
- প্রতিটি PATCH response সংরক্ষণ করে পরবর্তী GET ফলের সঙ্গে মিলিয়ে নিন। Preview contract বদলালে request schema, API version এবং error handling পুনরায় যাচাই করুন।
বর্তমান সীমা স্পষ্ট: API-টি public preview, github.com-এর GitHub Advanced Security গ্রাহকদের জন্য প্রযোজ্য এবং এই release-এ GitHub Enterprise Server অন্তর্ভুক্ত নয়। Organization enablement repository-কে opt out করার সুযোগ দেয়, বাধ্যতামূলকভাবে সব repo চালু করে না; আবার parent policy disabled হলে নিচের স্তর তা অতিক্রম করতে পারে না। পরবর্তী গুরুত্বপূর্ণ পরিবর্তন হবে preview contract, availability বা server support নিয়ে নতুন release তথ্য প্রকাশ পাওয়া।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।