GitHub Actions-এ নতুন ডিফল্ট বাধা—২ নভেম্বর ভাঙতে পারে কিছু workflow
GitHub Actions-এর workflow execution protections ১৭ সেপ্টেম্বর ২০২৬-এ general availability-তে এসেছে। GitHub-এর GA ঘোষণায় বলা হয়েছে, আগে থেকে প্রযোজ্য event policy নেই এমন public repository-তে একটি default rule এখন evaluate mode-এ pull_request_target event শনাক্ত করছে; সংশ্লিষ্ট repository-তে ২ নভেম্বর থেকে এটি enforce করা হবে।
Evaluate mode-এ workflow এখনো চলে, তবে policy insights দেখায় enforcement চালু থাকলে কোন run ব্যর্থ হতো। ReleaseBytes-এর ১৭ সেপ্টেম্বরের স্বাধীন প্রকাশনাও GA status, public repository-র default block, evaluate mode এবং ২ নভেম্বর ২০২৬-এর enforcement সময়রেখা নথিবদ্ধ করেছে। তাই pull_request_target-নির্ভর automation এখন পরীক্ষা না করলে ওই তারিখের পর কিছু workflow run error-সহ থামতে পারে।
কোন repository ও workflow প্রভাবিত হবে
পরিবর্তনটি সব GitHub Actions workflow বন্ধ করবে না। Default rule প্রযোজ্য public repository-তে, যদি সেখানে আগে থেকেই ওই run-এর ওপর কার্যকর কোনো Actions event policy না থাকে। Private ও internal repository এই default-এর আওতায় নয়; আগে কনফিগার করা প্রযোজ্য event policy-ও নতুন rule দিয়ে প্রতিস্থাপিত হবে না।
ঝুঁকিতে থাকবে সেই workflow file, যার trigger হিসেবে on: pull_request_target আছে। Enforcement-এর পর default block বহাল থাকলে ওই event থেকে run শুরু হবে না। একই YAML file-এ push, pull_request, schedule বা workflow_dispatch-ও থাকলে নতুন default rule কেবল pull_request_target থেকে আসা run-কে লক্ষ্য করবে—পুরো workflow file মুছে যাবে বা অন্য সব trigger অকার্যকর হবে না।
প্রভাব শুধু দৃশ্যমান run failure-এ সীমাবদ্ধ থাকতে পারে না। pull_request_target run যদি label যোগ করে, triage চালায়, authenticated status check প্রকাশ করে, required check পূরণ করে বা পরবর্তী automation-এর input তৈরি করে, তাহলে সেই নির্ভরতাও থামতে পারে। Audit-এ তাই trigger পাওয়া গেলেই কাজ শেষ নয়; ওই run-এর ফল repository-র merge ও review প্রক্রিয়ায় কোথায় ব্যবহৃত হয়, সেটিও ধরতে হবে।
Actor rule, event rule ও workflow path কীভাবে মেলে
Execution protections দুই ধরনের allowlist একসঙ্গে মূল্যায়ন করে। Actor rule নির্ধারণ করে কোন পরিচয়, role বা অনুমোদিত application workflow শুরু করতে পারবে; event rule নির্ধারণ করে push, pull_request, pull_request_target বা workflow_dispatch-এর মতো কোন event গ্রহণযোগ্য। একটি শর্ত পেরোলেও অন্যটি ব্যর্থ হলে run অনুমোদন পাবে না।
GA release-এর workflow file targeting সুবিধা exception-এর পরিধি ছোট রাখার পথ দেয়। pull_request_target প্রয়োজন এমন একটি নির্দিষ্ট workflow path অনুমোদন করা যায়, অথচ একই repository-র অন্য workflow-গুলোর জন্য default block রাখা সম্ভব। Enterprise, organization ও repository স্তরের policy পরস্পরের সঙ্গে layer হতে পারে; নিচের স্তরে অনুমতি থাকলেই ওপরের স্তরের restriction অকার্যকর হয়ে যায় না।
এই কারণে impact inventory-তে চারটি তথ্য পাশাপাশি রাখতে হবে: event, actor, workflow path এবং কার্যকর policy level। শুধু YAML-এ pull_request_target খোঁজা সম্ভাব্য workflow দেখাবে, কিন্তু runটি শেষ পর্যন্ত অনুমোদিত হবে কি না তা জানাবে না। আবার শুধু policy settings দেখলে workflow-এর downstream dependency বাদ পড়ে যেতে পারে।
Evaluate mode-এ pre-enforcement audit
Audit-এর লক্ষ্য সম্ভাব্য প্রতিটি block-এর সঙ্গে তার operational consequence ও প্রয়োজনীয় সিদ্ধান্ত জুড়ে দেওয়া। Public repository-র workflow files, evaluate ফল এবং account-level policy একত্রে পরীক্ষা করলে অপ্রয়োজনীয় broad exception এড়ানো যায়।
- Event inventory তৈরি করুন: প্রতিটি প্রাসঙ্গিক repository-র .github/workflows directory-তে pull_request_target খুঁজুন। কোন file-এ eventটি আছে, তার সঙ্গে অন্য trigger আছে কি না এবং event-নির্ভর condition কোন job চালায়, তা আলাদা করে লিখুন।
- Default rule-এর scope যাচাই করুন: repository public কি না এবং enterprise, organization বা repository স্তরে আগে থেকেই প্রযোজ্য event policy আছে কি না নির্ধারণ করুন। এতে GitHub-এর default evaluate rule কোথায় বাস্তবে প্রযোজ্য, তা বোঝা যাবে।
- Policy insights পর্যালোচনা করুন: evaluate mode-এ যে run-গুলো enforcement হলে blocked হতো, সেগুলো workflow path অনুযায়ী ভাগ করুন। Run metadata থেকে trigger ও actor মিলিয়ে দেখুন; শুধু মোট blocked-run সংখ্যা সিদ্ধান্ত নেওয়ার জন্য যথেষ্ট নয়।
- নির্ভরতা চিহ্নিত করুন: সম্ভাব্য blocked run required check, merge condition, label, comment, release step বা অন্য workflow-এর input তৈরি করে কি না নথিবদ্ধ করুন। এতে একটি event বন্ধ হওয়ার পরোক্ষ প্রভাব ধরা পড়বে।
- Event-এর প্রয়োজন নির্ধারণ করুন: privileged context প্রয়োজন না হলে pull_request-এর মতো উপযুক্ত event ব্যবহার করা যায় কি না দেখুন। pull_request_target দরকার হলে applicable event policy-তে সেটি স্পষ্টভাবে allow করে exception-টি প্রয়োজনীয় workflow path-এ সীমিত রাখুন।
- Actor rule আবার পরীক্ষা করুন: event অনুমোদনের পরও বাস্তব user, role, GitHub App বা bot actor rule-এ গ্রহণযোগ্য কি না নিশ্চিত করুন। Event exception actor rejection বাতিল করে না।
Exception দেওয়ার আগে নিরাপত্তা সীমা
pull_request_target base repository-র trusted context-এ চলে এবং jobটি base repository-র GITHUB_TOKEN ও repository বা organization secrets পেতে পারে। GitHub-এর pull_request_target নিরাপত্তা নির্দেশনায় ব্যাখ্যা করা হয়েছে, default branch-এর trusted workflow নিজে থেকে fork-এর code চালায় না; ঝুঁকি তৈরি হয় যখন workflow fork-এর head, merge commit, artifact বা configuration এনে privileged context-এ execute করে।
শুধু checkout step থাকা মানেই অবিশ্বস্ত code চলেছে—এমন নয়। পরের build, test, install বা script step যদি checkout করা fork code ব্যবহার করে, তখন token ও secrets উন্মুক্ত হওয়ার পথ তৈরি হতে পারে। Exception review-তে তাই checkout ref, fork repository থেকে fetch, downloaded artifact, executable configuration, token permissions, secrets এবং self-hosted runner ব্যবহারের সীমা দেখতে হবে।
Metadata-ভিত্তিক labeling, triage বা comment automation এবং fork-এর পরিবর্তিত code চালানো CI একই ধরনের কাজ নয়। প্রথমটি base branch-এর trusted workflow দিয়ে pull request-এ প্রতিক্রিয়া জানাতে পারে; দ্বিতীয়টি privileged context-এ অবিশ্বস্ত code চালাতে পারে। Workflow-path targeting exception-এর ক্ষেত্র ছোট করে, কিন্তু workflow file-এর ভেতরের অনিরাপদ execution pattern নিজে থেকে সংশোধন করে না।
বর্তমান নিশ্চিত অবস্থা হলো, default rule evaluate mode-এ সম্ভাব্য ব্যর্থ run দেখাচ্ছে; enforcement শুরু হলে disallowed pull_request_target run ব্যর্থ হবে। প্রতিটি চিহ্নিত workflow-এর জন্য তখন তিনটির একটি সিদ্ধান্ত প্রয়োজন: event বদলানো, block বহাল রাখা, অথবা নিরাপত্তা যাচাই শেষে নির্দিষ্ট path-এর সীমিত exception দেওয়া। GitHub প্রভাবিত repository বা run-এর কোনো সামগ্রিক সংখ্যা প্রকাশ করেনি, তাই প্রকৃত impact সংশ্লিষ্ট দলের নিজস্ব workflow inventory, policy insights ও dependency mapping থেকেই নির্ধারিত হবে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।