يمثل نشر MDASH في الإمارات اختباراً عملياً لفكرة الدفاع السيبراني المدعوم بوكلاء الذكاء الاصطناعي على مستوى جهات حكومية متعددة. المشروع الذي أعلنت عنه Microsoft ومجلس الأمن السيبراني لحكومة الإمارات وCore42 لا يقتصر على شراء أداة فحص شفرة؛ فهو يجمع فحصاً وكشفاً وتحققاً واقتراح إصلاح مع مختبر وطني للاختبار وبنية سحابية سيادية وبرنامج إدخال تدريجي.
يشرح هذا المقال كيف تعمل MDASH، وما الفرق بينها وبين ماسح الثغرات التقليدي، ولماذا تحتاج نتائجها إلى حوكمة بشرية وخط تطوير آمن. كما يقدم نموذج تطبيق يمكن للجهات الحكومية والشركات العربية استخدامه من دون منح الوكيل ثقة مطلقة أو إغراق الفرق بتنبيهات غير قابلة للتنفيذ.
ما الذي أُعلن في الإمارات؟
أعلنت الأطراف الثلاثة خطة لنشر قدرات MDASH على مراحل عبر جهات حكومية في دولة الإمارات. يتولى مجلس الأمن السيبراني دعم التبني المسؤول من خلال المختبر الوطني لاختبار والتحقق من الذكاء الاصطناعي، بينما تساعد Core42 في الإدخال والتنفيذ وبناء القدرات عبر سحابتها العامة السيادية. ويشمل المسار التوعية والتجارب وورش العمل والإدخال التدريجي.
هذه التفاصيل مهمة لأن مشروعاً أمنياً على نطاق حكومي لا ينجح بتثبيت أداة مركزية فقط. تختلف الجهات في مستودعاتها ولغاتها وخطوط بنائها وتصنيف بياناتها ونضج فرقها. لذلك يحتاج البرنامج إلى معايير قبول مشتركة، ثم تكييف التنفيذ، وتوثيق المسؤوليات، وقياس النتائج لدى كل جهة.
وفق الوثائق الحالية، MDASH ما تزال في وضع المعاينة، وتصفها Microsoft بأنها ماسح شفرة وكيل ضمن منظومة إدارة التعرض الأمني. كما تشير وثائق المنتج إلى أن الدعم الحالي في الإمارات يتعلق بفحوصات واجهة الأوامر. هذه حالة قابلة للتغير، لذا يجب التحقق من نطاق الخدمة والتكاملات قبل أي التزام تشغيلي.
ما هي MDASH؟
الاسم يعبّر عن نظام متعدد الوكلاء لاكتشاف الثغرات والتحليل الأمني. الفكرة أن مجموعة عوامل متخصصة تتعاون لفهم المستودع، وترتيب المسارات المهمة، والبحث عن أنماط ضعف، ثم التحقق من قابلية الاستغلال وتقليل التكرار. بدلاً من تطبيق قاعدة ثابتة على كل سطر، يحاول النظام تتبع تدفق البيانات وسياق الاستدعاءات.
تدعم الوثائق لغات رئيسية مثل Java وC وC++ وC# وJavaScript وTypeScript وPython، مع دعم عام للغات أخرى. لكن وجود اسم اللغة في القائمة لا يضمن جودة متساوية لكل إطار أو نمط معماري. يجب بناء مجموعة اختبار من مستودعات المؤسسة نفسها، تشمل نقاط الضعف المعروفة ونتائج صحيحة ونظيفة.
توفر المنصة درجات ثقة وتفسيراً ونتائج يمكن ربطها بخطوط GitHub أو Azure DevOps بحسب الإتاحة. كما تستطيع اقتراح إصلاحات باستخدام أدوات Microsoft. الاقتراح ليس تصحيحاً معتمداً؛ يجب أن يمر باختبارات ومراجعة ومالك شفرة، خصوصاً عندما يمس المصادقة أو التشفير أو التعامل مع البيانات.
كيف تختلف عن أدوات SAST التقليدية؟
أداة التحليل الساكن التقليدية تعتمد غالباً على قواعد وأنماط ومحللات تدفق محددة. ميزتها أنها قابلة للتكرار وسريعة ومعروفة السلوك، لكنها قد تولد عدداً كبيراً من النتائج أو تفوت عيباً يحتاج إلى فهم سياق أوسع. MDASH تضيف طبقة وكلاء ونماذج تحاول تفسير النية والمسار وعلاقة الملفات والخدمات.
هذا لا يجعل الأسلوبين متنافسين بالضرورة. القواعد ممتازة للأخطاء المعروفة والسياسات الصريحة، مثل دالة خطرة أو سر مخزن أو إعداد غير آمن. التحليل الوكيلي مفيد عندما يحتاج الباحث إلى وصل سلسلة استدعاءات أو فهم أن مدخلاً غير موثوق يصل إلى عملية حساسة عبر طبقات عدة.
التركيب الأفضل عادة هو دفاع متعدد الأدوات: فحص أسرار، وتحليل تبعيات، وSAST، واختبارات ديناميكية، وفحص بنية تحتية ككود، ثم تحليل وكيل للمسارات ذات المخاطر. إلغاء الأدوات الناضجة لمجرد ظهور أداة ذكاء اصطناعي يخلق فجوة، بينما إضافة كل أداة بلا إدارة يخلق ضوضاء.
مراحل الفحص متعدد الوكلاء
1. التحضير وترتيب المخاطر
تبدأ العملية بفهم بنية المستودع ونقاط الدخول والعلاقات. يمكن إنشاء رسم استدعاءات يساعد على تحديد أين تدخل البيانات وأين تقع العمليات الحساسة. ترتيب المناطق يمنع استهلاك الوقت بالتساوي على ملف تنسيق بسيط ومسار مصادقة أو معالجة دفع.
2. المسح المتخصص
تستخدم المنصة عدداً كبيراً من الوكلاء المتخصصين للبحث عن فئات ضعف مختلفة. التخصص يسمح لكل عامل بتركيز تعليماته وأدواته، لكن العدد ليس دليلاً على الدقة. القيمة تقاس بقدرة النظام على اكتشاف عيوب حقيقية قابلة للإصلاح من دون رفع كلفة المراجعة.
3. التحقق من النتيجة
تأتي مرحلة تحقق تستخدم تحليل التلوث وحل الأنواع وخدمات اللغة ونقاشاً بين نماذج متعددة وفق الوثائق. الهدف هو إثبات أن المسار ممكن وتقليل النتيجة الوهمية. يجب مع ذلك الاحتفاظ بدليل قابل للمراجعة: المصدر، والمصب الحساس، والمسار، والشروط، ونسخة الشفرة.
4. إزالة التكرار والتجميع
قد يظهر السبب نفسه في ملفات أو فروع متعددة. إزالة التكرار تجمع النتائج حتى يتعامل الفريق مع مشكلة واحدة بدلاً من عشرين تذكرة. يجب ألا تخفي عملية الدمج اختلافاً يجعل فرعاً أكثر خطورة أو يغيّر مالك الخدمة.
لماذا يهم مختبر الاختبار والتحقق الوطني؟
أدوات الذكاء الاصطناعي الاحتمالية قد تغير النتيجة مع إصدار النموذج أو التعليمات أو المستودع. وجود مختبر وطني يسمح بوضع منهج موحد لقياس الدقة والخصوصية والمرونة قبل التوسع. الاختبار لا يقتصر على العثور على الثغرة؛ يجب أن يفحص أيضاً التسريب، والتحيز للغات، ومقاومة التعليمات الخبيثة داخل الشفرة والتعليقات.
يمكن للمختبر بناء حزم مرجعية تتضمن تطبيقات عربية وإنجليزية، وأنظمة حديثة وقديمة، وثغرات مركبة وحالات سليمة تشبهها. تُقاس الحساسية والدقة والوقت والتكلفة ونسبة النتائج التي قبلها المختصون. كما يمكن اختبار اختلاف النتائج بين تشغيلين، لأن عدم الثبات يؤثر على التدقيق.
على المستوى المؤسسي، ينبغي لكل جهة امتلاك مجموعة أصغر تعكس تقنياتها. اعتماد ختم عام لا يكفي إذا كان التطبيق يستخدم إطاراً أو لغة غير ممثلة. الاختبار المحلي يكشف الفجوة قبل ربط النتيجة ببوابة تمنع النشر.
السحابة السيادية: ماذا تحل وماذا لا تحل؟
تساعد السحابة السيادية في تطبيق متطلبات تتعلق بموقع البيانات والتشغيل والتحكم والوصول، وهي مهمة عندما تحتوي الشفرة على منطق حكومي أو أسرار بنية أو تفاصيل أمنية. دور Core42 المعلن يشمل الإدخال والتنفيذ وبناء القدرة مع التركيز على الخصوصية والمرونة.
لكن كلمة سيادية ليست ضابطاً واحداً. يجب توثيق مكان معالجة الشفرة والمطالبات والنتائج والسجلات والنسخ، ومن يملك مفاتيح التشفير، ومن يستطيع تقديم الدعم، ومدة الاحتفاظ. كما يجب فحص تبعيات الخدمة: نموذج، وطبقة مراقبة، ومستودع، ونظام تذاكر، وأداة بناء.
لا تمنع الاستضافة المحلية خطأ صلاحيات أو تسريباً في سجل أو حساب مطور مخترق. تظل الهوية وأقل صلاحية وفصل الشبكات والمراقبة والاستجابة مسؤوليات أساسية. السيادة تزيد التحكم المتاح، لكنها لا تستخدمه نيابة عن الجهة.
الخطر الأول: إرسال شفرة حساسة إلى الفحص
الشفرة مصدر للملكية الفكرية وتكشف بنية الأنظمة ونقاط الاتصال وأحياناً أسراراً مخزنة خطأ. قبل الفحص يجب تصنيف المستودعات وتحديد ما يجوز إرساله، ثم تنظيف الأسرار واستخدام اتصال وهوية معتمدين. لا ينبغي نسخ مستودع كامل إلى مساحة مؤقتة غير مراقبة.
اسأل بوضوح هل تستخدم البيانات لتدريب نموذج، وأين تعالج، وكم تبقى، وكيف تحذف، ومن يستطيع الوصول إليها. اجعل الإجابات جزءاً من التصميم والعقد. افصل مستودعات الأمن الوطني أو الأنظمة الحرجة في سياسة أعلى، وقد تحتاج بعض الحالات إلى تشغيل معزول أو استثناء.
راقب أيضاً المخرجات. تقرير الثغرة قد يحتوي مسار استغلال ومقاطع حساسة، فلا يجوز إرساله تلقائياً إلى قناة واسعة. طبّق تصنيفاً على النتائج، وحدد من يرى التفاصيل ومن يرى مؤشراً عاماً.
الخطر الثاني: حقن التعليمات داخل المستودع
يمكن لمهاجم أو مساهم أن يضع تعليقاً أو ملفاً نصياً يحاول توجيه الوكيل إلى تجاهل مشكلة أو كشف بيانات أو استخدام أداة. النموذج قد يتعامل مع محتوى المستودع كتعليمات إذا لم يفصل النظام بين البيانات والأوامر. هذه صورة من حقن المطالبات غير المباشر.
يجب أن يعامل النظام كل محتوى المستودع كبيانات غير موثوقة، وأن تكون تعليمات النظام والأدوات خارج سيطرة الشفرة المفحوصة. امنع الوصول الشبكي غير الضروري، واستخدم قائمة أدوات مسموحة، ولا تمنح الفحص قدرة كتابة على الفرع الأساسي. اختبر عينات حقن ضمن التقييم الدوري.
إذا اقترح الوكيل إصلاحاً، أنشئه في فرع منفصل بهوية محددة وتوقيع وسجل. لا تسمح لنتيجة من محتوى غير موثوق بتجاوز المراجعة أو دمج نفسها في الإنتاج.
الخطر الثالث: الإصلاح الآلي الذي يغير السلوك
قد يغلق تعديل ثغرة لكنه يكسر وظيفة أو يضعف الأداء أو يغير صلاحيات المستخدم. وقد يستبدل دالة بطريقة تبدو آمنة لكنها لا تناسب إصدار المكتبة. لذلك يجب معاملة الإصلاح المقترح مثل مساهمة مطور خارجي: مراجعة، واختبارات وحدة وتكامل وأمن، وتحليل تبعيات.
أضف إلى طلب الدمج شرح السبب والمسار الذي عالجه والاختبارات الجديدة. إذا لم يستطع الفريق كتابة اختبار يفشل قبل الإصلاح وينجح بعده، فالثقة بالتغيير أقل. في الأخطاء المعقدة يفضل أن يقدم الوكيل خيارات وأن يقرر مالك الخدمة.
لا تستخدم معدل قبول الإصلاحات كمؤشر وحيد؛ قد يقبل الفريق تعديلات سطحية لإغلاق التنبيهات. راقب عودة الثغرة والحوادث والانحدارات ووقت المعالجة بعد التحقق.
من النتيجة إلى أولوية قابلة للتنفيذ
درجة الشدة العامة لا تكفي. ثغرة حرجة في مكتبة غير قابلة للوصول قد تكون أقل إلحاحاً من عيب متوسط في خدمة عامة تحمل بيانات حساسة. اربط نتيجة MDASH بسياق الأصل: تعرض الإنترنت، والامتيازات، ونوع البيانات، والاستغلال المعروف، والضوابط التعويضية.
أنشئ معادلة أولوية مفهومة، ولا تخفها داخل نموذج. يجب أن يستطيع مالك التطبيق معرفة لماذا استحقّت التذكرة موعداً قصيراً. وفر مسار استثناء بمدة ومبرر وضابط تعويضي وموافق، ولا تسمح بتأجيل مفتوح.
من المفيد ربط النتائج بإدارة التعرض حتى ترى المؤسسة مسار الهجوم عبر الهوية والسحابة والنقطة الطرفية والشفرة. لكن الربط يزيد حساسية البيانات، ولذلك يحتاج إلى فصل صلاحيات وتدقيق.
بناء خط تطوير آمن حول MDASH
ضع الفحوصات السريعة الحتمية عند كل طلب دمج، وشغّل الفحص الوكيلي الأعمق للمستودعات الحساسة أو دورياً أو عند تغييرات عالية المخاطر. هذا يمنع رفع زمن البناء لكل تعديل صغير. يمكن أيضاً تحديد الملفات المتغيرة وسياقها بدلاً من مسح كامل دائماً، إذا حافظ ذلك على القدرة على تتبع المسار.
تبدأ البوابة في وضع إرشادي، ثم تتحول إلى منع عند ثغرات عالية الثقة ضمن فئات متفق عليها. إذا بدأ المنع من اليوم الأول بنتائج غير معايرة، سيبحث المطورون عن طرق تجاوز الأداة. اجمع ملاحظاتهم في عملية واضحة، وميّز بين النتيجة الخاطئة والخطر المقبول مؤقتاً.
احتفظ بنسخة الأداة والنموذج والسياسة ووقت الفحص وبصمة المستودع. من دون هذه المعلومات لا يمكن إعادة نتيجة أو تفسير اختلافها. هذا مهم للجهات التي تحتاج إلى أدلة تدقيق أو تحقيق حادث لاحق.
حوكمة متعددة الجهات الحكومية
على المستوى الوطني، يلزم فصل ما هو مركزي عما هو محلي. يمكن مركزياً تحديد الضوابط الدنيا، ومنهج القياس، وتصنيف النتائج، ونموذج العقد، ومعيار السجلات. وتحتفظ الجهة بملكية الشفرة وقبول المخاطر ومواعيد الإصلاح والاستجابة للحادث.
يجب ألا تتحول لوحة مركزية إلى مستودع مكشوف لكل تفاصيل الثغرات الحكومية. يمكن مشاركة مؤشرات مجمعة واتجاهات، مع بقاء الدليل الفني لدى الجهة والفرق المصرح لها. عند وجود تهديد مشترك، تنشأ آلية مشاركة سريعة ومحمية.
برنامج بناء القدرات أساسي. يحتاج المطور إلى فهم النتيجة، ويحتاج فريق الأمن إلى قراءة الشفرة، ويحتاج المدير إلى تفسير المؤشر بلا تضخيم. ورش العمل يجب أن تستخدم تطبيقات واقعية وتنتج إجراءات وأدواراً، لا عرضاً عاماً للمنتج.
مقاييس تكشف القيمة الحقيقية
قِس معدل النتائج الصحيحة بين ما راجعه المختص، ومعدل الثغرات المعروفة التي اكتشفها، وزمن الوصول إلى نتيجة، وزمن الإصلاح، ونسبة العودة، وعدد النتائج المكررة. افصل المقاييس حسب اللغة ونوع التطبيق وشدة المشكلة حتى لا يخفي المتوسط ضعفاً مهماً.
راقب عبء المطورين: كم دقيقة يحتاجون للتحقق؟ كم مرة أغلقوا نتيجة بلا إجراء؟ هل زاد زمن الدمج؟ الأداة التي تجد مشكلات كثيرة لكنها تستهلك الفريق في ضوضاء قد تقلل الأمن عملياً. قارن كذلك النتائج بحوادث الإنتاج واختبارات الاختراق.
لا تستخدم عدد الثغرات المكتشفة لتقييم فريق بعينه، لأن ذلك يشجع إخفاء الفحص أو تجزئة المستودعات. الهدف تقليل المخاطر مع مرور الوقت. مؤشرات الاتجاه والنضج أفضل من ترتيب الجهات بصورة عقابية.
خطة تطبيق على أربع مراحل
المرحلة الأولى: التحقق المعزول
اختر مستودعات اختبار تحتوي على ثغرات معروفة ولا تضم بيانات حساسة. قارن MDASH بأدوات المؤسسة وبمراجعين بشريين. اختبر الدقة والتكرار وحقن التعليمات والتسريب والتكلفة.
المرحلة الثانية: تشغيل الظل
افحص مستودعات حقيقية من دون فتح تذاكر تلقائية أو منع بناء. يراجع فريق صغير النتائج ويضبط الفئات والثقة. وثّق أسباب الرفض والقبول لتحديث السياسة.
المرحلة الثالثة: تكامل إرشادي
اعرض النتائج داخل طلبات الدمج، واربط النتائج المؤكدة بالتذاكر ومواعيد المعالجة. قدم إصلاحات مقترحة في فروع منفصلة، وراقب أثرها على الاختبارات وزمن العمل.
المرحلة الرابعة: بوابات محدودة
امنع فقط فئات عالية الخطورة وعالية الثقة في تطبيقات محددة، مع مسار طوارئ واستثناء مؤقت. وسّع النطاق بعد دورات قياس مستقرة، واحتفظ بالأدوات الأخرى كطبقات دفاع.
قائمة تحقق قبل التشغيل
- تصنيف المستودعات والبيانات وتحديد ما يجوز إرساله إلى الخدمة.
- توثيق مكان المعالجة والاحتفاظ والمفاتيح والوصول والدعم.
- حساب خدمة بأقل صلاحية ومن دون كتابة على الفرع الأساسي.
- اختبار حقن تعليمات وتسريب أسرار وتغيير غير مصرح.
- مجموعة مرجعية للغات والأطر المستخدمة وقياس دقة منفصل.
- مالك لكل نتيجة ومسار استثناء بمدة وموافقة.
- اختبارات إلزامية لأي إصلاح مقترح ومراجعة بشرية.
- سجل للإصدار والسياسة وبصمة الشفرة والنتيجة.
- خطة بديلة إذا تعطلت الخدمة أو تغير نطاق المعاينة.
أسئلة شائعة حول MDASH في الإمارات
هل MDASH بديل كامل لاختبار الاختراق؟
لا. تحليل الشفرة يغطي طبقة مهمة، لكنه لا يختبر كل إعداد وتشغيل وسلوك أعمال وسلسلة هوية كما يفعل اختبار شامل. الأفضل استخدامه ضمن طبقات متعددة.
هل الأداة متاحة كمنتج نهائي مستقر؟
تصفها وثائق Microsoft الحالية بأنها معاينة. يجب التحقق من شروط الدعم والميزات والقيود والتكاملات قبل الاعتماد عليها في بوابة حرجة.
هل يمكن قبول الإصلاح الآلي مباشرة؟
لا. يجب مراجعة التعديل واختباره وفهم أثره الوظيفي والأمني. يوضع في فرع منفصل ولا يدمج تلقائياً في الإنتاج.
كيف نمنع تسريب الشفرة؟
بالتصنيف، والحد الأدنى من البيانات، واتصال وهوية محكومين، وفحص الأسرار، وتشفير، وسياسة احتفاظ واضحة، وسجلات وصول، وعقد يحدد استخدام البيانات ومكانها.
ما أهم مقياس للنجاح؟
لا يوجد مقياس وحيد. اجمع دقة النتائج وتغطية الثغرات وزمن الإصلاح وعبء المراجعة والانحدارات وأثرها على المخاطر الفعلية.
هل يناسب الشركات خارج الحكومة؟
المبادئ مناسبة للشركات أيضاً: تحقق مستقل، وتشغيل ظلّي، وتكامل تدريجي، وأقل صلاحية، ومراجعة الإصلاح. يختلف مستوى السيادة والتنظيم حسب القطاع.
الخلاصة
يضع مشروع MDASH في الإمارات الذكاء الاصطناعي داخل عملية أمنية فعلية تجمع التقنية والحوكمة والسيادة وبناء المهارات. يمكن للوكلاء تحسين اكتشاف المسارات المعقدة وتقليل وقت التحليل، لكنهم يضيفون مخاطر تتعلق بالشفرة الحساسة وحقن التعليمات وعدم ثبات النتيجة والإصلاح الخاطئ. التطبيق الناضج يبدأ بالتحقق المعزول، ثم الظل، ثم إرشاد المطور، وأخيراً بوابات محدودة مبنية على دليل. بهذه المقاربة يصبح الذكاء الاصطناعي مضاعفاً لخبرة الفرق، لا سلطة غير قابلة للمراجعة.
