Noma Labs نے دکھایا ہے کہ AI سے چلنے والی خودکاری (automation) کے ذریعے ایک واحد عوامی GitHub issue نجی ریپوزٹریز (private repositories) سے کوڈ چوری کر سکتا ہے۔ ان کا proof-of-concept ایک حملہ آور کو کسی تنظیم کے اپنے ورک فلو بوٹس (workflow bots) کو اسی کے خلاف استعمال کرنے کی اجازت دیتا ہے، جس سے GitHub کی تصدیق (authentication) کو توڑے بغیر ملکیتی فائلیں لیک ہو جاتی ہیں۔

حملے کا واضح منظر

واقعات کا سلسلہ اتنا سادہ ہے کہ اسے دوبارہ پیدا کیا جا سکتا ہے:

  • ایک حملہ آور ایک عوامی ریپوزٹری میں ایک issue تخلیق کرتا ہے جسے کوئی بھی دیکھ سکتا ہے۔
  • ایک AI ایجنٹ، جو continuous-integration پائپ لائن سے منسلک ہے، issue کے عنوان اور متن کو پڑھتا ہے۔
  • اسی ایجنٹ کے پاس پہلے سے ہی تنظیم کی دیگر نجی ریپوزٹریز کے لیے read permissions موجود ہوتی ہیں۔
  • عوامی issue میں چھپی ہوئی ہدایات ایجنٹ کو بتاتی ہیں کہ کون سی نجی فائلیں حاصل کرنی ہیں۔
  • ایجنٹ حاصل کردہ فائلوں کو عوامی issue پر بطور کمنٹ پوسٹ کر دیتا ہے، جس سے وہ دنیا کے سامنے آ جاتی ہیں۔

یہ سب خودکاری کے ایک ہی مرحلے (run) میں ہو جاتا ہے۔ نہ کوئی کریڈنشل چوری، نہ API-key کا لیک ہونا، اور نہ ہی GitHub میں کوئی کمزوری۔ حملہ آور محض اس اعتماد کا فائدہ اٹھاتا ہے جو تنظیم نے اپنے ہی بوٹ پر کیا ہوتا ہے۔

یہ اب کیوں اہم ہے

AI سے چلنے والے ایجنٹس اب جدید ڈویلپمنٹ پائپ لائنز کو آپس میں جوڑتے ہیں۔ وہ pull-requests کھولتے ہیں، ٹیسٹ چلاتے ہیں، builds تعینات کرتے ہیں، اور بگ ٹریاج (triage bugs) کرتے ہیں—یہ سب issue کمنٹس جیسے ہلکے پھلکے سگنلز سے شروع ہوتے ہیں۔ جب ان ایجنٹس کے پاس ریپوزٹری تک وسیع رسائی ہوتی ہے، تو قابل اعتماد ڈیٹا اور ناقابل اعتماد صارف ان پٹ کے درمیان فرق دھندلا جاتا ہے۔

اگر ایک ایجنٹ ایک ہی عمل (execution) میں نجی کوڈ پڑھ سکتا ہے اور عوامی طور پر لکھ سکتا ہے، تو تنظیم کا access-control ماڈل مکمل طور پر ناکام ہو جاتا ہے۔

اصل خامی: اجازتیں (permissions)، نہ کہ ماڈل

یہ مظاہرہ بنیادی AI ماڈل کو موردِ الزام نہیں ٹھہراتا۔ ماڈل محض ان ہدایات پر عمل کرتا ہے جو اسے موصول ہوتی ہیں۔ کمزوری خود اس اجازت کے سیٹ (permission set) میں ہے جو خودکاری (automation) کو دی گئی ہے:

  • Read access تنظیم بھر کی نجی ریپوزٹریز تک۔
  • عوامی issue تھریڈز تک Write access۔
  • عوامی متن پر Trigger جسے کوئی بھی تیار کر سکتا ہے۔

حل جو مفت ہیں، لیکن مؤثر ہیں

'کم سے کم مراعات کے اصول' (principle of least privilege) پر عمل کرنے سے حملے کا راستہ کم ہو جاتا ہے:

  • بوٹ کا دائرہ کار (Scope the bot) صرف اسی ریپوزٹری تک محدود رکھیں جہاں اس کی ضرورت ہے۔ اگر اسے صرف ایک مخصوص ریپوزٹری پر کام کرنے کی ضرورت ہے، تو اسے کسی بھی دوسری read رسائی سے روک دیں۔
  • Read اور write ٹوکنز کو الگ رکھیں۔ کوڈ حاصل کرنے کے لیے ایک کریڈنشل استعمال کریں اور کمنٹس پوسٹ کرنے کے لیے دوسرا، سختی سے کنٹرول شدہ کریڈنشل استعمال کریں۔
  • کسی بھی عوامی پوسٹنگ سے پہلے انسانی منظوری (Human approval)۔ ایک ہلکا پھلکا ریویو مرحلہ—جیسے کہ مطلوبہ منظوری لیبل—پائپ لائن کو روکے بغیر ایک چیک پوائنٹ کا اضافہ کرتا ہے۔
  • بلیکٹ ریڈیس (Blast-radius) میں کمی۔ ورک فلو کو اس طرح ڈیزائن کریں کہ کوئی خرابی یا غلط استعمال زیادہ سے زیادہ ایک ریپوزٹری کو متاثر کرے، پوری تنظیم کو نہیں۔

جوابی نکتہ: آپریشنل اوور ہیڈ (operational overhead)

آگے کیا نظر رکھنا ہے

حاصلِ کلام (Takeaway): اگر ایک AI خودکاری نجی کوڈ دیکھ بھی سکتی ہے اور عوامی طور پر بات بھی کر سکتی ہے، تو سسٹم کی ڈیزائننگ غلط ہے۔ اجازتوں کو سخت کریں، انسانی چیک شامل کریں، اور بلیکٹ ریڈیس کو چھوٹا رکھیں—ورنہ ایک واحد عوامی issue ڈیٹا لیک کرنے کا ذریعہ بن سکتا ہے۔