النقاط الأمنية العمياء.

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

• الاستعلامات / الأوامر البرمجية المدمجة عبر دمج النصوص بدلاً من الاستعلامات ذات المعاملات (مواقع استدعاء لثغرات حقن SQL/الأوامر البرمجية/حقن LDAP).
• تدفق مدخلات المستخدم مباشرة إلى المخرجات دون أي ترميز (ثغرات XSS المنعكسة/المخزنة) أو تدفقها إلى دوال fs/child_process/fetch دون وجود قائمة سماح معتمدة (ثغرات اجتياز المسار، و SSRF).
• نقطة النهاية تقوم بالمصادقة ولكنها لا تفحص الصلاحيات أبداً — فهي تتحقق من هويتك، ولكنها لا تتحقق أبداً من صلاحيتك في تعديل أو رؤية هذا السجل المحدد (ثغرات IDOR / صلاحيات الكائنات المكسورة).
• الأسرار المكتوبة بشكل مباشر — مثل مفاتيح واجهة برمجة التطبيقات، أو الرموز المميزة، أو كلمات مرور قواعد البيانات المكتوبة داخل الكود "لتسهيل التشغيل".
• عناصر التحكم المفقودة بسبب الإغفال: غياب رموز CSRF المميزة، وغياب الترويسات الأمنية، وعدم وجود حد لمعدل الاستخدام (rate limit)، واستخدام تشفير ضعيف أو قديم (مثل MD5، و SHA-1، أو Math.random() لتوليد الرموز).
• تعليقات وهمية: مثل تعليق // validate input أو // TODO: add auth يستقر في المكان الذي كان ينبغي وضع التحقق الفعلي فيه — وجدت Ox تعليقات مكررة في 90-100% من أكواد الذكاء الاصطناعي، وغالباً ما تكون بديلاً للمنطق المفقود.

// معالج Express مولد بالذكاء الاصطناعي — يبدو كاملاً، ولكنه يشحن ثلاث ثغرات أمنية
app.get("/api/orders/:id", authMiddleware, async (req, res) => {
  const apiKey = "sk_live_8f3b2a91c7d44e0f";            // 1. سر مكتوب بشكل مباشر
  const order = await db.query(
    `SELECT * FROM orders WHERE id = ${req.params.id}`   // 2. حقن SQL
  );
  res.send(`<h1>Order for ${order.customerName}</h1>`);  // 3. ثغرة XSS منعكسة
  // note: authMiddleware يثبت تسجيل الدخول، ولكنه لا يفحص أبداً ما إذا كان order.userId === req.user.id (ثغرة IDOR)
});

أربع ثغرات أمنية متميزة، ولا توجد اختبارات تفشل — الرائحة البرمجية تكمن في ما هو غير موجود هناك.

لماذا تنتجها النماذج؟

• الهدف من التدريب هو المعقولية والقبول، وليس الأمان. يعمل التنبؤ بالرمز التالي على تحسين الكود ليكون على الشاكلة الأكثر شيوعاً في الكتابة، وتمتلئ مجموعات البيانات العامة بأكواد تعليمية تحتوي على استعلامات مدمجة ومفتقرة للمصادقة. تشير Ox Security إلى أن النماذج "تلجأ افتراضياً إلى الأساليب غير الآمنة لأنها الأكثر تكراراً في بيانات التدريب". ووجدت جامعة كارنيجي ميلون أن 61% من المقاطع البرمجية للذكاء الاصطناعي تعمل ولكن ~10.5% فقط منها تجتاز المراجعة الأمنية.
• تعريف "الانتهاء" مبني على المسار السعيد. يعمل نموذج اللغة الكبيرة على تحسين المخرجات لتنجح المهمة المطلوبة بشكل مرئي. ولا تنتج عناصر التحكم الأمنية أي إشارة نجاح إيجابية في التشغيل السريع، لذلك يتم إسقاطها — وهو ما تسميه Ox "غير آمن بسبب الجهل": كود يعمل بنجاح ولكن مع غياب الضمانات الأمنية لأن أحداً لم يدرك وجود المتطلبات الأمنية.
• غياب سياق المستودع. لا يستطيع النموذج رؤية دالة المساعدة authorize() الخاصة بك، أو مخطط التحقق الخاص بك، أو مدير الأسرار لديك، لذا يقوم بكتابة مفتاح مباشر أو يتخطى الفحص تماماً بدلاً من إعادة استخدام عناصر التحكم المتوفرة.
• التملق + السرعة. يعيد النموذج الشيء الذي طلبته منه حرفياً ("إضافة نقطة نهاية للطلبات")، وليس نموذج التهديدات المحيط به. وتعتبر مراجعة الكود ونمذجة التهديدات هي العقبات التي تزيلها سرعة تطوير الذكاء الاصطناعي — والنتيجة الأساسية لتقرير Ox هي أن السرعة، وليس معدل العيوب لكل سطر، هي التي تتسبب في شحن أكواد برمجية تحتوي على ثغرات إلى بيئة الإنتاج.
• تاريخ انتهاء التدريب (Training-cutoff staleness). تلجأ النماذج إلى أساليب تشفير ومكتبات كانت تعتبر مقبولة قبل سنوات (مثل MD5، و SHA-1، وخيارات TLS المهملة، ومسارات المصادقة القديمة).

لماذا يسبب ضرراً؟

• قابلية الاستغلال المباشرة. تشير دراسات مستقلة نقلتها Ox إلى أن: ~62% من الأكواد المولدة بالذكاء الاصطناعي تشحن مع ثغرة أمنية واحدة على الأقل؛ وفشل 86% منها في اختبارات دفاعات XSS (منظمة CSET/Georgetown)؛ ورصدت CodeRabbit ثغرات XSS بمعدل 2.74 مرة أكثر مقارنة بالكود البشري؛ بينما وجدت Tenzai أن 0 من أصل 15 تطبيقاً بناه الذكاء الاصطناعي وضع ترويسات أمنية أو حماية ضد ثغرات CSRF؛ ووجدت Escape.tech أكثر من 400 سر مكشوف عبر 5600 تطبيق تم توليدها بالذكاء الاصطناعي.
• غير مرئي للاختبارات وللقراء. لا يؤدي فحص صلاحيات مفقود إلى فشل الاختبارات ولا يحتوي على فروقات واضحة للإشارة إليه، لذا يمر عبر المراجعة بسهولة — وحجم إنتاج الذكاء الاصطناعي الهائل يعني عدم قدرة المراجعة البشرية على التوسع لالتقاط كل المشكلات.
• تضاعف الديون التقنية. إن انخفاض نسبة إعادة الهيكلة من 25% إلى أقل من 10% من السطور المتغيرة، وارتفاع النسخ/اللصق ليتجاوز السطور المنقولة، وتضاعف الكتل المكررة بمعدل ~8 أضعاف وفقاً لبيانات GitClear، يعني أن النمط البرمجي الضعيف نفسه يتم استنساخه عبر قاعدة الكود بالكامل، مما يضاعف نطاق تأثير أي نقطة عمياء أمنية فردية.

تكتيكات المراجعة وصياغة الأوامر

• اذكر نموذج التهديدات الأمنية في أمر التوجيه. وجّه النموذج: "اكتب نقطة النهاية هذه بافتراض أن معرف id يتم التحكم به بواسطة المهاجم؛ وافرض فحص الصلاحيات على مستوى الكائنات، واجعل كل الاستعلامات ذات معاملات، وقم بترميز كل المخرجات، واقرأ الأسرار من process.env". تحديد الخصم أمنياً يقلب السلوك الافتراضي للنموذج.
• افرض إعادة استخدام عناصر التحكم الحالية. وجّه النموذج: "استخدم الدالة المساعدة authorize(user, 'order', id) وأداة التحقق orderSchema — ولا تقم بكتابة تحقق مخصص جديد". هذا يواجه مباشرة سبب غياب سياق المستودع (ورائحة الكود المكرر المرتبطة به).
• أجبر النموذج على تشغيل الأدوات الأمنية. اطلب منه تشغيل الأمر semgrep --config p/owasp-top-ten، و gitleaks detect، و npm audit، وإعدادات eslint-plugin-security لديك، وإصلاح ما تكتشفه من أخطاء قبل إعلان الانتهاء.
• اطلب الجوانب السلبية صراحة. "عدد مخاطر المصادقة، والصلاحيات، والتحقق من صحة المدخلات، وترميز المخرجات، وإدارة الأسرار لهذا المعالج وبيّن مكان فرض كل منها". الفجوة في هذه القائمة هي الثغرة البرمجية.
• حلل التهديدات في ملف الفروقات (diff) بأكمله، وليس في سطور الكود المنفصلة. بما أن الثغرات الخطيرة تكمن في الإغفال، قم بالمراجعة الأمنية بالسؤال "ما هو عنصر التحكم الذي كان يجب وضعه هنا ولم يُوضع؟" بدلاً من مجرد البحث عن سطور كود سيئة.

إعادة الهيكلة — جعل الاستعلام ذو معاملات (parameterized) (يتخلص من الحقن)، وترميز المخرجات (يتخلص من ثغرات XSS)، وإضافة فحص صلاحيات على مستوى الكائن (يتخلص من ثغرات IDOR)، واستخراج السر المكتوب مباشرة إلى ملف الإعدادات:

// بعد
app.get("/api/orders/:id",
  authMiddleware,
  validate(orderParamsSchema),                    // التحقق من صحة المدخلات
  async (req, res) => {
    const order = await db.query(
      "SELECT * FROM orders WHERE id = $1", [req.params.id]   // ذات معاملات (parameterized)
    );
    if (!order || order.userId !== req.user.id) {            // مصادقة على مستوى الكائن
      return res.sendStatus(404);
    }
    res.json({ customerName: order.customerName });          // مخرجات مهيكلة، ومحولة تلقائياً
  }
);
// السر: process.env.STRIPE_API_KEY، يتم تحميله مرة واحدة عند البدء، ولا يكتب مباشرة أبداً

إذا انتشرت الرائحة الأمنية عبر نسخ الكود، فقم بإصلاحها مرة واحدة واستخدم استخراج الدالة (Extract Function) لعنصر التحكم (مثل requireOrderOwnership، و escapeHtml) بحيث تشترك كل مواقع الاستدعاء في كود واحد خضع للمراجعة الأمنية بدلاً من وجود N من النسخ الضعيفة.