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

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

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

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

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

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

• هدف التدريب هو المعقولية لا الأمان. يحسّن التنبؤ بالرمز التالي من أجل الطريقة الأكثر شيوعاً في كتابة الكود، والمدونات العامة مليئة بمقتطفات تعليمية تبني الاستعلامات بدمج النصوص ولا تتحقق من الصلاحيات. ويقولها مقال OX Security عن أمان البرمجة بالإحساس (vibe coding) صراحة: "دمج النصوص هو الأكثر ظهوراً في بيانات التدريب". وفي معيار SusVibes من جامعة كارنيجي ميلون، الذي يضم 200 مهمة حقيقية لتطوير الميزات، أنتج SWE-Agent مع Claude 4 Sonnet حلولاً صحيحة وظيفياً في نحو 61% من الحالات، لكنها كانت آمنة في نحو 10.5% فقط.
• "الانتهاء" يُعرَّف بالمسار السعيد. يحسّن النموذج اللغوي الكبير من أجل نجاح الطلب الظاهر. ولا تعطي ضوابط الأمان أي إشارة إيجابية في تشغيل سريع — فالفحص الغائب لا يُفشل أي اختبار ولا يعطّل أي عرض تجريبي — لذا يتم إسقاطها.
• غياب سياق المستودع. لا يستطيع النموذج رؤية دالة المساعدة authorize() الخاصة بك، أو مخطط التحقق الخاص بك، أو مدير الأسرار لديك، لذا يقوم بكتابة مفتاح مباشر أو يتخطى الفحص تماماً بدلاً من إعادة استخدام عناصر التحكم المتوفرة.
• التملق + السرعة. يعيد النموذج ما طلبته حرفياً ("أضف نقطة نهاية للطلبات")، لا نموذج التهديدات المحيط به، ومراجعة الكود ونمذجة التهديدات هي بالضبط العقبات التي يزيلها التطوير بسرعة الذكاء الاصطناعي. والنتيجة الأساسية لـ OX Security هي أن الكود المولد بالذكاء الاصطناعي لا يحتوي على ثغرات لكل سطر أكثر من الكود الذي يكتبه البشر؛ ما يوصل الكود الضعيف إلى الإنتاج هو السرعة، لأن "مراجعة الكود السليمة لا يمكنها ببساطة مجاراة سرعة الإنتاج الجديدة". وتحذر OX أيضاً من تطبيقات "غير آمنة بسبب الغباء" (insecure by dumbness): يبنيها وينشرها بالذكاء الاصطناعي مستخدمون غير تقنيين يفتقرون إلى الخبرة الأمنية اللازمة لملاحظة ما هو مفقود.
• تاريخ انتهاء التدريب (Training-cutoff staleness). تلجأ النماذج إلى أساليب تشفير ومكتبات كانت تعتبر مقبولة قبل سنوات (مثل MD5، و SHA-1، وخيارات TLS المهملة، ومسارات المصادقة القديمة).

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

• قابلية الاستغلال المباشر. وجد تقرير Veracode لأمان الكود المولد بالذكاء الاصطناعي لعام 2025 (80 مهمة برمجية وأكثر من 100 نموذج لغوي) ثغرات أمنية في 45% من الحالات، وفشلت النماذج في الحماية من البرمجة العابرة للمواقع (CWE-80) في 86% من الحالات. ووجدت CodeRabbit ثغرات XSS في طلبات الدمج المكتوبة بمشاركة الذكاء الاصطناعي أكثر بـ 2.74 مرة منها في الطلبات التي كتبها بشر فقط؛ ووجدت Tenzai أن أياً من 15 تطبيقاً بناها خمسة وكلاء برمجة لم يتضمن حماية من CSRF ولم يضبط ترويسات الأمان؛ ووجدت Escape.tech أكثر من 400 سر مكشوف في أكثر من 5600 تطبيق مبني بالبرمجة بالإحساس.
• غير مرئي للاختبارات وللقراء. لا يؤدي فحص صلاحيات مفقود إلى فشل الاختبارات ولا يحتوي على فروقات واضحة للإشارة إليه، لذا يمر عبر المراجعة بسهولة — وحجم إنتاج الذكاء الاصطناعي الهائل يعني عدم قدرة المراجعة البشرية على التوسع لالتقاط كل المشكلات.
• تراكم الدين التقني. وجد تحليل GitClear لعام 2025 لـ 211 مليون سطر معدّل أن الأسطر المرتبطة بإعادة الهيكلة ("المنقولة") انخفضت من 25% من الأسطر المعدلة في 2021 إلى أقل من 10% في 2024، بينما ارتفعت الأسطر المنسوخة والملصقة من 8.3% إلى 12.3% وتجاوزت الأسطر المنقولة لأول مرة في 2024؛ ونمت الكتل التي تضم خمسة أسطر مكررة أو أكثر نحو ثمانية أضعاف خلال 2024. فيُستنسخ النمط غير الآمن نفسه عبر قاعدة الكود، مضاعفاً نطاق الضرر لأي نقطة عمياء واحدة.

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

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

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

// بعد
app.get("/api/orders/:id",
  authMiddleware,
  validate(orderParamsSchema),                    // التحقق من صحة المدخلات
  async (req, res) => {
    const { rows: [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، يتم تحميله مرة واحدة عند البدء، ولا يكتب مباشرة أبداً

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