ثغرات وهمية بالذكاء الاصطناعي: كيف تفرز تنبيهات CVE

في 3 أغسطس 2026، نشر فريق أبحاث الأمن في JFrog نتيجة ينبغي أن تغيّر طريقة قراءة كل فريق هندسي لتنبيهات الثغرات لديه. دفعة من ست ثغرات SQLite مصنّفة حرجة وعالية الخطورة — إحداها منحتها Red Hat في البداية درجة CVSS كاملة 10.0 — تبيّن أنها محض خيال. ليست مبالغاً فيها، ولا محل خلاف. بل مُختلقة.

استشهدت البلاغات بدوال غير موجودة أصلاً في الإصدارات المتأثرة. وأشارت إلى أرقام أسطر تقع على تعليقات برمجية. وأحالت إلى رقع أمنية بلا أي تغيير مقابل في الشيفرة. وحين تتبّعتها JFrog، تبيّن أن الستة جميعاً صادرة عن مستودع GitHub واحد أُنشئ حديثاً ونشر 55 بلاغاً خلال أربعة أيام، 54 منها مُختلق بالكامل.

تعمل SQLite داخل كل هاتف أندرويد، وكل جهاز iOS، وكل متصفح، ومعظم الأنظمة المدمجة على وجه الأرض. ولمدة أسبوع تقريباً، كانت فرق الأمن حول العالم تنظر إلى ست ثغرات حرجة وهمية في طوابير عملها، ضد واحدة من أوسع البرمجيات انتشاراً في التاريخ.

هذا هو الجانب من قصة الذكاء الاصطناعي والأمن الذي لم يخطط له أحد.

ما وجدته JFrog فعلياً

لم تكن البلاغات الستة خاطئة بشكل خفي. كل واحد منها انهار لحظة فتح الشيفرة المصدرية.

تأمّل CVE-2026-51296 لحظة. أشار البلاغ إلى السطر 3555 في ملف طوله 2706 أسطر. هذا الفحص وحده — هل يملك الملف هذا العدد من الأسطر أصلاً؟ — يستغرق نحو عشر ثوانٍ ويُبطل بلاغاً مصنّفاً "عالي الخطورة". لم يُجرِه أحد في السلسلة كلها قبل نشر الثغرة ونسخها إلى قواعد البيانات التابعة.

أما أدلة إثبات المفهوم، حيثما وُجدت، فلم تُنتج النتيجة الموصوفة. كانت درجات الخطورة واثقة ودقيقة ومرتبطة بلا شيء.

لماذا يختلف هذا بنيوياً عن البلاغات الرديئة المعتادة

البلاغات الأمنية الزائفة ليست جديدة. الجديد هو اختلال تكلفة الطرفين.

كان إنتاج بلاغ يبدو معقولاً يتطلب فهماً للشيفرة يكفي ليكون خطيراً. أما اليوم فيتطلب أمراً نصياً واحداً. سيُنتج نموذج لغوي عن طيب خاطر بلاغاً فصيحاً تقنياً — مصطلحات صحيحة، وأسماء دوال مقنعة، وتصنيف CWE، ومتّجه CVSS، ودليل إثبات مفهوم يقرأ بشكل مُقنع — لبرمجية لم يحلّلها قط بل طابق أنماطها فحسب. المُخرَج لا يُميَّز عن عمل الخبراء بنظرة سريعة، وعديم القيمة عند الفحص.

انقلبت المعادلة الاقتصادية. توليد الضجيج صار مجانياً عملياً، بينما التحقق منه ما زال يكلّف بعد ظهيرة خبير كامل. هذه الفجوة هي المشكلة برمّتها، ولهذا يبدو الأمر أقرب إلى هجوم حجب خدمة على انتباه المشرفين منه إلى بريد مزعج.

اصطدم مشروع curl بهذا الجدار أولاً. سحب Daniel Stenberg مكافآت curl المالية للثغرات مطلع 2026 بعد أن تضاعف حجم البلاغات نحو ثمانية أضعاف، وكان خُمسها تقريباً يصف ثغرات غير موجودة ببساطة. ونجح إلغاء المكافأة — إذ أفاد Stenberg لاحقاً بأن "مشكلة البلاغات الرديئة لم تعد مشكلة"، وأن معدلات الثغرات المؤكدة ارتفعت فوق مستويات ما قبل 2024 بعد انصراف باحثي المكافآت. أما Linus Torvalds فوصف قائمة أمن النواة بأنها شبه غير قابلة للإدارة، مشيراً إلى الأثر التبعي البديهي: "إن وجدت خللاً بأدوات الذكاء الاصطناعي، فالأرجح أن غيرك وجده أيضاً." نتائج مكررة من أدوات متطابقة، وعلى نطاق واسع.

والمسألة لا تتعلق بالبلاغات الزائفة وحدها. يُظهر رصد VulnCheck لمطلع 2026 أن حجم الإفصاحات الحقيقية المدعومة بالذكاء الاصطناعي يتسلق بحدّة أيضاً — Chrome بزيادة 563%، وبلاغات GitHub عبر المصادر المفتوحة بزيادة 476%، وApache بزيادة 170%. ولاحظت Madison Oliver Ficorilli من GitHub أن لا مُبلّغ واحد يمثل أكثر من نحو 3% من الحجم، ولا مشروع واحد أكثر من نحو 7%، وهو ما يستبعد وجود حفنة من المسيئين ويشير إلى تحوّل بنيوي.

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

قائمة الفرز العملية

تتعمّم مؤشرات JFrog التحذيرية إلى فحص يمكنك إجراؤه في دقائق، قبل أن تعيد ثغرة "حرجة" ترتيب أسبوع أحدهم.

1. راجع صفحة البلاغات الرسمية للمشروع أولاً. تنشر SQLite صفحتها على sqlite.org/cves.html. ومعظم المشاريع الجادة تنشر ما يعادلها. ثغرة حرجة لم يعترف بها المشرفون قط هي أقوى إشارة متاحة، وتكلفتها تحميل صفحة واحدة.

2. اطلب معرّف تعديل أو طلب دمج. لكل إصلاح حقيقي رقعة. إن قال البلاغ "أُصلح في 3.51.3" ولم يستطع الإشارة إلى التعديل، فاسأل عن السبب. ثم افحص الفرق بنفسك — git log -p v3.51.2..v3.51.3 -- src/expr.c كان كفيلاً بإسقاط CVE-2026-51303 فوراً.

3. تحقق من وجود الشيفرة أصلاً. استنسخ الإصدار المتأثر بالتحديد وابحث عن الدالة المذكورة في البلاغ. إن لم تكن موجودة، فقد انتهيت. يلتقط هذا الفحص غالبية الاختلاقات، لأن النماذج اللغوية تهلوس أسماء الرموز من إصدارات مجاورة ومن أعراف لغة C العامة.

4. افحص أرقام الأسطر. أرخص اختبار في القائمة. طبّق wc -l على الملف المذكور. إن أشار البلاغ إلى ما بعد نهاية الملف، فتوقف عن القراءة.

5. أعد إنتاج دليل إثبات المفهوم في بيئة معزولة. إن وُجدت حمولة، فشغّلها داخل حاوية معزولة على الإصدار المزعوم. لا إعادة إنتاج، لا أولوية. وهذا غير قابل للتفاوض في أي تصنيف حرج.

6. تفحّص اتساق البيانات الوصفية. تعريفات CPE فارغة، ونطاقات إصدارات متناقضة، وحساب مُبلّغ حديث النشأة بدفعة بلاغات، وعدة ثغرات حرجة ضد المشروع ذاته خلال ساعات — إشارات ضعيفة منفردة، حاسمة مجتمعة.

7. زِن مصدر البلاغ. ثغرة صادرة عن فريق أمن المشروع نفسه أو مورّد معروف أو مجموعة بحثية راسخة ليست المُنتج ذاته الصادر عن حساب أُنشئ الأسبوع الماضي. تعامل مع مصدر البلاغ كحقل من الدرجة الأولى في فرزك.

إليك بوابة أولية يمكنك دمجها في سكربت مراجعة:

#!/usr/bin/env bash
# فحص بنيوي سريع لصحة ادعاء ثغرة
# الاستخدام: ./cve-check.sh <مسار-المستودع> <وسم-الإصدار> <اسم-الدالة> <الملف> <السطر>
 
REPO=$1; TAG=$2; FUNC=$3; FILE=$4; LINE=$5
 
git -C "$REPO" checkout --quiet "$TAG" || { echo "FAIL: version tag $TAG not found"; exit 1; }
 
if ! grep -rq "\b$FUNC\b" "$REPO/$FILE"; then
  echo "RED FLAG: function '$FUNC' absent from $FILE at $TAG"
fi
 
TOTAL=$(wc -l < "$REPO/$FILE")
if [ "$LINE" -gt "$TOTAL" ]; then
  echo "RED FLAG: cited line $LINE exceeds file length ($TOTAL lines)"
fi
 
echo "Context at $FILE:$LINE —"
sed -n "$((LINE-2)),$((LINE+2))p" "$REPO/$FILE" 2>/dev/null

ثلاثة فحوص، وبضع ثوانٍ، وكانت وحدها ستُعلّم أربعاً من بلاغات SQLite الستة.

ما ينبغي تغييره في إجراءاتك

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

ثلاثة تعديلات تستحق التنفيذ الآن.

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

تتبّع مصدر البلاغ داخل أدواتك. إن كانت منصة إدارة الثغرات لديك لا تُظهر من قدّم البلاغ ومتى أُنشئ حسابه، فتلك ثغرة تستحق السد. كانت دفعة SQLite قابلة للتمييز كعنقود — 55 بلاغاً، أربعة أيام، مستودع واحد جديد — قبل وقت طويل من قراءة أي أحد لشيفرة C.

وثّق مسار الثغرات المطعون فيها. حين تقرر أن بلاغاً باطل، على أحدهم إبلاغ جهة إصدار المعرّف وقواعد البيانات التابعة، وعلى سجلك الداخلي أن يقول "تم التحقق: باطل" لا "لم يُرقّع بعد". وإلا ظهر الشبح ذاته في التدقيق التالي، وتعفّنت أدلة امتثالك بصمت. أبلغت JFrog نتائجها إلى GHSA وRed Hat وNVD — وتلك الخطوة تحديداً هي ما يزيل التلوث فعلاً.

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

التناظر المُقلق

القدرة نفسها تعمل في الاتجاهين، وهذا ما يجعل تنظيمها صعباً.

البحث الأمني المدعوم بالذكاء الاصطناعي يعثر على أخطاء حقيقية وخطيرة — عمل Anthropic في Project Glasswing وطفرة الإفصاحات المشروعة من Mozilla وMicrosoft وGoogle كلها واقعية، وقد غطّينا هذا الجانب في Claude Mythos ومشروع Glasswing. ولا أحد عاقل يريد إيقاف ذلك. تلقّت Apache تبرعاً بقيمة 1.5 مليون دولار تحديداً لاستيعاب عبء الاستجابة الحقيقي المتزايد. ولاحظ مشرف curl نفسه أن واحدة من كل خمس نتائج مبكرة من Mythos كانت صحيحة — نسبة إصابة 20% تُعدّ ممتازة لباحث بشري.

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

يبقى ما هو غير براق لكنه فعّال: أعد الإنتاج قبل أن تحدد الأولوية، وتعامل مع درجة الخطورة كادعاء لا كقياس. العشر ثوانٍ اللازمة لتشغيل wc -l على ملف مصدري هي حالياً من أعلى الممارسات الأمنية مردوداً.

للفرق في المنطقة

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

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

تلك النتيجة الثانية هي الخطر الحقيقي هنا. إرهاق التنبيهات هو الطريق الذي تُفوَّت به ثغرة CVSS 10.0 حقيقية.

قراءات ذات صلة:

• Claude Mythos ومشروع Glasswing: اكتشاف ثغرات اليوم صفر بالذكاء الاصطناعي
• أمن الشيفرة المولّدة بالذكاء الاصطناعي: دليل الثغرات
• Trapdoor: هجمات سلسلة التوريد على أدوات البرمجة بالذكاء الاصطناعي
• DevSecOps: الأمن المدمج في دورة التطوير