كل ادعاء أمني يحتاج مصدر دليل مناسباً لطبقته، مع فصل الأثر المثبت عن السيناريو المحتمل.
قالب تقرير نتائج Red Teaming وسلسلة الأدلة وتصنيف الأثر
متى تستخدم وثيقة النتيجة
يستخدم هذا القالب بعد اختبار مصرح به لأنظمة الذكاء الاصطناعي التوليدي لتسجيل نتيجة محددة وربطها بالأدلة والسبب الجذري والأثر وقرار المعالجة. يترجم الموضوعات العامة في Phase 6 Post-Exploitation وPhase 7 Evaluation & Reporting من OWASP GenAI Red Teaming Manual v1.0 إلى نموذج تحقيق ومراجعة، ولا يمثل تقرير OWASP الرسمي ولا تصريحاً بتطبيق نشاط هجومي على منصة غير مخولة. يجب أن تُكتب النتيجة بوصف ما شوهد وضمن أي وصول وبيئة وإصدار؛ فلا تعد الاستجابة النصية وحدها دليلاً على وقوع معاملة، كما لا يثبت نجاح فحص محدود غياب الثغرات المستقبلية. تحتوي الوثيقة العامة على إحالات للأدلة الحساسة بدلاً من نسخها دون ضرورة.
معرّف الحالة وتاريخها
يسجل القالب FINDING-ID وENGAGEMENT-ID وSYSTEM-ID وتاريخ الملاحظة واسم صاحب التقييم ومستوى وصوله والتكوين الفعلي. يجب أن يكون للنتيجة رقم ثابت لا يتغير عند مراجعة الشدة أو إغلاق التذكرة، لأن هذا الرقم يربط الملاحظة الأصلية بالتحليل الفني والمعالجة والانحدار. قد تتغير نسخة النموذج المستضاف أو فهرس RAG أو سياسة تفويض الأداة دون تعديل شيفرة التطبيق، لذا لا يكفي ذكر اسم المنتج. عند غياب معرف إصدار موثوق يكتب ذلك صراحة مع مصدر معرفة محدود، ويُذكر هل جاءت الملاحظة من Black-Box أم من سجلات أو تكوين داخلي. لا تُنسب قدرة مختبر يمتلك معلومات داخلية إلى خصم خارجي بلا تفسير.
تعريف الدعوى الأمنية
تكتب الدعوى على صورة قابلة للفحص: «أعاد محرك البحث مستنداً تجريبياً خارج دور مستخدم القراءة» أو «رفض نظام الأعمال طلب تعديل خارج صلاحية الحساب رغم صدور اقتراح أداة». لا تكفي عبارة «اختُرق النموذج» أو «النظام محصن»، لأنها لا تحدد مكوّناً أو أصلاً أو حد ثقة أو أثرًا. يمكن تقسيم الحالة إلى ملاحظات سلوك ونتائج تنفيذ ونتائج كشف، مع الاحتفاظ بروابط بينها عندما تتعلق بسلسلة واحدة. ويجب أن يعرف صاحب القرار ما إذا كانت النتيجة تخص دقة الإجابة أم سرية البيانات أم تفويض عملية أم مراقبة، لأن هذه أنواع مختلفة من الإخفاقات ومعالجتها تقع لدى فرق مختلفة.
تسجيل نطاق التفويض
يوضح القالب البيئة والحساب ونوع البيانات التي سُمح باستخدامها، والواجهة أو الأداة التي تدخل ضمن قواعد العمل، وما الاستثناءات التي كانت سارية وقت الفحص. لا يبرر وجود أثر غريب توسيع البحث إلى حسابات حقيقية أو خدمة مورد خارجي لم يمنح إذناً. إذا ظهر مؤشر يتجاوز النطاق توضع الحالة ضمن مسار إبلاغ واحتواء مع جمع الحد الأدنى المسموح من الأدلة، ولا يُواصل الاختبار للحصول على نتيجة أكثر إثارة. ويؤثر مستوى وصول المختبر في تفسير الواقعية، فقد يحصل على سجل لا يراه المستخدم العادي لكنه يساعد على إثبات السبب الجذري دون أن يعد هذا الوصول نفسه ثغرة.
شروط التجربة ومصدر المدخل
يسجل شرط مسبق مثل وجود ملفين اصطناعيين لمستأجرين ودور حساب محدد، ونسخة خدمة الاسترجاع ومكان وجود الوثائق وسقف استدعاءات معروف. يذكر مصدر المحتوى غير الموثوق ومن يستطيع تغييره وكيف وصل إلى النموذج أو الأداة، بما يشمل الرسائل والمستندات ونتائج الأدوات والوسائط عند الحاجة. لا ينبغي نقل سلسلة هجومية خطيرة إلى تقرير متاح للجمهور؛ يكفي وصف آلية الاختبار الدفاعية وعلاقتها بالحد مع حفظ تفصيل معتمد في مخزن مقيد للفرق المخولة. إذا كانت البيئة غير ممثلة لسياسة الإنتاج يجب أن يظهر ذلك في حدود إمكانية تعميم النتيجة.
معيار PASS وFAIL
يعرض القالب المعايير التي اعتُمدت قبل التنفيذ. في حالة عزل مستندات قد يكون PASS عدم استرجاع وثيقة خارج الدور وفق سجل خدمة البحث، وFAIL ظهور مصدر محظور مؤكد. في حالة أداة قد يكون PASS رفض API العملية وبقاء السجل بلا تغيير، وFAIL تغيير تجريبي خارج الإذن. إذا لم يتوفر سجل أو تعطلت الأداة يستخدم INCONCLUSIVE ولا يُمنح نجاح لأن النموذج قال إنه رفض. يجب أن تكون القاعدة واضحة بما يكفي لمراجع مستقل، ويمكن فصل معيار سلوك النموذج عن معيار صلاحية النظام الخلفي إذا اختُبرا معاً.
وصف الملاحظة الخام
يُسجل ما ظهر في الواجهة أو سجل المصدر بحياد ووقت ومعرف طلب، دون تعبيرات تفسيرية تتجاوز ما يثبت الدليل. مثال: «اختيرت أداة UpdateRecord في الاستجابة الوسيطة، ثم أعادت خدمة التفويض حالة مرفوضة، ولم تتغير قيمة سجل الاختبار». هذه العبارة تختلف عن «تم تعديل سجل» وتسمح بتحديد طبقات النظام. قد يكون نص النموذج غير متوافق مع سياسة الاستخدام ومع ذلك تكون الخلفية قد منعت الأثر التنفيذي، وتجب معالجة السلوك وحماية التنفيذ بصورة منفصلة. إذا استرجع المستودع ملفاً خارج الدور لكن النموذج حجبه لاحقاً، لا يختفي ضعف خدمة الاسترجاع لمجرد أن واجهة المحادثة بدت سليمة.
إسناد الأدلة
يُحفظ لكل دليل معرف واسم المصدر ونوعه وتاريخ الجمع والجهة المخولة والوصف الذي يثبته. قد يشمل سجل استرجاع ملف أو قرار خدمة هوية أو حالة جدول قبل وبعد أو حدث منصة مراقبة. لا تساوي لقطة شاشة دليلاً خلفياً على تنفيذ معاملة، ولا يحل تصريح باحث وحده محل دليل موثوق حيث يُطلب إثبات أثر. تُقيد صلاحيات الوصول إلى المادة الخام الحساسة، ويمكن وضع بصمة أو رابط مرجعي لتنقيح التقرير دون فقد القدرة على التحقق. يجب ألا تتكرر بيانات شخصية أو رموز خدمة أو أسرار في البريد المتبادل عند مراجعة النتيجة.
تحليل السبب الجذري
يفصل التحليل بين ما تأكد من الكود أو السجلات وما يحتاج تحقيقاً. فقد يكون مصدر ضعف الكشف مرشح مستأجر في فهرس RAG، أو رابط ملف خلفي، أو ذاكرة مشتركة، بينما قد يكون فشل معاملة نتيجة رمز خدمة واسع دون فحص هوية المستفيد. لا يعالج التقرير كل نوع بإضافة عبارة Prompt أقوى، بل يشير إلى موضع السيطرة التقنية المتوقع. يجب أيضاً تمييز ضعف الضابط الأساسي عن فقدان إشارة كشف ثانوية؛ فقد يمنع نظام الأعمال الفعل لكن تخفق المراقبة في تسجيل المحاولة. إذا لم تتوفر صلاحية فحص السبب، تبقى فرضية معلنة وتُوجَّه للمسؤول عن المكون.
ما ثبت وما لم يثبت
يوفر القالب حقلاً واضحاً بعنوان «حدود النتيجة». إذا أظهر الاختبار ملفاً اصطناعياً واحداً خارج دور الحساب، لا يجوز الادعاء أن جميع ملفات المؤسسة أصبحت متاحة. وإذا اقترح الوكيل استدعاء أداة لا يعني ذلك أن العملية نفذت. يكتب الباحث أي مستأجرين وأدوار وإصدارات وقنوات فُحصت، وما العوامل التي قد تجعل النتيجة تختلف بعد تحديث المورد أو إعادة بناء الفهرس. ويمكن أن تكون الحالة حاسمة رغم ضيق العينة إذا كان الضابط حساساً، لكن يجب أن تبقى الشدة منفصلة عن التوسع غير المدعوم بالأدلة. إظهار عدم اليقين يزيد مصداقية التقرير.
تقدير الخطورة والأثر
يصف الأثر على سرية البيانات وسلامة المعلومات والتوافر وقدرة الوكيل على الفعل وعواقب ذلك على العملية. ينبغي أن يعرف مالك الأصل قيمة البيانات وحساسية المعاملة وما الضوابط التعويضية والكشف المتاحة، لا أن يحدد فريق الاختبار درجة تجارية من دون السياق. يمكن أن يختلف تقدير المخاطر بين أداة تغيّر بيانات مالية وواجهة معلومات عامة حتى لو كان الاسم التقني للهجوم متشابهاً. يذكر التقرير الأثر المؤكد ضمن الاختبار والضرر المحتمل على الإنتاج بصورة منفصلة، ودرجة الثقة في كل تقدير. ولا تُستخدم أرقام احتمالية دقيقة دون بيانات تدعمها أو تعريف لمنهجية حسابها.
الاحتواء ومسؤول القرار
إذا ظهرت نتيجة عالية الحساسية قد يُوصى بتعليق أداة كتابة أو تضييق نطاقها مؤقتاً إلى حين الإصلاح، لكن لا يملك فريق الاختبار صلاحية إيقاف إنتاج المؤسسة خارج قواعد العمل. تتطلب التوصية اسم مالك التشغيل وأثر البديل والشروط اللازمة لرفع الاحتواء، وما إذا كان هناك ضابط مستقل يحمي الفعل. وقد لا يحتاج ضعف جودة نصية منخفض الأثر إلى تعليق الأداة، لكنه يحتاج تحسيناً وفق سياسة المنتج. يمنع التفريق بين الاحتواء والسبب الجذري إغلاق الحالة بمجرد تعطيل السطح، إذ قد تعود المشكلة عند تفعيله مجدداً إذا لم يصلح الضابط الأساسي.
سجل المعالجة والمالك
يحدد الإجراء المطلوب، مثل تصحيح فلاتر الاسترجاع أو تطبيق تفويض API أو منع حفظ نص غير موثوق في ذاكرة مشتركة، مع مالك تغييره ورقم إصدار وتاريخ هدف. ينبغي أن يربط التصحيح بنوع الضابط الذي فشل، لا بمكان ظهور النص فقط. وإذا كانت المشكلة مرتبطة بمورد خارجي يحدد مسار التبليغ وأي ضابط تعويضي تملكه المؤسسة والمهل التعاقدية، دون أن يمنح ذلك حق اختبار البنية الخارجية. لا يغني اسم معيار معروف عن دليل أن الضابط يعمل بالفعل، ولا يعني تحديث تذكرة إلى «مغلقة» نجاح إعادة الاختبار إن لم يتوفر دليل لاحق.
إعادة اختبار مستقلة
يُستخدم معرف الحالة الأصلية لإنشاء خطة تحقق بعد الإصلاح تشمل الشروط الأساسية نفسها قدر الإمكان، مع معرف إصلاح ونسخة منشورة جديدة. في مشكلة العزل يجب أن يتوقف رجوع مستند محظور وأن تظل الوثائق المسموحة قابلة للوصول. وفي مشكلة الأداة يجب أن يمنع النظام الخلفي التعديل خارج الدور ويتيح الوظيفة المشروعة لصاحب الصلاحية. لا يكفي أن يتغير رد النموذج أو تقل مرات حدوث ظاهرة لغوية إن ظل سبب الخلل في التفويض أو الفهرس. ويذكر التقرير ما إذا أمكن مقارنة النسختين، وأي تغير في المورد أو البيانات يؤثر على الاستنتاج.
سجل مراجعة الجودة
يراجع شخص مستقل أن النص يفرق بين الملاحظة والتحليل، وأن نوع الدليل مناسب للادعاء، وأن أصل الخطر وحساب الاختبار والإصدار معروفان، وأن حالة الحكم لا تخفي نقص معلومات. يمكن أن يختلف الباحث وفريق الهندسة حول السبب الجذري؛ ينبغي أن يسجل الخلاف دون محو السلوك المؤكد إذا كان مدعوماً بدليل. ويجب ألا تُنشر التفاصيل الحساسة أو مسارات تنفيذ غير معالجة في قناة عامة. تتطلب الجودة أيضاً بيان ما لم يُختبر ومدى قدرة القارئ على إعادة فهم النتيجة، وليس فقط وجود عناوين كثيرة أو أرقام نجاح مرتفعة.
مثال حالة معبأة: مستند
FINDING-01: المكوّن خدمة RAG؛ الأصل مستند سياسة تجريبي؛ الدور مستخدم قراءة في قسم أول؛ الهدف منع ظهور وثيقة قسم ثان. أظهر سجل الاسترجاع في بيئة الاختبار إعادة مرجع وثيقة خارج الدور وفق علامة اصطناعية، بينما لم تعرض واجهة المحادثة النص النهائي. النتيجة إخفاق مؤكد في حد الاسترجاع عند المصدر، وليس إثباتاً أن جميع بيانات المؤسسة كُشفت أو أن النموذج نفذ أداة. يتولى مالك خدمة البحث مراجعة مرشح الصلاحيات وربط المستخدم بالفهرس والنسخ المؤقتة، ثم يعاد اختبار الحسابين وفق نسخ معروفة. يُحفظ الدليل الأصلي في نطاق مراجعة مناسب.
مثال حالة معبأة: أداة
FINDING-02: المكوّن وكيل مسودات متصل بنظام أعمال؛ الحساب يملك القراءة وإنشاء مسودة ولا يملك الاعتماد؛ لوحظ اقتراح استخدام أداة اعتماد من طبقة النموذج، ثم رفض API الطلب بسبب سياسة الدور وبقي السجل التجريبي ثابتاً. تكون نتيجة التفويض الخلفي PASS في ذلك السيناريو، مع ملاحظة منفصلة لتحسين حدود سياق الوكيل وكشف محاولات الأدوات غير المناسبة. لا يُكتب أن الأموال خرجت أو المعاملة اكتملت، لأن الأدلة لا تدعم ذلك. إذا غاب سجل التنبيه تُضاف مهمة كشف مختلفة عن معالجة التفويض، ولا يُخلط بين فشل المراقبة ووقوع الفعل.
حقوق المصدر
المصدر المنهجي OWASP GenAI Red Teaming Manual v1.0، أكتوبر 2026، خاصة Phase 6 Post-Exploitation وPhase 7 Evaluation & Reporting وPhase 8 Remediation. الحقول والأمثلة والشرح صياغة عملية من سيادة AI ولا تمثل نموذج OWASP الرسمي ولا إثبات حوادث فعلية في مؤسسة محددة. يجب الالتزام بتفويض الاختبار وحماية الأدلة والبيانات، واحترام CC BY-SA 4.0 عند استخدام مواد مرخصة من الوثيقة الأصلية. يمكن الرجوع للصفحة الرسمية https://genai.owasp.org/resource/genai-red-teaming-manual-version-1-0/.