لماذا تُعدّ قوائم SBOM مهمة: الضرورة التنظيمية والأمنية
قائمة مكونات البرمجيات (Software Bill of Materials – SBOM) هي جرد رسمي قابل للقراءة آلياً لكل مكوّن ومكتبة وتبعية تُشكّل جزءاً من البرنامج. فكّر فيها كملصق المعلومات الغذائية لتطبيقك — لكن بدلاً من السعرات الحرارية والصوديوم، فأنت تسرد الحزم والإصدارات والتراخيص وبيانات المصدر.
انتقلت قوائم SBOM من كونها ميزة اختيارية إلى متطلب تنظيمي إلزامي. هناك سياستان بارزتان تدفعان نحو تبنّيها في جميع القطاعات:
الأمر التنفيذي 14028 (الولايات المتحدة)
صدر في مايو 2021، ويُلزم EO 14028 — “تحسين الأمن السيبراني للأمة” — بأن أي برنامج يُباع للحكومة الفيدرالية الأمريكية يجب أن يتضمن قائمة SBOM. وجّه الأمر معهد NIST لتحديد الحد الأدنى من عناصر SBOM، مما أسفر عن إرشادات تتوافق مع معايير NTIA لقوائم SBOM. إذا كانت مؤسستك تبيع للجهات الحكومية، فإن توليد SBOM لم يعد اختيارياً — بل هو شرط أساسي للمشتريات.
قانون المرونة السيبرانية في الاتحاد الأوروبي (CRA)
يتطلب قانون المرونة السيبرانية في الاتحاد الأوروبي، الذي دخل حيز التنفيذ في 2024، من المصنّعين والموزّعين للمنتجات ذات العناصر الرقمية تقديم قوائم SBOM كجزء من تقييم المطابقة. يُطبّق القانون على نطاق واسع — من أجهزة IoT إلى منصات SaaS المؤسسية. مع تصاعد الجداول الزمنية للتطبيق خلال 2026 و2027، يجب على منتجي البرمجيات للسوق الأوروبية دمج توليد SBOM في عمليات البناء الخاصة بهم الآن.
ما وراء الامتثال: القيمة التشغيلية
بصرف النظر عن المحركات التنظيمية، تقدم قوائم SBOM فوائد تشغيلية ملموسة:
- الاستجابة للثغرات: عند ظهور ثغرة CVE جديدة (مثل Log4Shell)، تتيح لك قائمة SBOM تحديد المنتجات والنشرات المتأثرة فوراً.
- الامتثال للتراخيص: تعدّد قوائم SBOM التراخيص عبر شجرة التبعيات، مما يُنبّه إلى تراخيص copyleft أو غير المتوافقة قبل أن تتحول إلى مشاكل قانونية.
- شفافية سلسلة التوريد: تُنشئ قوائم SBOM سلسلة حفظ قابلة للتدقيق، مما يتيح للمستهلكين التحقق مما يعملون عليه بالضبط.
- التحليل الجنائي للحوادث: أثناء التحقيقات في الاختراقات، تُسرّع قوائم SBOM تحليل السبب الجذري من خلال توفير جرد دقيق للمكونات وقت البناء.
لم يعد السؤال هل يجب توليد قوائم SBOM، بل أي أداة تستخدم. في هذه المقارنة، نُقيّم ثلاث أدوات رائدة مفتوحة المصدر لتوليد SBOM: Syft وTrivy وCycloneDX CLI.
Syft: مُولّد SBOM المُخصّص من Anchore
Syft طوّرته شركة Anchore وصُمّم للقيام بمهمة واحدة بامتياز: توليد قوائم SBOM دقيقة وشاملة. إنه أداة SBOM مُخصّصة، وليس ماسحاً يُنتج قوائم SBOM كأثر جانبي.
القدرات الرئيسية
- صيغ الإخراج: SPDX (JSON وtag-value)، CycloneDX (JSON وXML)، JSON الأصلي لـ Syft، وصيغة GitHub dependency snapshot.
- أنواع المصادر: صور الحاويات (من السجلات أو ملفات tarball أو Docker daemon)، أنظمة الملفات، المجلدات، وملفات الأرشيف (tar وzip وjar وwar).
- الأنظمة البيئية للغات: تغطية ممتازة — Go وJava (Maven/Gradle) وJavaScript (npm/yarn) وPython (pip/Poetry/Pipenv) وRuby وRust وPHP (Composer) و.NET (NuGet) وC/C++ (Conan) وSwift وDart وHaskell والمزيد.
- مُفهرسات الحزم: يستخدم Syft بنية مُفهرسات وحدوية. لكل نظام بيئي مُفهرس خاص يفهم ملفات القفل والبيانات الوصفية والعناصر الثنائية الأصلية، مما يُنتج نتائج عالية الدقة.
- دعم التصديق: يتكامل Syft بإحكام مع أُطر التصديق
cosignوin-toto. يمكنك توجيه مخرجات SBOM من Syft مباشرة إلىcosign attestلإنتاج تصديقات SBOM موقّعة.
نقاط القوة
تركيز Syft الحصري على توليد SBOM يعني أنه يمتلك أعمق تغطية للمُفهرسات مقارنة بأي أداة في هذه المقارنة. يكتشف مكونات تفوتها الأدوات الأخرى — خاصة الحزم الثنائية المُجمّعة في ثنائيات Go وRust، والتبعيات المتداخلة داخل ملفات Java uber-jars. مرونة صيغ الإخراج لا مثيل لها، ويتكامل أصلياً مع ماسح الثغرات Grype من Anchore.
القيود
لا يقوم Syft بفحص الثغرات بنفسه. تحتاج إلى دمجه مع Grype أو ماسح آخر. هذا يُعدّ نقطة قوة في الواقع (فلسفة Unix: افعل شيئاً واحداً بإتقان)، لكنه يعني أداة إضافية في خط الإنتاج الخاص بك.
أمثلة على الاستخدام
# Generate CycloneDX SBOM from a container image
syft packages registry.example.com/myapp:latest -o cyclonedx-json > sbom.cdx.json
# Generate SPDX SBOM from a local directory
syft dir:/path/to/source -o spdx-json > sbom.spdx.json
# Attest the SBOM with cosign
cosign attest --predicate sbom.cdx.json --type cyclonedx my-image:latest
Trivy: الماسح الشامل من Aqua Security مع وضع SBOM
Trivy طوّرته شركة Aqua Security وبدأ كماسح ثغرات للحاويات. مع مرور الوقت، تطوّر إلى أداة أمنية شاملة تُولّد أيضاً قوائم SBOM. أُضيفت قدرة SBOM كوضع مسح إلى جانب مسح الثغرات والتكوينات الخاطئة والأسرار والتراخيص.
القدرات الرئيسية
- صيغ الإخراج: CycloneDX (JSON) وSPDX (JSON) وJSON الأصلي لـ Trivy وSARIF والمخرجات المقروءة بشرياً.
- أنواع المصادر: صور الحاويات وأنظمة الملفات ومستودعات git ومجموعات Kubernetes وحسابات AWS وصور الأجهزة الافتراضية.
- الأنظمة البيئية للغات: تغطية قوية — Go وJava وJavaScript وPython وRuby وRust وPHP و.NET وC/C++ وElixir وDart وSwift والمزيد.
- فحص الثغرات المُدمج: هذه هي الميزة القاتلة لـ Trivy. توليد SBOM وفحصه بحثاً عن الثغرات في تمريرة واحدة، أو فحص ملف SBOM موجود أنتجته أداة أخرى.
- دعم التصديق: يمكن لـ Trivy توليد والتحقق من تصديقات in-toto أصلياً عبر
trivy image --format cosign-vuln، ويتكامل مع cosign لسير عمل تصديق SBOM.
نقاط القوة
أكبر ميزة لـ Trivy هي بنيته الشاملة. ثنائي واحد يتعامل مع توليد SBOM وفحص الثغرات واكتشاف التكوينات الخاطئة ومسح الأسرار وتحليل التراخيص. هذا يُقلّل من تعقيد سلسلة الأدوات بشكل كبير. وهو أيضاً الأداة الوحيدة في هذه المقارنة التي يمكنها مسح مجموعات Kubernetes والحسابات السحابية مباشرة. تُحدَّث قاعدة بيانات الثغرات بشكل متكرر وتُغطي مصادر متعددة (NVD واستشارات البائعين وGitHub Security Advisories).
القيود
نظراً لأن توليد SBOM في Trivy هو ميزة واحدة من بين العديد، فإن عمق المُفهرسات قد يتأخر عن Syft في حالات خاصة — لا سيما في التحليل الثنائي لثنائيات Go/Rust المُجمّعة وعناصر Java المتداخلة بعمق. أُضيف دعم SPDX لاحقاً بعد CycloneDX، لذا تميل مخرجات CycloneDX إلى أن تكون أكثر اكتمالاً في بعض السيناريوهات. الطبيعة الشاملة تعني أيضاً ثنائياً أكبر حجماً وتنزيلات أولية أطول لقاعدة البيانات.
أمثلة على الاستخدام
# Generate CycloneDX SBOM from a container image
trivy image --format cyclonedx --output sbom.cdx.json registry.example.com/myapp:latest
# Generate SPDX SBOM from a filesystem
trivy fs --format spdx-json --output sbom.spdx.json /path/to/source
# Scan an existing SBOM for vulnerabilities
trivy sbom sbom.cdx.json
# Combined: generate SBOM + scan in one pass
trivy image --format json --list-all-pkgs registry.example.com/myapp:latest
CycloneDX CLI: مجموعة أدوات SBOM الأصلية من OWASP
CycloneDX CLI جزء من مشروع OWASP CycloneDX. على عكس Syft وTrivy، فهو ليس في الأساس مُولّد SBOM من الشيفرة المصدرية أو صور الحاويات. بل هو مجموعة أدوات لمعالجة وتحويل والتحقق من ودمج ومقارنة قوائم CycloneDX SBOM. يتضمن النظام البيئي الأوسع لـ CycloneDX إضافات توليد SBOM الخاصة بكل لغة (مثل cyclonedx-maven-plugin وcyclonedx-npm وcyclonedx-gomod) التي تُنتج قوائم SBOM أثناء عملية البناء نفسها.
القدرات الرئيسية
- صيغ الإخراج: CycloneDX (JSON وXML وProtocol Buffers) — بدقة كاملة. يمكنه التحويل بين إصدارات CycloneDX. دعم محدود لتحويل SPDX.
- عمليات SBOM: دمج قوائم SBOM متعددة في واحدة، ومقارنة قائمتي SBOM لرؤية التغييرات، والتحقق من صحة قوائم SBOM مقابل مخطط CycloneDX، والتحويل بين صيغ CycloneDX.
- التوليد وقت البناء: تُولّد إضافات لغات نظام CycloneDX البيئي قوائم SBOM أثناء البناء من خلال قراءة مُحلّل التبعيات مباشرة (Maven وnpm وGo modules وpip وغيرها)، مما ينتج أدق رسم بياني ممكن للتبعيات.
- دعم التصديق: يمكن تغليف قوائم CycloneDX SBOM في تصديقات CycloneDX BOM-Link، ويدعم النظام البيئي مستندات VEX (Vulnerability Exploitability eXchange) كعناصر من الدرجة الأولى.
نقاط القوة
نهج التوليد وقت البناء في نظام CycloneDX البيئي يُنتج أدق قوائم SBOM لأنه يتصل بآلية حل التبعيات الفعلية لأداة البناء — وليس مسحاً لاحقاً لنظام الملفات. قدرة الدمج في CLI لا تُقدّر بثمن للمستودعات الأحادية وبُنى الخدمات المصغّرة حيث تحتاج إلى دمج قوائم SBOM لكل خدمة في قائمة SBOM على مستوى المنتج. يضمن التحقق من المخطط أن قوائم SBOM تتوافق مع المواصفات قبل التوزيع. دعم VEX هو الأكثر نضجاً في هذا النظام البيئي.
القيود
يتطلب نهج CycloneDX دمج إضافة خاصة بكل لغة في نظام البناء الخاص بك. هذا عمل أكثر من تشغيل ثنائي واحد على صورة حاوية. CLI نفسه لا يمسح الحاويات أو أنظمة الملفات بحثاً عن الحزم — تحتاج إلى إضافات اللغات للتوليد. دعم SPDX محدود مقارنة بـ Syft وTrivy. الأدوات أكثر تجزؤاً (CLI + إضافات متعددة) مقابل ثنائي واحد.
أمثلة على الاستخدام
# Generate SBOM during Maven build
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom
# Generate SBOM from npm project
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
# Merge multiple SBOMs
cyclonedx merge --input-files sbom-api.cdx.json sbom-frontend.cdx.json --output-file product-sbom.cdx.json
# Validate an SBOM against the schema
cyclonedx validate --input-file sbom.cdx.json --fail-on-errors
# Diff two SBOMs to see what changed between releases
cyclonedx diff --from v1-sbom.cdx.json --to v2-sbom.cdx.json
جدول المقارنة المباشرة
| الميزة | Syft | Trivy | CycloneDX CLI + الإضافات |
|---|---|---|---|
| الغرض الأساسي | توليد SBOM | ماسح أمني شامل | معالجة SBOM + التوليد وقت البناء |
| مخرجات SPDX | JSON وtag-value (ممتاز) | JSON (جيد) | تحويل محدود فقط |
| مخرجات CycloneDX | JSON وXML (ممتاز) | JSON (ممتاز) | JSON وXML وProtobuf (أصلي، الأفضل) |
| مسح الحاويات | نعم (سجل، daemon، tarball) | نعم (سجل، daemon، tarball) | لا (وقت البناء فقط) |
| مسح نظام الملفات | نعم | نعم | عبر إضافات اللغات |
| التحليل الثنائي | قوي (ثنائيات Go وRust) | متوسط | لا يوجد |
| فحص الثغرات | لا (استخدم Grype) | نعم (مُدمج) | لا (استخدم أداة منفصلة) |
| الدقة (عمق التبعيات) | ممتاز | جيد جداً | الأفضل (حل وقت البناء) |
| دمج/مقارنة SBOM | لا | لا | نعم (أصلي) |
| دعم VEX | عبر Grype/Vunnel | دعم OpenVEX | VEX أصلي من CycloneDX |
| توقيع التصديق | عبر تكامل cosign | عبر تكامل cosign | تصديق BOM-Link |
| تكامل CI/CD | GitHub Action وCLI | GitHub Action وCLI ومُشغّل Kubernetes | إضافة بناء لكل لغة |
| السرعة (حاوية نموذجية) | سريع (15-30 ثانية) | متوسط (20-60 ثانية مع تنزيل قاعدة البيانات) | الأسرع (مُدمج في البناء، بدون مسح منفصل) |
| مسح مجموعة Kubernetes | لا | نعم | لا |
الدقة والاكتمال: حيث يهم الأمر حقاً
دقة SBOM هي أهم عامل تمييز. قائمة SBOM غير مكتملة أسوأ من عدم وجود قائمة SBOM — فهي تمنح ثقة زائفة.
إضافات CycloneDX وقت البناء تتفوق في الدقة لسبب واضح: فهي تتصل بمُحلّل مدير الحزم أثناء البناء. عندما يعمل cyclonedx-maven-plugin، يرى نفس شجرة التبعيات التي حلّها Maven بالضبط. لا تخمين ولا مطابقة استدلالية — يقرأ الرسم البياني المحلول مباشرة.
Syft يأتي ثانياً. بنية المُفهرسات مُعدّة خصيصاً لتحليل ملفات القفل والبيانات الوصفية والبيانات الوصفية الثنائية بدقة عالية. يتفوق Syft في اكتشاف المكونات التي تفوتها الأدوات الأخرى — خاصة ثنائيات Go (التي تُضمّن معلومات الوحدات)، وثنائيات Rust، وملفات Java uber-jars ذات التبعيات المُضمّنة.
Trivy جيد جداً لمعظم حالات الاستخدام لكنه قد يفوّت حالات خاصة في التحليل الثنائي. قوته في الاتساع — يُغطي أنواع مصادر أكثر (Kubernetes والسحابة) حتى لو كان العمق لكل مصدر أقل قليلاً من Syft في بعض السيناريوهات.
تكامل CI/CD: إدخال قوائم SBOM في خط الإنتاج
تتكامل جميع الأدوات الثلاث مع خطوط إنتاج CI/CD، لكن أنماط التكامل تختلف بشكل كبير:
Syft في CI/CD
يوفر Syft GitHub Action رسمي (anchore/sbom-action) يُولّد قوائم SBOM ويرفعها اختيارياً كلقطات تبعيات GitHub. لأنظمة GitLab وJenkins وأنظمة CI الأخرى، تثبيت واستدعاء ثنائي CLI بسيط ومباشر. ادمجه مع anchore/scan-action (Grype) لبوابات فحص الثغرات.
Trivy في CI/CD
يوفر Trivy أوسع سطح تكامل مع CI/CD: GitHub Action (aquasecurity/trivy-action)، ومُشغّل Kubernetes (Trivy Operator)، ومخرجات SARIF لتكامل GitHub Code Scanning. يمكن لخطوة Trivy واحدة إنتاج SBOM وفحص الثغرات والتحقق من التكوينات الخاطئة واكتشاف الأسرار — مما يحل محل ثلاث أو أربع أدوات منفصلة.
CycloneDX في CI/CD
يتطلب تكامل CycloneDX إضافة الإضافة المناسبة للغة إلى تكوين البناء الخاص بك. لـ Maven، تضيف الإضافة إلى POM. لـ npm، تضيف سكريبت يستدعي @cyclonedx/cyclonedx-npm. هذا النهج الأصلي للبناء يعني أن SBOM يُولَّد كعنصر بناء إلى جانب تطبيقك، بدون خطوة مسح منفصلة.
متى تستخدم أي أداة
اختر Syft عندما:
- دقة توليد SBOM هي أولويتك القصوى
- تحتاج أقصى مرونة في صيغ الإخراج (SPDX + CycloneDX)
- تمسح صور حاويات أو عناصر مبنية مسبقاً (وليس الشيفرة المصدرية)
- تستخدم بالفعل أو تخطط لاستخدام Grype لفحص الثغرات
- تحتاج لتحليل ثنائيات مُجمّعة (Go وRust)
- تريد أداة خفيفة ومُخصّصة لغرض واحد بأقل تبعيات
اختر Trivy عندما:
- تريد أداة واحدة لتوليد SBOM وفحص الثغرات
- تحتاج لمسح مجموعات Kubernetes أو حسابات سحابية
- البساطة وتقليل تعقيد سلسلة الأدوات أهم من أقصى عمق لـ SBOM
- تريد اكتشاف التكوينات الخاطئة والأسرار مُدمجاً إلى جانب قوائم SBOM
- يفضل فريقك أداة واحدة مُصانة جيداً على تجميع مكونات متعددة
- تحتاج مخرجات SARIF لتكامل GitHub Code Scanning أو Azure DevOps
اختر CycloneDX CLI + الإضافات عندما:
- تحتاج أدق حل ممكن للتبعيات
- اعتمدت مؤسستك صيغة CycloneDX كمعيار
- تدير مستودعات أحادية وتحتاج لدمج قوائم SBOM لكل خدمة في قوائم على مستوى المنتج
- تحتاج لمقارنة قوائم SBOM بين الإصدارات لتتبع تغييرات التبعيات
- التحقق من صحة المخطط لقوائم SBOM قبل التوزيع هو متطلب
- توليد مستندات VEX جزء من سير عمل الإفصاح عن الثغرات لديك
خط إنتاج مُدمج: استخدام الأدوات الثلاث معاً
عملياً، تجمع العديد من المؤسسات الناضجة بين هذه الأدوات. إليك نمط خط إنتاج يستفيد من نقاط قوة كل منها:
# Stage 1: Build-time SBOM (most accurate dependency graph)
# In your Maven/npm/Go build step:
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom
# Output: target/bom.json (CycloneDX format)
# Stage 2: Container-level SBOM (catches OS packages + runtime deps)
syft packages myapp:${BUILD_TAG} -o cyclonedx-json > container-sbom.cdx.json
# Stage 3: Merge build-time and container SBOMs
cyclonedx merge \
--input-files target/bom.json container-sbom.cdx.json \
--output-file merged-sbom.cdx.json
# Stage 4: Validate the merged SBOM
cyclonedx validate --input-file merged-sbom.cdx.json --fail-on-errors
# Stage 5: Vulnerability scan the merged SBOM
trivy sbom merged-sbom.cdx.json --exit-code 1 --severity CRITICAL,HIGH
# Stage 6: Sign and attest
cosign attest --predicate merged-sbom.cdx.json \
--type cyclonedx myapp:${BUILD_TAG}
يحقق خط الإنتاج هذا أفضل ما في جميع العوالم: توفر إضافات CycloneDX دقة وقت البناء، ويُضيف Syft اكتشاف الحزم على مستوى الحاوية، ويدمج CycloneDX CLI قوائم SBOM المُدمجة ويتحقق منها، ويفحص Trivy الثغرات كبوابة جودة، ويوفر cosign التصديق التشفيري.
اعتبارات الأداء
السرعة مهمة في خطوط إنتاج CI/CD حيث لكل دقيقة من وقت البناء تكلفة:
- Syft سريع باستمرار. يكتمل مسح صورة حاوية نموذجية في 15-30 ثانية بدون الحاجة لتنزيل قاعدة بيانات خارجية. الثنائي خفيف ويبدأ فوراً.
- Trivy يتطلب تنزيل قاعدة بيانات ثغرات أولية (~30-50 ميغابايت) في التشغيل الأول، مما يُضيف 10-30 ثانية. التشغيلات اللاحقة مع ذاكرة تخزين مؤقتة مُحمّلة مسبقاً مشابهة لـ Syft. استخدام
--skip-db-updateفي CI (مع ذاكرة تخزين مؤقتة مُسخّنة مسبقاً) يُلغي هذا العبء. - إضافات CycloneDX تُضيف وقتاً ضئيلاً للبناء لأنها تعمل كجزء من عملية البناء الحالية. لا توجد مرحلة مسح منفصلة — SBOM هو ناتج ثانوي لحل التبعيات الذي حدث بالفعل.
التصديق والتوقيع: إثبات مصدر SBOM
SBOM غير موقّع هو مستند “ثق بي”. لكي يكون لقوائم SBOM قيمة حقيقية في أمن سلسلة التوريد، يجب أن تكون موقّعة تشفيرياً ومرتبطة بالعنصر الذي تصفه.
Syft + cosign هو سير عمل التصديق الأكثر نضجاً. استثمرت Anchore بكثافة في دعم تصديقات SLSA وin-toto، وصُمّمت مخرجات Syft لتُغذّي cosign attest مباشرة.
Trivy يدعم التصديق المبني على cosign ويمكنه التحقق من التصديقات الموجودة. مخرجات trivy image --format cosign-vuln تُنتج تقارير ثغرات جاهزة للتصديق.
CycloneDX يدعم BOM-Link، الذي يوفر آلية ربط قائمة على URI بين قوائم SBOM والعناصر التي تصفها. مع Sigstore أو in-toto، ينشئ هذا سلسلة قابلة للتحقق من المصدر إلى النشر.
الخلاصة
لا توجد أداة SBOM واحدة “أفضل” — الاختيار الصحيح يعتمد على احتياجاتك المحددة. لأعمق توليد SBOM، Syft هو المعيار الذهبي. للبساطة الشاملة، Trivy يُقلّل تعقيد سلسلة الأدوات بشكل كبير. لدقة وقت البناء وإدارة دورة حياة SBOM، نظام CycloneDX البيئي لا مثيل له.
أقوى نهج هو الجمع بينها: استخدم إضافات CycloneDX وقت البناء لأقصى دقة، وSyft لاكتشاف مستوى الحاوية، وCycloneDX CLI للدمج والتحقق، وTrivy لفحص الثغرات. أضف تصديق cosign فوق ذلك، وستحصل على خط إنتاج SBOM بمستوى الإنتاج يُلبّي EO 14028 وقانون CRA الأوروبي واحتياجاتك الأمنية التشغيلية.
مستعد لبناء خط الإنتاج هذا عملياً؟ اطّلع على مختبر SBOM للحصول على شرح خطوة بخطوة مع صور حاويات حقيقية وقوالب CI/CD.