التحقق من الكود ونقاط الضعف ومخاطر مخرجات الذكاء الاصطناعي

المكاسب:

• القدرة على التحقق من مخرجات الذكاء الاصطناعي على ثلاث طبقات: الدقة والأمان والمصدر/الترخيص
• القدرة على تغطية المخاطر مثل الحقن وعبوات الهلوسة والأسرار المدفونة بقوالب وأدوات آمنة
• القدرة على تقديم الكود الأمني ​​الحرج لموافقة المهندس المختص وفهم عدم قابلية نقل المسؤولية

يعد إنشاء كود الذكاء الاصطناعي أمرًا سهلاً؛ الثقة به مكلفة. الغرض الوحيد من هذه الوحدة هو تحويل مبدأ "التحقق" الذي كررناه في جميع الوحدات السابقة إلى تخصص هندسي منهجي. لأن الكود الذي ينتجه الذكاء الاصطناعي، حتى لو بدا صحيحًا للوهلة الأولى، فإنه يحمل ثلاثة مخاطر منفصلة: أن يكون غير صالح للعمل/غير صحيح (الهلوسة)، وأن يكون غير آمن (ضعفًا)، وأن يحمل مخاطر قانونية/ترخيصية. معرفة هؤلاء الثلاثة وإنشاء باب لكل منهم يجعلك محترفاً.

نحن هنا نعتبر "التحقق" من ثلاث طبقات: الصحة (هل يقوم الكود بالمهمة بالفعل؟)، والأمان (هل يتحمل المدخلات الضارة؟)، والمصدر/الترخيص (هل لدي الحق في استخدام هذا الكود؟). كل طبقة لها وسائل التحكم الخاصة بها، ولا يمكن تجاوز أي منها بـ "هذا ما قاله الذكاء الاصطناعي".

ثلاث طبقات من المخاطر

1. خطر الدقة (الهلوسة). قد يستدعي النموذج وظيفة غير موجودة، أو يسيء استخدام واجهة برمجة التطبيقات (API)، أو يتجاوز حالة الحافة بصمت. يبدو الرمز "معقولًا" ولكنه خاطئ. الترياق: التجميع والاختبار والتحليل الثابت والفحص البصري.

2. المخاطر الأمنية. يمكن للذكاء الاصطناعي تكرار أنماط غير آمنة في بيانات التدريب: الاستعلام عرضة لحقن SQL، وإدخال المستخدم غير المصادق عليه، والتشفير الضعيف، وإلغاء التسلسل غير الآمن، وإعادة التوجيه المفتوحة. الكود يعمل ولكنه عرضة للهجوم. الترياق: المراجعة التي تركز على الأمان، والماسحات الضوئية الآلية (SAST)، وفرض أنماط آمنة معروفة.

3. مخاطر المصدر/الترخيص. قد ينتج الذكاء الاصطناعي مخرجات تشبه إلى حد كبير التعليمات البرمجية المرخصة المحمية بحقوق الطبع والنشر أو المقيدة، أو قد تشير إلى تبعية مرخصة بشكل غير مناسب. الترياق: التحقق من التبعية والترخيص، والتحقق من الأصالة، وسياسة الشركة.

تحذير: إن أكثر هذه المخاطر الثلاثة غدراً هو الأمن؛ لأن الكود يمكن أن يجتاز الاختبار، ويعمل بسلاسة في الإنتاج، ولا يتم الكشف عن الثغرة الأمنية إلا عندما يعثر عليها المهاجم. "العمل" ليس مثل "آمن".

خطوة بخطوة: بوابة المصادقة ذات الطبقات

1. اقرأ بفهم. افهم الكود جيدًا قبل قبوله؛ لا تقم بدمج التعليمات البرمجية التي لا تفهمها. إذا لم تتمكن من شرح "سبب نجاحه"، فهذا يعني أنه لم يتم التحقق من صحته بعد.
2. التحقق من وجوده. تأكد من أن كل وظيفة وواجهة برمجة تطبيقات وحزمة مستخدمة موجودة بالفعل ويتم استخدامها بشكل صحيح (بوابة الهلوسة).
3. تشغيل الأدوات الآلية. مترجم، linter (ماسح الأنماط/الأخطاء)، مدقق النوع، اختبارات الوحدة، وإذا أمكن، SAST (اختبار أمان التطبيقات الثابتة - أداة تقوم بمسح الكود المصدري بحثًا عن نقاط الضعف).
4. انظر إلى الأمر من منظور أمني. هل تم التحقق من صحة الإدخال؟ هل الاستعلام ذو معلمات؟ هل السر مدفون؟ هل هناك مراقبة الترخيص؟
5. التحقق من المصدر والترخيص. هل التبعيات الجديدة مرخصة؟ هل يبدو الإخراج مشابهًا بشكل مفرط لقاعدة تعليمات برمجية معروفة؟
6. إذا كان الأمر بالغ الأهمية للأمان، فاطلب موافقة الخبراء. تعتبر المراجعة المستقلة من قبل مهندس مختص في مجالات مثل المصادقة والدفع والتشفير والتحكم في الوصول إلزامية.

ثلاث حالات صغيرة

الحالة 1 - تم اكتشاف إدخال SQL عند بوابة التفتيش. الكود الذي أنشأه الذكاء الاصطناعي والذي يقوم بربط إدخال المستخدم مباشرة في استعلام SQL لنقطة نهاية البحث ("... WHERE name = '" + q + "'"). كان الكود يعمل واجتاز الاختبار. اكتشف الفحص الذي يركز على الأمان ومسح SAST هذا الأمر؛ تم تحويله إلى استعلام ذو معلمات (بيان معد). إذا لم يتم اكتشافها، لكانت ثغرة أمنية كلاسيكية لتسرب البيانات.

الحالة 2 - حزمة الهلوسة. اقترح الذكاء الاصطناعي حزمة npm غير موجودة (تحليل سريع وآمن) لمهمة ما. عندما حاول المطور تثبيته، لم يتم العثور على الحزمة. والأسوأ من ذلك: في بعض الحالات، يمكن للمهاجمين ملء أسماء الحزم "الشبحية" هذه بحزم حقيقية وخبيثة (ارتباك التبعية). الدرس المستفاد: التحقق من كل حزمة موصى بها مقابل السجل الرسمي وسجل التنزيل/الصيانة.

الحالة 3 - عدم توافق الترخيص. كانت المكتبة المصاحبة الأنيقة التي اقترحتها منظمة العفو الدولية تتمتع بترخيص قوي للحقوق المتروكة كان غير متوافق مع ترخيص المنتج الخاص بالمؤسسة. أبلغ فحص ترخيص التبعية عن ذلك؛ وقام الفريق باستبدال الرخصة ببديل مناسب. وبدون التحقق، سينشأ عبء قانوني في توزيع المنتج.

أربعة قوالب قابلة للنسخ

الفحص الذاتي قبل القبول:

قبل قبول التعليمات البرمجية التالية التي تم إنشاؤها بواسطة الذكاء الاصطناعي، تحقق مما يلي: 1) هل كل وظيفة/واجهة برمجة تطبيقات/حزمة تستخدمها موجودة بالفعل؟ قم بالإبلاغ عن المشتبه بهم.2) هل هناك أي مدخلات لم يتم التحقق منها، أو تسلسل أوامر SQL/، أو سر مدفون، أو تشفير ضعيف؟ 3) ما هي حالات الأخطاء/الحواف التي لم تتم معالجتها؟ قم بتسمية كل نتيجة على أنها "مؤكدة / محتملة" واقترح الإصلاحات. {{code}}

مراجعة تركز على الأمان:

افحص هذا الرمز بعين أمنية. ابحث عن نقاط الضعف الشائعة في نمط OWASP: الحقن، والمصادقة/الترخيص المعطلة، والكشف عن البيانات الحساسة، وإلغاء التسلسل غير الآمن، وإعادة التوجيه غير المصادق عليه. لكل نتيجة: المخاطر، سيناريو الاستغلال، العلاج. هذا فحص أولي. إحالة النتائج المهمة إلى مراجعة الأمن البشري.{{code}}

التحقق من التبعية والترخيص:

قم بإدراج التبعيات المضافة/المقترحة بواسطة هذا الرمز. لكل منها: هل الحزمة موجودة بالفعل، وهل تتم صيانتها، وما هو الترخيص النموذجي الخاص بها (يجب التحقق منه)، وهل هي مطلوبة بالفعل للمشروع أم يمكن تنفيذها باستخدام أداة موجودة؟ {{code or Depenency list}}

فرض القوالب الآمنة (في الإنتاج):

اكتب الكود الخاص بـ {{task}}. قواعد الأمان الإلزامية: - التحقق من صحة/تعقيم جميع المدخلات الخارجية. - استخدم الاستعلام ذي المعلمات فقط في الوصول إلى قاعدة البيانات. - لا تقم بتضمين أسرار في التعليمات البرمجية؛ افترض متغير البيئة/المدير السري - لا تبتلع الأخطاء؛ اعتبرها ذات معنى. اشرح كيفية التزام الكود بهذه القواعد في 3 بنود.

موجه ضعيف / موجه قوي

ضعيف: "اكتب استعلامًا يبحث حسب اسم المستخدم." (قد يحدث رمز عرضة للحقن.)

Strong: "اكتب دالة تبحث حسب اسم المستخدم. لا تقم أبدًا بضم إدخال المستخدم في استعلام كسلسلة؛ استخدم استعلام ذو معلمات (بيان مُجهز). تحقق من صحة الإدخال من حيث الطول والحرف. اشرح في جملتين سبب إغلاق الكود للحقن."

النسخة القوية تفرض النمط الآمن منذ البداية؛ وبالتالي، فهو يضمن عدم حدوث الثغرة الأمنية على الإطلاق، بدلاً من اكتشافها لاحقًا. ومع ذلك، فمن الضروري تمرير الرمز الذي تم إنشاؤه عبر بوابات التحقق.

طبقة المصادقة

الأداة/الطريقة

هل "قال الذكاء الاصطناعي" يكفي؟

الدقة

التجميع والاختبار والفحص البصري

لا

واقع واجهة برمجة التطبيقات/الحزمة

مراقبة الوثائق/السجلات الرسمية

لا

الأمن

SAST، مراجعة الأمن

لا

الترخيص/المصدر

فحص التبعية والترخيص

لا

المنطق الأمني الحرج

موافقة المهندس الخبير

بالتأكيد لا

لا يمكن نقل المسؤولية

تقع مسؤولية الأخطاء أو نقاط الضعف أو الانتهاكات الناشئة عن التعليمات البرمجية التي تنتجها أداة الذكاء الاصطناعي على عاتق الفريق الذي يقوم بتجميع تلك التعليمات البرمجية وتوزيعها، وليس على موفر الأداة. هذه حقيقة مهنية وقانونية أيضًا: عليك التوقيع. لذا فإن عبارة "لقد أنتجها الذكاء الاصطناعي" ليست عذرا، بل مبررا لمزيد من الحذر. لا تعد مخرجات الذكاء الاصطناعي بديلاً للمراجعة والموافقة من قبل مهندس مؤهل تحت أي ظرف من الظروف، خاصة في الأنظمة ذات الأهمية الحيوية للسلامة؛ على الأكثر، يوفر الذكاء الاصطناعي مخططًا يعمل على تسريع عمل هذا المهندس.

نصيحة: قم بإنشاء قائمة مرجعية قصيرة لفريقك والتي تسميها "بوابة التحقق من صحة التعليمات البرمجية التي تم إنشاؤها بواسطة الذكاء الاصطناعي" (إنشاء + اختبار + فحص أمني + فحص بصري). بمجرد أن تصبح هذه البوابة عادة، يكون فقدان السرعة في حده الأدنى والحد من المخاطر يصل إلى الحد الأقصى.

الأخطاء الشائعة

• الخلط بين "يعمل" و"آمن". قد تكون التعليمات البرمجية التي تجتاز الاختبار عرضة للهجوم.
• استخدام الحزمة/واجهة برمجة التطبيقات (API) دون التحقق منها. الحزم المهلوسة فاسدة وتشكل خطرًا أمنيًا.
• تجاوز الأدوات الآلية. يلتقط Linter وType Checker وSAST ما يفتقده البشر بثمن بخس.
• إهمال الترخيص التبعية المرخصة غير الصحيحة تخلق عبئًا قانونيًا على التوزيع.
• وضع المسؤولية على السيارة. الفريق مسؤول عن الكود في الإنتاج؛ "الذكاء الاصطناعي هو الذي فعل ذلك" ليس عذرا.

باختصار

يتطلب قبول مخرجات الذكاء الاصطناعي ثلاث طبقات من التحقق: الصحة (التجميع والاختبار والفحص البصري)، والأمان (SAST والمراجعة التي تركز على الأمان)، والمصدر/الترخيص (التحقق من التبعية). تأكد من أن كل حزمة وواجهة برمجة تطبيقات مستخدمة موجودة بالفعل، وقم بفرض أنماط آمنة من البداية، وأرسل رمز الأمان المهم للموافقة عليه من قبل مهندس مؤهل. "يعمل" لا يعني الأمان، و"إنتاج الذكاء الاصطناعي" لا يزيل المسؤولية. بوابة التحقق هي ثمن الاحترافية وليس السرعة.

مهمة التطبيق

تكليف الذكاء الاصطناعي عمدًا بمهمة حساسة للأمان (على سبيل المثال، "وظيفة تبحث في قاعدة البيانات بإدخال المستخدم")، هذه المرة دون فرض نمط آمن. قم بتمرير التعليمات البرمجية الواردة من خلال قوالب "التدقيق الذاتي قبل القبول" و"المراجعة التي تركز على الأمان": هل هناك أي حقنة، أو سر مدفون، أو حزمة مهلوسة، أو مدخلات غير مصادق عليها؟ ثم اطلب نفس المهمة مرة أخرى باستخدام قالب "فرض النمط الآمن" وقارن بين الناتجين. إذا كان ذلك ممكنًا، قم بتشغيل أداة linter/SAST وقارن النتائج بالتنظيم الذاتي للذكاء الاصطناعي.

قائمة مرجعية

• [ ] أتحقق من مخرجات الذكاء الاصطناعي في ثلاث طبقات: الدقة والأمان والترخيص.
• [ ] أؤكد أن كل وظيفة وواجهة برمجة تطبيقات وحزمة مستخدمة موجودة بالفعل.
• [ ] أقوم بتشغيل أدوات الترجمة والاختبار واللينتر، وإذا أمكن، أدوات SAST.
• [ ] أفرض أنماطًا آمنة (استعلام محدد، التحقق من صحة الإدخال، الإدارة السرية) من البداية.
• [ ] أتحقق من الترخيص ومتطلبات التبعيات الجديدة.
• [ ] أقوم بإرسال رمز أمني بالغ الأهمية للموافقة عليه من قبل مهندس مختص وأدرك أنني المسؤول.