کوڈ کی تصدیق، کمزوریاں، اور AI آؤٹ پٹ کے خطرات

فائدہ:

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

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

یہاں ہم تین پرتوں پر "توثیق" پر غور کرتے ہیں: درستگی (کیا کوڈ اصل میں کام کرتا ہے؟)، سیکیورٹی (کیا یہ نقصان دہ ان پٹ کو برداشت کرتا ہے؟)، اور پرووینس/لائسنس (کیا مجھے اس کوڈ کو استعمال کرنے کا حق ہے؟)۔ ہر پرت کے کنٹرول کے اپنے ذرائع ہوتے ہیں، اور ان میں سے کسی کو بھی "AI نے یہی کہا" کے ساتھ نظرانداز نہیں کیا جا سکتا۔

خطرے کی تین پرتیں۔

1. درستگی کا خطرہ (ہیلوسینیشن)۔ ماڈل ایک غیر موجود فنکشن کو کال کر سکتا ہے، API کا غلط استعمال کر سکتا ہے، خاموشی سے کسی کنارے کے معاملے کو نظرانداز کر سکتا ہے۔ کوڈ "معقول" لگتا ہے لیکن غلط ہے۔ تریاق: تالیف، جانچ، جامد تجزیہ اور بصری معائنہ۔

2. سیکورٹی رسک۔ AI تربیتی ڈیٹا میں غیر محفوظ نمونوں کو دہرا سکتا ہے: استفسار SQL انجیکشن، غیر مستند یوزر ان پٹ، کمزور انکرپشن، غیر محفوظ ڈیسیریلائزیشن، اوپن ری ڈائریکشن کا خطرہ۔ کوڈ کام کرتا ہے لیکن حملے کا خطرہ ہے۔ تریاق: سیکیورٹی پر مرکوز جائزہ، خودکار اسکینرز (SAST)، اور معلوم محفوظ نمونوں کو مسلط کرنا۔

3. ماخذ/لائسنس کا خطرہ۔ AI ایسا آؤٹ پٹ تیار کر سکتا ہے جو کاپی رائٹ یا پابندی والے لائسنس یافتہ کوڈ سے قریب سے ملتا ہو، یا یہ نامناسب طور پر لائسنس یافتہ انحصار کا مشورہ دے سکتا ہے۔ تریاق: انحصار اور لائسنس کی جانچ، اصلیت کی جانچ، کارپوریٹ پالیسی۔

احتیاط: ان تین خطرات میں سے سب سے زیادہ خطرناک سیکورٹی ہے۔ کیونکہ کوڈ ٹیسٹنگ پاس کر سکتا ہے، پروڈکشن میں آسانی سے چل سکتا ہے، اور کمزوری تب ظاہر ہوتی ہے جب کوئی حملہ آور اسے تلاش کرتا ہے۔ "کام کرنا" "محفوظ" جیسا نہیں ہے۔

مرحلہ وار: پرتوں والا توثیق گیٹ

1. سمجھ کر پڑھیں۔ کوڈ کو قبول کرنے سے پہلے اسے واقعی سمجھیں؛ کوڈ کو ضم نہ کریں جسے آپ نہیں سمجھتے ہیں۔ اگر آپ "یہ کیوں کام کرتا ہے" کی وضاحت نہیں کر سکتے ہیں، تو ابھی تک اس کی توثیق نہیں ہوئی ہے۔
2. تصدیق کریں کہ یہ موجود ہے۔ تصدیق کریں کہ استعمال ہونے والا ہر فنکشن، API اور پیکیج درحقیقت موجود ہے اور صحیح طریقے سے استعمال کیا گیا ہے (ہیلوسینیشن گیٹ)۔
3. خودکار ٹولز چلائیں۔ کمپائلر، لنٹر (اسٹائل/ ایرر اسکینر)، ٹائپ چیکر، یونٹ ٹیسٹ، اور اگر ممکن ہو تو SAST (سٹیٹک ایپلیکیشن سیکیورٹی ٹیسٹنگ - ٹول جو کمزوریوں کے لیے سورس کوڈ کو اسکین کرتا ہے)۔
4. اسے سیکورٹی کے نقطہ نظر سے دیکھیں۔ کیا ان پٹ کی توثیق ہوئی ہے؟ کیا استفسار پیرامیٹرائزڈ ہے؟ کیا راز دفن ہے؟ کیا اجازت کا کنٹرول ہے؟
5. ماخذ اور لائسنس چیک کریں۔ کیا نئے انحصار لائسنس یافتہ ہیں؟ کیا آؤٹ پٹ کسی معروف کوڈ بیس سے حد سے زیادہ ملتا جلتا نظر آتا ہے؟
6. اگر یہ سیکورٹی کے لحاظ سے اہم ہے، تو ماہر کی منظوری طلب کریں۔ توثیق، ادائیگی، خفیہ نگاری، رسائی کنٹرول جیسے شعبوں میں قابل انجینئر کی طرف سے آزادانہ جائزہ لازمی ہے۔

تین چھوٹے کیسز

کیس 1 - ایس کیو ایل انجیکشن معائنہ گیٹ پر پکڑا گیا۔ AI تیار کردہ کوڈ جو صارف کے ان پٹ کو تلاش کے اختتامی نقطہ ("... WHERE name = '" + q + "'") کے لیے براہ راست SQL استفسار میں جوڑتا ہے۔ کوڈ کام کر رہا تھا اور اس نے امتحان پاس کیا۔ سیکورٹی پر مرکوز معائنہ اور SAST سکیننگ نے اسے پکڑ لیا؛ اسے پیرامیٹرائزڈ استفسار (تیار شدہ بیان) میں تبدیل کر دیا گیا تھا۔ اگر اسے پکڑا نہیں جاتا تو یہ ڈیٹا لیک ہونے کا ایک کلاسک خطرہ ہوتا۔

کیس 2 - ہیلوسینیشن پیکیج۔ AI نے ایک کام کے لیے ایک غیر موجود npm پیکیج (تیز سیف پارس) تجویز کیا۔ جب ڈویلپر نے اسے انسٹال کرنے کی کوشش کی تو پیکیج نہیں ملا۔ بدتر: بعض صورتوں میں، حملہ آور ایسے "بھوت" پیکیج کے ناموں کو حقیقی، بدنیتی پر مبنی پیکیجز (انحصار کنفیوژن) سے بھر سکتے ہیں۔ سبق: ہر تجویز کردہ پیکیج کی سرکاری رجسٹری اور ڈاؤن لوڈ/مینٹیننس ہسٹری کے خلاف تصدیق کریں۔

کیس 3 - لائسنس کی عدم مطابقت۔ AI کی تجویز کردہ ایک نفٹی ساتھی لائبریری کے پاس ایک مضبوط کاپی لیفٹ لائسنس تھا جو ادارے کے پروڈکٹ لائسنس سے مطابقت نہیں رکھتا تھا۔ انحصار لائسنس اسکین نے اس کی اطلاع دی۔ ٹیم نے لائسنس کو ایک مناسب متبادل کے ساتھ بدل دیا۔ تصدیق کے بغیر، مصنوعات کی تقسیم میں ایک قانونی بوجھ پیدا ہوگا۔

چار کاپی ایبل ٹیمپلیٹس

داخلہ سے پہلے خود چیک کریں:

درج ذیل AI جنریٹڈ کوڈ کو قبول کرنے سے پہلے، چیک کریں: 1) کیا ہر فنکشن/API/پیکیج جو اس کا استعمال کرتا ہے حقیقت میں موجود ہے؟ مشتبہ افراد کو جھنڈا لگائیں۔2) کیا کوئی غیر تصدیق شدہ ان پٹ، SQL/کمانڈ کنکٹنیشن، دفن خفیہ، کمزور کرپٹو ہے؟

سیکورٹی فوکسڈ جائزہ:

حفاظتی نظر سے اس کوڈ کی جانچ کریں۔ عام OWASP طرز کی کمزوریوں کو تلاش کریں: انجیکشن، ٹوٹی ہوئی تصدیق/تصدیق، حساس ڈیٹا کا انکشاف، غیر محفوظ ڈیسیریلائزیشن، غیر تصدیق شدہ ری ڈائریکشن۔ ہر ایک تلاش کے لیے: خطرہ، استحصال کا منظر، تدارک۔ یہ ایک ابتدائی اسکریننگ ہے؛ انسانی سلامتی کے جائزے کے لیے اہم نتائج کا حوالہ دیں۔{{code}}

انحصار اور لائسنس کی جانچ:

اس کوڈ کے ذریعہ شامل / تجویز کردہ انحصارات کی فہرست بنائیں۔ ہر ایک کے لیے: کیا پیکیج اصل میں موجود ہے، کیا اسے برقرار رکھا گیا ہے، اس کا عام لائسنس کیا ہوگا (تصدیق ہونی چاہیے)، اور کیا اس کی اصل میں پروجیکٹ کے لیے ضرورت ہے یا اسے کسی موجودہ ٹول سے کیا جا سکتا ہے؟{{code or dependency list}}

محفوظ فارم ورک کا نفاذ (پیداوار میں):

{{task}} کے لیے کوڈ لکھیں۔ لازمی حفاظتی اصول: - تمام بیرونی ان پٹ کی توثیق/صاف کرنا۔- ڈیٹا بیس تک رسائی میں صرف پیرامیٹرائزڈ استفسار کا استعمال کریں۔ ماحول متغیر/خفیہ مینیجر فرض کریں - غلطیوں کو نگل نہ جائیں؛ اس پر معنی خیز غور کریں۔ وضاحت کریں کہ کوڈ 3 آئٹمز میں ان اصولوں کی تعمیل کیسے کرتا ہے۔

کمزور فوری / مضبوط اشارہ

کمزور: "ایک استفسار لکھیں جو صارف نام سے تلاش کرے۔" (انجیکشن کے لیے خطرناک کوڈ ہو سکتا ہے۔)

مضبوط: "ایک فنکشن لکھیں جو صارف نام سے تلاش کرتا ہے۔ صارف کے ان پٹ کو کبھی بھی استفسار میں بطور سٹرنگ شامل نہ کریں؛ پیرامیٹرائزڈ استفسار (تیار شدہ بیان) کا استعمال کریں۔ لمبائی اور کردار کے لیے ان پٹ کی توثیق کریں۔ 2 جملوں میں وضاحت کریں کہ کوڈ انجیکشن کے لیے کیوں بند ہے۔"

مضبوط ورژن شروع سے ہی محفوظ نمونہ نافذ کرتا ہے۔ اس طرح، یہ یقینی بناتا ہے کہ خطرے کو بعد میں پکڑنے کے بجائے، بالکل بھی واقع نہ ہو۔ تاہم، تیار کردہ کوڈ کو تصدیقی دروازوں سے منتقل کرنا ضروری ہے۔

توثیق کی پرت

ٹول/طریقہ

کیا "AI کہا" کافی ہے؟

درستگی

تالیف، جانچ، بصری معائنہ

نہیں

API/پیکیج کی حقیقت

سرکاری دستاویز/ریکارڈ کنٹرول

نہیں

سیکورٹی

SAST، سیکورٹی کا جائزہ

نہیں

لائسنس/ذریعہ

انحصار اور لائسنس کی جانچ

نہیں

حفاظتی تنقیدی منطق

ماہر انجینئر کی منظوری

بالکل نہیں۔

ذمہ داری کو منتقل نہیں کیا جا سکتا

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

مشورہ: اپنی ٹیم پر ایک مختصر چیک لسٹ بنائیں جسے آپ "AI سے تیار کردہ کوڈ کے لیے توثیق گیٹ" کہتے ہیں (تعمیر + ٹیسٹ + سیکیورٹی اسکین + بصری معائنہ)۔ ایک بار جب یہ گیٹ عادت بن جائے تو رفتار کا نقصان کم سے کم ہوتا ہے اور خطرے میں کمی زیادہ سے زیادہ ہوتی ہے۔

عام غلطیاں

• "محفوظ" کے ساتھ "کام" کو الجھانا۔ ٹیسٹنگ پاس کرنے والا کوڈ حملے کا خطرہ ہو سکتا ہے۔
• پیکج/API کو تصدیق کیے بغیر استعمال کرنا۔ ہیلوسینٹری پیکٹ دونوں بدعنوان اور سیکورٹی کے لیے خطرہ ہیں۔
• خودکار ٹولز کو نظرانداز کرنا۔ لنٹر، ٹائپ چیکر اور SAST سستے طریقے سے وہ چیز پکڑتے ہیں جو انسانوں سے چھوٹ جاتی ہے۔
• لائسنس کو نظر انداز کرنا۔ نامناسب لائسنس یافتہ انحصار تقسیم پر قانونی بوجھ پیدا کرتا ہے۔
• گاڑی پر ذمہ داری ڈالنا۔ ٹیم پیداوار میں کوڈ کے لئے ذمہ دار ہے؛ "AI نے یہ کیا" کوئی عذر نہیں ہے۔

خلاصہ میں

AI آؤٹ پٹ کو قبول کرنے کے لیے تصدیق کی تین پرتوں کی ضرورت ہوتی ہے: درستگی (مرتب، جانچ، بصری معائنہ)، سیکیورٹی (SAST اور سیکیورٹی پر مرکوز جائزہ)، اور ذریعہ/لائسنس (انحصار کی جانچ)۔ تصدیق کریں کہ ہر ایک پیکج اور API کا استعمال کیا گیا اصل میں موجود ہے، شروع سے ہی محفوظ نمونوں کو نافذ کریں، اور ایک اہل انجینئر کے ذریعے منظوری کے لیے سیکیورٹی کے لیے اہم کوڈ جمع کرائیں۔ "کام" کا مطلب محفوظ نہیں ہے، اور "AI تیار کردہ" ذمہ داری کو ختم نہیں کرتا ہے۔ تصدیقی گیٹ پیشہ ورانہ مہارت کی قیمت ہے، رفتار نہیں۔

درخواست کا کام

جان بوجھ کر ایک AI کو ایک حفاظتی حساس کام دیں (مثال کے طور پر "ایک فنکشن جو صارف کے ان پٹ کے ساتھ ڈیٹا بیس کو تلاش کرتا ہے")، اس بار محفوظ پیٹرن کو مسلط کیے بغیر۔ آنے والے کوڈ کو "پری ایڈمشن سیلف آڈٹ" اور "سیکیورٹی فوکسڈ ریویو" ٹیمپلیٹس کے ذریعے پاس کریں: کیا کوئی انجیکشن، دفن شدہ خفیہ، فریب شدہ پیکٹ، یا غیر تصدیق شدہ ان پٹ ہے؟ پھر وہی کام دوبارہ "سیکیور پیٹرن امپوزیشن" ٹیمپلیٹ کے ساتھ پوچھیں اور دونوں آؤٹ پٹس کا موازنہ کریں۔ اگر ممکن ہو تو، ایک linter/SAST ٹول چلائیں اور نتائج کا AI کے سیلف ریگولیشن سے موازنہ کریں۔

چیک لسٹ

• میں تین پرتوں پر AI آؤٹ پٹ کی تصدیق کرتا ہوں: درستگی، سیکورٹی اور لائسنس۔
• میں تصدیق کرتا ہوں کہ استعمال ہونے والا ہر فنکشن، API اور پیکیج درحقیقت موجود ہے۔
• میں کمپائل، ٹیسٹ، لنٹر اور اگر ممکن ہو تو SAST ٹولز چلاتا ہوں۔
• میں شروع سے ہی محفوظ پیٹرن (پیرامیٹرائزڈ استفسار، ان پٹ کی توثیق، خفیہ انتظام) نافذ کرتا ہوں۔
• میں لائسنسنگ اور نئے انحصار کی ضرورت کو چیک کرتا ہوں۔
• میں ایک قابل انجینئر کی طرف سے منظوری کے لیے حفاظتی اہم کوڈ جمع کر رہا ہوں اور میں سمجھتا ہوں کہ میں ذمہ دار ہوں۔