SBOM چیست؟ راهنمای ساخت، ارزیابی و استفاده امنیتی

یک آسیب‌پذیری مهم مانند Log4Shell اعلام شده و مدیر امنیت فقط یک سؤال دارد: «کدام نسخه‌های ما واقعاً این جزء را دارند؟» اگر پاسخ تیم جست‌وجوی دستی در مخزن‌ها، حدس‌زدن از روی نام سرویس یا منتظرماندن برای صاحب هر محصول باشد، مسئله فقط اسکن امنیت نیست؛ موجودی نرم‌افزار قابل اتکا ندارید. SBOM قرار است این نقطه کور را کم کند، نه اینکه به‌تنهایی امنیت را تضمین کند.

در این راهنما می‌خوانید SBOM چیست، چگونه برای هر Artifact ساخته و ارزیابی می‌شود، SPDX و CycloneDX چه تفاوتی دارند، نتیجه اسکن آسیب‌پذیری چگونه Triage می‌شود و تیم‌های ایرانی با محدودیت دسترسی به Registry و Feed چه کنترل‌هایی لازم دارند. خروجی، یک فایل تزئینی برای ممیزی نیست؛ یک زنجیره قابل‌آزمون از Artifact → Component → Vulnerability → Evidence → Decision است.

SBOM چیست؟

Software Bill of Materials یا صورتحساب مواد نرم‌افزار، موجودی رسمی و ماشین‌خوانی از Componentها، اطلاعات شناسایی آن‌ها، Dependencyها و رابطه‌هایشان در یک محصول نرم‌افزاری است. تعریف به‌روز چارچوب شفافیت اجزای نرم‌افزار CISA تأکید می‌کند که موجودی باید تا حد امکان جامع باشد و جاهایی که رابطه معلوم نیست صریحاً اعلام شوند.

برای یک Image پرداخت، SBOM مفید فقط فهرست «OpenSSL، Log4j و چند Package» نیست. باید روشن کند:

• موضوع سند دقیقاً کدام Image/Package/Release و با چه Digest یا شناسه‌ای است؛
• هر جزء چه نام، نسخه، تأمین‌کننده و شناسه استانداردی دارد؛
• Dependency مستقیم است یا انتقالی و گراف تا کجا شناخته شده؛
• SBOM چه زمان، با کدام ابزار و از چه Generation Context ساخته شده؛
• کدام بخش‌ها کامل، ناقص، ناشناخته یا عمداً محدود شده‌اند.

SBOM چه مسئله‌ای را حل می‌کند؟

در رخداد امنیتی، تیم می‌تواند به‌جای سؤال از تک‌تک توسعه‌دهندگان، Releaseهای دارای Component خاص را Query کند. در خرید نرم‌افزار، مصرف‌کننده درباره شفافیت، چرخه پشتیبانی و پاسخ‌گویی تأمین‌کننده Contract می‌سازد. در CI/CD نیز Diff اجزا، Dependency جدید یا نسخه خارج از Policy پیش از انتشار دیده می‌شود.

SBOM چه چیزی نیست؟

• گزارش «نرم‌افزار امن است» یا گواهی نبود آسیب‌پذیری نیست؛
• جایگزین SCA، SAST، DAST، Pen Test یا Threat Modeling نیست؛
• به‌تنهایی نشان نمی‌دهد Component آسیب‌پذیر Reachable یا قابل بهره‌برداری است؛
• به‌تنهایی ثابت نمی‌کند Artifact از Source مورد انتظار و Build سالم تولید شده؛
• تفسیر حقوقی مجوزهای متن‌باز یا انطباق قانونی نیست؛
• فهرست Assetهای نصب‌شده سازمان یا CMDB کامل نیست.

برای مرز Toolها و Signalهای مکمل، راهنمای ابزارهای تست امنیت را ببینید.

مرز SBOM با SCA، VEX، Provenance و امضا

SLSA Provenance 1.2 منشأ را اطلاعات قابل‌راستی‌آزمایی درباره محل، زمان و شیوه تولید Artifact تعریف می‌کند. پس امضای SBOM می‌تواند تمامیت و هویت صادرکننده همان Statement را بررسی‌پذیر کند، اما SBOM امضاشده هنوز ممکن است ناقص باشد. Hash داخل یک SBOM نامطمئن نیز صرفاً یک ادعاست؛ Consumer باید Subject، Digest، امضا، زنجیره اعتماد و Policy را مستقلاً Verify کند.

نقطه شروع: هویت دقیق Artifact

بیشترین خطای عملی زمانی رخ می‌دهد که تیم SBOM را برای «پروژه فروشگاه» می‌سازد، نه برای Artifact غیرقابل‌تغییر. نام و Version قابل بازنویسی‌اند؛ Digest باید مرجع اصلی پیوند باشد.

قرارداد Subject

برای هر Release این فیلدها را در Manifest نگه دارید:

• Product و Component سطح بالا؛
• نسخه Release و Commit/Tag؛
• Artifact URI مانند Registry/Repository؛
• Digest الگوریتم قوی مانند SHA-۲۵۶؛
• Platform/Architecture و Variant؛
• Build ID و زمان تولید؛
• SBOM ID، Format/Version و Digest خود SBOM؛
• Provenance/Signature reference و Policy نتیجه Verify.

اگر یک Release برای amd64 و arm64 دو Image متفاوت دارد، هرکدام Subject و SBOM خود را می‌خواهد؛ SBOM یک Manifest چندمعماری نباید تفاوت Binaryها را پنهان کند.

انواع SBOM و دلیل تفاوت خروجی ابزارها

راهنمای انواع SBOM از CISA شش Context رایج Design، Source، Build، Analyzed، Deployed و Runtime را تفکیک می‌کند. هیچ نوعی در همه Use caseها کامل‌ترین نیست.

Source و Design

Lockfile، Manifest و Source tree را خوب می‌بینند و برای بازخورد زودهنگام مفیدند؛ اما Build flag، حذف Dependency، Package سیستم‌عامل، Vendoring، Generated binary یا جزء تزریق‌شده در Image را ممکن است نبینند.

Build

در جریان ساخت، به ورودی‌های واقعی و خروجی Release نزدیک است. اگر Build hermetic نیست یا ابزار فقط Ecosystem package manager را می‌خواند، همه اجزای نهایی را تضمین نمی‌کند. Build SBOM را کنار Artifact و Provenance تولید کنید، نه با اسکن دوباره Tag قابل‌تغییر.

Analyzed یا Post-build

Binary، Package، Container image یا VM را پس از ساخت تحلیل می‌کند و می‌تواند Packageهای OS و فایل‌های Vendored را پیدا کند؛ ولی نتیجه به Signature/Heuristic وابسته است و ممکن است نسخه یا Dependency graph را اشتباه یا Unknown گزارش کند.

Deployed و Runtime

آنچه واقعاً نصب یا در اجرا دیده می‌شود، Configuration، Dynamic library و Pluginهای دیرهنگام را بهتر منعکس می‌کند؛ اما مسیر کم‌استفاده یا Component بارگذاری‌نشده ممکن است دیده نشود. Runtime observation نبودن Component را ثابت نمی‌کند.

رویکرد قابل دفاع، مقایسه چند View است: Source برای قصد، Build برای ورودی واقعی، Analyzed برای خروجی و Deployed برای وضعیت محیط. Diffها باید به‌عنوان Signal بررسی شوند، نه اینکه فایل‌ها بدون Provenance در یک فهرست ادغام و منشأ هر Claim گم شود.

حداقل داده‌های لازم در SBOM

حداقل عناصر NTIA در سال ۲۰۲۱ کف شناخته‌شده‌ای از Data fields، Automation support و Practices/processes ارائه کرد: تأمین‌کننده، نام و نسخه Component، شناسه‌های دیگر، Dependency relationship، نویسنده SBOM و Timestamp.

پیش‌نویس عمومی CISA در ۲۰۲۵ مواردی مانند Component hash، License، Tool name و Generation context را اضافه و Coverage، Known unknowns، Distribution، Frequency و Identifierها را دقیق‌تر می‌کند. این سند صریحاً پیش‌تصمیم و برای نظر عمومی است؛ آن را الزام نهایی دولت آمریکا یا قانون ایران معرفی نکنید. بااین‌حال، برای طراحی Contract داخلی منبع مفیدی است.

فیلدهای عملی پیشنهادی

• SBOM author، Software producer، Product و Supplier هر Component؛
• نام، Namespace، Version و Qualifier دقیق؛
• PURL و در صورت کاربرد CPE یا شناسه Ecosystem؛
• Hash Component و Digest Subject؛
• رابطه direct/transitive/contains/dependsOn و Parent؛
• License assertion/concluded با Provenance داده؛
• Tool name/version/config، Timestamp و Generation context؛
• Coverage، Completeness، Known unknowns و دلیل Redaction؛
• External reference به Source، Distribution و Advisory؛
• Document ID/version و اطلاعات امضا یا Attestation.

نام «commons-io» بدون Ecosystem، Namespace و Version برای Match مطمئن کافی نیست. PURL می‌تواند هویت Package را استانداردتر کند؛ CPE برای برخی Productها مفید است، اما نگاشت خودکار PURL/CPE/CVE همیشه بدون خطا نیست.

SPDX یا CycloneDX؛ کدام فرمت بهتر است؟

پاسخ از قابلیت Consumer و Contract تبادل می‌آید، نه از رتبه‌بندی کلی.

SPDX

صفحه رسمی مشخصات SPDX نسخه جاری را ۳.۰ و این خانواده را استاندارد باز بین‌المللی ISO/IEC ۵۹۶۲:۲۰۲۱ معرفی می‌کند. SPDX از تمرکز اولیه بر License فراتر رفته و مدل‌های Software، Security، Build، Dataset و AI دارد. Consumer باید Profile و Serialization دقیق مورد پشتیبانی خود را اعلام کند؛ صرف عبارت «SPDX-compatible» Contract کافی نیست.

CycloneDX

CycloneDX 1.7 نسخه جاری این استاندارد ماژولار است و JSON، XML و Protobuf، گراف Dependency، Component/Service، Composition completeness، Vulnerability، Formulation و Annotation را پشتیبانی می‌کند. توانایی Schema برای ثبت Vulnerability یا Signature به معنی آن نیست که هر فایل CycloneDX همه این بخش‌ها را دارد.

معیار انتخاب

اگر Vendor یک فرمت و Scanner شما فرمت دیگر می‌خواهد، تبدیل را با Fixture واقعی و Diff معنایی تست کنید. تبدیل موفق فایل، حفظ همه Semantics را تضمین نمی‌کند.

قرارداد کیفیت SBOM؛ تستر دقیقاً چه چیزی را بررسی کند؟

وظیفه QA شمارش Component نیست؛ سنجش Fitness for use است. برای هر Product و نوع SBOM، Test contract نسخه‌دار بسازید.

۱. اعتبار ساختاری و قابلیت مصرف

• فایل با Schema همان Format/version معتبر است؛
• Document ID، Timestamp و Root component وجود و نوع درست دارند؛
• Referenceها یکتا و همه Dependency edgeها قابل Resolve هستند؛
• Consumer واقعی فایل را بدون Drop کردن Fieldهای ضروری ingest می‌کند؛
• حجم، Encoding و Unicode نام‌های داخلی Pipeline را نمی‌شکند.

۲. اتصال به Subject

• Digest ثبت‌شده با Artifact دریافتی برابر است؛
• Product/version/platform با Release manifest تطبیق دارد؛
• SBOM پس از Build همان Artifact تولید شده و Tag دوباره Resolve نشده؛
• Signature/Attestation با Identity و Trust policy معتبر Verify می‌شود؛
• SBOM قدیمی به Artifact جدید Attach نشده است.

۳. پوشش و کامل‌بودن

• Dependencyهای مستقیم Lockfile با SBOM تطبیق دارند؛
• Transitive، OS package، binary، plugin، vendored code و private fork نمونه‌برداری می‌شوند؛
• Componentهای Development/Test از Runtime با Scope روشن جدا هستند؛
• Known unknown و ناحیه اسکن‌نشده به‌جای حذف ساکت ثبت می‌شود؛
• گراف orphan، cycle ناموجه یا Root بدون child بررسی می‌شود.

۴. صحت شناسایی و داده

• نام، Namespace، Version و PURL با Package manager/Artifact قابل تطبیق‌اند؛
• Hash با Bytes Component، در جایی که استخراج معتبر ممکن است، مقایسه می‌شود؛
• Version مبهم مانند latest، unknown یا range بدون دلیل Gate می‌شود؛
• License داده و Provenance آن ثبت می‌شود؛ تفسیر مجوز با Legal است؛
• Tool/version/config و Generation context برای بازتولید نتیجه موجود است.

۵. پایداری و Diff

یک Artifact ثابت را با Tool/config ثابت دوباره اسکن کنید. تغییر ترتیب JSON یا Document timestamp نباید به صدها Component change جعلی تبدیل شود. Diff را Normalize و این رویدادها را جدا کنید: Added، Removed، Version changed، Identity enriched، Relationship changed، Coverage changed و Tool changed.

Pipeline عملی تولید و مصرف SBOM

1. Policy: Productها، Artifactها، Format/version، Context و Owner را تعریف کنید.
2. Generate: SBOM را نزدیک Build و با ورودی/ابزار Pin‌شده بسازید.
3. Validate: Schema، Required field، graph، identity و quality thresholds را تست کنید.
4. Bind: SBOM را به Digest Artifact و Build ID متصل کنید.
5. Sign/attest: Statement را با Identity ماشین و Policy قابل Verify صادر کنید.
6. Store: Artifact، SBOM، Provenance و Evidence را با Retention و Access control نگه دارید.
7. Ingest: موجودی مرکزی را با Document version و منبع Claim به‌روز کنید.
8. Monitor: Advisory/CVE/KEV/EPSS و Vendor bulletin جدید را به Inventory Match کنید.
9. Triage: Match، affected range، reachability، exposure، impact و control را بررسی کنید.
10. Act: Update/rebuild، mitigation، isolation، risk acceptance یا investigation اجرا شود.
11. Publish: SBOM/VEX جدید و Release evidence پس از تغییر ساخته شود.

این جریان در معماری Continuous Testing یک Lane امنیتی است و در Pipeline تست خودکار Jenkins و GitLab باید به Artifact immutable متصل شود. SBOM را در Cache موقت Job رها نکنید؛ یک Release evidence است.

Gate پیشنهادی

Build را برای Schema نامعتبر، Subject digest مفقود، Root نامعلوم، Dependency direct بدون Version یا افت ناگهانی Coverage متوقف کنید. CVE Match خام را کورکورانه Block نکنید؛ Policy می‌تواند KEV تأییدشده، Vulnerability واقعاً Affected با Exposure بالا یا پایان SLA را Gate کند. Exception باید Owner، دلیل، کنترل جبرانی و Expiry داشته باشد.

از Component تا CVE؛ چرا Match خودکار کافی نیست؟

نام Packageها با نام Product در NVD/Vendor advisory همیشه یکی نیست. Fork داخلی، Backport امنیتی بدون تغییر Version، Package توزیع لینوکس، Fat jar، shaded library و CPE عمومی می‌توانند False positive یا False negative بسازند.

فرایند Triage هشت‌مرحله‌ای

1. Subject و نسخه SBOM را با Release در حال اجرا تأیید کنید.
2. Component identity را با PURL/namespace/hash و منبع Package بازسازی کنید.
3. CVE و Affected range را در Advisory ناشر و منابع معتبر کنترل کنید.
4. وجود Component/نسخه را در Artifact و در صورت لزوم Deployed view تأیید کنید.
5. Reachability، Configuration، Platform و Feature فعال را بررسی کنید.
6. Exposure، privilege، داده، tenant و Blast radius را بسنجید.
7. KEV، EPSS، شدت فنی، Impact کسب‌وکار و کنترل جبرانی را ترکیب کنید.
8. نتیجه Affected/Not affected/Fixed/Under investigation، Evidence و اقدام را ثبت کنید.

کاتالوگ KEV از CISA منبع معتبر آسیب‌پذیری‌های مشاهده‌شده در بهره‌برداری واقعی و یک ورودی مهم اولویت است. EPSS از FIRST احتمال مشاهده بهره‌برداری در ۳۰ روز آینده را برآورد می‌کند، اما Impact، محیط شما و کنترل جبرانی را نمی‌داند و Risk score کامل نیست.

CVSS شدت ویژگی‌های Vulnerability را خلاصه می‌کند؛ Priority عملی می‌تواند چنین داده‌هایی را کنار هم بگذارد:

Priority evidence = confirmed presence
 affected configuration/reachability
 internet or trust-boundary exposure
 KEV / current threat evidence / EPSS
 business and data impact
 compensating controls
 fix availability, change risk and time

برای Signal-to-decision عمومی‌تر و Retest، راهنمای تست امنیت نرم‌افزار را مبنا قرار دهید.

VEX چیست و چگونه نویز را کم می‌کند؟

Vulnerability Exploitability eXchange یک Statement ماشین‌خوان درباره وضعیت Product/Component نسبت به Vulnerability مشخص است. حداقل الزامات VEX از CISA چهار وضعیت رایج Affected، Not affected، Fixed و Under investigation را توضیح می‌دهد. همان سند تصریح می‌کند که این کار جامعه‌محور، سیاست رسمی یا الزام CISA نیست.

VEX خوب چه دارد؟

• Document ID، Author، Timestamp و Version؛
• هویت دقیق Product/Component و Vulnerability؛
• Status و Action statement؛
• برای Not affected، Justification معتبر مانند code_not_present یا vulnerable_code_not_in_execute_path؛
• Impact statement و Evidence reference؛
• زمان بازبینی/انقضا هنگام تغییر Configuration یا Version؛
• امضا/Attestation و Trust policy مصرف‌کننده.

VEX قدیمی را دائمی فرض نکنید. Upgrade، Feature flag، plugin یا تغییر مسیر اجرا ممکن است نتیجه Reachability را عوض کند. Under investigation باید Owner و Deadline داشته باشد؛ Not affected بدون Justification راهی برای خاموش‌کردن هشدار نیست.

مثال رخداد: پاسخ به Log4j بدون جست‌وجوی دستی

فرض کنید یک شرکت ایرانی سه محصول، ۷۰ سرویس و چند Image قدیمی دارد. CVE جدید برای Log4j اعلام می‌شود.

1. Inventory مرکزی روی Package identity و Version query می‌شود؛ زمان Query و نسخه Feed ثبت می‌گردد.
2. هر Match به Product، Artifact digest، Environment و Owner متصل می‌شود.
3. Imageهای Source-only با Analyzed/Deployed view کنترل می‌شوند تا Fat jar و Image پایه جا نماند.
4. Vendor advisory و محدوده نسخه تأیید و Fork/Backport جدا بررسی می‌شود.
5. Internet exposure، مسیر JNDI، Configuration و کنترل خروجی شبکه ارزیابی می‌شوند.
6. نسخه در معرض خطر Rebuild و همان Artifact جدید تست و Promote می‌شود.
7. SBOM و Provenance جدید تولید و Digest قدیم از Deployment حذف می‌شود.
8. VEX برای هر Product با Evidence منتشر و Inventory دوباره Query می‌شود.

«صفر Match» فقط وقتی نتیجه قابل دفاع است که Coverage، Freshness و Known unknown معلوم باشند. Query روی موجودی ناقص، اطمینان کاذب را سریع‌تر تولید می‌کند.

SBOM در خرید نرم‌افزار و قرارداد تأمین‌کننده

در RFP یا قرارداد، جمله «Vendor باید SBOM بدهد» مبهم است. این Acceptance criteriaها را متناسب با ریسک محصول تعیین کنید:

• فرمت، نسخه، Profile و Schema مشخص؛
• یک SBOM برای هر Release/Platform متصل به Artifact digest؛
• Generation context، Tool/version و حداقل Coverage؛
• Component identity، direct/transitive relationships و Known unknowns؛
• روش امن Delivery، Access control، Retention و امکان Automation؛
• Frequency: هر Release و هنگام تغییر Component؛
• VEX یا Advisory machine-readable برای Matchهای پرخطر؛
• مهلت اعلان Vulnerability، Mitigation و نسخه اصلاحی؛
• EOL/EOS، Patch policy، Fork و Sub-supplier obligations؛
• حق انجام Validation/PoC و فرایند رفع SBOM ناقص.

SBOM دریافتی را مثل هر Input غیرقابل اعتماد Schema-validate و در محیط محدود Parse کنید. QA صحت داده و تطبیق با Contract را می‌سنجد؛ Legal درباره الزام قراردادی، مجوز و کاربرد قانونی تصمیم می‌گیرد.

چالش‌های SBOM در ایران و کنترل‌های عملی

دسترسی ناپایدار به Registry و Feed

تحریم، محدودیت جغرافیایی، Rate limit، قطعی یا TLS inspection می‌تواند Package metadata، Advisory و Vulnerability feed را ناقص کند. Mirror داخلی با Snapshot زمان‌دار، Digest/signature verification و Log منشأ بسازید. «آخرین همگام‌سازی» و Staleness باید روی داشبورد دیده شود؛ آفلاین‌بودن نباید به معنی نامعلوم‌بودن بی‌صدا باشد.

Package داخلی، Fork خصوصی و Backport

برای Package داخلی Namespace و PURL policy یکتا تعریف کنید. Fork باید Upstream، Commit مبنا، Patchها و Version داخلی قابل‌ردیابی داشته باشد. Backport ممکن است CVE را رفع کند ولی Scanner به‌سبب Version قدیمی هشدار دهد؛ VEX و Evidence Patch لازم است. تغییر Version برای ساکت‌کردن Scanner داده را فاسد می‌کند.

Vendor بدون پشتیبانی یا ابزار Cloud-only

یک PoC آفلاین/On-prem برای تولید، Validate و Query انتخاب کنید؛ Database و Rule snapshot باید Checksum و زمان داشته باشد. Exit test اجرا کنید: آیا فایل استاندارد را می‌توان بدون Vendor SaaS خواند و Archive کرد؟ Secret، Source code و معماری حساس را بدون Data-flow و مجوز به سرویس خارجی نفرستید.

متن فارسی و منطق بومی

نام Packageهای داخلی با حروف فارسی/عربی، نیم‌فاصله، اعداد فارسی/لاتین و Normalization متفاوت می‌توانند Identity collision بسازند. Identifier ماشین را ASCII و پایدار نگه دارید و Display name فارسی را جدا ثبت کنید. Productهای پرداختی باید Packageهای مرتبط با ریال/تومان، تقویم و PSP adapter را با Owner و Support lifecycle روشن داشته باشند.

برای Mobile SDK و کتابخانه‌های بسته، تست امنیت اپلیکیشن موبایل و برای Pipelineهای داده و Packageهای تحلیلی، امنیت دریاچه داده مکمل این راهنما هستند.

امنیت خود SBOM

SBOM می‌تواند معماری، نسخه‌های قدیمی، Endpoint، Supplier و Component خصوصی را افشا کند. از سوی دیگر، دستکاری آن می‌تواند Scanner را منحرف کند.

• Public/private classification و Audience را بر اساس Threat model تعیین کنید؛
• Secret، Token، مسیر محلی حساس و Credential را هرگز در SBOM نگذارید؛
• Access control، audit، encryption و retention برای Repository اعمال کنید؛
• Document/Artifact digest و Signature/Attestation را Verify کنید؛
• Parser را sandbox و اندازه/عمق/External reference را محدود کنید؛
• Redaction را اعلام کنید تا Consumer آن را با Completeness اشتباه نگیرد؛
• کلید امضا، Identity workload و فرایند Revocation را مدیریت کنید.

متریک‌های سالم برنامه SBOM

تعداد Component یا تعداد CVE به‌تنهایی KPI موفقیت نیست. موجودی دقیق‌تر ممکن است CVE بیشتری نشان دهد؛ این افزایش می‌تواند بهبود مشاهده‌پذیری باشد.

برنامه ۳۰روزه پیاده‌سازی SBOM

هفته اول: Use case و خط مبنا

یک سرویس پرریسک و یک Artifact واقعی انتخاب کنید. Owner، Consumer، Format/version، Subject identity، Context و پنج سؤال رخداد را مشخص کنید. Source و Image نهایی را با دو View بررسی و Gapها را ثبت کنید.

هفته دوم: قرارداد کیفیت و CI

Schema، Required fields، Digest binding، direct dependency sample، Known unknown و Diff normalization را خودکار کنید. فایل را همراه Artifact نگه دارید و Pipeline در افت Coverage Fail شود.

هفته سوم: مصرف و Triage

SBOM را در Inventory ingest و یک CVE واقعی/آزمایشی را از Match تا Advisory، Reachability، KEV/EPSS و تصمیم دنبال کنید. چهار وضعیت VEX و Evidence template را تمرین کنید.

هفته چهارم: Vendor و Incident drill

Contract یک Supplier را با Acceptance criteria بازبینی کنید. یک رخداد فرضی Component recall اجرا، Query snapshot و زمان‌ها را ثبت و نتیجه را با این معیارها تصمیم‌گیری کنید: Adopt، Adapt، Expand یا Stop.

ضدالگوهای رایج

• تولید یک SBOM برای نام Project به‌جای هر Artifact digest؛
• ساخت SBOM فقط از package manifest و ادعای پوشش Runtime؛
• اتکا به Tag مانند latest یا Version بازنویسی‌شونده؛
• درست دانستن هر CVE match یا بی‌خطر دانستن هر No-match؛
• اولویت‌بندی فقط با CVSS و نادیده‌گرفتن KEV/exposure/impact؛
• استفاده از VEX دائمی و Not affected بدون Evidence؛
• امضاکردن فایل ناقص و معرفی امضا به‌عنوان تضمین صحت محتوا؛
• تبدیل SPDX/CycloneDX بدون Semantic round-trip test؛
• بی‌صدا حذف‌کردن Component ناشناخته یا Redacted؛
• ارسال Source/SBOM حساس به SaaS بدون Data-flow و مجوز؛
• سپردن تفسیر حقوقی License به Scanner یا QA؛
• اندازه‌گیری موفقیت با تعداد SBOM، Component یا CVE.

چک‌لیست انتشار

• هر Artifact/Platform منتشرشده SBOM مستقل و Digest-bound دارد.
• Format، version، profile، schema و Consumer test موفق‌اند.
• Root، Component identity، Version، PURL/hash و Dependency graph قابل Resolve هستند.
• Generation context، Tool/version/config، Timestamp و Coverage ثبت شده‌اند.
• Unknown، Redaction، private fork و Vendored component صریح‌اند.
• Source/Build/Analyzed/Deployed اختلاف‌های مهم Triage شده‌اند.
• Signature/Attestation و Trust policy مستقل Verify شده‌اند.
• Advisory matching، KEV/EPSS و VEX workflow Owner/SLA دارند.
• SBOM حاوی Secret نیست و Repository دسترسی/Audit/Retention دارد.
• نسخه قبلی با Query رخداد قابل بازیابی و نسخه جدید Diff‌پذیر است.

سؤالات متداول

جمع‌بندی

ارزش SBOM از تعداد فایل‌های تولیدشده نمی‌آید؛ از توان پاسخ‌گویی دقیق می‌آید: کدام Artifact، دقیقاً کدام Component را، با چه هویتی و چه درجه‌ای از اطمینان دارد؛ Match آسیب‌پذیری چگونه Triage شد؛ و تصمیم چه Evidence، Owner و تاریخ انقضایی دارد؟ از یک Artifact پرریسک شروع کنید، SBOM را به Digest آن ببندید، کیفیت را مثل یک API contract تست کنید و جریان را تا VEX، اصلاح، Rebuild و Incident recall ببندید.