أمان الكود المُولَّد بالذكاء الاصطناعي: المخاطر وأفضل الممارسات

أدوات البرمجة بالذكاء الاصطناعي — Copilot وClaude Code وCursor وWindsurf — غيّرت قواعد اللعبة في إنتاجية المطورين. لكن هذا التسارع له ثمن: وفقاً لتقرير Veracode 2026، 82% من الشركات تحمل الآن ديوناً أمنية، مقارنة بـ 74% قبل عام واحد. ومعيار Opsera 2026 أكثر وضوحاً: الكود المُولَّد بالذكاء الاصطناعي يُدخل 15 إلى 18% ثغرات إضافية لكل سطر مقارنة بالكود المكتوب يدوياً.

يُحلّل هذا المقال المخاطر الفعلية ويقدّم إطاراً عملياً لدمج الأمان في سير عمل الذكاء الاصطناعي.

حجم المشكلة بالأرقام

البيانات متقاربة، وليست مطمئنة:

• 45% من كود الذكاء الاصطناعي يحتوي على ثغرات — اختبرت Veracode أكثر من 80 مهمة برمجية عبر 4 لغات و4 أنواع من الثغرات الحرجة؛ 55% فقط من الكود الناتج كان آمناً.
• اختراق واحد من كل 5 ناجم الآن عن كود مُولَّد بالذكاء الاصطناعي (Aikido Security، 2026).
• 24% من الكود في بيئة الإنتاج عالمياً مُولَّد بالذكاء الاصطناعي — 21% في أوروبا، 29% في الولايات المتحدة.
• الثغرات عالية الخطورة قفزت من 8.3% إلى 11.3% خلال عام واحد.

المشكلة ليست أن الذكاء الاصطناعي يكتب كوداً "سيئاً". المشكلة أنه يُعيد إنتاج الأنماط الضعيفة الموجودة في بيانات التدريب بشكل منهجي — على نطاق واسع وبدون تمييز.

أكثر 5 ثغرات شيوعاً

1. حقن SQL وغياب تنظيف المدخلات

هذه الثغرة الأولى. تُولّد نماذج اللغة الكبيرة (LLMs) استعلامات SQL عبر ربط السلاسل النصية بشكل متكرر، وهو نمط منتشر في الكود المفتوح المصدر الذي تدرّبت عليه.

# كود مُولَّد بالذكاء الاصطناعي — ثغرة أمنية
def get_user(username):
    query = f"SELECT * FROM users WHERE name = '{username}'"
    return db.execute(query)
 
# النسخة الآمنة — استعلام مُعلَّم
def get_user(username):
    query = "SELECT * FROM users WHERE name = %s"
    return db.execute(query, (username,))

2. الحزم الوهمية (هجوم سلسلة التوريد)

تقترح النماذج أحياناً حزماً غير موجودة. يُسجّل المهاجمون هذه الأسماء على npm أو PyPI بكود خبيث. إذا ثبّت المطور الحزمة دون التحقق، يحصل المهاجم على صلاحية كاملة للنظام.

# النموذج يقترح:
pip install flask-auth-utils  # هذه الحزمة غير موجودة
 
# مهاجم ينشرها بحمولة خبيثة
# ← نظام CI/CD يُثبّتها تلقائياً

3. التحكم بالوصول غير المكتمل

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

// مُولَّد بالذكاء الاصطناعي — ينقصه التحقق من الدور
app.put('/api/users/:id', async (req, res) => {
  const user = await User.findByIdAndUpdate(req.params.id, req.body);
  res.json(user);
});
 
// النسخة الآمنة
app.put('/api/users/:id', requireRole('admin'), async (req, res) => {
  const user = await User.findByIdAndUpdate(req.params.id, req.body);
  res.json(user);
});

4. الأسرار المُضمَّنة في الكود

تُعيد النماذج إنتاج أنماط التكوين مع مفاتيح API والرموز وكلمات المرور مباشرة في الكود المصدري — سبب كلاسيكي لتسريب البيانات.

5. التشفير الضعيف

استخدام خوارزميات قديمة (MD5، SHA-1 لتجزئة كلمات المرور)، أطوال مفاتيح غير كافية، أو تطبيقات محلية لبروتوكولات التشفير.

لماذا لا يكتشف المطورون هذه الثغرات؟

المشكلة منهجية. تُظهر الدراسات الحديثة:

• أقل من 50% من المطورين يراجعون كود الذكاء الاصطناعي قبل حفظه (commit).
• سرعة الإنتاج تخلق إحساساً زائفاً بالكفاءة — الكود يعمل، إذن لا بد أنه صحيح.
• نماذج اللغة الكبيرة لا تفهم نموذج التهديد الخاص بتطبيقك، ولا معاييرك الأمنية الداخلية.

الذكاء الاصطناعي يُولّد أنماط ثغرات مؤتمتة. لم يعد هذا خطأً بشرياً معزولاً، بل خطر منهجي.

إطار DevSecOps للكود المُولَّد بالذكاء الاصطناعي

الخطوة 1: الفحص قبل الدمج

ادمج أدوات SAST (اختبار أمان التطبيقات الثابت) مباشرة في خط أنابيب CI/CD. كل طلب دمج (pull request) يحتوي على كود ذكاء اصطناعي يجب أن يمر عبر تحليل آلي.

# مثال GitLab CI
security_scan:
  stage: test
  script:
    - semgrep --config auto --error src/
    - npm audit --audit-level=high
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

الخطوة 2: تأمين التبعيات

• استخدم ملفات القفل (package-lock.json، poetry.lock).
• فعّل التحقق من السلامة (npm ci بدلاً من npm install).
• افحص التبعيات باستخدام أدوات مثل Snyk أو Dependabot أو Socket.

الخطوة 3: المراجعة البشرية الإلزامية

ضع قاعدة: كل كود مُولَّد بالذكاء الاصطناعي يجب مراجعته بشرياً قبل الدمج. ركّز المراجعة على:

• تنظيف مدخلات المستخدم
• التحكم بالوصول والتفويض
• إدارة الأسرار والتشفير
• التبعيات المستوردة

الخطوة 4: ضبط حواجز الأمان في الأوامر

أضف تعليمات أمنية في ملفات تكوين الوكيل (مثل CLAUDE.md أو قواعد Cursor):

## قواعد الأمان الإلزامية
- استخدم دائماً الاستعلامات المُعلَّمة (لا ربط سلاسل SQL أبداً)
- لا تضمّن الأسرار في الكود المصدري أبداً
- تحقق من الصلاحيات على كل نقطة نهاية API
- استخدم bcrypt أو argon2 لتجزئة كلمات المرور

الخطوة 5: الاختبار المستمر

أكمل الفحوصات الثابتة باختبارات ديناميكية (DAST) واختبارات اختراق دورية. توصي ANSSI الفرنسية في تقريرها لفبراير 2026 بمنهج مراقبة مستمرة للثغرات المتعلقة بنماذج الذكاء الاصطناعي.

الخلاصة

أدوات البرمجة بالذكاء الاصطناعي باقية، واعتمادها لن يتوقف عن التسارع. السؤال ليس هل نمنعها، بل كيف نُنظّمها. مع حمل 82% من الشركات لديون أمنية وارتفاع الثغرات عالية الخطورة بنسبة 36%، تجاهل أمان الكود المُولَّد بالذكاء الاصطناعي لم يعد خياراً.

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