إدارة SBOM لـ سلسلة توريد البرمجيات

صيغتان مفتوحتان تهيمنان على الممارسة. ينبثق CycloneDX من مجتمع OWASP ويُوحَّد دوليًا عبر لجنة Ecma TC54: نُشر الإصدار 1.6 في يونيو 2024 بوصفه ECMA-424 (الطبعة الأولى)، ونُشر الإصدار 1.7 الصادر في أكتوبر 2025 في ديسمبر 2025 بوصفه ECMA-424 (الطبعة الثانية) – مع نمذجة موسّعة من بين أمور أخرى للمخرجات التشفيرية ونماذج تعلّم الآلة (ML). ويُطوَّر SPDX تحت مظلة Linux Foundation؛ وتوحّد ISO/IEC 5962:2021 الإصدار 2.2.1، بينما تمرّ المواصفة الحالية 3.0.1 (ديسمبر 2024) بإجراءات ISO بوصفها ISO/IEC DIS 5962. تعود جذور SPDX إلى مجال الامتثال للتراخيص، بينما يتوجّه CycloneDX أكثر نحو حالات الاستخدام الأمنية – وكلاهما يستوفي متطلب CRA بشأن «صيغة شائعة وقابلة للقراءة آليًا».

حدّدت NTIA عام 2021 لأول مرة الحد الأدنى من مكوّنات SBOM في ثلاث فئات: حقول البيانات (منها المورّد، واسم المكوّن، والإصدار، والمعرّفات الفريدة، وعلاقات التبعية، ومؤلف SBOM، والطابع الزمني)، ودعم الأتمتة، والعمليات المصاحبة. وفي يوليو 2026 نشرت CISA وNSA وFBI والجهات الشريكة الدولية وثيقة «2026 Minimum Elements for a SBOM» التي تحلّ محلّ نسخة NTIA. ومن الإضافات الجديدة تجزئات المكوّنات، وبيانات الترخيص، واسم أداة التوليد، وسياق التوليد؛ كما دُقّقت الحقول القائمة ووُحّدت تسمياتها. ويُعدّ الحد الأدنى من المحتوى صراحةً حدًا أدنى – وتبعًا لغرض الاستخدام تكون بيانات إضافية مفيدة.

التوقيت الأكثر موثوقية لتوليد SBOM هو مرحلة البناء: فهناك تكون جميع التبعيات المحلولة معروفة بإصداراتها الدقيقة، وهو ما لا يستطيع تحليل الشيفرة المصدرية وحده ولا التحليل الثنائي اللاحق إعادة بنائه بالكامل. وفي الممارسة يتولّى ذلك إضافات (Plugins) لمديري الحزم وأنظمة البناء أو مولّدات مثل cdxgen وSyft، مدمجة كخطوة ثابتة في خط CI/CD. وبذلك يحصل كل إصدار على SBOM خاصة به ذات إصدار محدّد، تُحفظ مع مخرجات البناء ويُفضّل توقيعها. كما يوضّح سياق التوليد المطلوب في عناصر CISA 2026 في أي مرحلة من دورة الحياة نشأت SBOM.

لا تُظهر قائمة SBOM قيمتها إلا من خلال الربط المستمر ببيانات الثغرات الأمنية من مصادر مثل NVD أو OSV أو GitHub Advisories – وبذلك يمكن عند ظهور CVE جديدة الإجابة فورًا عن السؤال: أي المنتجات تحتوي على مكونات متأثرة. ولأن المكوّن المعرّض للثغرة لا يعني تلقائيًا أن المنتج معرّض لها، يُكمّل VEX (Vulnerability Exploitability eXchange) قائمة SBOM بتصريحات قابلة للقراءة آليًا من الشركات المصنِّعة حول التأثر الفعلي؛ وقد نشرت CISA لهذا الغرض متطلبات دنيا في أبريل 2023. وتُستخدم صيغًا للتبادل كلٌّ من Common Security Advisory Framework (CSAF 2.0، معيار OASIS منذ نوفمبر 2022، مع ملف تعريف VEX خاص به) وCycloneDX مع VEX مُضمَّن. وعند استخدام هذا المزيج على النحو الصحيح، فإنه يقلّل الإنذارات الكاذبة بشكل كبير ويركّز المعالجة على الثغرات القابلة للاستغلال فعليًا.

يجعل قانون المرونة السيبرانية الأوروبي (CRA) (اللائحة (EU) 2024/2847، السارية منذ 10 ديسمبر 2024) قائمة SBOM إلزامية: إذ يُلزم الملحق I الجزء II الشركات المصنِّعة بتوثيق الثغرات الأمنية والمكونات، بما في ذلك قائمة مكونات برمجية بصيغة شائعة وقابلة للقراءة آليًا تغطي على الأقل التبعيات من المستوى الأعلى (Top-Level Dependencies). وتُعدّ SBOM جزءًا من الوثائق الفنية، ويجب تقديمها إلى سلطات مراقبة السوق عند الطلب؛ ولا يوجد التزام بنشرها. وتسري الالتزامات الرئيسية اعتبارًا من 11 ديسمبر 2027، أما التزامات الإبلاغ فتسري اعتبارًا من 11 سبتمبر 2026. ويُفصّل BSI هذه المتطلبات في المبدأ التوجيهي الفني TR-03183 الجزء 2 (الإصدار 2.1.0، أغسطس 2025) بمواصفات شكلية وموضوعية لكل حقل بيانات – بما في ذلك توصيات الربط مع SPDX وCycloneDX، ومنذ الإصدار 2.1.0 معالجة المكونات الافتراضية والمُشار إليها.

في التشغيل المستمر، ترسّخ نمط المنصة المركزية لـ SBOM، ويُعدّ OWASP Dependency-Track أشهر مثال مفتوح المصدر عليه. تستهلك المنصة وتُنتج وثائق SBOM وVEX بصيغة CycloneDX، وتجرد المكونات عبر جميع المشاريع والإصدارات، وتطابقها باستمرار مع مصادر الثغرات الأمنية مثل NVD أو OSV أو GitHub Advisories أو Snyk. ويفرض محرك السياسات (Policy Engine) سياسات الأمن والتراخيص والتشغيل آليًا؛ ويتيح التصميم القائم على API أولًا الربط المباشر بخطوط CI/CD. والعامل الحاسم هو التحول الجذري: بدلًا من عمليات الفحص المتقطعة، تُعاد تقييم المحفظة بأكملها تلقائيًا مع كل إعلان عن ثغرة أمنية جديدة.