يتطلب إنشاء منتجات أو تطبيقات برمجية آمنة في هذا العصر معرفة كاملة بالمكونات الدقيقة للتطبيق الذي تقوم بإنشائه. تعد التبعيات والتراخيص والملفات والأصول الأخرى التي تشكل حزمة البرامج الخاصة بك نقاط ضعف محتملة يمكن من خلالها للجهات الفاعلة الخبيثة شن هجوم على برامجك والتطبيقات الأخرى أسفل سلسلة التوريد.
كجزء من الجهود المبذولة لمكافحة الزيادة الأخيرة في وتيرة وتأثير الهجمات على سلاسل توريد البرمجيات، أصدرت الحكومة الفيدرالية بالتنسيق مع NTIA أمرًا تنفيذيًا يوضح بالتفصيل الإجراءات المختلفة لتحسين الأمن السيبراني وضمان سلامة مكونات الطرف الثالث المستخدمة في حزم البرامج. أحد هذه التدابير هو فاتورة مواد البرمجيات.
هذه وثيقة رسمية تحتوي على كافة مكونات حزمة البرامج وعلاقات سلسلة التوريد بين هذه المكونات. لا يعد إعداد قائمة مواد البرامج الشاملة مجرد ممارسة قياسية، بل إنه مطلوب أيضًا بموجب القانون. يحدد هذا المنشور نطاق قائمة مواد البرنامج و الحد الأدنى من العناصر التي يجب تضمينها في فاتورة المواد الشاملة.
ما الذي توفره NTIA الحد الأدنى من مكونات SBOM؟
يعمل دليل SBOM كدليل رسمي للشركات التي تقوم ببناء البرامج أو شرائها أو تشغيلها، حيث يوفر جميع المعلومات التي يحتاجونها لتعزيز فهمهم لسلسلة توريد البرامج. كما أنه يساعد على تعقب نقاط الضعف الناشئة بسهولة في حالة حدوثها تقليل مخاطر سلسلة توريد البرمجيات. ومع ذلك، لكي يفي SBOM بالمتطلبات المنصوص عليها من قبل الحكومة الفيدرالية، هناك بعض العناصر الأساسية التي يجب أن تحتوي عليها. غالبًا ما يتم تصنيف هذه العناصر إلى ثلاث فئات:
- حقول البيانات: من المتوقع أن يوفر SBOM بيانات مهمة حول مكونات البرنامج مثل اسم المكون واسم المورد وإصدار البرنامج والمعرفات الفريدة الأخرى. وينبغي أيضا أن توضح بالتفصيل العلاقات بين التبعيات. تتيح هذه البيانات تحديد جميع مكونات البرامج بدقة وتعقبها عبر سلسلة توريد البرامج.
- دعم الأتمتة: يجب أن تكون قائمة مواد البرنامج قابلة للقراءة آليًا وقابلة للإنشاء تلقائيًا. وهذا يسمح بالتتبع المستمر للبيانات المضمنة في SBOM. عادةً ما تكون هذه المستندات بتنسيقات قياسية مثل علامات SPDX وCycloneDX وSWID، مما يجعلها قابلة للقراءة أيضًا.
- الممارسات والعمليات: من المتوقع أيضًا أن تتضمن وثائق SBOM تفاصيل الممارسات والعمليات القياسية لإعداد وتحديث SBOM. ويجب أن يتضمن أيضًا ممارسات التوزيع والوصول إلى SBOM بالإضافة إلى إجراءات التعامل مع الأخطاء العرضية.
يوفر الحد الأدنى من العناصر المطلوبة من وثائق SBOM الخاصة بـ NTIA معيارًا واضحًا لما هو متوقع في إرشادات SBOM لحالات الاستخدام الأساسية لقائمة مواد البرنامج الخاصة بك مثل إدارة نقاط الضعف، وجرد مكونات البرنامج، وإدارة تراخيص البرامج. يتم تحديث إطار العمل وقد يتضمن عناصر إضافية تزيد من قابليته للاستخدام في المستقبل القريب. في الأقسام اللاحقة من هذه الصفحة، سنشرح هذه المكونات الرئيسية لقائمة مواد البرنامج الخاصة بك بمزيد من التفصيل. يتضمن الحد الأدنى من العناصر المطلوبة في قائمة مواد البرنامج سبعة حقول بيانات كما هو محدد أدناه.
حقول البيانات: الحد الأدنى من المتطلبات
الغرض من قائمة مواد البرنامج هو توفير المعلومات التي تساعد المستخدمين وأصحاب المصلحة الآخرين على التعرف على مكونات البرنامج بسهولة. من المتوقع أن يكون أحد العناصر الأولى والأكثر أهمية في SBOM هو البيانات التي يجب تضمينها لكل مكون مفصل في المستند. بالإضافة إلى المساعدة في تحديد المكونات الفردية، تسهل البيانات أيضًا تتبع المكونات عبر الأماكن المختلفة التي يتم استخدامها فيها في سلسلة توريد البرامج.
- اسم المورد: المورد هو المنشئ أو الشركة المصنعة لمكون البرنامج المعني. هذا هو اسم الفرد أو المؤسسة التي تقوم بإنشاء مكونات البرنامج وتعريفها والتعرف عليها.
- اسم مكون: يشير هذا إلى الاسم المعين للبرنامج كما هو محدد بواسطة المورد أو الشركة المصنعة الأصلية. في الحالات التي توجد فيها أسماء وأسماء مستعارة متعددة للبرنامج، يمكن الإشارة إليها أيضًا.
- إصدار المكون: يجب أن يتضمن SBOM رقم الإصدار أو رقم الفئة كما هو محدد من قبل المورد أو الشركة المصنعة. تعمل بيانات الإصدار كمعرف يحدد أي تغيير في البرنامج من إصدار محدد مسبقًا للإصدار اللاحق للبرنامج.
- المعرفات الفريدة الأخرى: ويشير هذا إلى معرفات إضافية غير اسم المكون وإصداره. توفر هذه المعرفات الإضافية طبقة تعريف إضافية للمكون ويمكن استخدامها أيضًا كمفتاح بحث للعثور على المكون في قواعد البيانات ذات الصلة.
- علاقة التبعية: يعد هذا أحد أهم مكونات البيانات في قائمة مواد البرنامج، نظرًا لأن SBOM يهدف إلى تفصيل كيفية توافق مكونات البرنامج معًا. تحدد علاقة التبعية العلاقة بين البرنامج X المستخدم داخل التطبيق الخاص بك ومكوناته الأولية.
- مؤلف بيانات SBOM: يشير هذا إلى الفرد الذي قام بإنشاء بيانات SBOM. في بعض الأحيان، قد يكون مورد البرنامج أيضًا هو المؤلف. ومع ذلك، في كثير من الحالات، يكون المؤلف فردًا أو مجموعة أخرى.
دعم الأتمتة: الحد الأدنى من المتطلبات
غالبًا ما يتجاوز استخدام قائمة مواد البرنامج الحدود التنظيمية. وهذا يعني أن البيانات الموجودة في SBOM غالبًا ما يتم استخدامها من قبل أقسام متعددة داخل المؤسسة ومن قبل العديد من المؤسسات أيضًا. لضمان سهولة استخدام هذه الوثائق، توصي NTIA بأن يكون SBOM بتنسيق يمكن قراءته آليًا ويمكن قراءته بواسطة الإنسان. يؤدي إعداد وإرسال SBOM بتنسيقات آلية قياسية مثل هذا إلى تحسين إمكانية التشغيل البيني لهذه الوثيقة لأغراضها المقصودة المختلفة.
تتعرف NTIA على ثلاثة تنسيقات تسليم لإنشاء وإرسال SBOMs. يجب أن تتطابق قائمة المواد البرمجية الخاصة بك مع أي من هذه التنسيقات لتكون متوافقة مع المعايير المنصوص عليها في الأمر التنفيذي للحكومة بشأن الأمن السيبراني. تتضمن هذه التنسيقات القياسية ما يلي:
- تبادل بيانات حزمة البرامج (SPDX)
- علامات تعريف البرامج (SWID).
- سيكلون DX
تبادل بيانات حزمة البرامج (SPDX)
يعد SPDX معيارًا مفتوحًا لتقديم بيانات SBOM. فهو يلتقط معلومات مهمة حول البرنامج بما في ذلك مكوناته ومصدره وتراخيصه وحقوق الطبع والنشر. كما يوفر مراجع الأمان. ال سبدكس الإصدار 2.2 هو الإصدار الأحدث ويدعم نوع الملف YAML 1.2 وJavaScript Object Notation وResourceوصف الإطار (RDF/XML). العلامة: قيمة الملف النصي المسطح وجداول البيانات .xls
علامات تعريف البرامج (SWID).
تم تصميم علامات SWID للمساعدة في تحديد مكونات أي منتج برمجي ووضعها في سياقها. مشروع علامات تعريف البرنامج (علامات SWID) عبارة عن مجموعة من الأدوات لإنشاء علامات التعريف الخاصة بأحد البرامج والتحقق من صحتها. تدعم هذه الأدوات المستندة إلى Java علامات XML SWID استنادًا إلى التنسيق القياسي كما هو محدد في ISO/IEC 19770-2:2015، والتمثيل الثنائي المختصر للكائنات (CBOR). ال NIST لديه موقع على الانترنت مع قائمة بالموارد المفيدة لـ:
- بناء علامات SWID وCoSWID
- التحقق من صحة علامات SWID وCoSWID بناءً على متطلبات المخطط المحددة وإرشادات أفضل الممارسات
- تطبيق ويب يوفر خدمة التحقق من صحة علامة SWID والتي يمكن نشرها على خادم تطبيق Java
- عميل SWID repo لنشر العلامات إلى قاعدة بيانات الضعف الوطنية
سيكلون DX
سيكلون DX يدعي أنه "معيار قائمة مواد البرامج (SBOM) خفيف الوزن." وهو مفيد لتحليل مكونات سلسلة التوريد وأمن التطبيقات. يمكن للمؤسسات التي تعتمد CycloneDX تلبية الحد الأدنى من متطلبات SBOM بسلاسة والنضج إلى حالات استخدام أكثر تطورًا لوثائق SBOM بمرور الوقت.
عادةً ما يتم تقديم CycloneDX SBOMs بتنسيقات XML أو JSON أو Protocol Buffers. تتضمن المواصفات غالبًا هذه الحقول الخمسة:
- البيانات الوصفية لقائمة المواد: تتضمن المعلومات العامة حول التطبيق أو منتج البرنامج نفسه.
- المكونات: هذا جرد شامل يغطي جميع مكونات البرنامج الخاصة والمفتوحة المصدر.
- معلومات الخدمات: تتضمن هذه التفاصيل جميع واجهات برمجة التطبيقات الخارجية التي من المحتمل أن يستدعيها التطبيق أثناء تشغيله. ويتضمن جميع عناوين URL لنقطة النهاية ومتطلبات المصادقة وعمليات اجتياز حدود الثقة.
- التبعيات: تتضمن الوثائق أيضًا تفاصيل كافة المكونات والخدمات الموجودة ضمن حزمة البرامج. وهذا يشمل كلا من العلاقات المباشرة والانتقالية.
- التراكيب: يشير هذا إلى اكتمال جميع الأجزاء المكونة بما في ذلك المكونات الفردية والخدمات وعلاقات التبعية. يتم وصف كل مقطوعة موسيقية عادةً من حيث ما إذا كانت كاملة، أو غير مكتملة، أو غير مكتملة للطرف الأول فقط، أو غير مكتملة للطرف الثالث فقط، أو غير معروفة تمامًا.
الممارسات والعمليات: الحد الأدنى من المتطلبات
يركز العنصر الأخير في قائمة المواد الخاصة بالبرنامج على آليات استخدام SBOM نفسه. تغطي الممارسات والعمليات التفاصيل التشغيلية لإنشاء واستخدام SBOM ويجب تضمينها في أي سياسة أو عقد يطلب ذلك. فيما يلي المتطلبات الأساسية التي يجب تفصيلها في قسم الممارسات والعمليات في قائمة مواد البرنامج الخاصة بك:
- التكرار يوضح هذا القسم عدد المرات التي يتعين فيها على المؤسسة إنشاء فاتورة برمجيات جديدة للمواد. بشكل عام، توصي NTIA بإنشاء SBOM جديد في أي وقت يتم فيه تحديث مكون البرنامج الخاص بك أو إصدار إصدار جديد. من المتوقع أيضًا أن يقوم الموردون بإنشاء SBOMs جديدة عندما يجدون خطأ في الإصدار الأصلي أو يتعلمون تفاصيل جديدة حول مكونات برامجهم التي لم يتم تضمينها في الوثائق الأولية.
- عمق: يعتمد عمق SBOM الخاص بك على ما تم تضمينه في المستند. لكي تكون متوافقًا، من المتوقع أن يتضمن SBOM الخاص بك كافة مكونات المستوى الأعلى وجميع التبعيات المتعدية. في الحالات التي يكون فيها المؤلف غير قادر على تضمين كافة التبعيات المتعدية، يجب أن يقوم المستند بإرشاد المستهلك حول المكان الذي يمكنه العثور عليه.
- هناك حالات حيث لا يمكن لمؤلف SBOM توفير رسم بياني تبعية كامل لسبب أو لآخر. قد يكون هذا بسبب عدم وجود تبعيات أخرى للمكون أو أنهم لا يعرفون ما إذا كانت هذه التبعيات موجودة أم لا. مطلوب مؤلف SBOM لتحديد هذا السبب.
- التوزيع والتسليم: الهدف من هذا المطلب هو ضمان تسليم SBOMs بسرعة وبتنسيق سهل الهضم. على الرغم من أن هذا المتطلب لا يحدد عدد الأيام أو الأسابيع التي من المفترض أن يتم تسليم SBOMs خلالها، إلا أنه يجب تسليمها في أسرع وقت ممكن. بالإضافة إلى ذلك، يجب أن يكون لدى SBOM الأدوار المناسبة وأذونات الوصول المحددة عند تسليمها. أخيرًا، ينص المتطلب على أنه يمكن توزيع SBOM مع كل مثيل للمنتج أو إتاحته بأي طريقة أخرى يمكن الوصول إليها بسهولة مثل عبر موقع ويب عام.
- صلاحية التحكم صلاحية الدخول: في الحالات التي يقرر فيها المورد قصر الوصول إلى بيانات SBOM على مستخدمين أو عملاء محددين، يتعين على المؤلف تحديد شروط التحكم في الوصول. هناك أيضًا حاجة إلى تقديم بدلات محددة للمستهلكين الذين يرغبون في دمج بيانات SBOM في أدوات الأمان الخاصة بهم.
- استيعاب الأخطاء: يمكن أن تساعد SBOM في تحسين ضمان البرامج و إدارة مخاطر سلسلة توريد البرمجيات. ومع ذلك، فإنه لا يزال بعيدا عن الكمال. وبالتالي، يحتاج المستهلكون إلى التسامح مع الأخطاء أو السهو غير المقصود الذي قد يحدث في إعداد SBOMs.
التفكير فيما يتجاوز الحد الأدنى من متطلبات NTIA
لقد ناقشنا حتى الآن الحد الأدنى من العناصر المطلوبة في قائمة مواد البرنامج الخاصة بك. تمثل هذه العناصر الدنيا المتطلبات الموصى بها، خاصة بالنسبة لحالات الاستخدام الأساسية لهذه الوثائق. وفي حين أنها تضع أساسًا جيدًا لمصدر البرامج وأمنها، إلا أنه يجب على المرء أن ينظر إلى ما هو أبعد من هذه المتطلبات. فيما يلي بعض التوصيات التي يجب مراعاتها في حالات استخدام SBOM الأكثر تقدمًا.
حقول البيانات الإضافية
بالإضافة إلى حقول البيانات المشمولة في وثيقة الحد الأدنى من المتطلبات، هناك حقول بيانات إضافية يوصى بها للحالات التي يكون فيها مستوى الأمان الأعلى ضروريًا. تتضمن بعض حقول البيانات الإضافية هذه ما يلي:
- تجزئة تشفير لمكونات البرنامج
- بيانات مرحلة دورة حياة البرنامج
- العلاقات بين المكونات الأخرى
- معلومات الترخيص
البرامج المستندة إلى السحابة والبرامج كخدمة
هناك مجال آخر محتمل قد تتجاوز فيه متطلبات SBOM الأساسيات وهو إدارة منتجات البرامج كخدمة (SaaS). تواجه هذه الأنواع من منتجات البرامج تحديات فريدة فيما يتعلق ببيانات SBOM. في البداية، تعتبر المخاطر الأمنية في السياق السحابي فريدة من نوعها. كما أن مسؤولية التعامل مع تلك المخاطر تقع على عاتق مزود الخدمة. يعد إعداد وثائق SBOM للبرامج المستندة إلى السحابة أيضًا أكثر تعقيدًا نظرًا لأنها تميل إلى أن تكون لها دورة إصدار أقصر.
SBOM النزاهة والأصالة
هناك مشكلة محتملة أخرى جديرة بالملاحظة وهي عملية مصادقة مصدر بيانات SBOM نفسها. حاليًا، تعد التوقيعات والبنية التحتية للمفتاح العام هي الحلول المعتمدة للتحقق من سلامة البرامج في العالم الرقمي اليوم. قد يحتاج مؤلفو وموردو SBOMs إلى الاستفادة من توقيعات البرامج الحالية لتحسين موثوقية بيانات SBOM.
الضعف والاستغلال في التبعيات
على الرغم من أن الغرض من SBOMs هو تسهيل اكتشاف الثغرات الأمنية، فمن المهم ملاحظة أنه ليست كل الثغرات الأمنية في التبعيات تشكل مخاطر كبيرة على البرامج التي تعتمد عليها. لتجنب إضاعة الوقت والموارد، سيحتاج موردو البرامج إلى وضع تدابير لتحديد التأثيرات المحتملة لثغرة التبعية على البرامج التي تستخدم المصب وإبلاغ مستوى المخاطر (أو عدم وجوده في هذه الحالة) لمستخدمي SBOM البيانات في اتجاه مجرى النهر.
المرونة مقابل التوحيد في التنفيذ
عندما تتم مناقشة أمان البرامج، تظهر دائمًا مسألة المرونة والتوحيد في المقدمة. وينطبق هذا على حالات الاستخدام المتقدمة لـ SBOMs أيضًا. لتنفيذ SBOMs بنجاح، ستكون هناك حاجة إلى سياسات واسعة تنطبق على جميع المجالات بالإضافة إلى حالات محددة حيث ستكون المرونة ضرورية.