AI سے لیس GitHub Actions کو محض ایک کمنٹ کے ذریعے ہائی جیک کیا جا سکتا ہے، جس سے API keys، کلاؤڈ ٹوکنز اور دیگر خفیہ معلومات (secrets) لیک ہو سکتی ہیں۔ ایک سیکیورٹی محقق نے 22 ایسے اوپن سورس ریپوزٹریز کا پتہ لگایا ہے جہاں ایک عوامی ٹرگر، "skip prompts" فلیگ کے ساتھ چلنے والا ایک AI ٹول، اور ظاہر شدہ سیکرٹس مل کر ڈیٹا چوری کرنے کا ایک سیدھا راستہ بنا دیتے ہیں۔
یہ نقص کیسے کام کرتا ہے
اب پروجیکٹس AI ایجنٹس—جیسے Claude Code، GitHub Copilot CLI، اور اسی طرح کے ٹولز—کو براہ راست CI پائپ لائنز میں شامل کر رہے ہیں۔ ایک ورک فلو سٹیپ شیل کمانڈ (shell command) چلاتا ہے اور اکثر ایک ایسا فلیگ شامل کرتا ہے جو ٹول کو انٹرایکٹو اجازت کی درخواستوں کو نظر انداز کرنے کا کہتا ہے۔ جب ورک فلو کسی بھی عوامی ان پٹ—جیسے کہ کوئی ایشو (issue)، کمنٹ، یا پرل ریکوسٹ (pull-request) کے عنوان—پر شروع ہوتا ہے، تو حملہ آور کو صرف ٹیکسٹ کی ایک ایسی لائن پوسٹ کرنے کی ضرورت ہوتی ہے جسے AI ایک کمانڈ کے طور پر سمجھے گا۔
AI، جسے "skip prompts" فلیگ کے ذریعے پہلے ہی غیر محدود شیل رسائی (unrestricted shell access) دے دی گئی ہوتی ہے، ورک فلو کے ذریعے ظاہر کیے گئے کسی بھی انوائرمنٹ ویری ایبل (environment variable) یا فائل کو پڑھ لیتا ہے۔ اگر جاب میں سیکرٹس—جیسے API keys، کلاؤڈ سروس ٹوکنز، یا مکمل سروس اکاؤنٹ کی کریڈنشلز—بھی لوڈ کیے جاتے ہیں—تو AI ان ویلیوز کو حملہ آور کے کنٹرول والے سرور پر بھیج دیتا ہے۔ نہ کوئی کوڈ کی تبدیلی، نہ کوئی نئی ڈیپینڈینسی، بس ایک بے ضرر نظر آنے والا کمنٹ۔
حقیقی دنیا کی مثالیں
محقق نے تین ایسے کمزور ریپوزٹریز کی تصدیق کی ہے جنہیں پہلے ہی پیچ (patch) کیا جا چکا ہے:
- pymc-labs/pymc-marketing – پرامپٹ انجیکشن (prompt injection) کے ذریعے Anthropic API key تک رسائی حاصل کرنے کے لیے ایک عوامی ایشو کا استعمال کیا جا سکتا تھا۔
- MadAppGang/dingo – ورک فلو نے Claude Code کو مکمل Bash رسائی دی اور اسی جاب میں دو سیکرٹس ظاہر کر دیے۔
- MadAppGang/claudish – dingo پروجیکٹ کے ہی کمزور ٹیمپلیٹ کو دوبارہ استعمال کیا گیا۔
ایک دریافت میں ایک لائیو کلاؤڈ سروس اکاؤنٹ کی (key) شامل تھی، جسے محقق نے براہ راست ایک بڑے AI فراہم کنندہ کی سیکیورٹی ٹیم کو رپورٹ کیا۔ مزید بارہ رپورٹس مینیٹینرز کے پاس زیر التوا ہیں؛ ان کے نام تب تک ظاہر نہیں کیے جائیں گے جب تک کہ ان کی اصلاح (fixes) لائیو نہیں ہو جاتی۔
کیا خطرے میں ہے
جب کوئی حملہ آور کوئی سیکرٹ نکال لیتا ہے، تو نقصان فوری اور مہنگا ہو سکتا ہے۔ ایک کلاؤڈ سروس اکاؤنٹ کی (key) کمپیوٹ ریسورسز، اسٹوریج بکٹس اور دیگر بامعاوضہ خدمات تک غیر محدود رسائی فراہم کرتی ہے۔ ایک لارج لینگویج ماڈل (LLM) فراہم کنندہ کی API key لامحدود کوئریز چلا سکتی ہے، جس سے ممکنہ طور پر ہزاروں ڈالر کے اخراجات ہو سکتے ہیں۔ چونکہ یہ ایکسپلائٹ (exploit) CI ماحول کے اندر چلتا ہے، اس لیے یہ خلاف ورزی آگے کی طرف پھیل سکتی ہے: کسی بھی متاثرہ رنر (runner) پر بنایا گیا کوئی بھی آرٹفیکٹ (artifact) نقصان دہ کوڈ لے جا سکتا ہے، جس سے ایک واحد ریپوزٹری سپلائی چین ویکٹر (supply-chain vector) میں بدل سکتی ہے۔
ان ٹیموں کے لیے جو AI سے مدد یافتہ CI پر انحصار کرتی ہیں، یہ توازن بہت اہم ہے۔ خودکار طریقے سے تیار کردہ کوڈ، لنٹنگ (linting) یا دستاویزات کی سہولت کا موازنہ اس خطرے سے کرنا ضروری ہے کہ ایک عوامی کمنٹ ایک خفیہ بیک ڈور (backdoor) بن سکتا ہے۔
اس نقص کو نظر انداز کرنا کیوں آسان ہے
محقق نے شروع میں چھ رپورٹس جمع کرائی تھیں جنہیں بعد میں واپس لے لیا گیا۔ یہ واپسی GitHub Actions کے پرمیشن چیکس کے بارے میں مفروضوں کی وجہ سے تھی، نہ کہ ایکشن کے سورس کوڈ کے لائن بہ لائن جائزے کی وجہ سے۔ دستاویزات اور وجدان (intuition) گمراہ کن ہو سکتے ہیں؛ AI سے لیس سٹیپ کی سیکیورٹی کی تصدیق کرنے کا واحد قابل اعتماد طریقہ وہ کوڈ معائنہ کرنا ہے جو ٹول کو چلاتا ہے اور وہ ورک فلو YAML ہے جو اسے آپس میں جوڑتا ہے۔
بچاؤ کے اقدامات کی فہرست (Mitigation checklist)
اگر آپ GitHub Actions ورک فلو کے اندر کوئی AI CLI یا اسی طرح کا ٹول چلاتے ہیں، تو مرج (merge) کرنے سے پہلے ان دو سوالات کے جوابات دیں:
ورک فلو کو کون ٹرگر کر سکتا ہے؟ ٹرگرز کو قابل اعتماد ایونٹس (مثلاً محفوظ برانچز پر پش کرنا) تک محدود رکھیں یا بیرونی حصہ داروں (external contributors) کے ذریعے شروع کیے گئے رنز کے لیے واضح منظوری درکار کریں۔ اضافی گیٹنگ (gating) کے بغیر
on: issue_commentیاon: issuesسے پرہیز کریں۔اسی جاب میں کون سے سیکرٹس لوڈ کیے گئے ہیں؟ ایسی جاب میں کبھی بھی API keys، کلاؤڈ ٹوکنز، یا سروس اکاؤنٹ کی کریڈنشلز ظاہر نہ کریں جو غیر محدود شیل رسائی کے ساتھ AI ایجنٹ بھی چلا رہی ہو۔ سیکرٹ سے بھرپور سٹیپس کو الگ جابز یا رنرز میں تقسیم کریں جو AI ٹولز کو کال نہ کرتے ہوں۔
مزید مضبوط بنانے کے اقدامات:
- اس فلیگ کو ہٹا دیں جو پرمیشن پرامپٹس کو چھوڑ دیتا ہے، تاکہ AI ٹول کو شیل کمانڈز چلانے سے پہلے واضح تصدیق کے لیے مجبور کیا جا سکے۔
- ایک ایسا سٹیپ شامل کریں جو کسی بھی انوائرمنٹ ویری ایبل کو صاف (sanitize) یا چھپا (redact) دے جسے AI ٹول پڑھ سکتا ہو۔
- نیٹ ورک ایگریس (egress) کنٹرولز کے ساتھ سیلف ہوسٹڈ رنرز کا استعمال کریں تاکہ کسی بھی غیر متعلقہ اینڈ پوائنٹ پر ڈیٹا بھیجنے (exfiltration) کو روکا جا سکے۔
دوسرا پہلو: CI میں AI کی افادیت
حامیوں کا کہنا ہے کہ پیداواری صلاحیت میں اضافہ خطرے سے زیادہ اہم ہے۔ خودکار کوڈ تجاویز ریویو کے وقت کو کم کرتی ہیں، اور AI سے چلنے والی ٹیسٹنگ بگ کو جلد سامنے لاتی ہے۔ تاہم، یہی سہولت حملے کی سطح (attack surface) کو بڑھا دیتی ہے۔ کلید یہ نہیں ہے کہ AI کو چھوڑ دیا جائے بلکہ کسی بھی ایسے ٹول کے ساتھ پیش آنا ہے جس کے پاس شیل لیول کے اختیارات ہوں، اسے ایک ممکنہ ویکٹر کے طور پر سمجھا جائے۔
آگے کیا نظر رکھنا ہے
ان نتائج نے GitHub کے سیکیورٹی فورمز پر AI سے لیس Actions کے لیے سخت تر ڈیفالٹ اجازتوں کے حوالے سے بحث چھیڑ دی ہے۔ مستقبل کی پلیٹ فارم اپ ڈیٹس میں درج ذیل چیزیں شامل ہو سکتی ہیں:
- ایک ایسا flag جو AI ٹولز کو براہ راست shell رسائی کے بغیر ایک sandboxed ماحول میں چلنے پر مجبور کرے۔
- issue کے متن یا کمنٹس میں prompt-injection پیٹرنز کی بلٹ ان شناخت۔
- جب کوئی workflow پبلک ٹریگرز کو secrets والے jobs کے ساتھ ملا دیتا ہے تو خودکار الرٹس۔
فی الحال، ذمہ داری repository maintainers پر ہے۔ شناخت شدہ 22 repositories سے ظاہر ہوتا ہے کہ یہ مسئلہ صرف ایک جگہ تک محدود نہیں ہے؛ کوئی بھی پروجیکٹ جو اسی طرح کے workflow پیٹرن پر مبنی ہو، خطرے سے دوچار ہو سکتا ہے۔ CI کنفیگریشنز کا ایک فوری آڈٹ حملہ آور سے پہلے مسئلے کو بے نقاب کر سکتا ہے۔
حاصلِ کلام: پبلک GitHub issue میں متن کی ایک لائن بھی ایک AI agent کو آپ کے CI ماحول پر مکمل کنٹرول دے سکتی ہے اور وہاں محفوظ کیے گئے secrets چرا سکتی ہے۔ تصدیق کریں کہ کون آپ کے workflows چلا سکتا ہے، secrets کو AI سے چلنے والے مراحل سے دور رکھیں، اور ہر اس flag کا باریک بینی سے جائزہ لیں جو غیر محدود اجازتیں دیتا ہے۔ ایک breach کی قیمت ایک منظم جائزے کی کوشش سے کہیں زیادہ ہے۔