تشير سلسلة توريد البرامج إلى كل شيء وكل شخص متصل بكود البرنامج الخاص بك بطريقة ما طوال دورة حياة التطوير. يتكون كل جزء من البرنامج من عدة مكونات. بالإضافة إلى التعليمات البرمجية الخاصة المكتوبة من الصفر، تتطلب التعليمات البرمجية أيضًا بنية تحتية خارجية للبرامج والخدمات السحابية وأنظمة التشغيل للعمل بشكل صحيح. تعد السجلات والمستودعات وقواعد التعليمات البرمجية وحتى الأشخاص الذين كتبوا هذا البرنامج جزءًا من سلسلة توريد البرامج.
تمثل كل عقدة في هذه السلسلة المعقدة نقطة ضعف محتملة قد تؤثر على أداء وأمان برنامجك في بعض النواحي. إن الثغرات الأمنية التي يتم تقديمها في أي نقطة على طول سلسلة التبعية هذه لها تداعيات خطيرة. وذلك لأن تعقيد سلسلة توريد البرامج يخفي المخاطر ويجعل من الصعب التنبؤ بها وتحديدها بدون إطار موحد لتأمين سلسلة التوريد. ولهذا السبب من المهم للمطورين ومؤسسات المنتجات أن يفعلوا ذلك تعلم ما هو أمن سلسلة توريد البرمجيات.
يشير أمان سلسلة توريد البرامج إلى مجموعة الممارسات القياسية الموضوعة لحماية برنامجك من نقاط الضعف المحتملة عبر دورة حياة تطوير البرامج بدءًا من نقطة تطوير التطبيقات ومن خلال التكامل والنشر المستمر (خط أنابيب CI/CD).
من المهم أن تفهم فرق الأمان قائمة أفضل ممارسات أمان سلسلة توريد البرامج وتتبعها من أجل الحفاظ على أمان سلسلة توريد برامج مؤسستهم. يعرض هذا المنشور تفاصيل أفضل ممارسات سلسلة التوريد التي يجب أن تعرفها.
- أفضل الممارسات لتأمين سلسلة توريد البرامج لديك
- الحصول على مكونات مؤمنة بشكل جيد
- قم بإنشاء مكونات برامج آمنة داخليًا تلتزم بممارسات الترميز الآمنة
- استخدم سلاسل أدوات البرامج الآمنة التابعة لجهات خارجية ومكتبات التوافق
- التخفيف من تعديل أو استغلال كود المصدر من قبل المطلعين
- قم بتخزين الكود أو الملفات التنفيذية ومراجعة جميع التغييرات قبل الموافقة عليها
- إنشاء وصيانة SBOM لكل حزمة برامج تم إنشاؤها
- تصلب بيئة البناء
- قم بتحليل كل ثغرة لجمع المعلومات الكافية للتخطيط لعلاجها
- صيانة المكونات
أفضل الممارسات لتأمين سلسلة توريد البرامج لديك
يشير هذا القسم إلى الممارسات القياسية التي يتعين على المطورين ومؤسسات المنتجات اتباعها لتأمين سلسلة توريد البرامج الخاصة بهم. يمكنك استخدام هذه الإرشادات كإطار أساسي لوصف وتقييم وقياس الممارسات الأمنية لمؤسستك خلال المراحل المختلفة من دورة حياة برنامجك. تتقاطع أفضل الممارسات هذه مع مرحلة الاستحواذ والتطوير والنشر لسلسلة توريد البرامج لضمان سلامة بيئة التطوير الخاصة بك، والتعليمة البرمجية المصدرية، والمنتج النهائي.
الحصول على مكونات مؤمنة بشكل جيد
يعد دمج مكونات الطرف الثالث في البرامج ممارسة قياسية للمطورين، حيث يتيح لهم ذلك الاستفادة من إمكانات واجهة برمجة التطبيقات الحالية لتقديم الوظائف المطلوبة بدلاً من البناء من الصفر. يمكن أن تكون مكونات الطرف الثالث إما في شكل برامج تجارية مملوكة أو أدوات مجانية مفتوحة المصدر. عند تحديد مصدر لأي من هذه المكونات، من المهم أن تعتبر الأمان أحد أهم المعايير التي يجب أن يستوفيها مكون البرنامج.
لتحديد أمان مكونات الطرف الثالث، قد تحتاج إلى إجراء تحليل أمني متقدم مثل تحليل التركيب الآمن، وتحليل قاعدة بيانات الثغرات الأمنية، وتقييم التعليمات البرمجية المصدر، وتحليل تقييم المخاطر. ستساعد نتيجة عمليات التحقق هذه في تحديد ما إذا كان هذا المكون آمنًا ويجب السماح به لمنتجك
بالإضافة إلى ذلك، تحتاج المكونات المحددة إلى المراقبة بشكل مستمر باستخدام خدمة تتبع الثغرات الأمنية التلقائية لتحديد نقاط الضعف في أسرع وقت ممكن وإزالتها على الفور.
قم بإنشاء مكونات برامج آمنة داخليًا تلتزم بممارسات الترميز الآمنة
على الرغم من أهمية مكونات البرامج الخارجية المدمجة في برنامجك، إلا أن أمان منتجات البرامج وسلامتها يعتمدان أيضًا على ممارسات الترميز الآمن التي تتبعها داخل الشركة.
تحتاج كل مؤسسة إلى إطار عمل شامل لدورة حياة تطوير البرمجيات يتضمن ممارسات ترميز آمنة لضمان توافق العناصر التي تم إنشاؤها مع الإرشادات المنصوص عليها.
في البداية، تعتمد سلامة منتجاتك البرمجية والأدوات التي تصنعها داخل الشركة على جودة فريقك. يجب أن يضم فريق التطوير الخاص بك خبراء تطوير، وضمان الجودة، ومتخصصين في الأمن السيبراني، وبناء مهندسين يتمتعون بمعرفة جيدة بممارسات الأمان القياسية.
يجب أن يشمل فريق إدارة المنتج أيضًا مهندسي الأمان ومديري المنتجات وقادة المنتجات الذين يعملون على ضمان الامتثال لسياسات التطوير الآمنة. تتضمن بعض الاستراتيجيات الأساسية للتأكد من إنشاء عناصر برمجية آمنة داخل الشركة ما يلي:
- إنشاء وثائق التصميم والهندسة المعمارية لكل قطعة أثرية
- إنشاء نماذج التهديد للمنتجات البرمجية
- تحديد وتنفيذ الاختبارات الأمنية
- وضع معايير إصدار محددة لتقييم المنتج
- وضع سياسات التعامل مع الثغرات الأمنية لكل منتج
- توثيق ونشر الإجراءات الأمنية لكل إصدار برمجي
استخدم سلاسل أدوات البرامج الآمنة التابعة لجهات خارجية ومكتبات التوافق
العديد من بيئات التطوير المتكاملة (IDE) المستخدمة في عملية تطوير البرمجيات مستقلة بذاتها. وهذا يعني أنها تسمح لك بتنفيذ خطوات مختلفة ضمن عملية التطوير مثل البرمجة، والتجميع، والتعبئة، وتصحيح الأخطاء البرمجية - كل ذلك من نفس الأداة. تحتوي بعض IDEs أيضًا على أدوات لتوصيل المصدر بمستودع خارجي. تدعم IDEs التي تحتوي على هذه الوظيفة لغات مترجم متعددة. بالإضافة إلى هذه الوظائف الأساسية، قد يتمكن المطورون من توسيع قدرات IDE التي يستخدمونها مع المكونات الإضافية. يعد هذا مصدرًا محتملاً للضعف بالنسبة لبيئة التطوير المحلية، نظرًا لتعقيد المصادر غير الموثوقة مثل هذا.
من أجل الحفاظ على بيئة التطوير الخاصة بك آمنة، يجب تدقيق جميع بيئة التطوير المتكاملة والمكونات الإضافية التي سيتم استخدامها داخل البيئة والموافقة عليها مسبقًا بعد فحصها بحثًا عن نقاط الضعف والتحقق من صحتها.
بالإضافة إلى المكونات الإضافية التي تعمل على توسيع إمكانيات بيئة البناء الخاصة بك، هناك فئة أخرى من أدوات البناء التابعة لجهات خارجية والتي قد تحتاج إليها للتحقق من وجود ثغرات أمنية وهي سلاسل أدوات البرامج ومكتبات التوافق. يتم تثبيت أدوات نظام التشغيل التابعة لجهات خارجية في بيئة التطوير للسماح لك باستخدام أدوات مساعدة وأوامر محددة فريدة لنظام التشغيل هذا. على سبيل المثال، قد تتطلب بيئة تطوير Windows بعض أوامر نظام التشغيل الفريدة لنظام التشغيل Linux أثناء عملية الإنشاء من أجل توفير التوافق بين كلا النظامين أثناء عملية الإنتاج.
وبالمثل، تساعدك مكتبات تحويل API أيضًا على إنشاء بيئة ترميز مشتركة لنظامي تشغيل مختلفين. تعد سلاسل أدوات واجهة برمجة التطبيقات (API) أدوات مفتوحة المصدر وتجارية ويجب الوصول إليها بحثًا عن نقاط الضعف قبل اعتمادها في بيئة البناء الخاصة بك واستخدامها في مشروعك.
التخفيف من تعديل أو استغلال كود المصدر من قبل المطلعين
وفقًا لوكالة الأمن السيبراني وأمن البنية التحتية (CISA)، فإن الشخص المطلع هو أي شخص لديه حق الوصول المصرح به أو المعرفة بموارد المنظمة. يمكن للأفراد الذين لديهم أو تمكنوا من الوصول إلى المرافق والشبكات والمعدات والأنظمة الخاصة بك أن يعرضوا سلامة منتج البرنامج الخاص بك للخطر، سواء عن قصد أو عن غير قصد.
كجزء من الجهود المبذولة لتأمين البرنامج الخاص بك، يجب عليك التأكد من أن عملية التطوير لديها سياسات معمول بها لمنع التعرض المتعمد أو غير المتعمد للتعليمات البرمجية الضارة في رمز الإنتاج الخاص بك من قبل المطلعين مثل الموظفين المخترقين، أو المهندسين ذوي التدريب السيئ، أو الموظفين غير النشطين. بعض التدابير التي يمكنك اتخاذها للتخفيف من ذلك تشمل:
- عملية تسجيل وصول متوازنة وموثقة لرمز المصدر
- المسح الأمني الآلي لنقاط الضعف
- التدريب على تطوير البرمجيات الآمنة
- تصلب بيئة التطوير
- تحديد أولويات مراجعات الكود
قم بتخزين الكود أو الملفات التنفيذية ومراجعة جميع التغييرات قبل الموافقة عليها
يعد تعيين الإصدار أحد الممارسات القياسية التي يمكن أن تساعد في الحفاظ على سلامة برنامجك. كجزء من عملية التكامل والنشر المستمر (خط أنابيب CI/CD)، ستحتاج إلى الاحتفاظ بمستودع لتخزين التعليمات البرمجية والملفات التنفيذية الخاصة بك. يوفر هذا سجل عمل للتعليمات البرمجية الخاصة بك حتى تتمكن بسهولة من تتبع ما حدث في حزمة التطوير حتى تلك النقطة.
ستحتاج أيضًا إلى نظام موافقة مستمر لمراجعة جميع التغييرات التي يتم إجراؤها على برنامجك قبل الموافقة عليها. وهذا مفيد بشكل خاص عند التعاون مع المطورين الآخرين ضمن الفرق. يعد استكشاف المشكلات وإصلاحها أسهل في هذه الحالة حيث يمكنك بسهولة التعرف على التغييرات أثناء إجرائها ومن يقوم بها.
بغض النظر عن مدى بساطة أو تعقيد البرنامج الذي تقوم بإنشائه، فإن نظام التحكم في المصدر أو الإصدار يجعل من السهل رؤية وتتبع جميع التغييرات التي يتم إجراؤها على التعليمات البرمجية الخاصة بك، وتتبع سجل الإصدارات عند الحاجة، أو حتى العودة إلى إصدار سابق من برنامجك. الرمز عند الضرورة.
إنشاء وصيانة SBOM لكل حزمة برامج تم إنشاؤها
إنّ فاتورة مواد البرمجيات هي وثائق حيوية توضح تفاصيل جميع مكونات الطرف الثالث المدمجة في منتج البرنامج الخاص بك. يسهّل SBOM التحقق من صحة جميع المكونات المعتمدة لأحد البرامج وتحديد أي نقاط ضعف أو عيوب بسهولة. بالنسبة لكل حزمة برامج تقوم بإنشائها، يجب عليك أيضًا إنشاء وصيانة SBOM لها.
يمكن إعداد قائمة مواد البرنامج بناءً على المواصفات المحددة في التنسيقات القياسية مثل علامات تبادل بيانات حزمة البرامج (SPDX)، وCycloneDX، وعلامات تعريف البرامج (SWID) كما هو محدد بواسطة Linux، وOWASP، وNIST، على التوالي.
بالنسبة لكل منتج برمجي تقوم بإنشائه، يجب على الموردين أو مالكي مكونات الطرف الثالث التي تستخدمها تقديم قائمة مواد برمجية شاملة. يمكن أيضًا التحقق من صحة تسليمات مشروعك وSBOMs المقدمة من المورد باستخدام أداة تحليل التركيب (SCA).
حتى إذا لم يقدم المورد SBOM، فإن SBOM الذي تم إنشاؤه باستخدام أداة تحليل تكوين البرنامج لا يزال بإمكانه توفير المعلومات المطلوبة لوصف مكونات الطرف الثالث للبرنامج. عملية توليد SBOMs يجب أن تكون آلية. أتمتة SBOM يعد أمرًا حيويًا لأن البائعين والمطورين التابعين لجهات خارجية يحتاجون إلى إنشاء SBOM جديد في كل مرة يتم فيها تعديل برنامج تابع لجهة خارجية، والقيام بذلك يدويًا أمر غير عملي. سوف يصف SBOM المحدث أي تحسينات أو تغييرات في كود المكون وعلاقتها بـ منتج البرنامج.
تصلب بيئة البناء
تتمثل إحدى طرق ضمان سلامة برنامجك في تقوية بيئة التطوير ضد نقاط الضعف المحتملة. يتضمن ذلك كلاً من بيئة التطوير الفردية وبيئة بناء الإنتاج الشاملة.
سواء كانت بيئة البناء الخاصة بك مستضافة في السحابة أو محليًا، فأنت بحاجة إلى تكوينها ووضع التدابير اللازمة لتأمين الخادم والشبكة مع التحكم أيضًا في من يمكنه الوصول إلى ماذا. سيؤدي إجراء العناية الواجبة في تحسين بيئة البناء وتأمينها بهذه الطريقة إلى ضمان سلامة كود المصدر والمنتج النهائي.
يتضمن تأمين مسار الإنشاء تأمين جميع الأنظمة التي تستخدمها أثناء عملية الإنشاء لمنتجك. يتضمن ذلك مستودعات التعليمات البرمجية وخوادم التوقيع ومحطات العمل الهندسية وخوادم النشر وما إلى ذلك. تتضمن بعض الإجراءات التي يمكنك اتخاذها لتأمين البنية التحتية لخط أنابيب البناء الخاص بك ما يلي:
أنظمة القفل
لتأمين أنظمتك، يجب عليك قصر عمليات النظام على وظائف محددة من المفترض أن يؤديها النظام. على سبيل المثال، يجب استخدام نظام البناء الخاص بك فقط لعمليات البناء وليس أي شيء آخر.
الحد من أنشطة الشبكة الخارجية وخارج الشبكة المحلية
من المحتمل أن تعرض أنشطة الشبكة الواردة والصادرة نظامك للخطر الهجمات. يجب عليك حظر جميع الأنشطة الخارجية وخارج الشبكة المحلية وقصر الاتصالات الخارجية على عناوين URL الضرورية.
أنظمة مراقبة تسرب البيانات
لضمان سلامة الكود المصدري لمنتجك، يجب عليك إعداد دفاعات الأمن السيبراني الخاصة بك لحماية مستودعك ومحطة العمل والأجزاء الأخرى من بيئة البناء الخاصة بك من تسلل البيانات وتسللها. يتضمن ذلك حظر جميع السلوكيات الضارة، وعزل التطبيقات، وإعداد أنظمة الكشف لاكتشاف أي تطفل بمجرد حدوثه.
قم بتكوين مسار التحكم في الإصدار الخاص بك
يجب أن يتم التحكم في إصدار التعليمات البرمجية الخاصة بك. عند إجراء أي تغييرات على منتجك، يجب إجراء التحديثات على رمز التكوين وليس على الأنظمة الفعلية.
المصادقة متعددة العوامل
يجب تكوين كل نظام يمثل جزءًا من بيئة البناء الخاصة بك باستخدام مصادقة متعددة العوامل حيثما أمكن ذلك. يجب أيضًا وضع تدابير أمنية إضافية مثل الوصول المستند إلى الأدوار والامتيازات الأقل وما إلى ذلك. توصي إرشادات NIST أيضًا بنظام ترخيص مزدوج لجميع الأنظمة المهمة أو الحساسة في بيئة البناء الخاصة بك.
افصل شبكتك الهندسية
يجب ألا يتم الوصول إلى نظام البناء الخاص بك إلا عبر شبكة هندسية معزولة تختلف عن بقية شبكة مؤسستك. عندما يكون ذلك ممكنًا، يجب أن تكون الشبكة الهندسية غير متصلة بالإنترنت.
قم بتحليل كل ثغرة لجمع المعلومات الكافية للتخطيط لعلاجها
عند تطوير البرامج، يجب اتخاذ التدابير اللازمة لضمان خلو منتجك وجميع مكوناته من نقاط الضعف المعروفة عالية المخاطر. وبالمثل، عندما يكتشف أحد العملاء ثغرات أمنية جديدة أو يبلغ عنها، يجب عليك الاستجابة للحادث على الفور. في بعض الحالات، سيتطلب ذلك منك تحديث نظامك للتخفيف من المخاطر المرتبطة بالثغرة الأمنية المكتشفة حديثًا.
يجب أن يكون لدى بائعي البرامج عملية معمول بها لقبول التحديثات أو التقارير حول نقاط الضعف أو العيوب المحتملة في منتجاتهم، سواء من الباحثين أو العملاء الخارجيين. تحتاج أيضًا إلى أن يكون لديك نظام آلي يُعلمك بتحديثات الثغرات الأمنية التي تعلن عنها المنظمات الموثوقة مثل وكالة الأمن السيبراني وأمن البنية التحتية (CISA).
تحتاج كل مؤسسة إلى سياسة داخلية لإدارة الثغرات الأمنية تتوافق مع الإرشادات القياسية. ينبغي تقييم التنبيهات المتعلقة بالتهديدات عالية الخطورة استنادًا إلى العلاقة بين منتجك ومكوناته التي ربما تأثرت بالثغرة الأمنية المبلغ عنها. يجب أن يكون لدى فريقك الهندسي أيضًا نظام شامل لمراجعة المشكلات وتشخيصها وربما حلها
صيانة المكونات
منتج البرنامج ومكوناته لا تكون ثابتة أبدًا. يجب أن تضع في اعتبارك أن مكونات الطرف الثالث المدمجة في منتجاتك قد يتم تعديلها أو تحديثها بواسطة المورد بشكل دوري. يجب عليك مراقبة هذه التعديلات خاصةً عندما تكون مرتبطة بنقاط الضعف والتعرضات الشائعة (CVEs).
جزء كبير من الحفاظ على مكونات البرنامج الخاص بك هو مراقبة آليات إعداد التقارير القياسية لمكافحة التطرف العنيف وقنوات الدعم الأخرى لتحديد ما إذا كانت الثغرات الأمنية التي تم تحديدها حديثًا في مكون جهة خارجية مدمجة داخل منتجك تؤثر على سلامة أنظمتك الخاصة واتخاذ الإجراءات المناسبة للتخفيف من المخاطر ( لو اي).
عند تحديد مكونات خارجية ليتم تضمينها في منتجك، يجب عليك التحقق من العقد للتأكد من أن مالك المكون لديه سياسات حول كيفية إخطار مؤسسات المنتج حول تحديثات أنظمتها، ووجود ثغرات أمنية، والإطار الزمني للثغرات الأمنية الدقة بالإضافة إلى أي إجراءات قد تحتاج إلى تنفيذها من جانبك لضمان الأمان الأمثل.