زيد الحماني، الرئيس التنفيذي ومؤسس شركة 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 – وكانت تجربتنا حتى ذلك الحين هي أن تقنيات الأمان في وقت التشغيل كانت صعبة الصيانة وغير فعالة. تصورنا طريقة حيث يمكن استبدال جدران الحماية بحل أكثر دقة وأسهل في الصيانة – من خلالstrumenting التطبيق.

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

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

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

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

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

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

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

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

لم يكن لدينا حلاً لذلك. كانت مكدسة DevSecOps التي بنيناها على مدار عقد من الزمن لا تملك إجابة لهذا.

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

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

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

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

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

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

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

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

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

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

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

الجهاز نفسه الذي يحمل هذه البيانات يتصفح أيضًا الإنترنت ويثبت ملحقات VS Code العشوائية.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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