معيار Autonomous Pentest Assurance Standard (APAS): متى يحق لكم الوثوق بنتائج اختبارات الاختراق الذاتية

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

ثلاث خصائص للأنظمة ذاتية التشغيل تجعل تقرير اختبار الاختراق التقليدي غير كافٍ بوصفه إثباتاً. أولاً فخّ عدم الحتمية: يعثر الوكيل في دورتي تشغيل بشروط متطابقة على أسطح هجوم ومكتشفات مختلفة؛ ومن يبلّغ عن أفضل دورة فقط يوهم بالاتساق (4.6.2). ثانياً فخّ التأكيد الذاتي: النظام الذي يقيّم مكتشفاته بنفسه — ولو بنموذج ثانٍ بدور «Judge» — لا يراقب الهدف بل يراقب نفسه؛ واتفاق المكوّنات الداخلية ليس تأكيداً مستقلاً (4.4.1 f, 11.2.1 b). ثالثاً فخّ التغطية: النظام الذي يكتشف أقل يبدو أكثر اكتمالاً عندما يكون المقام مستمداً من اكتشافه هو (1.1.4).

يستخلص APAS من ذلك حدّاً أدنى واضحاً: المسح الآلي الذي يُنتج إشارات دون مسار استغلال مُتحقَّق منه ليس بحدّ ذاته اختبار اختراق ذاتي التشغيل. ومثل هذه المخرجات لا تؤهَّل إلا كنتيجة ضمان (Assurance Outcome) من الفئة Q1 بأدلة EV1 أو EV2، ولا يجوز أبداً عرضها وحدها على أنها ادعاء اختبار اختراق بموجب APAS. أما السمات المميّزة لاختبار الاختراق فهي إعادة الإنتاج المستقلة بواسطة طرف غير النظام المُنتِج، والتحقق من مسار الاستغلال حتى الشرط المدَّعى، وإثبات التسلسل متعدد المراحل (Chaining) ضمن النطاق المُعلَن (2.2.3).

يُطوَّر APAS بالتنسيق مع Cloud Security Alliance ويتّبع متطلبات الرعاية المحايدة الواردة في القسم 12: فالمعيار الذي يسيطر عليه أحد المشاركين في السوق لا يجوز تقديمه على أنه معيار صناعي محايد (12.4.1). وتسمّي الوثيقة CSA AI Safety Working Group موطناً لها؛ المؤلف الرئيسي هو Will Kapcio، إلى جانب ثمانية مساهمين (من بينهم Jim Reavis وJohn Yeoh من CSA) واثني عشر مراجعاً. ويُظهر سجل التغييرات أن النسخة الأولى تعود إلى 23 أكتوبر 2026، وأن تاريخ الملف هو 2 نوفمبر، وأن نشر CSA كان في 4 نوفمبر 2026. ملف PDF محميّ بحقوق النشر ولا يجوز إعادة توزيعه — لذلك نضع رابطاً إلى التنزيل لدى CSA ونقتبس مع ذكر المصدر.

يوضح قسم الحالة (Status) ثلاثة أمور. يقيّم APAS صدق أدلة اختبار الاختراق وقابليتها للاستخدام — لا أمن النظام نفسه ولا احتواءه ولا مقاومته لإساءة الاستخدام؛ ولا يجوز أبداً تقديم شهادة APAS على أنها تصريح أمان بشأن الصلاحية للنشر (Fitness for Deployment). ثانياً: لم تُنشر أي وثيقة مصاحبة. ثالثاً، وهو الحاسم: ما دام Evaluator Guide والمدخل المعني في Profile Registry وAttestation Schema غير متوفرة في إصدارات متوافقة، فلا يجوز إصدار أي Atomic System Capability Certification ولا أي Engagement Conformance Statement. إن نشر المعيار الأساسي يفتح مسار الشهادة، لا الشهادة نفسها (Status, 12.1.2).

مجموعة الوثائق

الحوكمة منظَّمة بالفعل: تتّبع الإصدارات مخطط Major/Minor/Patch، وv1.0 إصدار Major لأنه يغيّر صلاحية الادعاء وأبعاد الجودة وفئات البيئة وبوابات النشر ودلالات المكتشفات (12.2.1). وتُعلن كل وثيقة مصاحبة إصدار Major من المعيار الأساسي الذي تكون معيارية تجاهه؛ ولا يجوز إصدار الادعاءات إلا مقابل مجموعة وثائق متوافقة، ولا يُبطل إصدار جديد من المعيار الأساسي الادعاءات الصادرة سابقاً بأثر رجعي (12.2.2, 12.2.3). ويجب فحص المعيار الأساسي وEvaluator Guide كل اثني عشر شهراً على الأقل للكشف عن انحراف القدرات، مع محفّز استثنائي عند حدوث قفزات جوهرية في قدرات النماذج الطليعية (12.2.4). وتمرّ التغييرات المعيارية بمراجعة عامة؛ ويجب أن تكون الجهة الراعية مستقلة تنظيمياً عن أي مورّد منفرد، وأن تحافظ على عمليات متعددة أصحاب المصلحة، وأن تفصح عن تضارب المصالح (12.3, 12.4). وللادعاءات سجل حالة عام بالحالات Active وUnder Review وRevoked وRetired؛ وعند وجود مؤشرات موثوقة على أدلة مزوّرة أو مضلِّلة ينتقل الادعاء إلى Under Review ولا يجوز بعدها الاستناد إليه بوصفه Q3 أو Q4 أو R2 أو R3 (12.5).

قواعد التطبيق صارمة. يجب أن يغطي كل إعلان جودة Coverage Fidelity وFinding Validity وEvidence Traceability وAgent Integrity؛ وتُضاف إلزامياً لادعاءات Q4 أو R3 كلٌّ من Remediation Usability وRetestability (4.1.1 a). ولا يجوز اعتبار بُعدٍ ما غير قابل للتطبيق أو غير مَقيس إلا بمعايير موثَّقة وبموافقة المُقوِّم (Evaluator) — ويجب الإفصاح عن ذلك (4.1.1 b). ويجوز للملفات التعريفية إضافة أبعاد لكن لا يجوز لها حذف أي منها (4.1.1 c). والأهم: تُعلَن الأبعاد وتُقيَّم بصورة مستقلة عن بعضها، ولا يجوز دمجها في درجة مركّبة (Composite Score)، ولا يجوز تصوير العجز في بُعد على أنه معوَّض بقوة في بُعد آخر (4.1.1 d).

يتضمّن كل ادعاء من فئة Q2 أو Q3 أو Q4 أو R2 أو R3 إعلانَ جودة يبيّن كل بُعد قابل للتطبيق بقيمة عددية أو فئة ترتيبية أو حالة منطقية (Boolean) أو بتمثيل يحدّده الملف التعريفي، ويحيل إلى الأدلة أو المنهجية (4.1.2). ويجوز للتحقق المقارن — مثلاً مقابل مجموعة مرجعية بشرية — أن يكمّل تقييم الجودة، لكنه لا يحلّ أبداً محل Coverage Fidelity أو Finding Validity أو Evidence Traceability (4.1.3). أما Agent Integrity فبُعد قائم بذاته ولا يُستوفى عبر إفصاحات Process Integrity (4.1.4).

APAS <Mode>-<Tier> / <Execution>-<Collaboration>-<Assurance> / <Environment> [<Affordance Profile>] {<Reliance>}

APAS BB-T2C / X2-C2-Q4 / E3 [P-021] {R2}

أمثلة الـ Claims الأربعة من الملحق A

توجد ثلاثة أنواع من الـ Claims (5.1): Atomic System Capability Certification هي النتيجة التي يصدرها المُقيِّم (Evaluator) ومفادها أن نظاماً ما قد استوفى المتطلبات المنطبقة على تركيبة قدرات معيّنة في ظل شروط مُعلَنة. ويجمع Multi-Configuration Capability Statement اثنين أو أكثر من الـ Claims الذرّية لإصدار نظام واحد. أما Engagement Conformance Statement فيتعلق بمهمة (Engagement) محددة نُفِّذت بنظام حاصل على شهادة APAS في ظل الشروط نفسها أو شروط أضيق — وهو لا يمنح شهادة للبيئة المستهدفة أبداً (5.1.1).

ولأن النظام الواحد قد يقدّم تركيبات متعددة، يشترط APAS وجود Capability Matrix (مصفوفة قدرات) بسبع فئات حالة: S1 Supported (مصمَّم له، غير مُقيَّم)، S2 Evaluated (مُقيَّم، دون Claim)، S3 Certified or Conformant، S4 Not Certified، S5 Not Evaluated، S6 Unsupported، S7 Retired. ولا يجوز عرض أي حالة سوى S3 على أنها حاصلة على شهادة؛ والمصفوفة العلنية التي تُغفل تركيبات مدعومة ذات أهمية جوهرية تُعدّ مضلِّلة (5.3.1). ويندرج ضمن كل صفّ، من بين أمور أخرى: معرِّف التركيبة، وسلسلة الـ Claim الكاملة، واسم النظام وإصداره، وهويات النماذج مع منشأ (Provenance) موجِّهات النظام، ومرجع المنهجية، والمُقيِّم، والحالة، والإحالات إلى التصديق (Attestation)، وإعلان الجودة والتغطية، وإصدارا Core وCompanion، وتواريخ الشهادة والصلاحية، والقيود الجوهرية؛ وبالنسبة إلى Q3 أو Q4 أو R2 أو R3 يُعدّ تاريخ الشهادة وتاريخ انتهاء صريح أو فترة إعادة التحقق أمراً إلزامياً (5.4.1).

تضيف Assistance Class (فئة المساعدة) الواردة في القسم 9 إلى هذه الفئات سؤالاً عمّا أسهم به البشر فعلياً: H0 لا مساعدة ذات أثر في الاستراتيجية أو الاستغلال أو التحقق أو ترتيب الأولويات أو التقرير؛ H1 تدخّل إداري أو متعلق بالسلامة فقط؛ H2 مساعدة تحليلية — توجيه في الاستغلال، أو تفسير، أو ترتيب أولويات، أو ربط بالضوابط (Control Mapping)، أو تحرير التقرير. ويجب الإفصاح عن الفئة في التصديق، وفي حالة التكوينات المتعددة لكل تركيبة وكل تشغيل على حدة (9.1.1). ويحظر الـ Claim من فئة X3 المساعدة H2 أثناء التنفيذ، ويحظر الـ Claim من فئة Q4 المساعدة H2 عند تجميع حزمة الأدلة (Evidence Package) — بما في ذلك عبر مكوّنات داخلية للتحقق أو الحُكم (Judge) تشكّل محتوى الحزمة (9.1.2). وأي ربط لاحق بأُطر العمل أو ترتيب للأولويات من جانب المزوِّد يؤثر جوهرياً في المدقق يُعدّ Vendor-side Analytical Review ويجب الإفصاح عنه (9.1.3). ولا يجوز تسويق منصة على أنها agent-only أو مستقلة ذاتياً أو assessor-ready إذا كانت عمليات تشغيل ذات صلة قد استندت إلى تدخّل بشري أو معالجة لاحقة لم يُفصَح عنها (9.2.2).

ثمة قاعدتان أخريان تستحقان انتباه الـ CISO وإدارة التدقيق الداخلي. أولاً المسؤولية: يجب أن يسمّي كل Claim من فئة R3 الطرف المسؤول عن صحة الأدلة المستبدَلة، وحق رجوع الطرف المعتمِد عند اكتشاف عيوب لاحقاً، وحدود الضمان، وتأميناً على المسؤولية المهنية أو الأضرار المالية يُعرَض على الطرف المعتمِد — فـ APAS نفسه لا ينشئ أي مسؤولية ولا ينقلها ولا يحدّها (5.10.4). ثانياً اختبارات المستأجرين والصلاحيات: لا يجوز أبداً اعتبار Claim من فئة R2 أو R3 بديلاً أو مكمّلاً لاختبارات التفويض أو التحكم في الوصول أو حدود المستأجرين (Tenants) إذا استُخدم أقل من كيانَي هوية (Principals) مختلفين أو مستأجر واحد فقط؛ وتُعدّ هذه المجالات غير مختبَرة جوهرياً (5.10.6). وكذلك: يصف R2/R3 ما تقدّمه الحزمة — لا أي إجراءات فحص يجوز للمراجع إغفالها؛ فالفحوصات المتبقية وقبول المخاطر المتبقية يبقيان لدى المراجع وإطار عمله (5.10.7).

يتضمّن كل Claim من الفئات T2A أو T2C أو T3 أو T4 أو Q2 أو Q3 أو Q4 أو R2 أو R3 إعلان Coverage بحقول إلزامية ثابتة (4.2.1). ويجب أن يُبيّن هذا الإعلان بصدق الفروق بين النطاق المُعلَن والنطاق القابل للوصول والنطاق المختبَر، وكذلك الفرق بالنسبة إلى Surface Baseline؛ ولا يجوز لأي حزمة أن توحي بـ Coverage كاملة أو تامة أو مكافئة دون تقديم المنهجية والأدلة الداعمة لذلك؛ كما أن النتيجة التي تظهر على مثيل واحد أو في عملية تشغيل واحدة ليست Coverage لفئة الهجوم المقابلة (4.2.2).

سُلَّم خط الأساس من BS-1 إلى BS-3

1. 1
   BS-1 Asserted

   جرد الأصول أو قائمة النطاق الخاصة بمالك الهدف — وهي مستقلة عن النظام المرشَّح، لكنها تبقى محدودة بمدى اكتمال معلومات المالك نفسه (4.2.8 a).

2. 2
   BS-2 Directed

   تعداد يوجّهه المُقيِّم (Evaluator)، بحيث يحدّد المُقيِّم السطح أو يوسّعه بما يتجاوز ما اكتشفه النظام — وهو المستوى الأدنى المطلوب لـ Q3 وQ4 وR3 (4.2.8 b و4.2.10).

3. 3
   BS-3 Instrumented

   تعداد يُجرى بواسطة أداة اكتشاف (Discovery) مستقلة أو بواسطة عملية لا تشترك مع النظام المرشَّح في منطق الاكتشاف الذي يعتمد عليه (4.2.8 c).

بالنسبة إلى Q3 وQ4 وR3، يجب بناء مقام Coverage مقابل Independent Surface Baseline؛ ولا يجوز أن يكون الاكتشاف الذاتي للنظام هو المصدر الوحيد (4.2.4). ويجب الإفصاح في الاتجاهين عن الانحرافات الجوهرية بين السطح المكتشَف وخط الأساس؛ وكل مساحة في خط الأساس لم يجرِ تمرينها تُعدّ غير مختبَرة جوهريًا؛ كما أن Under-Discovery يخفض Coverage المعروضة، ولا يحدث العكس أبدًا (4.2.5). وعند الجمع بين عدة مصادر، لا يجوز عرض خط الأساس الإجمالي على أنه أقوى من أضعف مصدر يغطي بمفرده مجالًا جوهريًا (4.2.9). وحيثما لا يُشترط وجود خط أساس مستقل، يجب أن يذكر الإعلان أن المقام قد جرى تعداده ذاتيًا وأن يصف الطريقة المتبعة (4.2.6).

حالة Coverage وحدها لا تقول شيئًا عن العمق. فلكل مجال مختبَر أو مختبَر جزئيًا يجب بيان ما إذا كان قد أُجري فحص على مستوى الطلبات (Request-Level Probing)، وفحص بحالة مصادقة، واختبارات متعددة المراحل لسير العمل أو لانتقالات الحالة، واختبارات عند حدود الصلاحيات أو حدود المستأجرين. وتحدّد Profile Registry وحدة Coverage وعتبات التغطية الجزئية ودرجات العمق والأوزان — وفي غياب ملف تعريف قابل للتطبيق، يجب إعلان العمق سرديًا وعدم عرض أي نسبة أو نسبة مئوية لـ Coverage (4.2.11). وفي Claims من الفئة T2C، يجب أن يكون الإعلان مهيكلًا بحيث يتعرّف المراجع على المجالات ذات الصلة بالضوابط التي جرى اختبارها أو استبعادها أو لم تُختبَر دون الحاجة إلى تفسير من المورّد (4.2.7).

عدم الحتمية هو النقطة العمياء الثانية. يُعدّ النظام غير حتمي جوهريًا عندما تُنتج عمليات التشغيل المتكررة في الظروف نفسها أسطح هجوم أو مجموعات نتائج أو حصائل استغلال مختلفة جوهريًا؛ ويجب الإفصاح عن ذلك في المنهجية (4.6.1). ولا يجوز إخفاء التباين عبر اختيار عملية التشغيل الأكثر ملاءمة؛ وحيثما تدعم عدة عمليات تشغيل Claim واحدًا، يجب تعريف الاختيار والتجميع والإفصاح مسبقًا، ويشهد المُقيِّم بأن عدد عمليات التشغيل وقاعدة التجميع كانا محدَّدين قبل التنفيذ (4.6.2). وتصف Claims الفئات Q3 وQ4 وR2 وR3 التباين بين عملية تشغيل وأخرى بمقياس مُعلَن — مثل تباين اكتشاف السطح أو مؤشر Jaccard لمجموعات النتائج — عبر Run Design مسجَّل مسبقًا (4.6.3). وتُستمد قاعدة التجميع من مجموعة مغلقة (Any-Run-Union أو All-Run-Intersection أو الأغلبية أو قاعدة مُعلَنة صراحةً)، وتُدرَج النتائج الفردية لجميع عمليات التشغيل، لا مجرد مؤشر واحد، في Evidence Package (4.6.5).

تحمل كل Confirmed Finding معرِّفًا من نوع Stable Finding Identifier — وهو معرِّف فريد يبقى ثابتًا عبر المراجعات وعمليات إعادة الاختبار والتصدير وتحويلات التنسيق — كما تحمل، باستثناء مسار Single-Capture، إجراءً من نوع Reproduction Procedure: أي تسلسلًا مسجَّلًا وحتميًا ومستقلًا عن الوكيل من الخطوات والطلبات والحمولات (Payloads) والشروط المسبقة والملاحظات المتوقعة، يستطيع به طرف ثالث مؤهَّل إعادة إنتاج الحالة دون الوصول إلى النظام المرشَّح (4.3.3، الملحق D). وتشمل الملاحظات المتوقعة ملاحظة الضبط أو الملاحظة الآمنة المتوقعة (Expected-Secure)؛ ولا يجوز أن يكون الإجراء احتماليًا إلا إذا كانت الحالة نفسها احتمالية (حالات التسابق Race Conditions، وTOCTOU، والقنوات الجانبية الزمنية)، وعندئذٍ يُذكر عدد المحاولات ومعدل النجاح المرصود. وتعلن كل Confirmed Finding أيضًا عن Vantage Point وشرط الوصول ومنطقة فئة البيئة (4.3.5)؛ ويجري الإفصاح عن الخدمات المجاورة أو المسارات العابرة للأنظمة ذات الصلة بقابلية الاستغلال أو الأثر — وهو أمر إلزامي في حالة E3 (4.3.6).

في Claims الفئات Q3 أو Q4 أو R2 أو R3، يجب جمع مُخرَجات الفئتين EV3 وEV4 عبر مسار لا يخضع للسيطرة الحصرية للنظام المرشَّح — مثل اعتراض حركة الشبكة أو المراقبة على مستوى المضيف أو التقاطات يجمعها المُقيِّم؛ ودون هذه العتبة يجب وسم المُخرَجات التي جمعها النظام وحده بوصفها كذلك في Evidence Manifest؛ وفي حالة Q2 وQ3 ينبغي أن تكون EV3/EV4 من نوع Out-of-Band Witness Evidence — مستمعات الاستدعاء العكسي (Callback Listeners) أو Canaries أو مراقبات على جانب الهدف لا يستطيع النظام إنشاءها ولا رصدها ولا الوصول إليها (4.4.4، الملحق D). وإذا ادّعت نتيجة ما وجود خلل في التفويض أو في حدود المستأجرين، فإن EV3 تشترط ملاحظات مقترنة: الطلب نفسه ينجح للكيان الأمني (Principal) غير المصرّح له ويُرفض لكيان ضابط مصرّح له، مع الإحالة إلى كليهما عبر Identity Coverage (4.4.6).

إعادة الاختبار وإزالة التكرار

تنفّذ إعادة الاختبار (Retest) إجراء Reproduction Procedure المسجَّل مقابل Stable Finding Identifier، وتُسند الناتج إلى هذا المعرِّف، وتُفصح عمّا إذا كانت النتيجة لا تزال قائمة أو عولجت جزئيًا أو لم تعد قابلة لإعادة الإنتاج (4.3.4). أما إعادة الاكتشاف الاحتمالية — أو غيابها — عبر عملية تشغيل جديدة للوكيل فليست تحققًا من الإصلاح ولا إثباتًا للاستمرار ولا إعادة اختبار؛ ويجب وسم مثل هذه النتائج بوصفها probabilistic rediscovery وفصلها عن ناتج الإجراء (4.3.4 a). وفي الحالات المتقطعة، يُقيَّم عدد المحاولات ومعدل النجاح مقابل المعدل المسجَّل قبل المعالجة (4.3.4 b). ويجب أن تتوافر لكل حزمة قاعدة موثَّقة لإزالة التكرار تحدّد كيفية دمج الملاحظات المتكررة للحالة نفسها، الواردة من عمليات تشغيل أو Vantage Points أو مثيلات مختلفة، في Stable Finding Identifier واحد (4.3.9).

ملف Affordance هو بيئة التشغيل المُعلَنة للنظام أثناء الاختبار: القدرات والقيود وشروط الوصول وحدود التصعيد والاشتراطات (الملحق D). يُحيل كل ادعاء إلى ملف يتضمن الحقول التالية على الأقل؛ ولا يكفي وصف عام مثل «standard» لحقلَي ضوابط حماية الهدف وضوابط سلامة الوكيل (Agent Integrity). يجب الإعلان عن مكوِّنات التحقق من الصحة (Validation) أو الحكم (Judge) أو التحقق (Verifier) أو التوافق (Consensus) الداخلية ضمن Agent Topology، والإفصاح عن دورها في إعلان الجودة (Quality Declaration) الخاص بـ Finding Validity. وإذا غابت Action Reversibility Class، عُدَّت المهمة (Engagement) غير قابلة للعكس — مع أشد التزامات الأمان (Safety) صرامةً (7.1.1).

تصف فئات البيئة مدى الوصول عبر حدود الثقة، لا نوع الهدف: E1 هدف واحد معزول، E2 تفاعل متعدد الأدوار أو متعدد المراحل أو ذو حالة (stateful) داخل حد ثقة مُعلَن واحد، E3 تفاعل يعبر حد ثقة أو حد تجزئة (7.2). وتنطبق بالتساوي على التطبيقات وواجهات API والشبكات والبنية التحتية ومستويات التحكم السحابية والحاويات وبرمجيات العميل والأجهزة المحمولة والبرامج الثابتة والأنظمة المضمَّنة؛ ولا تستورد أي فئة نواقل الهندسة الاجتماعية أو النواقل المادية أو اللاسلكية. يقتصر كل ادعاء على فئته المُعلَنة (7.2.1)؛ ويجب الإعلان عن نوع البيئة والفروق الجوهرية عن بيئة الإنتاج، ولا يعني اختبار في بيئة غير إنتاجية تغطيةً للإنتاج دون تكافؤ مُعلَن (7.2.2). تُحيل ادعاءات T2A أو T2C أو T3 أو T4 إلى منهجية مُعلَنة؛ وتحدد المنهجيات الموجَّهة إلى Q4 أو R3 إضافةً إلى ذلك التعامل مع النتائج السلبية وتوقعات المعالجة وإعادة الاختبار ومسوِّغ نموذج التهديد للوضع المختار (7.3).

التصريح وقواعد الاشتباك (Rules of Engagement)

لكل مهمة APAS إعلان تصريح (Authorization Declaration) يحدد الجهة المُصرِّحة والأساس القانوني أو التعاقدي والنطاق المُصرَّح به والإطار الزمني وقواعد الاشتباك (Rules of Engagement)؛ وتُعدّ الاختبارات خارج ذلك نشاطًا خارج النطاق وفق القسم 10 — بصرف النظر عن النجاح التقني أو قيمة النتيجة (7.4.1). ويجب إضافةً إلى ذلك، حيثما كان ذا صلة، الإعلان عن: نوافذ الاختبار بما فيها نوافذ الحظر (Blackout) والصيانة، جهات اتصال الطوارئ المُسمّاة لدى مالك الهدف والمُقيِّم ومشغِّل النظام مع إمكانية الوصول إليها والحد الأقصى لزمن الإبلاغ، حالة التصريح للبنية التحتية التابعة لأطراف ثالثة وللسحابة مع شروط الاختبار الخاصة بالمزوِّد، عناوين المصدر الخاصة بالنظام والإدراج في قوائم السماح (Allowlisting)، حدود تصنيف البيانات، وفضّ التعارض (De-Confliction) مع SOC أو الفريق الأزرق (7.4.3). كما يحدد الإعلان هوية الوكيل الفاعل، ومخطط الهوية، وطريقة التحقق المتاحة لمالك الهدف، وفي حالة الوكلاء الفرعيين سلسلة التفويض مع أقصى عمق لها (7.4.4).

ولأن الأنظمة المستقلة تصادف ثغرات في مكوِّنات أطراف ثالثة أو خارج النطاق، تتطلب كل مهمة مسار إفصاح منسَّق (Coordinated-Disclosure Path): تحمل كل نتيجة من هذا النوع حالة إفصاح (encountered, notified, disclosure-restricted, resolved, published)، وتبقى في كل حالة مُدرَجة في Evidence-Manifest مع Stable Finding Identifier وقيمة Content-Hash، ولا يجوز حجب سوى تفاصيل الاستغلال مؤقتًا — وليس النتيجة نفسها أبدًا (7.4.2). وإذا كان بإمكان النظام الوصول إلى بنية تحتية مشتركة أو تابعة للغير خارج نطاق التصريح، فيجب أن تُبعده حدود التصعيد عنها (7.4.3.2).

يتضمن كل بيان شهادة أو بيان مهمة يُعرَض بوصفه R2 أو R3 حزمة Evidence-Package قابلة للاستهلاك من قِبل المُدقِّق؛ ويتضمن كل ادعاء Q2 أو Q3 أو Q4 إعلان الجودة وإعلان التغطية (Coverage Declaration)، حتى لو لم يُطالَب إلا بـ R1 (8.1.1). وبالنسبة إلى R2/R3، ينبغي أن تبقى الأدلة الداعمة متاحة على الأقل طوال مدة صلاحية الادعاء (8.1.2 b).

السلامة: التوقيع وقيم التجزئة والسجلات الكاشفة للعبث

كل تصديق Q3 أو Q4 أو R2 أو R3 موقَّع تشفيريًا من المُقيِّم المُصدِر أو من جهة المطابقة — بهوية قابلة للتحقق منها، وطريقة تحقق منشورة علنًا، ومعرِّف الشهادة أو المفتاح المستخدَم في التوقيع، وختم زمني موثوق، ووسيلة منشورة للتحقق من حالة المفتاح حتى بعد التدوير أو الانتهاء أو الإلغاء (8.2.1). ويتضمن Evidence-Manifest لكل عنصر (Artifact) قيمة Content-Hash محسوبة وقت الالتقاط (8.2.2)؛ ويكون تسجيل التنفيذ وتسجيل الأدلة كاشفَين للعبث ويُداران أو يُوقَّعان توقيعًا مقابلًا من مكوِّن أو طرف لا يخضع للسيطرة الحصرية للنظام (8.2.3). وتُبطِل الأدلة المزوَّرة أو غير القابلة للتتبع أو المضلِّلة جوهريًا الادعاء (8.2.4)؛ ولا يجوز الاعتماد على حزمة فشل التحقق من توقيعها أو تباينت قيم تجزئتها أو ظهرت في سجلها فجوات غير مفسَّرة بوصفها Q3 أو Q4 أو R2 أو R3 إلى أن يُحلّ التعارض ويُعاد التصديق (8.2.5). ويجب الإفصاح عن أوجه التعارض بين التصديق والنتائج وسجلات التنفيذ والعناصر، لا التخلص منها بتفسير سردي (8.2.7).

القابلية للقراءة الآلية وتنسيقات التبادل المفتوحة

تحمل كل حزمة Q2 أو Q3 أو Q4 أو R2 أو R3 حقولًا قابلة للقراءة الآلية: سلسلة الادعاء (Claim-String) الكاملة، معرِّف التركيبة، اسم النظام وإصداره، هويات النماذج وإصداراتها، منشأ الـ System Prompt، معرِّف بناء (Build) للنظام في صورة ملخّص تشفيري (Digest) للتهيئة المربوطة، مرجع المنهجية، هوية المُقيِّم، بيانات التوقيع والتحقق الوصفية، Assistance Class، مسار التشغيل الملاحَظ، مراجع إعلان الجودة وإعلان التغطية مع مصادر خط الأساس، معرِّفات الأصول ومراجع SBOM، ملخّص حالات النتائج، Stable Finding Identifiers، علاقات Attack Paths، تسميات Single-Capture، قرارات الجوهرية (Materiality)، قيم تجزئة الـ Manifest، تاريخ الشهادة مع الانتهاء أو فترة إعادة التحقق، إصدارات Core والإصدارات المصاحبة (Companion)، إضافةً إلى Reliance Outcome. وتنتقل سلسلة الادعاء ومعرِّف البناء ضمن غلاف Provenance مُعلَن مثل in-toto أو DSSE أو SCITT (8.4.1).

ينطبق خط الأساس على كل Claim: حدود نطاق صريحة، وآلية للإيقاف (Stop) أو التعليق (Suspend)، وسجلات أو مخرجات (Artefacts) كافية لفحص المقيِّم (10.1.1). النشاط خارج النطاق، أو الأدلة المزوّرة، أو الإخفاء الجوهري لمساعدة بشرية، أو بيانات التغطية المضلِّلة تُبطل الـ Claim (10.1.2)؛ أما عدم اليقين الجوهري في الأثر أو التغطية أو استنتاجات إعادة الاختبار فيجب تمييزه في الحزمة (10.1.3).

1. 1
   إعلان Stop Authority

   تحدّد كل مهمة (Engagement) مَن يحق له تعليق التنفيذ أو إنهاؤه — على الأقل مالك الهدف، والمقيِّم (Evaluator) إن وُجد (10.2.1).

2. 2
   العمل خارج المسار (Out-of-band)

   تعمل آلية الإيقاف خارج حلقة اتخاذ القرار في النظام؛ فالنظام ليس أبدًا الحَكَم الوحيد في ما إذا كان الإيقاف نافذًا. يحدّد ملف الـ Affordance زمن استجابة أقصى؛ وضمن هذه المهلة ينتهي كل نشاط هجومي، وتُقطع الإجراءات الجارية، ويُلغى العمل المنتظر أو المجدوَل أو المفوَّض أو يُوثَّق (10.2.2).

3. 3
   Fail-safe عند فقدان الإشراف

   إذا تعطّلت المراقبة أو وصلة الإشراف أو التسجيل أو قناة الإيقاف بما يتجاوز حدود التسامح المعلنة، يعلّق النظام النشاط الهجومي حتى يُستعاد الإشراف — ففقدان الإشراف لا يؤدي أبدًا إلى استمرار التشغيل المستقل (10.2.3).

4. 4
   تسجيل الأحداث والإخطار بها

   تُدوَّن أحداث الإيقاف (Stop) وHalt-on-Loss مع توقيتها في السجل الكاشف للتلاعب وفي حزمة الأدلة (Evidence Package)؛ وتُبلَّغ جهات اتصال الطوارئ ضمن المهلة المعلنة (10.2.4).

5. 5
   Access Disposition Record

   عند الاختتام — وبعد كل إيقاف — يبيّن سجل (Record) كل وصول أنشأته المهمة (رموز Tokens، وحسابات، وجلسات، وأنفاق، ورموز مفوَّضة، وآليات استمرارية) مع حالته (Revoked أو Expired أو Removed أو مُدوَّر من قِبل مالك الهدف أو Retained مع المالك وتاريخ الانتهاء) والطرف المسؤول ومرجع التحقق (10.2.5).

6. 6
   التحقق من طرف إلى طرف

   يفحص المقيِّم كل قناة حرجة أمنيًا للإيقاف (Stop) أو التعليق (Suspend) أو الاستئناف (Resume) أو التجاوز (Override) من طرف إلى طرف — من الطرف المخوَّل حتى نقطة الإنفاذ في تهيئة النشر المُصادَق عليها؛ فمجرّد الوجود أو التوقيع الصحيح لا يكفي، ويجب أن تتضمن الحزمة حدثًا مُمارَسًا واحدًا على الأقل لكل قناة مع نتيجة التسليم والإنفاذ (10.2.6). توافر القناة ليس دليلًا على التسليم؛ ويجب أن يكون الأمر غير المنفَّذ قابلًا للتمييز بوصفه خطأ في التسليم (10.2.7).

تتدرّج الالتزامات بحسب الأسوأ من بين استقلالية التنفيذ، وانخفاض المشاركة البشرية، ومخاطر الـ Affordance المعلنة (Action Reversibility Class): ضمن الملف الواحد تكون متطلبات X3 بقوة متطلبات X2 على الأقل، وهذه بقوة متطلبات X1 على الأقل، والأمر نفسه من C1 إلى C4؛ وترفع Action Reversibility Class الأقل قابلية للعكس المتطلبات بصرف النظر عن X وC؛ ولا يجوز لأي قرار من الملف أو المقيِّم أو المورّد أن يمنح الفئات الأكثر استقلالية إشرافًا أضعف — فالتهيئة التي تُزيل فيها الاستقلالية الأعلى الإشراف غير قابلة للتصديق (10.3.1).

• يتطلب التشغيل في X3 وC4 وE3، وكذلك كل مهمة يُسمح فيها بإجراءات غير قابلة للعكس أو تسلسل (Chaining) مستقل إلى أسطح مجاورة، إضافةً إلى ذلك: التوافر الدائم لقناة الإيقاف أثناء التنفيذ (10.3.2 a)،
• والكشف الآلي عن الاقتراب من حدود النطاق أو انتهاكها بحيث يوقف الإجراء أو يحجبه بدلًا من مجرد تسجيله (10.3.2 b)،
• وإعلانًا لكيفية إنفاذ حدود النطاق المخوَّل في وقت التشغيل (10.3.2 c)، وHalt-on-Loss-of-Oversight (10.3.2 d)،
• وإنفاذ حدود التصعيد المعلنة عبر آلية يكون تعطّلها قابلًا للكشف عنه (10.3.2 e)،
• وفي الإجراءات المتسلسلة بوابة (Gate) على أسوأ Action Reversibility Class يمكن بلوغها في السلسلة كاملةً قبل تشغيل الخطوة الأولى (10.3.2 f).

Agent Integrity: الوكيل بوصفه هدفًا للهجوم

يقرأ وكيل اختبار الاختراق محتويات الهدف، ويستدعي الأدوات، ويستخدم خوادم MCP، ويحتفظ بالسياق بشكل دائم — وهو بذلك نفسه عرضة للهجوم. يشترط APAS ضوابط معلنة ضد أربع فئات من التلاعب على الأقل: حقن الأوامر (Prompt Injection) من محتويات الهدف أو استجاباته، والتلاعب بالأدوات أو الإضافات أو النماذج أو خوادم MCP وخوادم الأدوات المماثلة أو استبدالها، وتسميم (Poisoning) السياق المسترجَع أو المحفوظ، والتغيير أو التحايل غير المصرَّح به على ضوابط وقت التشغيل الخاصة بالنطاق والأدوات المسموح بها والصلاحيات (10.4.1). يتضمن كل Claim من فئة Q3 أو Q4 أو R2 أو R3 في إعلان الجودة إفصاحًا عن Agent Integrity يشمل الضوابط ومحاولات التلاعب المكتشفة وكيفية معالجتها؛ ورسالة يولّدها النظام بنفسه تفيد بأنه «لم يُكتشف أي تلاعب» ليست دليلًا على أنه لم يحدث (10.4.2).

الحاسم هو مَن يختبر: في Q3 أو Q4 أو R2 أو R3 يجب أن ينفّذ المقيِّم بنفسه اختبارات Agent Integrity عدائية — على الأقل Goal Hijack وTool-Response-Injection وContext-Poisoning أو Memory-Poisoning؛ فالضوابط التي يكتفي المورّد بادعائها لا تحمل أيًا من هذه الـ Claims (10.4.4). يقارن التقييم بين جولات تقييم مُعلَّمة وجولات عمياء من حيث الالتزام بالنطاق ورفض ما هو خارج النطاق والتغطية ومعدل الاختلاق؛ وأي فرق سلوكي جوهري يُعدّ Eval-Awareness يجب الإفصاح عنه ويضع سقفًا لنتيجة الـ Assurance (10.4.3). التلاعب غير المكتشف الذي غيّر الاستراتيجية أو النتائج أو الالتزام بالنطاق أو محتوى التقرير تغييرًا جوهريًا يُبطل أبعاد الـ Claim المتأثرة. وإذا اكتشف النظام تلاعبًا، فإنه يعلّق النشاط الهجومي، ويُبلغ مالك الهدف والمقيِّم وجهات اتصال الطوارئ، ويضع الأدلة والنتائج من النافذة الزمنية المشبوهة في الحجر (10.4.5).

البيانات الإلزامية لكل Claim علني خاص بـ APAS (11.1.1)

• الحالة الذرّية أو القائمة على مصفوفة،
• أبعاد الـ Claim الثمانية جميعها،
• هوية المقيِّم (Evaluator)،
• تاريخ التصديق وتاريخ انتهاء الصلاحية،
• رقم إصدار النظام المرشَّح،
• القيود الجوهرية حيثما يُطالَب بـ Reliance،
• مدى توافر إعلان الجودة المنطبق (Quality Declaration) أو ملخص له،
• في حال دعم عدة تركيبات، حالة التركيبات المجاورة التي يمكن لمشترٍ حصيف أن يفترض أنها متاحة،
• إصدار المعيار الأساسي (Core) ومعرِّف كل وثيقة مرافقة (Companion) مطبَّقة مع إصدارها،
• وحيثما كان ذلك جوهريًا، ما إذا كان التبديل الديناميكي بين التركيبات مدعومًا،
• وفي كل موضع يظهر فيه نص الـ Claim (Claim-String) علنًا أو في مواد موجّهة للمشترين أو التسويق أو المشتريات، قراءة بلغة واضحة من جملة واحدة وفق الملحق A — بالبروز نفسه الذي يحظى به النص المرمَّز.

العبارات المحظورة (11.2.1)

استنادًا إلى تصديق APAS وحده، لا يجوز لأحد أن يدّعي أو يُلمح إلى:

تكمل القسم قاعدتان أخريان: لا يجوز تسويق أي فئة تنفيذ أو تعاون أو Assurance أو Reliance دون أبعاد الـ Claim كاملةً — فـ«Q4» أو «X3» منفردًا في الكتيّب التسويقي غير جائز (11.2.2). كما يجب تمييز أي Single-Capture Confirmation بوصفها كذلك في كل Claim علني، ولا يجوز أبدًا تقديمها على أنها مُعاد إنتاجها بشكل مستقل (11.2.3). وعند التعارض تتقدّم الإعلانات المُصادَق عليها على أي عبارة علنية وأي ملخص تسويقي (13.2)؛ وإذا اشترط إطار عمل أو مدقق (Assessor) شروطًا أشد من APAS، فهي التي تسري (13.3).

تصنّف CSA نفسها معيار APTS بوصفه أقرب المبادرات صلةً به: مشروع مبكر من نوع OWASP Incubator للتشغيل الآمن والمحدود لمنصات اختبار الاختراق ذاتية التشغيل. ولا توجد تداخلات إلا في الحوكمة التشغيلية — وهي الأقسام 7 (Declared Conditions) و9 (Human Assistance) و10 (Safety) من APAS —، في حين لا ينص APTS على أي منهجية لقياس التغطية (Coverage)، ولا على تصنيف للاعتماد (Reliance) أو الاستبدال (Substitution)، ولا على شهادة قائمة على مقيّم (Evaluator)؛ وهذا تحديدًا هو جوهر APAS. وحيثما يتطرق APTS إلى قابلية إعادة إنتاج النتائج المكتشفة والأدلة الموجّهة إلى المقيّمين (Assessors)، يمضي APAS أبعد من ذلك: فالنتائج من فئة Confirmed Findings تشترط إعادة إنتاج مستقلة عن الوكيل، وتُقاس التغطية مقابل Independent Surface Baseline (Relationship to Existing Work).

هكذا تستخدمون كلا المعيارين معًا

القرار: أين تثبت اختبارات الاختراق الذاتية جدواها اليوم

تُظهر أنظمة اختبار الاختراق الذاتية نقاط قوتها حيث يكون للاتساع والتواتر وقابلية التكرار وزن: الفحص المستمر لسطح هجوم متغيّر، واختبارات الانحدار بعد الإصدارات، والفرز المسبق قبل اختبار اختراق يدوي، وإعادة الاختبارات (Retests) بإجراءات قابلة لإعادة الإنتاج، وتغطية عدد كبير من الأهداف المتماثلة. أما حدودها فيضعها APAS نفسه: لا هندسة اجتماعية، ولا متجهات مادية أو لاسلكية، ولا Red Team كامل النطاق (2.2, 5.6.3)، ولا تشغيل مستمر كادعاء (Claim) (2.2.4) — ولا استبدال للفحوص المطلوبة من دون R3 وملف تعريف (Profile) وقبول من إطار التدقيق المعني (5.10). لذلك نادراً ما يكون القرار «ذاتي أم بشري»، بل: أي مجموعة فرعية من أنشطة الفحص يمكن تنفيذها ذاتياً وبأي مستوى من الضمان (Assurance)، وما الذي يبقى تقليدياً؟

1. 1
   تحديد الغرض من الإثبات

   معالجة داخلية (Q2/R1)، أم تعزيز لعمل المدققين (Q4/R2)، أم استبدال (Q4/R3)؟ يقودكم Reliance Navigator في هذه الصفحة عبر هذا السؤال؛ والنتيجة تحدد جميع المتطلبات اللاحقة.

2. 2
   توفير النطاق وخط الأساس (Baseline)

   جردٌ قابل للقراءة آلياً (CMDB/CAASM، مراجع SBOM) هو خط الأساس BS-1 الخاص بكم؛ ولأجل Q3/Q4/R3 يُستكمل بتعداد يقوده المقيّم (BS-2). من دون Baseline لا يستطيع أحد قياس Coverage — ولا أنتم (4.2).

3. 3
   إعداد المشروع التجريبي كتقييم

   تصميم تشغيل مسجَّل مسبقاً بعدة عمليات تشغيل ومقياس للتباين (4.6.3)، وإعادة إنتاج مستقلة لعيّنة (EV3)، وملاحظات مقترنة عند نتائج الصلاحيات (4.4.6)، واختبار Stop Authority من طرف إلى طرف (10.2.6)، واختبارات عدائية لسلامة الوكيل (Agent Integrity) (10.4.4)، وتشغيل أعمى ضد Eval-Awareness (10.4.3).

4. 4
   تحديد نموذج التشغيل: الإنسان مع الوكيل

   أي فئة X/C تناسب قابليتكم لتحمّل المخاطر؟ تسري أشد الالتزامات على الأهداف الإنتاجية ذات الإجراءات غير القابلة للعكس (10.3.2)؛ حدّدوا نقاط الموافقة وجهات اتصال التصعيد ونوافذ الاختبار وفضّ التعارض (De-Confliction) مع مركز العمليات الأمنية (SOC) (7.4.3).

5. 5
   العقد والحوكمة

   معالجة البيانات (Data Handling) و Egress (7.1.1)، و Stop Authority وزمن الاستجابة، و Access Disposition، والإفصاح عن تغييرات التكوين وإعادة التصديق (5.11.3)، والمسؤولية عند الاستبدال (5.10.4)، وصيغ التبادل (8.4.3) — إضافة إلى مؤشرات الأداء (KPIs): Unsupported-Finding Rate، ونسبة إعادة الاختبار، و Coverage مقابل Baseline، وزمن الاستجابة للإيقاف.

تقييم الأدوات: قائمة المتطلبات المبنية على APAS

• ما تركيبات القدرات التي تقدمها المنصة — يُرجى تقديمها كـ Capability Matrix بجميع الأبعاد الثمانية وفئات الحالة، لا كقائمة ميزات (5.3, 5.4)؟
• ما القراءة بلغة واضحة لأقوى ادعاء (Claim) لديكم، وما القيود (Limitations) التي تسري عليه (11.1.1)؟
• من أين يأتي مقام Coverage في تقاريركم — من اكتشاف المنصة نفسها أم من Baseline مستقل؟ اعرضوا إعلان Coverage (Coverage Declaration) بجميع الحقول الإلزامية (4.2.1).
• ما مقدار Unsupported-Finding Rate لديكم لكل تركيبة، مفصّلةً حسب False Positives و Over-Severity (4.3.8)؟
• هل تتضمن كل نتيجة (Finding) إجراء Reproduction Procedure يستطيع فريقي تنفيذه من دون منصتكم، إضافة إلى Stable Finding Identifier (4.3.3)؟
• كيف تميّزون بين Observations و Validated Findings و Confirmed Findings — ومن الذي يؤكّد (4.3, 4.4.1)؟
• كيف توصّفون التباين بين عمليات التشغيل (Run-to-Run)، وهل تبلغون عن جميع عمليات التشغيل أم عن أفضلها فقط (4.6)؟
• ما الحقول التي يشملها Affordance Profile لديكم — لا سيما Inference Egress و Telemetry Egress مع الولاية القضائية، و Tool Provenance و MCP Provenance، و Action Reversibility (7.1.1)؟
• كيف تعمل Stop Authority خارج النطاق (out-of-band)، وبأي زمن استجابة أقصى، وماذا يحدث عند فقدان الإشراف (10.2.2, 10.2.3)؟
• ما الضوابط القائمة ضد Prompt Injection واستبدال الأدوات وتسميم السياق والتحايل على ضوابط وقت التشغيل، ومن اختبرها اختباراً عدائياً (10.4)؟
• هل تقدّمون Agent Execution Record وتجزئات المحتوى (Content Hashes) وتصديقاً موقَّعاً — وبأي صيغ تصدّرون النتائج والربط (Mappings) وحالة الإصلاح (8.2, 8.4.3)؟
• ما التغييرات في النموذج أو الموجّه (Prompt) أو التنسيق (Orchestration) أو مجموعة الأدوات التي تبلغوننا بها، وكم مرة تغيّر تكوينكم تغيّراً جوهرياً خلال الاثني عشر شهراً الماضية (5.11)؟

النسخة الكاملة مع مصفوفة التقييم ومعايير الاستبعاد و20 سؤالاً لطلبات العروض (RfP) يتضمنها الكتاب الأبيض لـ CISO الموجود أسفل هذه الصفحة.

التصنيف التنظيمي: ما الذي يمكن للمدققين قبوله

يوضح APAS أنه لا يُنشئ امتثالاً تنظيمياً أو تعاقدياً أو امتثالاً لمتطلبات التدقيق، وأن شهادة APAS لا تعني أبداً قبولاً من جانب الأطر التنظيمية (1, 5.9.1). وفي المقابل لا تقول معظم الأطر التنظيمية شيئاً عن المختبِرين الذاتيين — بل تطلب اختبارات ومنهجية ومؤهلات وتوثيقاً. لذلك فإن التصنيف التالي هو تقدير من VamiSec لفئة Reliance التي يمكن لمدقق أن يقبلها اليوم بشكل معقول بموجب الإطار المعني.

للجهات الرقابية في 2026 خط واضح المعالم: الذكاء الاصطناعي كقدرة مساندة تحت إشراف بشري. فقد طالبت الرقابة المصرفية في البنك المركزي الأوروبي المؤسسات المهمة في يوليو 2026 بخطط عمل ضد الهجمات المدعومة بالذكاء الاصطناعي، وتذكر الأدوات القائمة على الذكاء الاصطناعي كتكملة لفحص الثغرات — بشرط تقييم مسبق للمنافع والمخاطر وتدابير حماية مناسبة وإشراف بشري. وتصف ENISA في الشهر نفسه «Verification Bottleneck»: فحجم نتائج الذكاء الاصطناعي الصحيحة تقنياً يفوق طاقة التحقق — وهي بالضبط الفجوة التي يعالجها APAS عبر Confirmed Findings و Unsupported-Finding Rate. ويطلب NCSC البريطاني لوكلاء الذكاء الاصطناعي عزلاً (Sandboxing) وسجلات غير قابلة للتغيير وإمكانية «سحب القابس»؛ وتوصي الإرشادات المشتركة لتحالف Five Eyes الصادرة في مايو 2026 بـ Red Teaming واختبارات الاختراق ضد الأنظمة الوكيلة وبموافقة بشرية قبل الإجراءات عالية الأثر. ولا يوجد حتى الآن تصريح رقابي يعترف صراحةً باختبارات الاختراق الذاتية كدليل تنظيمي أو يرفضها.