- تعريف أمن سلسلة توريد البرمجيات
- الهجمات على سلاسل توريد البرمجيات: لماذا هي شائعة جدًا؟
- تم الانتهاء من SSDF (NIST 800-218) وأصبح ساري المفعول
- SLSA هو إطار عمل يجب عليك الالتزام به
- كيفية تأمين سلسلة توريد البرمجيات الخاصة بك؟
- يعد التحقق من سلامة البرامج أمرًا صعبًا
- ضمان الكود في جميع أنحاء SDLC بالكامل
- شرح أمن سلسلة توريد البرمجيات
- أتمتة تقييم الامتثال لـ SLSA
- Scribe Security - معيار جديد لأمن سلسلة توريد البرامج
- كيف يمكن للكاتب المساعدة؟
ما هو أمن سلسلة توريد البرمجيات؟
تشمل سلسلة توريد البرامج كل ما يؤثر أو يلعب دورًا في منتج أو تطبيق خلال دورة حياة تطوير البرنامج بأكملها (SDLC).
في السنوات الأخيرة، أصبحت الهجمات على سلسلة توريد البرمجيات أكثر انتشارًا وتطورًا. في تقريرهم لعام 2022، غارتنر الدول: "توقع التوسع المستمر في سطح الهجوم المؤسسي وزيادة الاستثمار في العمليات والأدوات اللازمة لاكتشاف تهديدات الهوية ومعالجتها وتكامل سلسلة التوريد الرقمية."
لقد أصبح من المهم أكثر من أي وقت مضى تأمين جميع المكونات والأنشطة وممارسات SDLC المشاركة في إنشاء البرامج ونشرها. يجب على فرق التطوير وبائعي البرامج التأكد من أنهم يستخدمون فقط مكونات التعليمات البرمجية الخالية من الثغرات الأمنية المعروفة وإيجاد طرق للتحقق من سلامة بنيتهم، والتحقق من التلاعب غير المصرح به.
- تعريف أمن سلسلة توريد البرمجيات
- الهجمات على سلاسل توريد البرمجيات: لماذا هي شائعة جدًا؟
- تم الانتهاء من SSDF (NIST 800-218) وأصبح ساري المفعول
- SLSA هو إطار عمل يجب عليك الالتزام به
- كيفية تأمين سلسلة توريد البرمجيات الخاصة بك؟
- يعد التحقق من سلامة البرامج أمرًا صعبًا
- ضمان الكود في جميع أنحاء SDLC بالكامل
- شرح أمن سلسلة توريد البرمجيات
- أتمتة تقييم الامتثال لـ SLSA
- Scribe Security - معيار جديد لأمن سلسلة توريد البرامج
- كيف يمكن للكاتب المساعدة؟
تعريف أمن سلسلة توريد البرمجيات
تشير سلسلة توريد البرامج إلى كل ما يتعلق بتطوير التطبيق طوال دورة حياة تطوير البرنامج (SDLC) بأكملها. يتطلب إنشاء البرامج ونشرها تأمين الأنشطة والعمليات والمكونات الخاصة بسلسلة التوريد الخاصة بها. هناك العديد من العوامل التي يجب مراعاتها في هذا الصدد، بما في ذلك التعليمات البرمجية المخصصة (المكونات الداخلية)، والتبعيات والمكتبات مفتوحة المصدر (مكونات الطرف الثالث)، وأدوات DevOps والبنية التحتية التي تشكل عملية CI/CD، وأخيرًا المطورين وDevOps فرق.
وتقع على عاتق المؤسسات مسؤولية تنفيذ هذه الأنشطة الأمنية وتقديم دليل على جهودها الأمنية للعملاء.
الهجمات على سلاسل توريد البرمجيات: لماذا هي شائعة جدًا؟
تعد مسارات البرامج الحديثة بيئات آلية تعتمد على مجموعة متنوعة من الأدوات للتكامل المستمر والتسليم المستمر. قد ينتهي الأمر بمشروع برمجي يتضمن آلاف التبعيات مفتوحة المصدر.
يمكن للجهات الفاعلة الضارة تقديم مكتبات مارقة على أنها مكتبات شرعية من خلال استغلال "العيوب المنطقية" في مديري الحزم مفتوحة المصدر. على سبيل المثال، يمكن أن تُنسب الحزم التي تحتوي على برامج ضارة إلى مشرفين موثوقين دون علمهم. مثل هذه الثقة في غير محلها يمكن أن تؤدي إلى ظهور ثغرات أمنية مخفية وإشكالية في التعليمات البرمجية الخاصة بك. يمكن أن توفر نقاط الضعف هذه للمهاجمين إمكانية الوصول إلى البيانات الحساسة أو تسمح لهم بزرع البرامج الضارة وأنظمة التحكم عبر سلسلة التوريد.
تتمتع بيئة التطوير الحديثة بنقاط ضعف خاصة بها، وقد استهدفت مجموعة متنوعة من هجمات سلسلة توريد البرامج خط أنابيب CI/CD لإدراج تعليمات برمجية ضارة في مرحلة ما خلال عملية التطوير. وهنا أيضًا، يعد افتراض الثقة الصفرية هو النهج المناسب لكسب الثقة في منتج البرنامج النهائي - فحص كل خطوة في سلسلة التطوير الداخلي والتحقق منها والتحقق من صحتها.
تفتقر خطوط أنابيب CI/CD اليوم إلى الرؤية والضوابط لتوفير الحماية الكافية لعملية تطوير البرمجيات. كما أنهم يكافحون من أجل اكتشاف التلاعب بالشفرات، مما يجعل ناقل الهجوم هذا أكثر جاذبية.
تم الانتهاء من SSDF (NIST 800-218) وأصبح ساري المفعول
إطار SSDF (NIST 800-218). يتطلب من الموردين تنفيذ ممارسات أمنية تغطي دورة حياة تطوير البرمجيات (SDLC). إنه يعزز الشفافية وإجراءات مقاومة التلاعب في محاولة لتقليل الثغرات الأمنية والتدخلات الضارة.
وعلى وجه التحديد، فهو يحتوي على إرشادات لنهج قائم على الأدلة لحماية البرنامج نفسه من العبث به.
يتكون SSDF من أربعة أجزاء رئيسية:
01 /
إعداد المنظمة (PO):
تأكد من أن الأشخاص مستعدون وأن العمليات والتكنولوجيا موجودة لتنفيذ تطوير آمن للبرامج على مستوى المؤسسة، وفي بعض الحالات، لمجموعات أو مشاريع التطوير الفردية.
02 /
حماية البرنامج (PS):
حماية كافة مكونات البرنامج من أي وصول غير مصرح به أو العبث.
03 /
إنتاج برامج مؤمنة جيدًا (PW):
إنتاج برامج آمنة بشكل جيد مع الحد الأدنى من الثغرات الأمنية في إصداراتها.
04 /
الاستجابة لنقاط الضعف (RV):
تحديد نقاط الضعف المتبقية في إصدارات البرامج، والاستجابة بشكل مناسب لمعالجة نقاط الضعف تلك، ومنع حدوث نقاط ضعف مماثلة في المستقبل.
لا ينبغي عليك الرجوع إلى SSDF كقائمة مرجعية بل كدليل لتخطيط وتنفيذ نهج قائم على المخاطر والأدلة لتطوير البرامج الآمنة.
يجب على الشركات اتخاذ خطوات لتحسين وضعها الأمني من أجل تسهيل الامتثال للتغييرات التنظيمية الناشئة.
SLSA هو إطار عمل يجب عليك الالتزام به
يوفر إطار العمل الذي تم إنشاؤه في Google، والذي يسمى SLSA (مستويات سلسلة التوريد لعناصر البرامج)، إرشادات حول كيفية الوصول إلى أربعة مستويات من حماية سلسلة توريد البرامج. يركز الإطار على سلامة بناء القطع الأثرية بهدف منع العبث بالقطع الأثرية وتأمينها.
تعمل SLSA بهذه الطريقة: تقوم بتنفيذ قوائم مرجعية لضوابط الأمان التي يجب عليك تنفيذها في المسار الخاص بك، وتكون عناصر التحكم هذه في نطاقات فرعية مثل أنظمة التحكم في المصدر، وأنظمة البناء والتبعيات التي تدخلها في مشاريع البرامج الخاصة بك.
ويضع SLSA أربعة مستويات من الامتثال بهدف الوصول إلى المستوى 4، والذي سيكون له أعلى قيمة أمنية، ولكن سيكون له قائمة أطول من المتطلبات.
يعتمد إطار عمل SLSA على مفهوم المصدر. وثيقة تمثل "سلسلة من الأدلة" تشير إلى أصل القطع الأثرية وعملية بنائها. عندما ترتفع مستويات SLSA، فإنك تحتاج إلى حماية الأدلة نفسها بشكل أفضل.
يجب عليك اعتبار SLSA معيارًا صناعيًا ومستوى حماية وامتثالًا معروفًا ومتفقًا عليه ويجب عليك الالتزام به.
كيفية تأمين سلسلة توريد البرمجيات الخاصة بك؟
ومع ذلك، نود أن نؤكد ثلاث فئات رئيسية من الضوابط الأمنية:
1. قم بتأمين تكوين دورة حياة تطوير البرامج الخاصة بك
تعمل بيانات الاعتماد المخترقة والتحكم غير الكافي في الأذونات وأنظمة البناء الضعيفة على إنشاء أسطح هجوم تؤثر على منتج البرنامج. يمكن للمهاجمين الذين يستغلون نقاط الضعف هذه سرقة أسرار غير آمنة أو العبث بعناصر البرامج. قد توفر مجموعة من الحلول التجارية ومفتوحة المصدر في هذه الفئة ضوابط لرسم خريطة للثغرات في الوضع الأمني ومعالجتها.
2. تجنب الاعتماد على التبعيات الضعيفة أو الضارة
ومن المؤكد أنه سيستمر اكتشاف نقاط الضعف الجديدة في البرامج مفتوحة المصدر والبرامج التجارية. يجب على منتجي البرمجيات التخفيف من هذه المخاطر عن طريق ترقية المكونات الضعيفة مفتوحة المصدر، والمسح بحثًا عن نقاط الضعف الذاتية في كود الملكية الخاص بهم، وإبلاغ مستهلكي البرامج حول قائمة مواد البرنامج (SBOM) والآثار المرتبطة بها. ويمكن لهؤلاء المستهلكين بدورهم اتخاذ الإجراءات وفقًا لذلك.
تشكل حسابات المشاريع مفتوحة المصدر التي تم الاستيلاء عليها والحزم الضارة التي تتنكر على أنها شرعية، مخاطر إضافية، تؤثر في المقام الأول على السرقة السرية من خطوط الأنابيب. يعمل مجتمع المصادر المفتوحة وبعض البائعين التجاريين على معالجة هذه المشكلة من خلال تحسين السمعة واكتشاف السلوكيات الضارة.
3. التحقق من سلامة وبنية البرمجيات الآمنة
الأمن السيبراني يتطلب الدفاع في العمق. يمكن أن تتسلل الهجمات عبر الشقوق عند استخدام أسلوب الحماية التقليدي لتقليل سطح الهجوم والكشف عنه والسمعة. وفي الوقت الحاضر، ليس لدى مستهلكي البرمجيات النهائية تأثير يذكر على هذه الضوابط. على الأكثر، يمكنهم الاعتماد على عمليات التدقيق الأمني في الوقت المناسب، مثل مسح التعليمات البرمجية الذي يوفر لمحة سريعة عن الثغرات الأمنية، للموردين الذين لا يخلقون ثقة حقيقية بأن قطعة البرنامج مؤمنة بشكل جيد ومحمية ضدها أثناء دورة حياة التطوير.
تتوفر الآن فئة جديدة وناشئة من عناصر التحكم التي تشهد بشكل مستمر على سلامة كل عملية تطوير آمنة لكل منتج برمجي. هذه الشهادات غير حسنة السمعة ويمكن مشاركتها بين المنتجين والمستهلكين النهائيين الذين يبحثون عن التحقق من الصحة. يتم تحقيق عدم الإنكار من خلال أساليب التشفير، وبالتالي يرفع بشكل كبير سعر أي مهاجم يتسلل إلى سلسلة التوريد.
يعتبر هذا النهج ضروريًا من قبل الخبراء في مجال أمن سلسلة توريد البرمجيات. ومع ذلك، على الرغم من وجود بعض العناصر الأساسية مفتوحة المصدر لدعم هذه الفئة من عناصر التحكم، إلا أن عددًا قليلاً فقط من البائعين يمكنهم توفير حل متكامل.
يجب أن يتضمن الحل الكامل لسلسلة توريد البرامج ما يلي:
جمع الأدلة وتوقيعها كشهادات من عمليات تطوير وبناء البرمجيات. عادةً ما يكون هذا الدليل عبارة عن تجزئات ملف تحتوي على بيانات التعريف التي تتم مقارنتها بين الخطوات ذات الصلة في العملية، والأحداث المتعلقة بالخطوات المتعلقة بالأمان مثل هويات مرتكب التعليمات البرمجية، ومراجعات التعليمات البرمجية، واختبارات الأمان التلقائية، وما إلى ذلك. ومن الضروري أيضًا تقديم شهادة فيما يتعلق بالوضع الأمني لعملية إنشاء منتج البرنامج في وقت إنشاء قطعة البرنامج.
مخزن تصديق آمن يسمح بالرؤية ويدعم التحليلات مثل التحقق من صحة سلامة التعليمات البرمجية.
محرك سياسة يقيس هذه الشهادات مقابل سياسة تنظيمية محددة أو سياسة قائمة على المعايير للتحقق من صحة الامتثال وإظهاره.
مركز تبادل للمعلومات المتعلقة بالثقة بين منتجي البرمجيات أو المستهلكين؛ قد يكون هذا بين المؤسسات أو داخلها).
يعد التحقق من سلامة البرامج أمرًا صعبًا
يجب أن يكون التحقق من سلامة التعليمات البرمجية أمرًا سهلاً من الناحية النظرية. مجرد مقارنة الملفات، أليس كذلك؟ في الواقع، هناك الكثير مما يجب أخذه بعين الاعتبار. بالنسبة للمبتدئين، تقوم كل لغة بتجميع الملفات بشكل مختلف. علاوة على ذلك، يتم استخدام الملفات بشكل مختلف تمامًا اعتمادًا على الغرض منها. بعضها مخصص للتغيير، بينما يتم حذف البعض الآخر، ويتم إنشاء البعض الآخر أثناء عملية التجميع.
أضف إلى ذلك حقيقة أن الشركات لا ترغب في تسليم رموز الملكية الخاصة بها لبعضها البعض.
ضمان الكود في جميع أنحاء SDLC بالكامل
يسعى Scribe إلى تأمين SDLC بالكامل بشكل مستمر. من خلال الأدلة التي تم جمعها من أجزاء مختلفة من عملية التطوير والبناء، يستخدم Scribe التوقيع الرقمي لإنشاء شهادات غير قابلة للتزوير.
بمجرد التوقيع، يمكن التحقق من كل جزء من الأدلة لاحقًا لضمان حدوث جميع العمليات كما هو مخطط لها وعدم حدوث أي تعديلات غير مخطط لها.
باتباع أفضل الممارسات المنصوص عليها في SSDF، يتيح لك Scribe استخدام سياسات المنطق السليم لزيادة ثقتك طوال عملية التطوير. تساعد السياسات مثل طلب الالتزامات الموقعة، والمصادقة الثنائية للمطورين، ومراجعة التعليمات البرمجية من شخصين، وما إلى ذلك، على توليد الثقة في أن كل جزء من البرامج قد تم إنتاجه باتباع الوضع الأمني الصحيح.
إن جمع كل هذه الأدلة في مكان واحد، إلى جانب تقرير سلامة التعليمات البرمجية وملخص لجميع السياسات والشهادات يسمح بمزيد من الرؤية والثقة في عملية التطوير ومنتجات البرامج المنتجة في النهاية، ويتوافق مع إرشادات SSDF المعمول بها على أساس اللائحة السيبرانية الجديدة.
إن السماح للمشتركين المحددين بمشاهدة امتثال المنتج لمتطلبات السياسة ونتائج التكامل يوفر للمستخدمين رؤية وثقة أكبر في مسارات التطوير ومنتج البرنامج النهائي.
والنتيجة النهائية لا تقتصر على اكتشاف العبث بالكود أو خطوط الأنابيب فحسب، بل أيضًا القدرة على إثبات الاختبارات وإجراءات الأمان التي تمت أثناء تصميم البرنامج وإنشائه، فضلاً عن سلامة الكود المصدري والحزم مفتوحة المصدر المستخدمة في بنائه.
شرح أمن سلسلة توريد البرمجيات
أتمتة تقييم الامتثال لـ SLSA
يجب قياس أمان خطوط الأنابيب الديناميكية بشكل مستمر. تحدد SLSA (مستويات سلسلة التوريد للعناصر البرمجية) أربعة مستويات لحماية سلسلة توريد البرامج بالإضافة إلى إرشادات حول كيفية الوصول إليها.
يمكن أتمتة تقييم الامتثال لـ SLSA لتلبية متطلباتهم. ولكن كيف ينبغي للمنظمة أن تسعى للحصول على واحدة؟ هل هناك أفضل الممارسات المحددة التي يجب عليك اتباعها؟
شاهد هذا الفيديو حيث نشارك أفضل الممارسات لتنفيذ الأتمتة، باستخدام أدوات مفتوحة المصدر مثل Sigstore وOPA في سيناريوهات العالم الحقيقي. تسلط أفضل الممارسات المفاهيمية والفنية الضوء على تفاصيل العالم الحقيقي وتحديات تقييم وأتمتة الامتثال لـ SLSA.
| قبل استخدام الكاتب | بعد استخدام الكاتب | |
|---|---|---|
| Trust Hub – تبادل المعلومات |
|
|
| SDLC الآمن – السياسة والامتثال |
|
|
| كشف النزاهة والتلاعب |
|
|
| وضوح |
|
|
| الموقف الأمني |
|
|
Scribe Security - معيار جديد لأمن سلسلة توريد البرامج
تتبع كل التفاصيل والحدث في عملية تطوير البرمجيات، بالإضافة إلى سلامة مكونات البرنامج وعناصره
التحقق من عدم حدوث أي تلاعب في أي وجميع أجزاء عملية تطوير البرمجيات
تحقق من سلامة أدوات CI/CD المستخدمة لإنشاء التعليمات البرمجية
التأكد من سلامة عملية التطوير - التأكد من تنفيذ الخطوات المتعلقة بالأمن وفقًا لسياسة المنظمة وعدم تجاوزها
من خلال جمع وتوقيع الأدلة على أي شيء وكل شيء يحدث للكود، في كل مرحلة من دورة حياة التطوير، فإنك تجعل من الصعب على المهاجمين التلاعب بالملفات أو الأدوات أو السلوك المتوقع لخط أنابيب CI/CD الخاص بك.
HELP؟
