جيف ويليامز، مؤسس OWASP ومؤسس ومدير تقني في Contrast Security – سلسلة المقابلات

يُعد جيف ويليامز، مؤسس OWASP ومؤسس Contrast Security ومديرها التقني، واحداً من أكثر الشخصيات تأثيراً في أمن التطبيقات الحديث. فعلى مدى العقود الماضية، ساعد في تشكيل الطريقة التي تتعامل بها المؤسسات مع تطوير البرمجيات الآمنة وإدارة الثغرات وحماية التطبيقات أثناء التشغيل. وكان لويليامز دور محوري في تحويل OWASP من مبادرة تطوعية صغيرة إلى مؤسسة أمنية غير ربحية معترف بها عالمياً، كما ساهم في مشاريع بارزة مثل OWASP Top Ten وWebGoat وESAPI وASVS ودليل منع هجمات XSS. وقبل تأسيس Contrast Security عام 2014، أسس أيضاً Aspect Security، وهي من أوائل الشركات التي تخصصت حصراً في استشارات أمن التطبيقات والتدريب واختبارات الاختراق وممارسات التطوير الآمن للمؤسسات.

OWASP مؤسسة غير ربحية تركز على تحسين أمن البرمجيات من خلال مشاريع مفتوحة المصدر، والتعاون المجتمعي العالمي، والتعليم، ومعايير الصناعة. تأسست المنظمة عام 2001 وأصبحت من أهم الجهات المرجعية في أمن التطبيقات، إذ تضم مئات الفروع المحلية وآلاف المساهمين، وتقدم موارد واسعة الاستخدام يعتمد عليها المطورون ومتخصصو الأمن والمؤسسات والحكومات في مختلف أنحاء العالم. وتشتهر OWASP خصوصاً بمشاريع مثل OWASP Top Ten، الذي يحدد أخطر مخاطر أمن تطبيقات الويب، إلى جانب أطر أمنية وأدوات اختبار ومشاريع توثيق ومبادرات تدريب عديدة. وتعمل المنظمة وفق فلسفة محايدة تجاه الموردين، مما يجعل مواردها التعليمية وإرشاداتها الأمنية متاحة مجاناً لمجتمع التقنية العالمي.

Contrast Security شركة لأمن التطبيقات تركز على حماية البرمجيات من داخل التطبيق أثناء تشغيله، بدلاً من الاعتماد حصراً على أدوات الفحص الخارجية. تستخدم منصة الشركة تقنية القياس أثناء التشغيل لتوفير رؤية آنية للثغرات والهجمات وواجهات API والتبعيات مفتوحة المصدر وسلوك التطبيقات عبر بيئات التطوير والإنتاج. وتشمل منتجاتها مجالات مثل الاختبار التفاعلي لأمن التطبيقات (IAST)، واكتشاف هجمات التطبيقات والاستجابة لها (ADR)، والحماية الذاتية للتطبيقات أثناء التشغيل (RASP)، وتحليل مكونات البرمجيات. وقد رسخت Contrast Security مكانتها عبر دمج الأمن مباشرة في مسارات عمل DevSecOps الحديثة، بما يمكّن المطورين وفرق أمن التطبيقات وفرق العمليات الأمنية من تحديد الثغرات ومعالجتها بسرعة أكبر مع الحفاظ على دورات تسليم البرمجيات السريعة.

بعد مساهمتك في تشكيل أمن التطبيقات الحديث من خلال عملك مع مشروع أمن تطبيقات الويب المفتوح (OWASP)، ما الفجوة في الصناعة التي دفعتك إلى تأسيس Contrast Security، وكيف صمدت تلك الفرضية الأصلية مع تطور التحديات الأمنية؟

كانت الصناعة غارقة في نتائج نظرية ناتجة عن التحليل الساكن، وعاجزة عن التركيز على المشكلات المهمة فعلاً. كانت لدى فرق الأمن أدوات فحص تولد قوائم ضخمة من المشكلات المتراكمة، من دون معرفة أي الثغرات يمكن الوصول إليها أو استغلالها أو تتعرض فعلاً لهجوم في بيئة الإنتاج. أسسنا Contrast انطلاقاً من فكرة بسيطة: ينبغي أن تستند القرارات الأمنية إلى المراقبة المباشرة للتطبيقات الفعلية أثناء تشغيلها، لا إلى التخمين من الخارج.

في نهاية المطاف، آمل أن تتقدم الصناعة إلى مرحلة نخرج فيها من عجلة اكتشاف المشكلات وإصلاحها ثم اكتشاف المزيد منها إلى ما لا نهاية. وآمل أن نبدأ بإنشاء برمجيات ذات بنية أمنية قوية وحجة حقيقية تثبت امتلاكها وسائل الدفاع المناسبة لمواجهة التهديدات المتوقعة. إن الجمع بين الأمن أثناء التشغيل والذكاء الاصطناعي يملك هذه الإمكانية، لكننا ما زلنا على بعد سنوات من تحقيقها.

وصفت ظهور «ثغرات بمستوى Mythos». ما الذي يحدد هذه الفئة الجديدة من المخاطر، ولماذا يصعب على أدوات الأمن التقليدية اكتشافها؟

ثغرات Mythos هي عيوب تنشأ من تعقيد حزم البرمجيات الحديثة. فالتفاعل بين سلوك أطر العمل والتبعيات والأنماط المعمارية معقد إلى درجة أن المطورين كثيراً ما لا يفهمونه بالكامل. وما زالت الأدوات التقليدية مصممة أساساً لاكتشاف الأنماط المعروفة والبسيطة نسبياً والأحداث القابلة للملاحظة. أما ثغرات Mythos فتتطلب غالباً فهماً أعمق بكثير لسلوك التطبيق ومسار التنفيذ والسياق أثناء التشغيل.

لماذا لا تولد فئات كاملة من الثغرات تنبيهات في بيئات مراكز عمليات الأمن الحديثة (SOC)، وماذا يكشف ذلك عن الطريقة التي تقيس بها فرق الأمن المخاطر حالياً؟

تُبنى معظم مراكز عمليات الأمن حول أحداث قابلة للملاحظة، مثل السجلات والتوقيعات وحركة الشبكة ونشاط نقاط النهاية. لكن كثيراً من الهجمات على طبقة التطبيق لا ينتج أي إشارات ذات معنى في تلك الأنظمة. فالمطور لم يكن يعرف بوجود الثغرة، ولذلك لم يضف أي تسجيل يكشف عملية استغلالها. ونتيجة لذلك، تكون معظم عمليات استغلال التطبيقات غير مرئية تماماً في السجلات. ولا تستطيع فرق مراكز العمليات الأمنية الاستجابة إلا لما يمكنها رؤيته. ومع تزايد أهمية طبقة التطبيقات وواجهات API، يصبح من الضروري تزويدها بمستشعرات أمنية قادرة على اكتشاف السلوك غير المعتاد والإبلاغ عنه.

تطورت بنى التطبيقات الحديثة، مثل الخدمات المصغرة وواجهات API والأنظمة بلا خوادم، بسرعة كبيرة. في أي جوانب تتقدم هذه البنى على أساليب الأمن الحالية القائمة على الاكتشاف؟

حطمت هذه البنى نموذج المحيط الأمني القديم. فالطلبات تمر الآن عبر عشرات الخدمات والدوال المؤقتة وواجهات API والطوابير والتبعيات الخارجية قبل إتمام المعاملة. ومع ذلك، لا تزال معظم أنظمة الاكتشاف ترى أجزاء متفرقة بدلاً من مسار التنفيذ الكامل. ويمكنها فحص الحزم أو السجلات، لكنها لا تستطيع فهم القصد أو تدفق البيانات أو معرفة ما إذا كانت شيفرة خطرة قد نُفذت فعلاً. يعتمد الأمن على السياق، ولذلك نحتاج إلى بناء نموذج، أو توأم رقمي، لبنية تطبيقاتنا التحتية يمكّننا، أو يمكّن وكلاء الذكاء الاصطناعي، من الاستدلال بشأن ما نراه يحدث.

لا تزال OWASP Top Ten تسلط الضوء على مشكلات مثل التصميم غير الآمن والمكونات المعرضة للثغرات. لماذا تستمر هذه المخاطر رغم انتشار الوعي والأدوات؟

الوعي لا يصلح الحوافز أو التعقيد. فما زالت معظم المؤسسات تقيس النجاح بحجم عمليات الفحص، أو إغلاق التذاكر، أو قوائم التحقق من الامتثال، بدلاً من قياس الانخفاض الفعلي في التعرض للمخاطر.

وفي الوقت نفسه، تضخمت سلاسل توريد البرمجيات. يجمع المطورون التطبيقات من آلاف المكونات التي لم يكتبوها، وبالتأكيد لم يقيّموها أمنياً. وتغرق فرق الأمن في محاولة فرز المخاطر النظرية، فلا تستطيع التركيز على نسبة 1 إلى 2% التي تهم فعلاً. ومن دون أدلة من بيئة التشغيل، تنهار عملية تحديد الأولويات. ومع ظهور نماذج وأطر ذكاء اصطناعي قوية، يتزايد هذا الحجم بوتيرة متسارعة جداً.

كيف ينبغي للمؤسسات إعادة التفكير في اعتمادها على السجلات والتنبيهات عندما لا تترك بعض أخطر الثغرات أي إشارات قابلة للملاحظة؟

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

دعوت إلى الرؤية أثناء التشغيل باعتبارها حلاً. كيف تبدو الرؤية الحقيقية أثناء التشغيل عملياً، وكيف تغير طريقة عمل فرق الأمن يومياً؟

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

كيف يقارن الأمن القائم على أدوات القياس بالأساليب التقليدية مثل SAST وDAST أو مراقبة المحيط من حيث الفاعلية وقابلية التوسع؟

تستنتج الأدوات التقليدية المخاطر من الخارج، أما أدوات القياس فترصد الواقع من خلال مراقبة الشيفرة الفعلية أثناء تشغيلها. ويمكنها رؤية مسارات التنفيذ الحقيقية، وسلوك أطر العمل، وسياق المصادقة، وتدفق البيانات، ونجاح الاستغلال في الوقت الفعلي. وهي تقضي على فئات ضخمة من النتائج الإيجابية الكاذبة وتكشف ثغرات لا تراها أدوات المحيط على الإطلاق.
وعند العمل على نطاق واسع، تصبح هذه الدقة بالغة الأهمية. فلم يعد بوسع المؤسسات فرز ملايين النتائج النظرية يدوياً، وأصبحت أدلة التشغيل هي المرشح المستدام الوحيد. كما يعمل نهج التشغيل في الوقت الفعلي، ولذلك يتلاءم مع التطوير ومسارات CI/CD بصورة أفضل من الفحص والفرز. وهو مستمر أيضاً، فلا يقتصر على لقطة أمنية في نقطة زمنية محددة.

مع انتشار أنظمة الذكاء الاصطناعي والتطبيقات المستقلة، هل تصبح هذه الثغرات غير المرئية أكثر خطورة، وكيف ينبغي للفرق أن تستعد؟

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

لو كنت تقدم المشورة اليوم لقائد مركز عمليات أمن حديث، فما أولى الخطوات الملموسة التي ينبغي اتخاذها لسد فجوة الرؤية قبل أن تؤدي إلى اختراق كبير؟

أولاً، يجب الإقرار بأن بيانات القياس عن بُعد في المحيط وحدها لا تكفي لأمن التطبيقات الحديث. ففي الواقع، يستحيل رؤية كثير من الهجمات على التطبيقات وواجهات API أو إيقافها عند المحيط. يحتاج مركز العمليات إلى رؤية داخل التطبيقات أثناء تشغيلها، لا إلى رؤية البنية التحتية التي تستضيفها فحسب. ثانياً، ينبغي إعطاء الأولوية لأدلة التشغيل على النتائج النظرية، والتركيز على الثغرات الموجودة في الشيفرة النشطة، وتحديد مسارات الهجوم الفعلية والخدمات المكشوفة التي يجري تنفيذها حقاً في الإنتاج. وأخيراً، يجب توحيد أمن التطبيقات وهندسة الاكتشاف. لا يمكن لمركز عمليات الأمن في المستقبل أن يواصل التعامل مع التطبيقات باعتبارها صناديق سوداء معتمة. فالتطبيقات أصبحت الآن سطح الهجوم الأساسي، ويجب أن تحظى برؤية من الدرجة الأولى أثناء التشغيل.

شكراً على هذه المقابلة الرائعة. يمكن للقراء الراغبين في معرفة المزيد زيارة OWASP أو Contrast Security.