OWASP SAMM يحصل على امتداد Agentic SAMM لتطوير آمن بمشاركة وكلاء الذكاء الاصطناعي

ظهر حول OWASP SAMM مشروع جديد بصيغة مسودة (draft) هو Agentic SAMM، أو ASAMM، وهو امتداد موجّه للفرق التي تبني منتجات تعتمد على وكلاء الذكاء الاصطناعي وتستخدم النماذج في عمليات التطوير. يهدف المشروع إلى معالجة مخاطر لا تراها دورة حياة التطوير الآمن (secure SDLC) التقليدية بوضوح: السياق الضار، واستدعاءات الأدوات الخطرة، ونوافذ الاستقلالية الطويلة أكثر مما ينبغي.

لماذا لا يكفي SAMM التقليدي؟

يعمل OWASP SAMM التقليدي جيدًا حيث تنحصر أهداف الحماية الرئيسية في الشيفرة والبناء والإصدار وبنية التوريد التحتية. أما في الأنظمة القائمة على الوكلاء، فيمتد سطح الهجوم أبعد من ذلك: إلى المستندات والمهام في أنظمة التتبع ووصف الأدوات ونتائج البحث على الويب وسجلات CI وأي محتوى آخر يقرؤه النموذج بوصفه جزءًا من سياق عمله. وحين يؤثر هذا السياق في سلوك الوكيل، فإنه يصبح جزءًا من مستوى التحكم (control plane)، لا مجرد بيانات إدخال.

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

ماذا يقترح ASAMM؟

لم يُصمَّم ASAMM ليحلّ محل OWASP SAMM، بل ليكون طبقة إضافية للفرق التي تُدخل وكلاء الذكاء الاصطناعي وخوادم MCP وأتمتة بصلاحيات مفوَّضة. يضيف الإطار طبقة مستقلة من الضمانات حيث تنتهي الفحوص المعتادة للشيفرة: عند حدود استدعاءات الأدوات، وفي تدفق السياق، وفي نقاط الموافقة (approval checkpoints)، وفي سلوك النظام أثناء التشغيل. وهو لا يلغي ممارسات SAMM الأساسية، بل يمدّها إلى سلوك وقت التشغيل (runtime) والإجراءات المفوَّضة.

• تصنيف للتهديدات في الأنظمة القائمة على الوكلاء، يُعامَل فيه السياق بوصفه أمرًا محتملًا
• نموذج ثقة ثنائي المحور للوكلاء والأدوات وخوادم MCP ومصادر السياق
• مجموعة ضوابط موزعة على وظائف SAMM الخمس، مع مستويات نضج وسيناريوهات تطبيق
• مساران للانطلاق: الانتقال من برنامج أمني قائم، أو النشر من الصفر
• مواءمة مع NIST AI RMF وتوصيات NCSC للفرق التي تحتاج إلى التوافق مع الأطر المألوفة لديها

ويُولي الإطار تركيزًا خاصًا لبيئة التطوير. فإضافات IDE وخطافات pre-commit ووكلاء CI وموصّلات MCP الخارجية تعمل بصلاحيات المطوّر، لكنها كثيرًا ما تقع خارج نموذج تهديدات متكامل. وبالنسبة إلى ASAMM، هذه ليست عناصر هامشية بل هدف كامل للتحليل: فإذا كان الوكيل قادرًا على القراءة والاستدعاء والتعديل أكثر مما يتتبعه الفريق فعليًا، فإن الحالات الخضراء في لوحات المتابعة لم تعد تضمن شيئًا. وعمليًا تتحول بيئة التطوير إلى بيئة إنتاج بالنسبة إلى الوكيل نفسه.

أين تخطئ الفرق بالفعل؟

يعدّد المصدر أخطاء نموذجية تظهر بوضوح خاص في التطوير القائم على الوكلاء. فقد تعدّ الفرقة نموذج التهديدات مكتملًا، بينما لا تتضمن مصادر السياق ولا مسارات استدعاء الأدوات إطلاقًا. وقد تغطي مراجعة الشيفرة كل ما في PR، لكنها لا تتناول موجّهات النظام (system prompts) ومخططات tool calls وإعدادات الوكلاء. وقد يُظهر DAST نتيجة نظيفة، دون أن يفحص أحد سلوك الوكيل عند مواجهة سياق معادٍ. أما مبدأ least privilege فكثيرًا ما يُطبَّق على مستوى حسابات الخدمة فقط، دون تقييد الإجراءات المسموح بها عبر الأدوات.

«لا توجد خطة تنجو من أول احتكاك». يستخدم المؤلف هذه الفكرة مبدأً في

التصميم: ينبغي أن يحدد موجّه النظام النية، لا أن يحاول رسم خوارزمية السلوك كلها بصرامة.

ومن هنا يأتي معيار آخر مهم للمخاطر، وهو حاصل ضرب نافذة الاستقلالية في blast radius للأدوات المتاحة. فكلما طال عمل الوكيل دون نقطة مراقبة بشرية واتسعت مجموعة قدراته، ارتفع الضرر المحتمل حتى مع صلاحيات وصول صحيحة من الناحية الشكلية. ولهذا تصبح نوافذ الاستقلالية هنا معيارًا معماريًا لا تشغيليًا فحسب.

ماذا يعني ذلك؟

يرصد Agentic SAMM تحولًا حدث بالفعل في تطوير الذكاء الاصطناعي: لم يعد الأمن يفحص الشيفرة وحدها، بل سلوك النظام بعد الإصدار أيضًا. وبالنسبة إلى الفرق التي تبني منتجات فوق الوكلاء وفوق vibe coding، فهذه إشارة إلى ضرورة مراجعة نموذج التهديدات ومراجعة الشيفرة وضبط الأدوات قبل أن يتحول أول خطأ مستقل إلى حادث كامل.