زيد الحماني، الرئيس التنفيذي ومؤسس شركة Boost Security – سلسلة المقابلات

زيد الحماني، الرئيس التنفيذي ومؤسس شركة Boost Security، هو قائد في مجال الأمن السيبراني و DevSecOps مع أكثر من عقدين من الخبرة في بناء وتوسيع عمليات التكنولوجيا العالمية. منذ تأسيسه لشركة Boost Security في عام 2020، ركز على تحديث كيفية حماية المنظمات لتطوير البرمجيات، مستنداً إلى أدوار سابقة بما في ذلك نائب الرئيس للأمن التطبيقي في Trend Micro و شريك مؤسس ومدير تنفيذي لشركة IMMUNIO. في وقت سابق، شغل مناصب قيادية في شركة Canonical، حيث قاد مبادرات المنتج والهندسة والدعم العالمي، وفي شركة SITA، حيث قام بإدارة عمليات تكنولوجيا المعلومات على نطاق كبير وحساسة للغاية. يعكس مساره المهني سجلاً قوياً في بناء الفرق وتنظيم الأنظمة وتحديث ممارسات الأمن الحديثة.

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

كنت قد قادت الأمن التطبيقي في Trend Micro و共同 تأسيس IMMUNIO. ما الذي دفعك إلى تأسيس شركة Boost Security، وما هو الفراغ في السوق الذي كنت في وضع فريد لتحديده في وقت مبكر؟

كانت IMMUN.IO واحدة من أولى الشركات التي طورت تقنية RASP – وكانت خبرتنا حتى ذلك الحين هي أن تقنيات الأمان في وقت التشغيل كانت صعبة الصيانة وغير فعالة. تصورنا طريقة يمكن فيها استبدال جدران الحماية بحل أكثر دقة وأسهل في الصيانة، من خلال仪mentation التطبيق.

كان ذلك في عام 2012، وكان DevOps لا يزال في بداياته، ولم تكن معظم الفرق تتبع ممارسات Agile، ولم تكن Kubernetes موجودة بعد.

استحوذت Trend Micro على IMMUN.IO في عام 2017. في ذلك الوقت، كان هناك المزيد من ممارسات DevOps: خطوط أنابيب CI/CD، وممارسات التطوير Agile، ودورات إطلاق أسرع. كانت فرق تطوير البرمجيات أفضل في بناء البرمجيات، وإطلاقها بسرعة. كان الأمن مازال معطلاً:

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

كان من السهل إنتاج برمجيات بسرعة. لكن إنتاج برمجيات آمنة بسرعة كان لا يزال صعباً.

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

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

لقد جادلتم بأن دورة حياة تطوير البرمجيات (SDLC) قد تغيرت بشكل جذري في اتجاه مجرى النهر. ما هو اللحظة التي أدركتم فيها أن النهج التقليدية ل DevSecOps لم تكن كافية بعد الآن؟

كان ذلك بمشاهدة كيف كان المهاجمون يخترقون فعلاً. لقد استمرنا في رؤية نفس النمط: تدفق عمل GitHub المعرض الذي لم يُ-reviewed منذ فورك المستودع، رمز مع حق الوصول إلى السحابة الإنتاجية المضمنة في تكوين تشغيل، وظيفة CI شرعية محجوزة لنشر حمولات المهاجم. أصبحت هذه معروفة باسم “هجمات العيش من خط الأنابيب”، لأن الخصم يستخدم تلقائياً ضدك، مع بيانات اعتماد التي أقرها فريق الأمن بالفعل.

لم يكن لدينا حزمة DevSecOps التي بنيناها على مدار عقد من الزمن أي जवاب لذلك. يفحص SAST مصدر التطبيق. يفحص SCA الاعتماديات التطبيق. يفترض كلاهما أن خط الأنابيب الذي يديرهما موثوق.

في هذه الأثناء، يكون خط الأنابيب نفسه عبارة عن ملف YAML مع أوامر shell ووصول شبكة ومعلومات اعتماد حساسة، و几乎 لا أحد يراجعها.

عندما يصبح ذلك أسهل طريق للمهاجم، يمكنك شحن كود نظيف تماماً ومازال تمنح المهاجمين سحابتك.

كيف يجب على الشركات إعادة التفكير في SDLC في عالم حيث يولد وكلاء الأعمال كوداً بشكل مستمر بدلاً من كتابة المطورين خطوة خطوة؟

يجب أن نوقف التفكير في SDLC كتسلسل من نقاط التفتيش. لقد قام وكلاء الأعمال بضغط الوقت بين “كتب شخص ما هذا” و “هذا في الإنتاج” من أسابيع إلى دقائق. افترض النموذج القديم إيقاعاً بشرياً بين مراجعة الكود، و SAST، و SCA، و النشر، ولكننا متجاوزون ذلك الآن.

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

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

يعامل أداة الترميز الألي كطبقة إنتاجية هو مثل معاملة مطور مبتدئ مع حق الوصول إلى الجذر كطبقة إنتاجية. الوصف دقيق تقنياً، لكنه لا يمنحك إطاراً مفيداً للتفكير في ما يمكن أن ي goes wrong.

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

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

تحدد شركة Boost جهاز المطور كخطة التحكم الجديدة. ما هي المخاطر التي توجد في النقطة النهائية التي يغفل عنها فرق الأمن حالياً؟

الأكبر هو الجرد. لا يستطيع معظم أفراد فرق الأمن أن يخبروك بأي وكلاء ألي يعملون على أي أجهزة محمولة، أو أي خوادم MCP يتصل بها هؤلاء الوكلاء، أو أي امتدادات IDE تقرأ محتوى المستودع الآن. لا تملك EDR أي رؤية في طبقة الوكيل؛ ولا يمكن لـ SIEM رؤية ما يفعله هؤلاء الوكلاء محلياً. إنه مشكلة تكنولوجيا الظل مع صلاحيات تنفيذ الكود.

تحت ذلك يقع فوضى المعلومات الضرورية. بنينا أداة مفتوحة المصدر تسمى Bagel جزئياً لجعل هذا ملموساً. تحتوي جهاز المطور النموذجي على رموز GitHub مع حق الوصول إلى المستودعات الإنتاجية، وبيانات اعتماد السحابة التي يمكنها تشغيل البنية التحتية، ورموز npm أو PyPI التي يمكن نشرها إلى ملايين المستخدمين، ومفاتيح خدمة الأعمال التي يمكن للمهاجمين إعادة بيعها. لا يتم حماية أي من هذه المعلومات الضرورية بنفس الطريقة التي يتم بها حماية تشغيل CI. نفس الجهاز الذي يحتوي على هذه المعلومات الضرورية cũng يتصفح الويب ويثبت امتدادات VS Code العشوائية.

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

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

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

يبدأ مشكلة الكشف لأن حركة المرور من تسرب يبدو متطابقة مع استخدام المنتج العادي. إنه TLS إلى api.openai.com أو api.anthropic.com. يأتي من تطبيق أعمال معتمد. يرى DLP العادي المطور يستخدم أداة الأعمال التي اشترت الشركة ترخيصاً لها. لا يرى أن أحد السلاسل في ذلك البرومت هو مفتاح سري لشركة Amazon الذي قام الوكيل بقراءته من ملف .env نسي في ديركتوري شقيق.

يمكنك فقط ملاحظته من خلال فحص البرومت قبل مغادرة جهاز المطور، وهو بالضبط حيث لا يوجد حالياً أي حزمة أمنية.

هل يمكنك أن تشرح سيناريو واقعي حيث يقدم وكيل الأعمال ثغرة أمنية أسرع من قدرة أدوات الأمن التقليدية على تحديدها؟

هنا سيناريو رأينا تحورات منه بشكل متكرر. يطلب المطور من الوكيل إضافة ميزة تحتاج إلى مكتبة إعادة محاولة HTTP. يقترح الوكيل اسم الحزمة. الحزمة تبدو معقولة ولا tồn على npm. في غضون ساعة، يسجل المهاجمها، ويملأها بمحاولة إعادة منطقية تعمل بالإضافة إلى سكريبت ما بعد التثبيت الذي يقرأ ~/.aws/credentials وينشر المحتوى إلى webhook. يعمل الوكيل npm install بدون التحقق، لأن الوكلاء لا يتحققون من السمعة. وقد فُقدت بيانات الاعتماد قبل أن ي chạy المطور حتى الكود.

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

نافذة النشر حتى الاعتداء الآن تقاس بالدقائق. أي شيء يتحقق بعد الحادث يتحقق متأخراً جداً.

هل أصبحت الاعتماديات الموهومة واحدة من أكبر المخاطر في التطوير الموجه بالأعمال، وما هي الخطوات العملية التي يمكن للمنظمات اتخاذها للدفاع عنها؟

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

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

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

لقد قلت إن الأمان لا يمكن أن يبدأ في CI/CD بعد الآن. ما يشبه خط أنابيب الأمان الحديث عندما يحتاج الحماية إلى البدء في وقت سابق في عملية التطوير؟

إذا بدأ الأمان في CI/CD، فقد استسلمت بالفعل لمرحلة ما قبل الالتزام لبيئة لا تتحكم فيها. لقد استهلك الوكيل بالفعل السياق، وربما تكون بيانات الاعتماد الخاصة بك قد تم تسريبها بالفعل. أنت تقوم بفحص جثة.

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

خط الأنابيب نفسه لا يختفي. دوره يصبح التحقق: التأكد من أن التحكمات في مجرى النهر تم الحفاظ عليها.

مع استمرار المنظمات في تبني وكلاء الترميز الألي، ما هي التغييرات الأكثر أهمية التي يجب أن يقوموا بها اليوم لضمان أن بيئات التطوير الخاصة بهم تبقى آمنة خلال السنوات القليلة القادمة؟

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

مرتبط chặt chẽ: أوقف معاملة وكلاء الترميز كبرمجيات إنتاجية. هم مستخدمون غير بشريين مع حق الوصول إلى shell، وامتيازات كتابة المستودع، واتصالات شبكة خروجية. حكمهم بنفس الطريقة التي تحكم بها أي هوية مفوضة أخرى، مع جرد، وسماحيات معتمدة، وسجلات مراجعة.

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

شكراً على المقابلة الرائعة، يرغب القراء في معرفة المزيد فيزيون شركة Boost Security.