قد يبدو تطوير التطبيقات عملية “نظيفة” من الخارج: زر هنا، صفحة هناك، رسالة أو عملية دفع، ثم حساب للمستخدم. لكن خلف هذا الشكل البسيط يوجد آلاف الأسطر من الكود—وأحيانًا ملايين—قد تتسلل بينها أخطاء صغيرة لا تُلاحظ أثناء الاستخدام العادي. المشكلة أن القراصنة لا يحتاجون إلى نظام كامل مليء بالأعطال؛ يكفيهم خطأ محدد يعرفون كيف يستغلونه ليصبح ثغرة تُكلف الشركة بيانات مسروقة أو وصولًا غير مصرح به أو تعطيلًا للخدمة. لهذا السبب لم يعد الأمن السيبراني مجرد مرحلة لاحقة بعد إطلاق المنتج، بل أصبح يسعى لأن يكون حاضرًا “في لحظة كتابة الكود نفسها”.
وبحسب ما أشارت إليه Microsoft Security Blog، طورت مايكروسوفت نظامًا باسم MDASH، وهو إطار فحص أمني يعتمد على شبكة من أكثر من 100 وكيل ذكاء اصطناعي متخصص. الفكرة ليست الاكتفاء بعثور الأداة على أخطاء محتملة فحسب، بل تدقيقها وتحويلها إلى تقييم عملي: هل الخطأ قابل للاستغلال فعلاً؟ وما السيناريو الذي قد يستغله المهاجم؟ وكيف يمكن التحقق من تأثيره داخل قاعدة الكود بدل الاكتفاء بتحذيرات عامة قد تكون بعيدة عن الواقع.
لماذا لم يعد “العثور على الأخطاء” كافيًا؟
أدوات فحص الكود التقليدية كثيرًا ما تقدم كمًا كبيرًا من التنبيهات: عشرات أو مئات التحذيرات يوميًا. جزء منها مهم فعلًا، وجزء آخر قد يكون إنذارًا زائفًا أو خطورة منخفضة لا تستحق الاستجابة العاجلة. ومع مرور الوقت قد يحدث “تبلّد” لدى فرق التطوير—أي الاعتياد على تجاهل التحذيرات—بسبب كثرتها. عندها تختبئ الثغرة الأكثر جدية داخل الضجيج.
لذلك تتجه الأنظمة الأحدث إلى مقاربة أقرب للواقع: إثبات أن الخطأ يمكن أن يتحول لسيناريو هجومي. بمعنى آخر، يتم الانتقال من “وجود مشكلة محتملة” إلى “قابلية للاستغلال” من خلال تحليل السياق داخل الكود، ومسار البيانات، وطريقة تنفيذ الدوال، وحدود الصلاحيات. يشبه ذلك الفرق بين طبيب يلاحظ رقمًا غير طبيعي في الفحوصات، وبين طبيب يربط الرقم بأعراض المريض والسبب المحتمل والسياق—فالتقييم الواقعي يقلل سوء القرار ويجعل الاستجابة أكثر ذكاءً.
كيف يغير MDASH طريقة عمل المطورين؟
التأثير الأبرز هو نقل الأمن إلى وقت أبكر داخل دورة التطوير بدل أن يصبح مهمة مستقلة بعد اكتمال البرمجية. يمكن تلخيص التدفق المقترح بشكل مبسّط كالتالي:
- يكتب المطور الكود أو تعديلات عليه.
- تفحص الأداة الأخطاء المحتملة.
- تحاول التحقق من مدى خطورة كل مشكلة وتفسيرها ضمن السياق البرمجي الفعلي.
- تقوم بتجميع النتائج وترتيب الأولويات بناءً على قابلية الاستغلال وتأثيرها المتوقع.
- تقترح مسار إصلاح أو مراجعة آمنة، وتدعم الفريق في تقليل المخاطر.
تظل نقطة مهمّة: القرار النهائي لا يجب أن يخرج من يد البشر. فالذكاء الاصطناعي قد يُقترح له إصلاح، لكن إصلاح ثغرة قد يؤدي إلى كسر وظيفة أخرى أو تغيير سلوك يعتمد عليه المنتج، كما قد توجد اعتبارات تجارية أو تشغيلية يعرفها الفريق وحده دون أن تكون واضحة للنموذج. لذلك يكون الذكاء الاصطناعي في هذا السياق “مساعدًا” يقلل الضوضاء ويُسرّع الفحص، لا “قاضيًا نهائيًا” على أمن التطبيق.
التكامل مع أدوات الحماية ضمن بيئة التطوير
يُذكر أيضًا أن MDASH يتكامل مع منظومة مايكروسوفت للأمان، بما في ذلك Microsoft Defender وGitHub Code Security. هذا النوع من التكامل يساعد الفرق على:
- ربط تقييمات الثغرات المبكرة بالخطط العملية للاستجابة داخل سير العمل.
- تحويل النتائج إلى ترتيب واضح للمخاطر بدل قوائم طويلة من التنبيهات النظرية.
- دعم الفرق في اتخاذ إجراءات أكثر اتساقًا بين التحليل داخل الكود وما يحدث لاحقًا على مستوى الحماية العامة.
معلومة إضافية: ما الذي يجعل “قابلية الاستغلال” أهم من “التنبيه”؟
في الأمن السيبراني، ليست كل مشكلة تظهر في الفحص دليلًا على اختراق فعلي. قد تكون الثغرة محصورة في مسار غير مستخدم، أو محمية بعزل صلاحيات، أو تتطلب شروطًا معقدة لا يملك المهاجم القدرة على تحقيقها. عندما يركز النظام على قابلية الاستغلال فإنه يقلل احتمال إضاعة وقت فريق التطوير في معالجة إنذارات ضعيفة التأثير، ويركز بدلًا من ذلك على ما يمكن أن يؤدي فعلاً إلى:
- وصول غير مصرح به إلى بيانات حساسة
- تنفيذ أوامر أو سلوكيات غير متوقعة
- تعطيل خدمة أو إحداث تدهور في الاستقرار
وبذلك تتحسن جودة قرارات الإصلاح، وتُبنى دورة تطوير أكثر أمانًا منذ البداية.
الخلاصة: MDASH تمثل اتجاهًا واضحًا في حماية البرمجيات: الأمن لا ينتظر وقوع الهجوم أو انتهاء التطوير، بل يدخل مبكرًا في مرحلة كتابة الكود، ويستخدم “شبكة وكيلـات ذكاء اصطناعي” لتقييم الثغرات ليس بوصفها تحذيرات فقط، بل بوصفها تهديدات قابلة للاستغلال يمكن ترتيبها ومعالجتها بأولوية دقيقة—مع بقاء الحكم النهائي للأشخاص لضمان توافق الإصلاح مع منطق المنتج والواقع التشغيلي.
التعليقات