لنكن صادقين: غالبًا ما تبدو أدوات الأمان وكأنها تحاول اللحاق بالركب، خاصة عند مقارنتها بالأدوات الأنيقة والبديهية التي يستخدمها المطورون كل يوم. ويتعامل المطورون اليوم بالفعل مع السرعة والابتكار والتوقعات المتزايدة لـ “البناء الآمن”. ومعظمهم لم يتدربوا حتى على هذا الجزء الأخير.
عندما تسبب أدوات الأمان احتكاكًا، أو تولد ضوضاء، أو ببساطة لا تكون متاحة في الزمان والمكان المناسبين، فإن الاعتماد يعاني. يشعر المطورون بالإحباط. يتم تجاهل التنبيهات.
قارن ذلك بـ GitHub Copilot. وقد شهدت اعتماداً مذهلاً، حيث بلغ عدد المستخدمين النشطين شهريًا أكثر من 15 مليونًا في عام 2025، أي بزيادة قدرها 4 أضعاف على أساس سنوي منذ إطلاقها. هذا النوع من الخبرة السهلة والمعززة للتدفق هو ما يجب أن تطمح إليه أدوات الأمان. إنه يثبت ما هو ممكن عندما تساعد الأداة المطور يوميًا بدلاً من إعاقته.
هذه المقالة لا تتعلق فقط بالإشارة إلى ما تم كسره. إنها بداية سلسلة من أربعة أجزاء حول كيفية إعادة التفكير في الأمان من خلال عدسة تجربة المطورين. في هذه المشاركة الأولى، سنضع رؤيتنا ومبادئنا الأساسية. ستوضح المنشورات الثلاثة التالية كيفية قيام Wiz بإحياء هذه الرؤية، خطوة بخطوة، عبر رحلة المطور: في IDE، وفي طلبات السحب وخطوط الأنابيب، وفي بوابة Wiz.
لا تزال أدوات AppSec عالقة في الماضي
النظام البيئي AppSec التقليدي، على وجه الخصوص أدوات مثل SAST، لم يتم تصميمه لكيفية بناء الفرق الحديثة للبرامج. تعمل هذه الأدوات بشكل منفصل، وتحلل التعليمات البرمجية دون فهم كيفية تصرف هذه التعليمات البرمجية بمجرد نشرها. أنها تفتقر إلى التحقق من صحة وقت التشغيل. إنهم يفتقرون إلى السياق.
يؤدي هذا إلى إنشاء نقاط عمياء عبر SDLC. غالبًا ما ينتهي الأمر بفرق الأمان والسحابة إلى العمل في صوامع متوازية، أو تكرار الجهود أو إغفال العلاقات المهمة بين التعليمات البرمجية والبنية التحتية وسلوك وقت التشغيل.
النتيجة؟ موجة من الإيجابيات الكاذبة والضوضاء التي تطغى على المطورين. لنأخذ مثالاً كلاسيكيًا: يقوم ماسح ضوئي SAST بوضع علامة على ثغرة أمنية في حقن SQL، ولكن في الواقع، يتم تطهير الإدخال بشكل أكبر في المكدس. من منظور التعليمات البرمجية فقط، تبدو النتيجة صالحة، ولكن من منظور وقت التشغيل، فهي غير قابلة للاستغلال. يرفض المطورون هذه النتائج باعتبارها نتائج إيجابية كاذبة. ولكن ماذا يحدث عندما يتغير منطق التعقيم هذا لاحقًا؟ وبدون سياق مشترك بين SDLC، يصبح الخطر النظري حقيقيًا، ولا يتوقع أحد حدوثه.
تبديل السياق مكلف
فكر الآن في عدد الأدوات التي يجب على المطور لمسها فقط لإجراء تغيير، مثل إضافة فاصلة منقوطة إلى السطر 11 في app.js، إلى الإنتاج. إنهم يقومون بمراجعة طلبات السحب، والتحقق من خطوط أنابيب CI، والتحقق من تأثير وقت التشغيل، والتبديل بين الأنظمة الأساسية لحل أي مشكلات. كل واحدة من تلك القفزات تحمل تكلفة عقلية.
العدد المثالي لمفاتيح السياق للتحقق من التغيير الآمن؟ صفر.
من الناحية العملية، يتنقل معظم المطورين بين اتساع نطاق الأدوات وحلقات الملاحظات المنعزلة التي تقطع تدفقهم. وكلما أصبحت هذه العملية أكثر تعقيدًا، زاد احتمال تخطي التوجيهات الأمنية أو تهميشها.
لقد رفعت السحابة الأصلية والذكاء الاصطناعي المستوى
يتوقع مطورو اليوم الأتمتة بشكل افتراضي. تعمل أدوات هندسة المنصات على تجريد التعقيد. يكتب GitHub Copilot ومساعدو الذكاء الاصطناعي المماثلون تعليمات برمجية معيارية، ويضعون علامة على الأخطاء، بل ويقترحون اختبارات في الوقت الفعلي. أنها تتناسب مع تجربة المطور؛ كل علامة تبويب يتم تحديدها تجعلهم يتقدمون بمزيد من التعليمات البرمجية، ولهذا السبب يتم اعتمادهم.
وعلى النقيض من ذلك، لم يستمر الوضع الأمني. نفس الذكاء الاصطناعي الذي يسرع عملية التطوير يعمل أيضًا على تسريع سطح المخاطر. عندما يتمكن المطورون من إنشاء مئات الأسطر من التعليمات البرمجية في دقائق، فإن التكوينات الخاطئة الجديدة أو التسريبات السرية أو الحزم الضعيفة تزداد بمعدل متناسب. وبدون الأمان الذي يتسم بنفس القدر من السرعة والتكامل والبديهية على حد سواء، فإن الفجوة بين التعليمات البرمجية المكتوبة والتعليمات البرمجية الآمنة سوف تستمر في التزايد.
في Wiz، نعتقد أن الأمان يجب أن يكون جزءًا أصليًا من تجربة المطورين، بدءًا من السطر الأول من التعليمات البرمجية وحتى نشر الإنتاج. وهذا يعني إعادة التفكير في كيفية ظهور الأدوات في سير عمل المطورين وما يبدو عليه “الأمان القابل للاستخدام” حقًا. فيما يلي خمسة مبادئ نتبعها.
1. “البدء الآمن” باستخدام الإعدادات الافتراضية الآمنة والأزرار السهلة
أفضل مشكلة أمنية هي المشكلة التي لا يتعين عليك إصلاحها أبدًا. لا ينبغي ترك المطورين يتحملون المسؤولية عن المخاطر التي لم يقدموها، مثل الصور الأساسية غير الآمنة، أو إعدادات خطوط الأنابيب الضعيفة، أو الأسرار غير المشفرة.
“البدء بشكل آمن” يعني منح المطورين أساسًا متينًا بشكل افتراضي. لهذا السبب ويزو، لدينا صورة صلبة ومتوافقة مع FIPS وخالية من CVE. لا ينبغي أن يحتاج المطورون إلى الاشتراك في الأمان؛ يجب أن يبدأوا من مكان يكون فيه الأمان هو الوضع الافتراضي، وليس الاستثناء.
الأزرار السهلة مهمة أيضًا. سواء كانت سياسة معدة مسبقًا، أو اقتراح إصلاح بنقرة واحدة، أو خطاف الالتزام المسبق الذي يشير إلى سر مسرب قبل أن يصل إلى GitHub، يجب أن يبدو الأمان وكأنه يد مساعدة، وليس عقبة إضافية.
2. الدرابزين بدلا من البوابات
الأمان الذي يعيق التقدم هو الأمان الذي يتم تجاوزه. لا يستجيب المطورون بشكل جيد للسياسات الصارمة التي تفشل في إنشاء المشكلات ذات الأولوية المنخفضة، خاصة عندما لا يكون لهذه المشكلات مسار استغلال حقيقي.
نحن نمنح الفرق السيطرة الكاملة على الطريقة التي يريدون بها فرض الأمن، سواء كان ذلك الحظر يعتمد على مكافحة التطرف العنيف الحاسم أو توفير إرشادات بسيطة للمشكلات متوسطة المخاطر. يسمح محرك السياسة الموحد الخاص بنا للمؤسسات بتحديد حدود المخاطر، وتطبيقها بشكل متسق عبر بيئات التطوير المتكاملة، وطلبات السحب، وCI/CD، وتذكر المشكلات التي تم فرزها أو إصلاحها أو تجاهلها، حتى لا يعلق المطورون في الحلقات.
ومن خلال التوجيه بدلاً من المنع، يصبح الأمن متعاوناً، وليس عنق الزجاجة.
3. “الأقل هو الأكثر” للمطورين
تجربة المطور الرائعة لا تثقل كاهلك بالمعلومات. فهو يخبرك بما يهم، عندما يكون الأمر مهمًا، ويبتعد عن الطريق.
ولهذا السبب نركز على تعليقات أمنية واضحة ومحدودة، مثل تعليق طلب سحب من سطر واحد يشرح الثغرة الأمنية وكيفية تأثيرها على تطبيقك، بالإضافة إلى رابط للإصلاح التلقائي. لا يوجد تفريغ لبيانات مكافحة التطرف العنيف الخام. يكفي فقط لفهم التأثير واتخاذ الإجراءات اللازمة.
خلف الكواليس, كود ويز يكتشف تلقائيًا SDLC الكامل: مستودعات VCS، وخطوط أنابيب CI، والبنية التحتية كرمز، وسجلات الحاويات، وعمليات النشر السحابية. لا يتعين على المطورين تكوين أي شيء يدويًا أو البحث عن السياق؛ نحن نربط النقاط لهم، من الالتزام الأول إلى الإنتاج.
4. تحدث بنفس اللغة: الرسم البياني الأمني
غالبًا ما يستخدم الأمان والمطورون أدوات مختلفة، ويعرضون مقاييس مختلفة، ويصممون التطبيقات بطرق مختلفة تمامًا. يؤدي هذا الانفصال إلى الارتباك وعدم التوافق والمخاطر الضائعة.
ال الرسم البياني الأمني ويز يغير ذلك. فهو يصمم التطبيق الكامل، بدءًا من عناصر التعليمات البرمجية وحتى أعباء العمل والأسرار وأدوار IAM وقواعد البيانات ونقاط النهاية العامة، ويرسم خرائط للعلاقات بينها. وتصبح لغة مشتركة للأمان والهندسة لفهم كيفية عمل التطبيق وما يرتبط به وما هو معرض للخطر.
يمكن للمطورين تتبع التكوين الخاطئ مرة أخرى إلى ملف Terraform الذي قام بنشره. يمكن لفرق الأمن معرفة ما إذا كانت ثغرة أمنية في التعليمات البرمجية (على سبيل المثال، كل من CVEs وCWEs) يمكن الوصول إليها من الإنترنت أو تم تخفيفها بالفعل في المنبع. الجميع يعمل وفقًا لنفس النموذج، وهذا ما يكسر الصوامع.
5. تبديل السياق صفر
أقوى طريقة لتقليل الاحتكاك هي مقابلة المطورين أينما كانوا بالفعل.
ولهذا السبب يتكامل Wiz Code في IDE للفحص في الوقت الفعلي، وسير عمل VCS مثل طلبات السحب، وعلامات التبويب GitHub وGitLab Security. لا داعي للانتقال إلى لوحات معلومات منفصلة أو تعلم واجهات جديدة. مجرد تعليقات أمنية قابلة للتنفيذ وفي الوقت المناسب من خلال أدوات مألوفة.
نقوم أيضًا بالأتمتة قدر الإمكان، وإنشاء طلبات سحب لإصلاح مشكلات التبعية، وتتبع تغطية الفحص تلقائيًا، وإرسال إشعارات تلقائية عند ظهور مخاطر جديدة. يحتاج المطورون فقط إلى التدخل عندما يكون الأمر مهمًا.
وهذه ليست رؤية بعيدة. لقد قمنا بالفعل بإضفاء الحيوية على هذا النهج الذي يعتمد على المطور أولاً عبر كل طبقة من طبقات SDLC باستخدام Wiz Code، وهو يتطور بسرعة. هذا هو الأساس لمشاركات المدونات الثلاث التالية في هذه السلسلة، حيث سنتعمق في كل جزء من رحلة المطور:
ما يلي هنا هو معاينة صغيرة لكيفية تنفيذ هذه التجربة عبر SDLC.
الجزء 2. في IDE
يجب أن يبدو الأمان فوريًا ومتكاملًا مثل “الإكمال التلقائي”، ولهذا السبب توفر Wiz Code أمانًا في الوقت الفعلي داخل المحرر يساعد المطورين على إصلاح المخاطر قبل أن يغادر الكود أجهزتهم.
سنستكشف اقتراحات المسح في الوقت الفعلي والإصلاحات المدعومة بالذكاء الاصطناعي مباشرةً في VS Code وJetBrains (الآن قيد المعاينة) والخطافات المسبقة لالتقاط الأسرار قبل أن يصل الكود إلى التحكم في الإصدار. سنراجع أيضًا كيفية قيام Wiz بتبسيط عملية الإعداد والإعداد، بدون رموز API المميزة أو توفير معقد.
الجزء 3. في نظام التحكم في الإصدار (VCS) وخطوط أنابيب CI/CD
من خلال تضمين حواجز الحماية مباشرة في مراجعات التعليمات البرمجية وبناء سير العمل، يضمن Wiz Code حدوث الأمان في التدفق الطبيعي للتطوير، دون إبطاء الإصدارات.
سنرى كيف يتم عرض النتائج في تعليقات العلاقات العامة وعلامات التبويب والتقارير في GitHub أو GitLab Security، مع تدفقات الإصلاح بنقرة واحدة ودعم لتحديد المشكلات أو تجاهلها بشكل مضمّن أو عبر ملفات التكوين .wiz.
يفرض Wiz Code سياسات الأمان عبر البيئات المحلية وبيئات خطوط الأنابيب باستخدام Wiz CLI الموحد. يمكن للفرق تخصيص حدود المخاطر لكل مشروع أو إعادة شراء، والفشل في البناء فقط عندما يكون ذلك مهمًا، وضمان الاتساق دون إدخال تعقيدات جديدة.
الجزء 4. في بوابة الحذق
من خلال طرق العرض المخصصة للمطورين وتتبع التقدم، سنرى كيف يحول Wiz الأمان من مهمة في الخلفية إلى إنجاز مشترك ومرئي عبر الأفراد والفرق.
يمكن للمطورين استكشاف لوحات المعلومات المخصصة التي توضح اتفاقيات إعادة الشراء التي يمتلكونها، والمخاطر التي تؤثر عليهم، والتقدم الذي يحرزونه بمرور الوقت. يتيح لهم دور المطور الجديد العمل بشكل مستقل داخل Wiz، في حين أن “مركز البطل” يحتفل بمعالم مثل “صفر أسرار في الريبو” أو “صفر مكافحة التطرف العنيف الحرجة مع الإصلاح.” التبني مرئي وقابل للقياس ومحفز.
تعكس هذه التجارب معًا إيماننا الأساسي: يجب أن تقلل الأدوات الأمنية من الجهد المبذول، لا أن تضيف إليه. يجب عليهم مساعدة المطورين على البناء بشكل آمن بشكل افتراضي، وليس مطالبتهم بأن يصبحوا خبراء في الأمان.
لا ينبغي لأدوات الأمان أن تقوم بالمسح فقط. ينبغي أن يرشدوا. يجب أن يساعدوا في الإصلاح. وينبغي عليهم تسريع عملية التنمية، وليس إبطائها.
في Wiz، نقوم بإعادة بناء إدارة وضع أمان التطبيقات (ASPM) من الألف إلى الياء، مع خبرة المطورين في المركز. لأنه إذا لم يستخدم المطورون لديك أداة أمنية، فلا يهم مدى قوتها.
لقد بدأنا للتو. ترقبوا مدونة Wiz لمعرفة الأقساط القادمة.
