قادة الفكر
ثغرات CVE زائفة وتقارير مولّدة بالذكاء الاصطناعي والحاجة إلى التحقق

أصبح إعداد تقارير مقنعة عن الثغرات أقل تكلفة، وهذا يزيد من تبعاتها على القائمين على صيانة البرمجيات وفرق الأمن. نُشرت ست ثغرات ضمن قاعدة بيانات نقاط الضعف والتعرّض الشائعة (CVE) بحق SQLite في يوليو 2026، وحصلت اثنتان منها على درجة خطورة بلغت 9.8. بدت التقارير موثوقة، إذ وصفت أخطاء في سلامة الذاكرة وأوردت شروحًا تقنية وشيفرات لإثبات المفهوم.
لكن باحثو JFrog اكتشفوا أن بعض الدوال التي أشارت إليها هذه التقارير لم تكن موجودة في الإصدارات المتأثرة. والأكثر من ذلك، أن أيًا من عمليات إثبات المفهوم (PoC) لم يُعِد إنتاج الثغرات المزعومة. وتشير صفحة CVE الخاصة بـSQLite حاليًا إلى أن هذه التقارير الستة لا تتعلق بأخطاء برمجية؛ وقد رُفضت سجلات CVE لاحقًا.
لا تقتصر المشكلة على SQLite. وقدّر دانيال ستينبرغ، المسؤول عن صيانة curl، في العام الماضي أن نحو 20% من تقارير الأمن الواردة كانت نتاج محتوى رديء مولّد بالذكاء الاصطناعي. وتلقت هيئة ترقيم CVE (CNA) التابعة لـGitHub ما يقارب 4,000 طلب CVE في مايو 2026؛ أي زيادة في حجم الطلبات بنحو عشرة أضعاف مقارنة بالعام السابق. ولم تُرجع GitHub هذه الزيادة إلى الذكاء الاصطناعي، ولم تشر إلى تراجع جودة الطلبات، لكن النمو الهائل في حجمها يبرز مدى الضغط الواقع على عملية الإفصاح عن الثغرات.
يسهّل الذكاء الاصطناعي إعداد ادعاءات مفصّلة بشأن الثغرات، لكن تحديد مدى صحتها يستغرق وقتًا. وحين يُدرج CVE في موجزات الأمن وقواعد البيانات العامة، فإن تصحيح السجل الأصلي لا يعني تلقائيًا تصحيح كل نسخة منه. وهذا يزيد الحاجة إلى التمييز بين ثغرة مُبلّغ عنها وأخرى جرى التحقق منها تقنيًا.
ما المقصود بثغرة CVE «زائفة»؟
يشيع استخدام مصطلح «CVE زائف» للإشارة إلى ثغرة CVE يُرجّح أن الإبلاغ عنها تم على نحو غير صحيح. لكن وصفها بأنها زائفة لا يعني أن الإبلاغ عنها كان مضللًا عمدًا. فقد تنتج عن تحليل ساكن يغفل فحصًا للتحقق من صحة البيانات أو يسيء تفسير المدخلات على أنها خاضعة لتحكم المهاجم. وقد يصف التقرير دالة حقيقية، لكنه يزعم وجود مسار هجوم غير صالح. وقد يُسنَد معرّف (معرّف CVE) إلى ثغرة ثم يُسحب لاحقًا إذا تبيّن أن الحالة المُبلّغ عنها لم تكن في الواقع ثغرة. وهذا يختلف عن تقرير مختلق عمدًا.
والخلاف لا يعني أيضًا أن ثغرة CVE زائفة. فقد يعترض أحد المورّدين على نتائج باحث بشأن قابلية الاستغلال أو حدود التهديد أو ما إذا كان المقصود من دالة ما معالجة مدخلات غير موثوقة. لكن الاعتراض لا يثبت أن الباحث أخطأ. كما أن رفض CVE لا يعني بالضرورة أنها مختلقة؛ فقد تُرفض لأنها مكررة أو لأسباب إدارية. ورغم أن معرّف CVE لا يُعد تحققًا تقنيًا مستقلًا، فإن على القطاع التعامل بجدية مع التقارير الحقيقية.
لماذا تُعدّ ثغرات CVE الزائفة مشكلة؟
من المشكلات التي نلاحظها استخدام أشخاص للذكاء الاصطناعي في إنشاء تقارير عن الثغرات من دون التحقق على النحو المناسب من النتائج. وقد تتضمن هذه التقارير شروحًا تقنية مفصّلة وإشارات إلى الشيفرة، بل وحتى عمليات إثبات مفهوم (PoC)، ما قد يجعلها تبدو موثوقة. لكن، كما رأينا في ثغرات CVE المتعلقة بـSQLite، فإن بعض الدوال المشار إليها لم تكن موجودة أصلًا في الإصدارات المتأثرة.
أفادت GitHub بزيادة كبيرة في عدد البلاغات عن الثغرات في عام 2026، لكنها لم تعزُ تلك الزيادة إلى الذكاء الاصطناعي ولم تذكر تراجعًا في جودة البلاغات. ويتمثل مصدر القلق في أن ازدياد عدد التقارير يرفع أيضًا حجم العمل اللازم للتحقيق فيها، سواء أكانت النتائج حقيقية أم لا.
ومن سبق لهم فرز تقارير الثغرات يعرفون مدى صعوبة هذه المهمة عمليًا. إذ يمكن لنموذج ذكاء اصطناعي تحديد استدعاء واجهة برمجة تطبيقات (API) مثير للريبة، ووضع تصور أولي لسيناريو استغلال، وصياغة تقرير احترافي المظهر بسرعة. لكن تحديد ما إذا كان ذلك السيناريو قابلًا للتنفيذ قد يتطلب التحقق من الإصدار المحدد، وتتبع تدفق التحكم، ومعرفة كيفية وصول البيانات إلى الدالة، وإعداد بيئة اختبار، وتجربة الاستغلال المزعوم. وتُتّبع العملية نفسها سواء أكان التقرير دقيقًا أم لا، وقد تكون مكلفة.
وقد تلحق ثغرات CVE الزائفة ضررًا بالسمعة أيضًا. إذ يمكن أن ينتشر إعلان عن ثغرة بسرعة عبر موجزات أدوات الفحص وقواعد بيانات الأمن ونتائج البحث. لكن التصحيح اللاحق قد لا يصل إلى النطاق نفسه. وحتى بعد الاعتراض على تقرير أو رفضه، قد يجد المورّدون أنفسهم في موقف دفاعي أمام عملاء اطّلعوا على التقرير الأصلي.
وثمة خطر آخر يتمثل في إغفال ثغرات حقيقية أو تأخر اكتشافها، لأن الفرق تقضي وقتًا في التحقيق في تقارير غير صحيحة. فعندما تكون موارد القائمين على الصيانة وفرق الأمن محدودة، تكون كل ساعة تُنفق في دحض نتيجة إيجابية كاذبة ساعة كان يمكن استثمارها في التحقيق في مشكلة أمنية فعلية.
التصدي للمشكلة بالأتمتة
لا يزال كثير من المحققين يعتمدون على الفرز اليدوي لمواجهة التدفق الهائل الجديد من التقارير، لكن هذا النهج غير قابل للاستمرار. وتُعد الأتمتة عونًا كبيرًا في التحقق من ادعاءات الثغرات بالرجوع إلى الإصدار المتأثر وإعداداته الفعلية. وفيما يلي خمسة أسئلة ينبغي طرحها:
- هل شروط الهجوم المسبقة معقولة، بما فيها الإعدادات والأذونات؟
- هل الدالة المزعومة موجودة في الإصدار المتأثر؟
- هل يستطيع المهاجم الوصول إلى الشيفرة المعرّضة للثغرات؟ حدّد ما إذا كان يمكن تنفيذ الشيفرة المعنية في ظل الظروف المتأثرة، وما إذا كان المهاجم يستطيع تقديم مدخلات تصل إليها.
- هل يستطيع المختبِرون إعادة إنتاج السلوك في اختبار مضبوط أو باستخدام إثبات مفهوم (PoC)؟
- هل يُظهر السلوك المرصود الأثر الأمني الموضح في الإشعار؟
يمكن للأدوات القائمة على الوكلاء إنشاء بيئات اختبار، وتحليل مسارات الشيفرة، وتوليد إثباتات المفهوم (PoCs)، وتسجيل أدلة التنفيذ لمراجعتها. لكنها لا تستطيع حسم كل ادعاء تلقائيًا. وحتى عندما تكون الثغرة حقيقية، قد يفشل إثبات المفهوم إذا كانت البيئة غير مكتملة أو كان المُحفِّز غير صحيح. وقد يتمكن المختبِرون من إعادة إنتاج انهيار من دون إثبات قابلية الاستغلال المزعومة. ولهذه المحاذير، يظل التقدير البشري بالغ الأهمية. لكن هذه الأدوات قد تساعد الفرق على الاقتراب من إجابة قابلة لإعادة الإنتاج قبل أن يستنزف التقرير مزيدًا من الوقت في فرق الهندسة وإدارة الثغرات ودعم العملاء.
التغلب على الإرهاق في منظومة CVE
لن تكفي سياسة موجزة واحدة لإصلاح مشكلة معرّفات CVE المزيفة بطريقة سحرية. لكن من المفيد اشتراط أدلة أقوى عند تقديم البلاغات، وتوضيح حالة إعادة الإنتاج. ومن المفيد أيضًا وضع آلية أوضح للتعامل مع السجلات المتنازع عليها، وتصحيح البيانات اللاحقة بسرعة أكبر. وينبغي تشجيع الباحثين على التحقق من النتائج التي توصلوا إليها بمساعدة الذكاء الاصطناعي قبل تقديمها.
يجب أن تركز فرق الأمن والمورّدون على فحص الأدلة. فدرجة الخطورة الحرجة في CVE لا تكشف ما إذا كان بالإمكان الوصول إلى المسار المعرّض للثغرة في بيئتهم. وفشل إثبات المفهوم لا يعني بالضرورة أن كل شيء على ما يرام. كما أن الحصول على معرّف CVE لا يعفي الفرق من تنفيذ العمل التقني اللازم لفهم المشكلة.
يعزز الذكاء الاصطناعي القدرة على اكتشاف الثغرات، كما يتيح إنشاء ادعاءات تبدو مقنعة لكنها غير صحيحة. وفي ظل تزايد التقارير، تحتاج المؤسسات إلى الاستثمار في التحقق. ويشمل ذلك إعداد الاختبارات، وإعادة إنتاج النتائج، والتحقق من الافتراضات، وتسهيل تقييم الأدلة. وهذا مجال يمكن أن يؤدي فيه الاختبار الأمني القائم على الوكلاء دورًا مهمًا.












