Pull request-এ secret থাকলে merge বন্ধ—push protection-এর পরেও নতুন জাল
GitHub ৯ সেপ্টেম্বর ২০২৬-এ public preview হিসেবে নতুন একটি repository ruleset rule চালু করেছে। Pull request-এর head commit-এর secret scan শেষ না হলে অথবা PR-এর commit থেকে তৈরি secret-scanning alert খোলা থাকলে ruleটি merge আটকে দেয়। GitHub-এর ঘোষণায় বলা হয়েছে, সুবিধাটি GitHub Secret Protection বা GitHub Advanced Security থাকা গ্রাহকদের জন্য এসেছে।
এটি push protection-এর বদলি নয়, বরং pull-request স্তরের আরেকটি gate। Push-এর সময় secret আটকানো না গেলে বা সেই সুরক্ষা bypass করা হলে, target branch-এর সক্রিয় ruleset merge-এর আগে exposureটি ধরার আরেকটি সুযোগ দেয়। ১০ সেপ্টেম্বরের একটি স্বতন্ত্র কারিগরি প্রতিবেদনে public-preview status, ৯ সেপ্টেম্বরের release এবং merge-এর আগের দুইটি check একইভাবে নথিবদ্ধ হয়েছে।
Commit থেকে merge: gateটি যেভাবে কাজ করে
নতুন rule নিজে alert তৈরির আলাদা ব্যবস্থা নয়; secret scanning-এর ফলকে merge-এর বাধ্যতামূলক শর্তে পরিণত করে। Administrator-কে repository, organization বা enterprise settings থেকে branch-targeted ruleset তৈরি বা সম্পাদনা করে Require secret scanning alerts are resolved চালু করতে হয়। ফলে ruleset-এর target নয় এমন branch-এ এই নির্দিষ্ট merge block প্রযোজ্য হবে না।
- Developer commit push করে pull request খোলে অথবা বিদ্যমান PR-এ নতুন commit যোগ করে।
- GitHub সর্বশেষ head commit-এর secret scan শেষ হওয়া পর্যন্ত merge আটকে রাখে।
- Scan শেষে PR-এর commit থেকে নির্বাচিত secret type-এর কোনো open alert এসেছে কি না পরীক্ষা করা হয়।
- Open alert থাকলে block বহাল থাকে। Alert resolve হলে এবং অন্য প্রযোজ্য rule পাস করলে merge এগোতে পারে।
Gateটি repository-র সব পুরোনো alert বন্ধ করার দাবি করে না; এর ঘোষিত scope হলো সংশ্লিষ্ট pull request-এর commit থেকে আসা alert। Head commit বদলে গেলে সেই নতুন commit-এর scan-ও শেষ হতে হবে—আগের head commit-এর সফল scan নতুনটির ফল হিসেবে গণ্য হয় না।
Push protection ও merge rule কোথায় মেলে, কোথায় ফাঁক থাকে
দুই ব্যবস্থার নিয়ন্ত্রণবিন্দু আলাদা। Push protection secret শনাক্ত করলে push repository-তে পৌঁছানোর আগেই বাধা দেয় এবং developer-কে তা সরানোর সুযোগ দেয়। নতুন rule কাজ করে পরে: commit repository ও pull request-এ পৌঁছালেও unresolved exposure নিয়ে নির্ধারিত branch-এ merge হতে দেয় না।
একই secret pattern দুই ব্যবস্থায় অন্তর্ভুক্ত থাকলে overlap তৈরি হয়। Push protection প্রথম বাধা; সেটি secret ধরতে না পারলে, configured না থাকলে বা bypass হলে পরবর্তী scan alert তৈরি করতে পারে, আর ruleset সেই open alert-এর কারণে merge থামায়। এই দ্বিতীয় স্তরই শিরোনামের “নতুন জাল”—প্রথম প্রতিরক্ষা পেরোনো মানেই আর protected flow-এ অবাধ merge নয়।
তবে merge gate থাকলেই secret repository-তে ঢোকা বন্ধ হয় না। Alert তৈরি হওয়ার আগেই credential code ও Git history-তে পৌঁছাতে পারে এবং PR-এ দৃশ্যমান থাকতে পারে। আবার ruleটি শুধু target করা branch, নির্বাচিত secret category এবং প্রযোজ্য bypass policy অনুযায়ী কাজ করে। তাই push-time prevention এবং merge-time enforcement একই ঝুঁকির দুই আলাদা পর্যায় সামলায়।
Provider, generic ও custom pattern-এর coverage
Public preview-তে provider pattern দিয়ে পাওয়া secret defaultভাবে block হয়; generic ও custom pattern আলাদাভাবে নির্বাচন করা যায়। Provider pattern পরিচিত service-এর token বা key শনাক্ত করে। Generic pattern private key, connection string ও সাধারণ API key-এর মতো কোনো এক provider-এর সঙ্গে বাঁধা নয় এমন credential ধরতে পারে; custom pattern প্রতিষ্ঠানের নিজস্ব token format শনাক্ত করার জন্য নির্ধারিত expression ব্যবহার করে।
Secret scanning-এ কোনো pattern সক্রিয় থাকলেই তা merge-blocking scope-এ থাকবে—এমন নয়। Repository administrator-কে ruleset-এর secret category, target branch এবং enforcement status পৃথকভাবে মিলিয়ে দেখতে হবে। GitHub-এর ঘোষণায় দেওয়া উদাহরণ অনুযায়ী, false positive-এর আশঙ্কায় generic pattern-এর push protection বন্ধ রেখেও একই category-কে pull-request ruleset-এ merge gate হিসেবে রাখা সম্ভব।
Alert resolve করা আর credential নিরাপদ করা একই কাজ নয়। GitHub-এর secret-scanning নির্দেশনা আক্রান্ত credential অবিলম্বে rotate করতে বলে; credential revoke হয়ে গেলে Git history থেকে string সরানো সময়সাপেক্ষ এবং সব ক্ষেত্রে প্রয়োজনীয় নয়। তাই আসল secret হলে নিরাপদ ক্রম হলো আগে token বা key revoke/rotate করা, code থেকে মানটি সরানো, তারপর সঠিক কারণসহ alert resolve করা।
Bypass permission audit-এ যে প্রশ্নগুলো জরুরি
ঘোষিত rule অনুযায়ী, bypass permission নেই এমন developer-কে প্রতিটি alert resolve করেই block সরাতে হবে। অর্থাৎ bypass তালিকা merge control-এর বাস্তব ব্যতিক্রম; অপ্রয়োজনীয় actor সেখানে থাকলে দ্বিতীয় gate-এর কার্যকারিতা কমে যায়। নিচের তালিকাটি GitHub-এর বাধ্যতামূলক workflow নয়, বরং repository audit-এর জন্য সম্পাদকীয় checklist।
- Actor: কোন user, role, team বা GitHub App ruleset bypass করতে পারে, তা repository, organization ও enterprise স্তর মিলিয়ে দেখা।
- Scope: permissionটি সব branch ও repository-র জন্য দরকার, নাকি নির্দিষ্ট automation বা জরুরি release-এর মধ্যে সীমিত রাখা যায়, তা যাচাই করা।
- Mode: actor-টি explicit bypass করছে, নাকি enforcement থেকেই exempt—এই পার্থক্য শনাক্ত করা; exemption থাকলে rule evaluation-এর দৃশ্যমানতা কমতে পারে।
- Trail: exception ব্যবহৃত হলে PR, commit, secret alert, সিদ্ধান্তের কারণ এবং credential owner-এর remediation record একসঙ্গে মিলিয়ে দেখা।
- Coverage: provider, generic ও custom category push protection এবং merge ruleset—দুই জায়গায় কীভাবে configured, তা পাশাপাশি পর্যালোচনা করা।
- Review: team membership, app access বা প্রশাসনিক দায়িত্ব বদলালে bypass তালিকা আবার যাচাই করা।
Bypass operationalভাবে বৈধ হতে পারে, কিন্তু সেটি exposed credential-কে নিরাপদ করে না। কোনো বাস্তব credential-সহ merge অনুমোদিত হলে আলাদা incident response হিসেবে revoke বা rotation নিশ্চিত করা দরকার; ruleset exception সেই দায় বাতিল করে না।
Public preview-তে এখন যা নিশ্চিত
নিশ্চিত সীমা হলো: ruleটি public preview, এর জন্য GitHub Secret Protection বা GitHub Advanced Security প্রয়োজন, এবং target branch-এর ruleset-এ ruleটি সক্রিয় থাকতে হবে। Head commit-এর scan শেষ হওয়া ও PR-এর commit থেকে আসা নির্বাচিত secret type-এর open alert না থাকা—এই দুই শর্ত পূরণ না হলে bypass permissionবিহীন developer merge করতে পারবেন না।
GitHub-এর ঘোষণায় general availability-এর কোনো সময়সীমা দেওয়া হয়নি। Preview চলাকালে supported environment, configuration বা bypass আচরণ বদলালে তা পরবর্তী release note ও documentation-এ স্পষ্ট হবে। আপাতত নতুন ব্যবস্থার সীমা পরিষ্কার: push protection repository-তে secret ঢোকার আগে বাধা দেয়, আর ruleset unresolved exposure-সহ pull request-এর merge বন্ধ করে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।