SBOM و Build Provenance

این درس قرار نیست یک CI/CD واقعی، registry واقعی یا signing service را پیکربندی کند. محیط SEC015-LAB1 کاملاً local و synthetic است و فقط از JSON و متن بی‌خطر استفاده می‌کند. هدف، پاسخ‌دادن به سه سؤال جداست: «این artifact چیست؟»، «چه componentهایی برای آن گزارش شده‌اند؟» و «این artifact طبق provenance چگونه و توسط کدام builder ساخته شده است؟».

خروجی اصلی درس SBOM & Build Provenance Verification Record v1 است. این record باید artifact، SBOM، provenance، policy decision، negative evidence و residual risk را در یک زنجیره‌ی قابل ممیزی نگه دارد.

1. SBOM و Build Provenance یک چیز نیستند

SBOM عمدتاً inventory و relationshipهای componentها را توصیف می‌کند. Build provenance درباره‌ی origin و process ساخت است: چه build typeای اجرا شده، چه builderی آن را انجام داده، چه inputهایی استفاده شده‌اند و output به کدام subject digest وصل شده است. اگر یکی از این دو را جای دیگری بنشانیم، evidence ناقص می‌شود.

SBOM نمی‌گوید build مورد اعتماد بوده است. provenance هم به‌تنهایی نمی‌گوید inventory dependencyها کامل است. تصمیم بهتر زمانی شکل می‌گیرد که هر دو به همان artifact متصل شوند و policy اعتماد نیز جداگانه بررسی شود.

2. اول artifact را ثابت کن، بعد metadata را تفسیر کن

در baseline یک artifact مصنوعی به نام acme-app-3.2.0 با یک SHA-256 ساختگی ولی ثابت داریم. SBOM و provenance هر دو باید به همین identity و digest مربوط باشند. اگر SBOM مربوط به 3.1.0 باشد یا provenance subject.digest دیگری را نشان دهد، schema-valid بودن فایل کمکی به تصمیم release نمی‌کند.

این اصل از یک خطای رایج جلوگیری می‌کند: «فایل metadata پیدا شد، پس حتماً برای همین artifact است.»

3. SBOM چه evidenceای می‌دهد

در fixture، SBOM یک primary component و dependencyهای مستقیم/انتقالی اعلام‌شده را نگه می‌دارد. ما component name, version, purl, hash و dependency relationship را به‌عنوان observation ثبت می‌کنیم. این درس از SBOM برای inventory transparency استفاده می‌کند، نه برای اثبات بی‌خطر بودن نرم‌افزار.

اگر یک dependency لازم از fixture حذف شود، نتیجه‌ی local policy می‌تواند DENY_SBOM_COVERAGE باشد؛ این فقط درباره‌ی coverage مورد انتظار در همین سناریوی آموزشی است، نه حکم جهانی درباره‌ی همه‌ی SBOMها.

4. SPDX و CycloneDX را با claim درست استفاده کن

SPDX و CycloneDX هر دو استانداردهای شناخته‌شده‌ی BOM هستند، اما این درس نمی‌خواهد یکی را «برنده» اعلام کند. baseline از یک representation ساده‌ی آموزشی استفاده می‌کند و فقط اصطلاحات و حدود claim را به استانداردهای رسمی متصل می‌کند.

در بازبینی منبع 17 سپتامبر 2026، صفحه‌ی رسمی SPDX نسخه‌ی پایدار 3.0 را current نشان می‌دهد؛ CycloneDX نیز 1.7 را نسخه‌ی current سری 1.x معرفی می‌کند. پیش‌نمایش‌ها یا release candidateها به‌عنوان authority پایدار این درس استفاده نمی‌شوند.

5. Build Provenance چه چیزی را اضافه می‌کند

SLSA provenance برای build، artifact output را در subject به digest وصل می‌کند و در predicate اطلاعاتی درباره‌ی buildDefinition و runDetails نگه می‌دارد. در مدل این درس، سه بخش مهم‌اند: subject.digest، builder.id و source revision داخل resolved dependencies.

وجود این فیلدها هنوز trust decision نهایی نیست. باید مشخص باشد کدام builder برای این release مجاز است و attestation identity مشاهده‌شده تحت policy محلی پذیرفته می‌شود یا نه.

6. subject digest مرز اتصال provenance به artifact است

اگر provenance برای artifact دیگری صادر شده باشد، بقیه‌ی فیلدهای زیبا و کامل بی‌اثر می‌شوند. probe منفی PROVENANCE_SUBJECT_MISMATCH فقط digest را تغییر می‌دهد و انتظار دارد تصمیم در همان boundary متوقف شود.

این failure با SBOM mismatch فرق دارد: اولی build-origin record را از artifact جدا می‌کند؛ دومی composition record را.

7. builder.id و attestation identity را از هم جدا نگه دار

در SLSA، builder identity نشان می‌دهد کدام build platform این invocation را انجام داده است. signer/attestation identity نیز بخشی از اعتماد به statement است. در lab رمزنگاری واقعی انجام نمی‌شود؛ فقط شناسه‌های synthetic داریم تا مدل تصمیم را تمرین کنیم.

baseline فقط https://builder.example/secure/v1 و attestor:test-build-A را مجاز می‌داند. اگر builder به https://builder.example/untrusted/v0 عوض شود، نتیجه DENY_UNAPPROVED_BUILDER است؛ حتی اگر subject digest همچنان درست باشد.

8. positive case چه چیزی را ثابت می‌کند

در baseline، artifact digest با SBOM target و provenance subject هماهنگ است، dependencyهای مورد انتظار حضور دارند، builder و attestation identity در policy مجازند و source revision همان revision مورد انتظار است. نتیجه ACCEPT_EVIDENCE_SET است.

این accept فقط می‌گوید evidence set در fixture با policy محدود سازگار است. هیچ ادعایی درباره‌ی malware-free بودن، نبود vulnerability، reproducible بودن build یا امنیت production مطرح نمی‌شود.

9. Negative Evidence اول: SBOM artifact mismatch

در probe اول، SBOM از acme-app-3.2.0 به acme-app-3.1.0 تغییر می‌کند ولی artifact واقعی همان baseline است. parser مشکلی ندارد، اما correlation شکست می‌خورد و باید DENY_SBOM_ARTIFACT_MISMATCH ثبت شود.

مهم است که failure را «SBOM خراب» ننامیم؛ ممکن است SBOM کاملاً معتبر باشد ولی برای artifact اشتباه باشد.

10. Negative Evidence دوم: provenance subject mismatch

در probe دوم فقط subject.digest.sha256 عوض می‌شود. builder و source revision همان مقادیر baseline هستند. decision باید DENY_PROVENANCE_SUBJECT_MISMATCH باشد.

این نشان می‌دهد اعتماد به builder جای artifact binding را نمی‌گیرد.

11. Negative Evidence سوم: unapproved builder

در probe سوم artifact و subject digest درست هستند، اما builder.id خارج از allowlist محلی است. نتیجه DENY_UNAPPROVED_BUILDER است. این failure درباره‌ی policy trust است، نه درباره‌ی syntax یا component inventory.

12. coverage و completeness را با صداقت ثبت کن

CISA در guidance جدید SBOM بر coverage و به‌روزرسانی SBOM همراه build/release تأکید می‌کند. در این درس coverage فقط با dependencyهای ازپیش‌تعریف‌شده‌ی fixture سنجیده می‌شود. اگر ecosystem واقعی dependencyهای dynamic، generated یا remote داشته باشد، همین مدل ساده کافی نیست.

پس Residual Risk باید همیشه توضیح دهد چه چیزهایی بیرون از lab باقی مانده‌اند.

13. Evidence Record چگونه پر می‌شود

برای هر case، record باید artifact_id, artifact_digest, sbom_format, sbom_version, sbom_component_count, sbom_artifact_match, provenance_predicate_type, provenance_subject_digest, builder_id, source_revision, attestation_identity, observed_state, acceptance_decision, negative_evidence, residual_risk را نگه دارد.

Observed State فقط output واقعی fixture است. Acceptance Decision نتیجه‌ی policy محلی است. Residual Risk جایی است که از overclaim جلوگیری می‌کنیم.

14. Changed-context transfer

در transfer case، application name ثابت می‌ماند اما digest، dependency graph و approved builder عوض می‌شوند. learner نباید decision baseline را کپی کند. باید artifact binding، SBOM coverage، provenance subject، builder policy و source revision را دوباره بسازد.

فیلد final_decision در template خالی می‌ماند تا تصمیم نهایی learner با ابزار جایگزین نشود.

15. مرز freshness منابع

بازبینی current-source در 17 سپتامبر 2026 فقط روی source plan ثبت‌شده انجام شده است. SPDX 3.0 به‌عنوان stable current، CycloneDX 1.7 به‌عنوان current 1.x، SLSA 1.2 به‌عنوان current specification و CISA 2025 Minimum Elements برای framing lifecycle/coverage استفاده شده‌اند. اگر این اسناد در review_due تغییر معنادار کنند، درس باید versioned requalification شود، نه silent edit.

16. خروجی نهایی Query 1

برای عبور از Macro-A، baseline positive، سه negative class، evidence template، assessment، bilingual parity و local executable lab باید هم‌زمان حاضر باشند. این Query درس را Golden نمی‌کند؛ فقط Atomic Candidate را برای F2-L2 — INTERNAL_ADVERSARIAL_PANEL آماده می‌کند.