GitHub اب secrets والے PR merge روک سکتا ہے، مگر feature preview میں
GitHub نے 9 ستمبر 2026 کو public preview میں ایک نیا branch ruleset جاری کیا جو pull request کے head commit کی secret scan نامکمل ہونے یا اسی PR کے commits سے پیدا ہونے والا متعلقہ secret alert کھلا رہنے پر merge روک سکتا ہے۔ GitHub کے changelog میں ان دونوں checks اور rule کے preview status کی تصدیق کی گئی ہے۔
یہ حفاظت ہر repository میں خودکار طور پر فعال نہیں ہوئی: administrator کو اسے منتخب branches کے ruleset میں شامل کرنا ہوگا، جبکہ GitHub Secret Protection یا GitHub Advanced Security اور secret scanning درکار ہیں۔ 10 ستمبر کی آزاد تکنیکی رپورٹ نے بھی 9 ستمبر کے اجرا، public-preview status، دونوں merge checks اور provider patterns کے default دائرے کی تصدیق کی ہے۔
نیا rule کن حالات میں merge روکتا ہے
Rule کا نام Require secret scanning alerts are resolved ہے۔ Merge کے لیے pull request کے head commit کی secret scan مکمل ہونی چاہیے اور اس PR کے commits سے متعارف ہونے والے، ruleset میں منتخب secret types سے مطابقت رکھنے والے تمام alerts حل ہو چکے ہوں۔
اس کا مطلب یہ نہیں کہ repository کا ہر پرانا alert ہر نئے PR کو روک دے گا۔ Gate صرف اس صورت میں حرکت میں آتا ہے جب موجودہ pull request کے کسی commit نے کھلا matching alert پیدا کیا ہو، یا اس کے تازہ ترین commit کی scan ابھی مکمل نہ ہوئی ہو۔
Provider patterns default دائرے میں آتے ہیں، جبکہ administrator custom یا generic patterns بھی منتخب کر سکتا ہے۔ اس انتخاب سے gate کی وسعت بدلتی ہے: جس secret category کو ruleset میں شامل نہیں کیا گیا، اس category کا alert اس مخصوص rule کے تحت merge blocker نہیں بنتا۔
Push protection اور PR merge gate کہاں مختلف ہیں
Push protection matching secret کو push کے مرحلے پر، repository تک پہنچنے سے پہلے روکنے کی کوشش کرتی ہے۔ نیا ruleset pull-request layer پر الگ check لگاتا ہے، اس لیے وہ ایسے alert کو merge سے پہلے روک سکتا ہے جسے push protection نے نہیں روکا یا جس pattern کے لیے وہ configured نہیں تھی۔
دونوں controls کا عملی بہاؤ یوں بنتا ہے:
- Developer تبدیلی push کرتا ہے؛ فعال push protection matching secret ملنے پر اسی مرحلے پر push روک سکتی ہے۔
- تبدیلی pull request تک پہنچے تو secret scanning اس کے commits اور head commit کو جانچتی ہے۔
- Head scan نامکمل ہو یا منتخب secret type کا متعارف کردہ alert کھلا ہو تو branch ruleset merge روکتا ہے۔
- Bypass permission نہ رکھنے والے developer کو matching alerts resolve کرنے ہوتے ہیں؛ scan مکمل ہونے کے بعد ہی متعلقہ check کامیاب ہو سکتا ہے۔
یوں PR rule، push protection کا متبادل نہیں بلکہ بعد کا enforcement point ہے۔ مثال کے طور پر کوئی team generic patterns کو push کے وقت block نہ کرنے کا فیصلہ کر سکتی ہے، مگر انہی patterns کو merge gate میں شامل کرکے review کے دوران alert حل کروانے کی شرط رکھ سکتی ہے۔
کن plans، repositories اور secret types پر دستیاب ہے
GitHub کی configuration documentation کے مطابق protected repositories میں GitHub Secret Protection یا GitHub Advanced Security کے ساتھ secret scanning فعال ہونا ضروری ہے۔ اسی صفحے پر Secret Protection کی دستیابی GitHub Team plan کے صارفین اور GitHub Enterprise Cloud یا GitHub Enterprise Server استعمال کرنے والی enterprise organizations کے لیے بیان کی گئی ہے۔
Rule صرف repositories کی branches کو target کرنے والے rulesets میں دستیاب ہے۔ Provider، custom اور generic patterns supported ہیں، لیکن AI-detected secrets اس preview rule کے merge blocking دائرے میں شامل نہیں؛ اس لیے secret-scanning dashboard میں دکھائی دینے والا ہر alert لازماً merge gate کو فعال نہیں کرے گا۔
Repository یا organization settings میں نیا یا موجودہ branch ruleset کھول کر target repositories، branches اور blocking secret types منتخب کیے جا سکتے ہیں۔ Rule کو Active کرنے پر وہ مقررہ targets پر نافذ ہو جاتا ہے، اس لیے administrator کو activation سے پہلے scope اور موجودہ ruleset settings دیکھنی چاہییں۔
Preview rollout میں bypass اور false positives کیسے سنبھالیں
Public preview میں محدود pilot ایک محتاط انتظامی طریقہ ہے، GitHub کی لازمی release شرط نہیں۔ اس سے administrator یہ دیکھ سکتا ہے کہ منتخب patterns، پہلے سے موجود branch rules اور bypass permissions مل کر حقیقی pull requests پر کیا اثر ڈالتے ہیں۔
- تصدیق کریں کہ pilot repositories میں اہل security product اور secret scanning دونوں فعال ہیں۔
- ابتدا میں ruleset کو ایک محدود repository یا چند protected branches تک رکھیں، اور موجودہ reviews، status checks اور دوسرے merge rules درج کریں۔
- Provider patterns سے baseline بنائیں؛ custom یا generic patterns شامل کرنے سے پہلے حالیہ alerts اور dismissal reasons کا جائزہ لیں تاکہ noisy matches سامنے آ سکیں۔
- Ruleset کی bypass list دیکھیں: کن roles، teams یا integrations کو استثنا حاصل ہے، اور کیا یہ دائرہ عملی ضرورت تک محدود ہے۔
- کسی حقیقی credential کے بجائے محفوظ test pattern یا واضح غیر حقیقی قدر سے تصدیق کریں کہ alert کھلا رہنے پر merge رکتا اور resolution کے بعد check دوبارہ چلتا ہے۔
GitHub کی تصدیق شدہ حد یہ ہے کہ bypass permission نہ رکھنے والے developer کو ہر blocking alert resolve کرنا ہوگا۔ Operational audit میں blocked PRs، alert resolutions، ruleset changes اور استعمال ہونے والے bypass کو ساتھ دیکھنا مفید ہے؛ صرف rule کا configured نظر آنا اس کے مؤثر نفاذ کا ثبوت نہیں۔
Public preview کی حد ابھی برقرار ہے
Rule فی الحال public preview میں ہے اور GitHub کی documentation کے مطابق تبدیل ہو سکتا ہے۔ اسے generally available یا تمام public اور open-source repositories کے لیے شامل سمجھنا درست نہیں؛ دستیابی repository کے security product، secret-scanning configuration اور branch ruleset پر منحصر ہے۔
اس وقت واضح نتیجہ یہ ہے کہ اہل GitHub repositories میں unresolved secret alerts کو PR merge کی قابل نفاذ شرط بنایا جا سکتا ہے، مگر protection منتخب patterns اور bypass policy کے دائرے تک محدود رہتی ہے۔ آئندہ اہم تبدیلی general availability یا supported secret types اور plan coverage سے متعلق کسی سرکاری update کی صورت میں آئے گی؛ تب تک preview کی موجودہ حدود ہی نافذ سمجھی جائیں گی۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔