Codex Security میں SAST رپورٹ کیوں شامل نہیں ہوتی؟

کئی دہائیوں سے، جامد ایپلیکیشن سیکیورٹی ٹیسٹنگ (SAST) سیکیورٹی ٹیموں کے لیے کوڈ ریویو کو بڑے پیمانے پر انجام دینے کے سب سے مؤثر طریقوں میں سے ایک رہا ہے. 

لیکن جب ہم نے Codex Security بنایا، تو ہم نے جان بوجھ کر ڈیزائن کا انتخاب کیا: ہم نے ایک جامد تجزیہ رپورٹ درآمد کرکے اور ایجنٹ سے اسے ٹرائیج کرنے کے لیے نہیں کہا۔ ہم نے نظام کو اس طرح ڈیزائن کیا کہ وہ ریپوزٹری ہی سے آغاز کرے—اس کے آرکیٹیکچر، اعتماد کی حدود، اور مطلوبہ رویے سے—اور جو کچھ وہ پاتا ہے اسے اس سے پہلے توثیق کرے کہ وہ کسی انسان سے اس پر وقت لگانے کا کہے. 

وجہ سادہ ہے: سب سے مشکل کمزوریاں عموماً ڈیٹا فلو کے مسائل نہیں ہوتیں. یہ اُس وقت ہوتا ہے جب کوڈ سیکیورٹی چیک نافذ کرتا ہوا دکھائی دے، لیکن وہ چیک درحقیقت اُس خاصیت کی ضمانت نہیں دیتا جس پر نظام انحصار کرتا ہے. باالفاظ دیگر، چیلنج صرف یہ نہیں ہے کہ ڈیٹا کسی پروگرام کے ذریعے کیسے حرکت کرتا ہے—بلکہ یہ تعین کرنا ہے کہ کوڈ میں موجود دفاع واقعی کام کرتے ہیں یا نہیں.

SAST کو اکثر ایک صاف پائپ لائن کے طور پر پیش کیا جاتا ہے: ناقابل اعتماد اِن پُٹ کے ایک ماخذ کی شناخت کریں، پروگرام کے ذریعے ڈیٹا کو ٹریک کریں اور ایسے کیسز کو فلیگ کریں جہاں وہ ڈیٹا سینیٹائزیشن کے بغیر کسی حساس سنک تک پہنچ جاتا ہے. یہ ایک نفیس ماڈل ہے اور یہ بہت سے حقیقی بگز کا احاطہ کرتا ہے.

عملی طور پر، SAST کو بڑے پیمانے پر قابلِ عمل رہنے کے لیے اندازے لگانے پڑتے ہیں—خاص طور پر حقیقی کوڈ بیس میں جس میں انڈائریکشن، ڈائنامک ڈسپیچ، کال بیکس، ریفلیکشن اور فریم ورک ہیوی کنٹرول فلو ہے. یہ اندازے SAST پر کوئی تنقید نہیں ہیں؛ یہ اس حقیقت کی عکاسی کرتے ہیں کہ کوڈ کو چلائے بغیر اس کے بارے میں استدلال کرنے کی کوشش کی جا رہی ہے.

یہی وجہ نہیں ہے کہ Codex Security SAST رپورٹ سے شروع نہیں کرتا.

گہرا مسئلہ یہ ہے کہ جب آپ کامیابی سے کسی سورس کو ایک سنک تک ٹریس کر لیتے ہیں تو اس کے بعد کیا ہوتا ہے.

یہاں تک کہ جب جامد تجزیہ درست طور پر ان پٹ کو مختلف فنکشنز اور پرتوں کے ذریعے ٹریس کر لیتا ہے، تب بھی اسے اس سوال کا جواب دینا ہوتا ہے جو یہ طے کرتا ہے کہ آیا کوئی کمزوری موجود ہے یا نہیں:

ایک عام پیٹرن لیجیے: کوڈ ناقابل اعتماد مواد کو رینڈر کرنے سے پہلے کچھ ایسا کال کرتا ہے جیسے sanitize_html(). ایک جامد اینالائزر دیکھ سکتا ہے کہ سینیٹائزر چلا تھا. جو چیز یہ عام طور پر طے نہیں کر پاتا وہ یہ ہے کہ آیا وہ سینیٹائزر واقعی شامل مخصوص رینڈرنگ سیاق و سباق، ٹیمپلیٹ انجن، انکوڈنگ رویے اور ڈاؤن اسٹریم تبدیلیوں کے لیے کافی ہے یا نہیں.

یہیں چیزیں مشکل ہو جاتی ہیں. مسئلہ صرف یہ نہیں ہے کہ آیا ڈیٹا کسی سنک تک پہنچتا ہے. یہ بات ہے کہ آیا کوڈ میں موجود چیکس واقعی قدر کو اس طریقے سے محدود کرتے ہیں جس طرح سسٹم یہ فرض کرتا ہے کہ وہ کرتے ہیں.

باالفاظ دیگر: "کوڈ ایک سینیٹائزر کو کال کرتا ہے" اور "نظام محفوظ ہے."کے درمیان واضح فرق موجود ہے.

یہ ایک ایسا نمونہ ہے جو حقیقی سسٹمز میں اکثر نظر آتا ہے.

ایک ویب ایپلیکیشن ایک JSON پے لوڈ وصول کرتی ہے، اس میں سے ایک redirect_url نکالتی ہے، اسے allowlist regex کے خلاف ویلیڈیٹ کرتی ہے، اسے URL-ڈی کوڈ کرتی ہے اور نتیجے کو ایک ری ڈائریکٹ ہینڈلر کو پاس کرتی ہے.

ایک کلاسک ماخذ سے منزل تک کی رپورٹ بہاؤ کو بیان کر سکتی ہے:

ناقابل اعتماد اِن پٹ → regex چیک → URL ڈیکوڈ → ری ڈائریکٹ

لیکن اصل سوال یہ نہیں ہے کہ چیک موجود ہے یا نہیں. یہ اس بات پر منحصر ہے کہ آیا وہ چیک بعد میں آنے والی ٹرانسفارمیشنز کے بعد بھی قدر کو پابند رکھتا ہے.

اگر regex ڈیکوڈنگ سے پہلے چلتا ہے، تو کیا یہ واقعی ڈیکوڈ کیا گیا URL کو اسی طرح محدود کرتا ہے جیسے ری ڈائریکٹ ہینڈلر اسے سمجھتا ہے؟

اس کا جواب دینے کا مطلب یہ ہے کہ پوری تبدیلی کی زنجیر کے بارے میں ریزننگ: ریجیکس کس چیز کی اجازت دیتا ہے، کیسے ڈی کوڈنگ اور نارملائزیشن برتاؤ کرتا ہے، URL پارسنگ ایج کیسز کو کیسے ٹریٹ کرتی ہے اور ری ڈائریکٹ منطق اسکیموں اور حکام کو کیسے حل کرتی ہے۔

بہت سی کمزوریاں جو عملی طور پر اہمیت رکھتی ہیں اس طرح نظر آتی ہیں: آپریشنز کی غلطیاں، جزوی نارملائزیشن، ابہام کو پارس کرنا اور توثیق اور تشریح کے درمیان مماثلت نہیں ہے۔ ڈیٹا فلو نظر آتا ہے. کمزوری اس بات میں ہے کہ پابندیاں تبدیلی کی زنجیر کے ذریعے کیسے آگے منتقل ہوتی ہیں—یا منتقل ہونے میں ناکام رہتی ہیں.

یہ محض ایک نظریاتی پیٹرن نہیں ہے. CVE-2024-29041⁠(نئی ونڈو میں کھلتا ہے) میں، ایکسپریس ایک اوپن ری ڈائریکٹ مسئلے سے متاثر تھا جس میں خراب شکل والی URLs عام allowlist امپلیمنٹیشنز کو بائی پاس کر سکتی تھیں کیونکہ ری ڈائریکٹ ٹارگٹس کو انکوڈ کرنے اور پھر ان کی تشریح کرنے کا طریقہ ایسا تھا. ڈیٹا فلو سیدھا سادہ تھا. زیادہ مشکل سوال—اور وہی جس نے یہ طے کیا کہ آیا bug موجود تھا—یہ تھا کہ آیا ٹرانسفارمیشن چین کے بعد بھی ویلیڈیشن برقرار رہتی ہے.

Codex Security ایک سادہ مقصد کے گرد بنایا گیا ہے: زیادہ مضبوط شواہد کے ساتھ مسائل کو سامنے لا کر ٹریایج کو کم کرنا. پروڈکٹ میں، اس کا مطلب ہے ریپو-مخصوص سیاق و سباق (بشمول ایک تھریٹ ماڈل) استعمال کرنا اور ہائی-سگنل مسائل کو سامنے لانے سے پہلے الگ تھلگ ماحول میں ان کی توثیق کرنا. 

جب Codex Security کو کوئی ایسی حد بندی ملتی ہے جو "ویلیڈیشن" یا "سینیٹائزیشن" جیسی لگتی ہو، تو یہ اسے چیک باکس کے طور پر نہیں لیتا. یہ سمجھنے کی کوشش کرتا ہے کہ کوڈ کس چیز کی ضمانت دینے کی کوشش کر رہا ہے—اور پھر یہ اس ضمانت کو غلط ثابت کرنے کی کوشش کرتا ہے.

عملی طور پر، یہ عموماً کچھ اس طرح کے امتزاج کی صورت میں ظاہر ہوتا ہے:

• مکمل ریپوزٹری سیاق و سباق کے ساتھ متعلقہ کوڈ پاتھ کو پڑھنا، جیسے کوئی سیکیورٹی ریسرچر کرے اور مقصد اور عمل درآمد کے درمیان فرق تلاش کرنا. اس میں تبصرے شامل ہیں، لیکن ماڈل لازمی طور پر تبصروں پر یقین نہیں کرتا، اس لیے اپنے کوڈ کے اوپر //ہیلور کہتا ہے: یہ کوئی بگ نہیں ہے شامل کرنے سے، اگر واقعی کوئی بگ ہے، تو یہ اسے الجھاتا نہیں ہے.
• مسئلے کو سب سے چھوٹے قابلِ آزمائش حصے تک محدود کرنا (مثال کے طور پر، ایک واحد اِن پٹ کے گرد ٹرانسفارمیشن پائپ لائن)، تاکہ آپ سسٹم کے باقی حصے کے بیچ میں آئے بغیر اس کے بارے میں استدلال کر سکیں. اس لحاظ سے، Codex Security باریک کوڈ کے حصے نکالتا ہے اور پھر ان کے لیے مائیکرو-فزرز لکھتا ہے.
• تبدیلیوں کے دوران ریزننگ پر غور کرنا، بجائے اس کے کہ ہر چیک کو الگ الگ سمجھا جائے. جہاں مناسب ہو، اس میں اطمینان کے سوال کے طور پر رسمی شکل دینا بھی شامل ہو سکتا ہے. دوسرے لفظوں میں، ہم ماڈل کو z3-سالور کے ساتھ ایک Python انوائرنمنٹ تک رسائی دیتے ہیں اور یہ ضرورت پڑنے پر اسے استعمال کرنے میں ماہر ہے، بالکل ویسے ہی جیسے کسی انسان کو خاص طور پر پیچیدہ ان پٹ کنسٹرینٹ پرابلم کا جواب دیتے وقت کرنا پڑتا ہے. یہ خاص طور پر نان-اسٹینڈرڈ آرکیٹیکچرز پر انٹیجر اوورفلو یا اسی طرح کے بگز کو دیکھنے کے لیے مفید ہے.
• جہاں ممکن ہو، سینڈباکسڈ ویلیڈیشن ماحول میں مفروضات کو انجام دینا، تاکہ "یہ مسئلہ ہو سکتا ہے" اور "یہ مسئلہ ہے" میں فرق کیا جا سکے. ڈی بگ موڈ میں کمپائل کیے گئے کوڈ کے ساتھ مکمل ایک سرے سے دوسرے تک PoC سے بہتر کوئی ثبوت نہیں. 

یہی بنیادی تبدیلی ہے: "ایک چیک موجود ہے" پر رکنے کے بجائے، سسٹم "یہ کہ ان ویرئینٹ برقرار ہے (یا نہیں ہے) اور یہ رہے شواہد" کی طرف آگے بڑھتا ہے. اور ماڈل اس کام کے لیے بہترین ٹول کا انتخاب کرتا ہے.

ایک معقول ردعمل یہ ہے: دونوں کیوں نہ کریں؟. SAST رپورٹ سے آغاز کریں، پھر زیادہ گہرائی سے استدلال کرنے کے لیے ایجنٹ استعمال کریں.

ایسے حالات بھی ہوتے ہیں جہاں پہلے سے تیار کردہ نتائج مددگار ثابت ہوتے ہیں، خاص طور پر محدود اور معلوم بگ کلاسز کے لیے. لیکن سیاق و سباق میں کمزوریوں کو دریافت کرنے اور ان کی توثیق کرنے کے لیے ڈیزائن کیے گئے ایک ایجنٹ کے لیے، SAST رپورٹ سے آغاز کرنے سے ناکامی کے تین متوقع موڈز پیدا ہوتے ہیں.

سب سے پہلے، یہ قبل از وقت محدودیت کی حوصلہ افزائی کر سکتا ہے. فائنڈنگز کی فہرست اس بات کا نقشہ ہے کہ ٹول نے پہلے ہی کہاں دیکھا ہے. اگر آپ اسے نقطۂ آغاز کے طور پر لیتے ہیں، تو آپ نظام کو انہی خطّوں میں غیر متناسب کوشش صرف کرنے، انہی تجریدات کو استعمال کرنے اور اُن مسائل کی اقسام کو نظر انداز کرنے کی طرف جھکا سکتے ہیں جو ٹول کے نقطۂ نظر میں فِٹ نہیں ہوتیں.

دوسرا، یہ غیر واضح فیصلے متعارف کروا سکتا ہے جنہیں واپس پلٹنا مشکل ہوتا ہے. بہت سے SAST نتائج سینیٹائزیشن، توثیق یا اعتماد کی حدود کے بارے میں مفروضوں کو اینکوڈ کرتے ہیں. اگر وہ مفروضے غلط ہوں—یا بس نامکمل ہوں—تو انہیں ریزننگ لوپ میں ڈالنا ایجنٹ کو "تحقیق کریں" سے "تصدیق کریں یا مسترد کریں" کی طرف منتقل کر سکتا ہے، جو وہ نہیں ہے جو ہم ایجنٹ سے کرنا چاہتے ہیں.

تیسرا، یہ ریزننگ سسٹم کا جائزہ لینا مزید مشکل بنا سکتا ہے. اگر پائپ لائن SAST آؤٹ پٹ سے شروع ہوتی ہے، تو یہ الگ کرنا مشکل ہو جاتا ہے کہ ایجنٹ نے اپنی تجزیہ کاری سے کیا دریافت کیا اور اس نے کسی دوسرے ٹول سے کیا اخذ کیا. یہ علیحدگی اہم ہے اگر آپ نظام کی صلاحیتوں کی درست طور پر پیمائش کرنا چاہتے ہیں، جو اس کے لیے ضروری ہے کہ نظام وقت کے ساتھ بہتر ہوتا جائے.

اسی لیے ہم نے Codex Security تیار کیا تاکہ وہاں سے آغاز کریں جہاں سیکیورٹی تحقیق شروع ہوتی ہے: کوڈ اور سسٹم کے ارادے سے اور توثیق کو اس لیے استعمال کریں کہ کسی انسان کو مداخلت کے لیے روکنے سے پہلے اعتماد کا معیار بلند ہو سکے.

SAST ٹولز اپنے مقصد میں بہترین ہو سکتے ہیں: محفوظ کوڈنگ معیارات نافذ کرنا، سیدھی سورس-ٹو-سنک مسائل کو پکڑنا اور قابلِ پیش گوئی سمجھوتوں کے ساتھ بڑے پیمانے پر معلوم پیٹرنز کا پتا لگانا. وہ دفاع کی تہہ در تہہ کا ایک مضبوط حصہ ہو سکتے ہیں.

یہ پوسٹ زیادہ محدود ہے: یہ اس بارے میں ہے کہ رویے کے بارے میں استدلال کرنے اور نتائج کی توثیق کرنے کے لیے ڈیزائن کیا گیا ایجنٹ اپنا کام ایک جامد نتائج کی فہرست سے منسلک ہو کر کیوں شروع نہیں کرنا چاہیے.

یہ خالص ماخذ سے ڈوبنے والی سوچ کی متعلقہ حد کو کال کرنے کے قابل بھی ہے: ہر کمزوری ڈیٹا فلو کا مسئلہ نہیں ہے۔ بہت سی حقیقی ناکامیاں حالت اور انویریئنٹ کے مسائل ہوتی ہیں—ورک فلو کو بائی پاس کرنا، اجازت دہی میں خلا اور "سسٹم غلط حالت میں ہے" والی خرابیاں. ان اقسام کی بگز کے لیے، ایک آلودہ قدر کسی ایک "خطرناک سنک" تک نہیں پہنچتی. خطرہ اس بات میں ہے کہ پروگرام جو کچھ فرض کرتا ہے وہ ہمیشہ سچ رہے گا. 

ہم توقع کرتے ہیں کہ سکیورٹی ٹولنگ ایکو سسٹم بہتر ہوتا رہے گا: اسٹیٹک اینالیسس، فزنگ، رن ٹائم گارڈز اور ایجنٹک ورک فلو—سب کے اپنے کردار ہوں گے.

ہم Codex Security کو اس چیز میں مہارت حاصل کرتے دیکھنا چاہتے ہیں جو سیکیورٹی ٹیموں کے لیے سب سے زیادہ مہنگی ہوتی ہے: "یہ مشتبہ لگتا ہے" کو "یہ حقیقی ہے، یہ ناکامی کی وجہ ہے اور یہ ایک ایسا حل ہے جو سسٹم کے مقصد سے مطابقت رکھتا ہے" میں تبدیل کرنا. 

اگر آپ یہ جاننا چاہتے ہیں کہ Codex Security مخزنوں کو کیسے اسکین کرتا ہے، نتائج کی توثیق کرتا ہے اور اصلاحات تجویز کرتا ہے، تو ہماری دستاویزات⁠(نئی ونڈو میں کھلتا ہے) ملاحظہ کریں.