ایک ڈویلپر، کسٹمر کی تلاش (search) کی ناکام ہونے والی استفسار (query) کو درست کرنے کے لیے اسسٹنٹ سے مدد لیتا ہے۔ تجویز کردہ پیچ (patch) ٹیسٹ کو تو کامیاب بنا دیتا ہے، لیکن ‘ٹیننٹ’ (tenant) کی حد تک محدود فلٹر کو ہٹا کر صرف customerId کی بنیاد پر تلاش کا طریقہ کار نافذ کر دیتا ہے۔ ‘پل ریکوئسٹ’ (pull request) کے ضم (merge) ہونے کے بعد، کوئی ایسا صارف جو کسی دوسرے ٹیننٹ کا شناخت کنندہ (identifier) جانتا ہو، اس دوسرے ٹیننٹ کے کسٹمر کا ریکارڈ حاصل کر سکتا ہے۔ حملہ آور کو ریپوزٹری، CI سسٹم، یا کوڈنگ اسسٹنٹ تک رسائی کی ضرورت نہیں پڑتی؛ وہ صرف ایک عام ایپلیکیشن ریکوئسٹ کا استعمال کرتا ہے جو ایسے اینڈ پوائنٹ (endpoint) پر بھیجی جاتی ہے جس کا اجازت نامے کی جانچ (authorization check) والا عمل خاموشی سے ختم ہو چکا ہوتا ہے۔
غیر مصدقہ تبدیلی (untrusted change) سے مراد کوڈ، ڈیپینڈنسی، کنفیگریشن، یا ورک فلو میں کی جانے والی کوئی بھی ایسی مجوزہ ترمیم ہے جو ابھی تک اس کے تخلیق کار سے آزادانہ جانچ کے مراحل (controls) سے نہیں گزری ہے۔ اسسٹنٹ کا آؤٹ پٹ بھی اسی زمرے میں آتا ہے، چاہے وہ کامیابی سے کمپائل ہو جائے، اس کی معقول وضاحت موجود ہو، اور وہ رپورٹ شدہ نقص کو دور کر دے۔ اسسٹنٹ نے یہ متن ‘پرامپٹ’ (prompt) اور ریپوزٹری کے سیاق و سباق (context) کی بنیاد پر تیار کیا ہوتا ہے۔ ان میں سے کوئی بھی پہلو اس بات کا ثبوت نہیں دیتا کہ نتیجے میں بننے والی استفسار (query) ایپلیکیشن کی ‘ٹیننٹ باؤنڈری’ (ٹیننٹ کے درمیان حد بندی) کو برقرار رکھتی ہے۔
متعلقہ عمل کئی حدود (boundaries) کو عبور کرتا ہے۔ اسسٹنٹ کا پیچ، اس کا تجویز کردہ پیکیج ورژن، اور کوئی بھی تیار کردہ کنفیگریشن، ریپوزٹری میں ‘غیر مصدقہ آرٹیفیکٹس’ (untrusted artifacts) کے طور پر داخل ہوتے ہیں۔ CI مجوزہ تبدیلی کا جائزہ تو لیتا ہے لیکن خودکار طور پر یہ تصدیق نہیں کرتا کہ اجازت نامے کی جانچ (authorization) درست ہے۔ پروڈکشن ماحول میں صرف ضم شدہ آرٹیفیکٹ ہی چلتا ہے، جہاں غائب شدہ فلٹر کی وجہ سے ایک کسٹمر کا ڈیٹا دوسرے ٹیننٹ کے سامنے ظاہر ہو جاتا ہے۔ ذیل میں دیا گیا باؤنڈری میپ ان آرٹیفیکٹس کو الگ الگ ظاہر کرتا ہے:
باؤنڈری میپ (حد بندی کا نقشہ) ظاہر کرتا ہے کہ یہ عمل ایک ہی سیکیورٹی معاہدے (security contract) کو کیوں استعمال کرتا ہے۔ AI کے تیار کردہ ہر آرٹیفیکٹ (کوڈ یا فائل) کو اس وقت تک ناقابلِ اعتماد سمجھیں جب تک کہ آزادانہ انسانی جائزے اور مطلوبہ خودکار جانچ پڑتال اس تبدیلی کو قبول نہ کر لیں۔ ماڈل کبھی بھی نفاذ کا نقطہ (enforcement point) نہیں ہوتا۔ ‘ٹیننٹ آئسولیشن’ (tenant isolation) کا مطالبہ کرنے والا پرامپٹ (prompt) محض ایک ترجیح ہے جو تجویز کردہ کوڈ کے ساتھ ہی اسی چینل سے آتی ہے، نہ کہ کوئی ایسا کنٹرول جو غیر محفوظ انضمام (merge) کو روک سکے۔
کسٹمر سرچ پیچ (patch) کے معاملے میں، پل ریکوئسٹ (pull request) کا جائزہ لینے والا یہ چیک کرتا ہے کہ آیا استفسار (query) اب بھی تصدیق شدہ صارف کے ٹیننٹ کے استحقاق (tenant entitlement) کا اطلاق کرتا ہے یا نہیں۔ CI (مسلسل انضمام) مختلف شواہد کی جانچ کرتا ہے: سورس اینالائسز نفاذ کے نمونوں (implementation patterns) کا جائزہ لیتا ہے، ڈیپینڈنسی اینالائسز نئے شامل کیے گئے پیکیج کو دیکھتا ہے، اور سیکرٹ اسکیننگ اسناد (credentials) کے لیے تبدیل شدہ سورس اور کنفیگریشن کی جانچ کرتی ہے۔ ریپوزٹری برانچ پروٹیکشن ان جانچ پڑتالوں اور منظوریوں کو لازمی قرار دے کر انضمام کے فیصلے کا نفاذ کرتی ہے۔ کسی بھی کنٹرول کا انحصار اسسٹنٹ کے اس دعوے پر نہیں ہونا چاہیے کہ پیچ محفوظ ہے۔
امتحانی اصول
AI کا تیار کردہ کوڈ صرف تب قبول کیا جاتا ہے جب آزادانہ جائزہ اور مطلوبہ سیکیورٹی گیٹس (security gates) ریکارڈ شدہ شواہد فراہم کریں۔ ماڈل کا آؤٹ پٹ اور پرامپٹ کی عبارت رسائی کے کنٹرول (access control) کا نفاذ نہیں کرتے۔
ہر کنٹرول کی ایک حد ہوتی ہے۔ جائزے کے دوران ڈیٹا کے بہاؤ (data-flow) کی کوئی باریک غلطی چھوٹ سکتی ہے، لہذا خودکار جانچ پڑتال ایک اور اشارہ فراہم کرتی ہے۔ اسکینر سے ایسی اجازت نامہ جاتی منطق (authorization logic) چھوٹ سکتی ہے جس کے لیے ایپلی کیشن کے سیاق و سباق (context) کی ضرورت ہو، لہذا ماہرانہ جائزہ لازمی رہتا ہے۔ کامیاب پائپ لائن کمزوریوں (vulnerabilities) کی عدم موجودگی کا ثبوت نہیں دیتی۔ یہ صرف اس بات کو ثابت کرتی ہے کہ اس نظرثانی (revision) کے لیے طے شدہ گیٹ کے شواہد موجود ہیں۔ جب کوئی مطلوبہ گیٹ ناکام ہو جاتا ہے، تو ریپوزٹری اس نتیجے کو ریکارڈ کرتی ہے، پالیسی کے مطابق انضمام کو روکتی ہے، اور قبولیت یا استثنیٰ کے فیصلے کے لیے آڈٹ ٹریل (audit trail) محفوظ رکھتی ہے۔
زیرِ عمل آرٹیفیکٹ ایک ‘پل ریکوئسٹ’ ہے جو ملٹی ٹیننٹ ویب سروس میں GET /search?q=... کا اضافہ کرتی ہے اور ٹیکسٹ سرچ کی ڈیپینڈنسی (dependency) شامل کرتی ہے۔ صارف کی درخواست ایک ناقابلِ اعتماد ان پٹ ہوتی ہے۔ ہینڈلر تصدیق شدہ صارف کی شناخت وصول کرتا ہے، ڈیٹا بیس کیوری تیار کرتا ہے، اور ڈیٹا بیس کی جانب سے قطاریں (rows) واپس کرنے سے پہلے اس صارف کے ٹیننٹ کے استحقاق کا اطلاق لازمی طور پر کرتا ہے۔ ڈیٹا بیس آپریشن ایپلیکیشن کی ‘سروس شناخت’ (service identity) کے تحت چلتا ہے، جبکہ کوئری یا پالیسی لیئر اس بات کا تعین کرتی ہے کہ اینڈ یوزر (صارف) کیا دیکھ سکتا ہے۔ اگر نیا اینڈ پوائنٹ درخواست سے tenantId کو تصدیق شدہ استحقاق (authenticated entitlement) سے موازنہ کیے بغیر قبول کر لیتا ہے، تو اس کے نتیجے میں ہونے والے ممکنہ نقصان کا دائرہ کار (blast radius) اس سروس شناخت کے ذریعے قابلِ رسائی ہر ریکارڈ تک پھیل سکتا ہے۔
‘پل ریکوئسٹ’ (pull request) بذاتِ خود بھی ناقابلِ اعتماد ہوتی ہے۔ اس کے ‘ڈِف’ (diff - تبدیلیوں کا موازنہ) میں ‘ٹیننٹ پریڈیکیٹ’ (tenant predicate) کو ہٹایا جا سکتا ہے، اس کے ‘ڈیپینڈنسی مینیفیسٹ’ (dependency manifest) میں کوئی کمزور یا نامناسب پیکیج شامل ہو سکتا ہے، اور اس کی تیار کردہ کنفیگریشن میں کوئی خفیہ معلومات (secret) بے نقاب ہو سکتی ہیں۔ اسسٹنٹ کی وضاحت ان میں سے کسی بھی سوال کا حتمی جواب نہیں دے سکتی۔ اصل شواہد ‘ڈِف’، تبدیل شدہ ‘ڈیپینڈنسی مینیفیسٹ’، اسکینر کی کیٹیگریز، جائزہ لینے والے کی منظوری، اور ‘مرج ریکارڈ’ (merge record) سے حاصل ہوتے ہیں۔
اسٹیٹک ایپلیکیشن سیکیورٹی ٹیسٹ (Static Application Security Test) معروف کمزوریوں کے نمونوں (patterns) کے لیے سورس کوڈ اور کوڈ کی سطح پر ڈیٹا کے بہاؤ کو اسکین کرتا ہے۔ سافٹ ویئر کمپوزیشن اینالائسز (Software Composition Analysis) سپلائی چین کے حالات کے تناظر میں ڈیپینڈنسیز اور اجزاء کے میٹا ڈیٹا کا جائزہ لیتا ہے۔ ‘سیکرٹ اسکیننگ’ (Secret scanning) ریپوزٹری کے تبدیل شدہ آرٹیفیکٹس میں ایسے اسناد (credentials) یا ٹوکنز کو تلاش کرتی ہے جنہیں کمٹ (commit) نہیں کیا جانا چاہیے۔ چونکہ یہ جانچ پڑتال مختلف آرٹیفیکٹس کا معائنہ کرتی ہے، اس لیے ایک ٹیسٹ کا کامیاب نتیجہ دوسرے کی جگہ نہیں لے سکتا۔ درخواست کا راستہ (request path) اور CI کا راستہ یہ ظاہر کرتے ہیں کہ تجاویز کہاں سے آتی ہیں اور تصدیق کا عمل کہاں قبولیت کے شواہد فراہم کرتا ہے: