SBOM Policy Template one signed document for scope, generation, signing, VEX, inbound vendor SBOMs, retention, and framework crosswalk
A free, copy-ready software bill of materials (SBOM) policy template. Twelve structured sections covering policy purpose and authority, outbound SBOM generation in CycloneDX 1.5 or SPDX 2.3 with NTIA Minimum Elements coverage, component depth and accuracy, signing and SLSA provenance with Sigstore Cosign and in-toto, publication and customer delivery channels, inbound third-party SBOM acceptance and ingestion, vulnerability matching and VEX (CSAF or CycloneDX VEX) publication policy, roles and RACI, retention and disposal per product class, framework crosswalk for NIST SSDF, CISA Self-Attestation, Executive Order 14028, EU Cyber Resilience Act, NIS2, DORA, FDA pre-market, and FAR/DFARS, governance and exception path, and document control with signed approval. Built for internal AppSec, product security, supply chain security, GRC, and CISO programmes that need a defensible policy artefact the procurement reviewer, the regulator, the build engineer, and the vulnerability manager all read on the same document.
Run the SBOM policy against the live component record, not against a separate spreadsheet
SecPortal carries every SBOM-derived finding, every inbound vendor SBOM import, every VEX status decision, and every retention disposition on one workspace so the policy commitments and the audit read are the same record. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn an SBOM intent into a defensible policy
A software bill of materials (SBOM) policy is the document a firm publishes so engineering, security, procurement, and audit operate against the same component-level visibility rules. The twelve sections below cover the durable shape of the artefact across NIST SP 800-218 (SSDF), CISA Self-Attestation Common Form, Executive Order 14028, the NTIA Minimum Elements, the EU Cyber Resilience Act Articles 13 and 14, NIS2 Article 21, DORA Article 28, CycloneDX 1.5, SPDX 2.3, SLSA v1.0, the in-toto specification, Sigstore Cosign, OASIS CSAF, and CycloneDX VEX. Copy the section that fits your stage and paste the rest as you go.
Copy the full policy (all twelve sections) as one block.
1. Policy purpose, scope, and authority
Open the policy with the firm intent and the executive authority. A reviewer should know in the first paragraph which entity publishes the policy, which product portfolio is in scope, which executive authority signed it, and the date the policy went into effect. NIST SP 800-218 (SSDF) practice PO.1.3 expects documented practices for software components; ISO/IEC 27001 Clause 5.2 expects documented information security policies with named authority. This section makes the SBOM policy traceable to the wider engineering and security programme rather than a stand-alone procurement document.
Policy title: Software Bill of Materials (SBOM) Policy
Policy version: {{POLICY_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next review date: {{NEXT_REVIEW_DATE}}
Purpose:
{{ENTITY_NAME}} produces and operates software that is consumed by enterprise buyers, regulated customers, and partner organisations who need component-level visibility for vulnerability management, procurement diligence, and regulator compliance. This policy publishes the rules {{ENTITY_NAME}} operates against for the creation, signing, publication, and inbound ingestion of software bills of materials (SBOMs) across the products we ship and the third-party software we consume.
Plain-language commitment:
{{PLAIN_LANGUAGE_COMMITMENT_PARAGRAPH}}
In scope (product and software classes the policy covers):
- First-party software products shipped under the {{ENTITY_NAME}} brand: {{PRODUCT_LIST}}
- Container images published to customer-facing registries: {{CONTAINER_IMAGE_LIST}}
- Hardware devices that embed firmware under the {{ENTITY_NAME}} brand: {{HARDWARE_DEVICE_LIST}}
- Mobile applications published under the {{ENTITY_NAME}} brand: {{MOBILE_APP_LIST}}
- Software-as-a-service offerings consumed by customers: {{SAAS_OFFERING_LIST}}
- Inbound third-party software the firm depends on for production operations: {{INBOUND_DEPENDENCY_CLASSES}}
Out of scope:
- Internal-only tooling consumed only by the {{ENTITY_NAME}} workforce.
- Marketing collateral, content websites, and short-link redirectors that do not host application code.
- One-off proof-of-concept code that does not enter the production release lifecycle.
- {{ADDITIONAL_OUT_OF_SCOPE_BOUNDARIES}}
Frameworks the policy evidences:
- NIST SP 800-218 (SSDF) practices PO.1.3, PS.3.2, PW.4.1, RV.1.1
- CISA Self-Attestation Common Form (Secure Software Development Attestation)
- Executive Order 14028 Section 4 (Improving the Nation Cybersecurity)
- NTIA Minimum Elements of an SBOM (2021)
- EU Cyber Resilience Act Articles 13 and 14
- NIS2 Directive Article 21 (supply chain security)
- DORA Regulation Article 28 (ICT third-party risk management)
- ISO/IEC 5962 (SPDX) and CycloneDX 1.5 (OWASP)
- SLSA v1.0 (Supply chain Levels for Software Artifacts)
- in-toto specification and Sigstore Cosign signing model
- OASIS CSAF (Common Security Advisory Framework) and CycloneDX VEX
Approving authority: {{APPROVING_AUTHORITY_NAME_AND_ROLE}}
Approval date: {{APPROVAL_DATE}}
2. Outbound SBOM generation, format, and depth
The generation commitment is the load-bearing section. It names the products and releases for which SBOMs are produced, the chosen format and schema version, the build-time integration rules, and the depth of the component graph the SBOM covers. NTIA Minimum Elements is the baseline; the policy commits to that baseline plus the deeper fields the firm chooses to populate (license, copyright, build provenance, supplier). The depth commitment names whether the SBOM covers only top-level dependencies or the full transitive closure plus container-image layers and platform runtime.
Outbound SBOM generation:
{{ENTITY_NAME}} produces an SBOM for every production release of every in-scope product. The SBOM is generated as part of the release pipeline rather than as a post-release reconstruction so the artefact reflects the actual shipped build rather than a snapshot of the source repository.
Primary SBOM format:
- Format: {{PRIMARY_FORMAT_CYCLONEDX_OR_SPDX}}
- Schema version: {{PRIMARY_SCHEMA_VERSION}}
- Encoding: JSON (preferred) and XML on request
- Profile: NTIA Minimum Elements plus the additional fields named in this section
Secondary SBOM format (accepted on inbound, produced on request):
- Format: {{SECONDARY_FORMAT}}
- Schema version: {{SECONDARY_SCHEMA_VERSION}}
NTIA Minimum Elements coverage (mandatory fields on every SBOM):
- Supplier name (the firm or open-source project that authored the component)
- Component name (canonical name in the upstream registry)
- Version of the component (semantic version, build identifier, or git commit hash as applicable)
- Other unique identifiers (PURL, CPE, or registry-specific identifier)
- Dependency relationships (the graph that names which component depends on which)
- Author of the SBOM data (the build system or person who produced the SBOM)
- Timestamp of when the SBOM was produced
Additional fields {{ENTITY_NAME}} populates beyond the NTIA baseline:
- License (SPDX license expression)
- Copyright statement where available
- Component hash (sha256) per component file or distribution
- Source repository URL where available
- Component evidence (the build-step that introduced the component)
- Build provenance reference (SLSA attestation or in-toto link statement)
Component depth commitment:
- Depth tier: {{DEPTH_TIER_LEVEL_1_OR_2_OR_3}}
- Tier 1 (top-level only): direct first-party dependencies declared in package manifests.
- Tier 2 (full transitive): the full closure of the dependency graph reachable through all package managers and language ecosystems used by the product.
- Tier 3 (transitive plus runtime): tier 2 plus base-image layers, system packages, runtime libraries, embedded firmware, and language-runtime components.
Build-time integration:
- Generator tooling: {{SBOM_GENERATOR_TOOLING}}
- Generation trigger: post-build, pre-release-publication
- Storage: SBOMs are published alongside the release artefact at {{SBOM_PUBLICATION_LOCATION}}
- Naming convention: {{PRODUCT_NAME}}-{{VERSION}}-{{ARCH}}-sbom.{{FORMAT_EXT}}
- Version history: every SBOM is associated with the immutable build identifier and retained per the retention rule in Section 9
Generation evidence:
- The build pipeline emits the SBOM-generation log per release into the activity record.
- The SBOM hash is recorded in the release notes.
- A reviewer can reproduce the SBOM from the named build by re-running the documented generator against the source tree at the release tag.
3. Accuracy, completeness, and freshness
An SBOM that misses components or that drifts behind the actual shipped artefact is worse than no SBOM. The accuracy section commits to the checks the firm runs on its own SBOMs before they leave the build pipeline and the refresh rule that keeps the artefact in step with the deployed build. The drift between the SBOM published with the marketing release and the SBOM that would be produced from the production registry digest is the audit-defensibility risk this section addresses.
Accuracy, completeness, and freshness commitments:
{{ENTITY_NAME}} treats the SBOM as the canonical component manifest for the deployed artefact. The artefact and the SBOM travel together; one is not published without the other.
Pre-publication accuracy checks:
- The build-time SBOM generator runs on the final release artefact, not on the source tree.
- Container images are scanned post-build with a layer-aware SBOM generator and the result is reconciled with the upstream Dockerfile dependency declarations.
- Language-runtime libraries surfaced by the build are reconciled against the explicit package manifest before publication.
- A diff against the previous release SBOM is reviewed; unexpected component additions or removals trigger a human review before publication.
Freshness commitments:
- Every production release produces a new SBOM.
- Hot-fix and patch releases produce a new SBOM that supersedes the previous one for that release line.
- Long-running release lines under extended support produce a refresh SBOM on at least a {{LONG_LINE_REFRESH_CADENCE}} cadence even when no new code ships, so the component-level vulnerability matching reflects upstream component metadata refreshes.
- The deployed artefact in the production environment is reconciled against the published SBOM on a {{PROD_RECONCILIATION_CADENCE}} cadence; drift triggers an investigation logged against the release.
Completeness coverage:
- Coverage target: {{COVERAGE_TARGET_PERCENT_OF_RELEASES_WITH_SBOM}} of in-scope releases publish an SBOM at GA.
- Coverage exceptions: releases that cannot meet the policy commitment are documented in the SBOM coverage exception register with a remediation date and a compensating-control narrative.
- Coverage reporting: the coverage rate, the exception list, and the drift count are reported quarterly to the policy owner and the executive approver.
Accuracy escalation:
- A material accuracy defect (missing critical component, wrong version, misattributed supplier) on a published SBOM triggers a corrective republication within {{ACCURACY_DEFECT_REPUBLICATION_WINDOW}} business days.
- The republication note names the defect, the affected releases, the corrected SBOM hash, and the cause.
- Material accuracy defects are reported in the quarterly governance review.
4. Signing, attestation, and provenance
An unsigned SBOM cannot survive procurement diligence at a security-mature buyer. This section commits to the integrity signature on the SBOM, the build-provenance attestation that connects the SBOM to the build event, and the chain-of-custody record that connects the published SBOM to the deployed artefact. SLSA, in-toto, and Sigstore Cosign are the durable references the policy reads against.
Signing, attestation, and provenance commitments:
{{ENTITY_NAME}} signs every published SBOM so a consumer of the SBOM can verify the artefact was produced by the firm release pipeline and has not been modified in transit. The signing layer is the difference between an SBOM that is evidence and an SBOM that is a marketing artefact.
SBOM integrity signing:
- Signing tool: {{SIGNING_TOOL_COSIGN_OR_GPG_OR_INTOTO}}
- Key custody model: {{KEY_CUSTODY_MODEL_HSM_OR_TRANSPARENCY_LOG_OR_OFFLINE}}
- Verification path: a consumer of the SBOM can verify the signature with the published {{VERIFICATION_GUIDE_URL}} guide.
- Key rotation cadence: {{KEY_ROTATION_CADENCE_MONTHS}} months or on key-material compromise.
- Revocation channel: {{KEY_REVOCATION_CHANNEL}}
Build provenance attestation (SLSA level):
- SLSA target level: {{SLSA_TARGET_LEVEL_1_OR_2_OR_3_OR_4}}
- Attestation format: in-toto link statement, attached to the release alongside the SBOM.
- Provenance fields populated: source repository URL, source commit hash, build entry point, build platform identifier, build start and end timestamps, materials and products lists, builder identity.
- Hermeticity commitment: {{HERMETICITY_COMMITMENT}}
Chain-of-custody from SBOM to deployed artefact:
- Each published SBOM carries the artefact identifier and the cryptographic hash of the artefact it describes.
- The deployment record carries the artefact identifier and the deployed registry digest.
- A reviewer can walk the chain from the published SBOM, to the artefact hash, to the registry digest, to the deployed instance.
- The chain-of-custody record is retained per the retention rule in Section 9.
Verification expectations for consumers:
- Customers and downstream consumers are expected to verify the SBOM signature before relying on the artefact.
- {{ENTITY_NAME}} publishes the verification command, the trust root, and the rotation history at {{VERIFICATION_GUIDE_URL}}.
- Consumers reporting failed verification follow the inbound channel in Section 12 of this policy.
5. Publication, access control, and customer delivery
Where SBOMs live and who can read them is a policy choice with regulatory and commercial consequences. Some firms publish SBOMs openly alongside the release; others publish under customer NDA only; regulated sectors publish to a controlled customer-facing portal. The publication section commits to the channels, the access control, the version-per-release rule, and the deprecation handling for retired releases.
Publication and access commitments:
{{ENTITY_NAME}} publishes SBOMs through {{PUBLICATION_TIER_OPEN_OR_GATED_OR_NDA}} channels matched to the audience.
Publication tiers in use:
- Open publication: SBOMs published alongside the release at {{OPEN_PUBLICATION_URL}} for {{OPEN_PUBLICATION_PRODUCT_LIST}}.
- Gated publication: SBOMs available behind authenticated customer access at {{GATED_PUBLICATION_URL}} for {{GATED_PUBLICATION_PRODUCT_LIST}}.
- NDA publication: SBOMs delivered to named procurement contacts under non-disclosure agreement for {{NDA_PUBLICATION_PRODUCT_LIST}}.
Access control model:
- Open SBOMs: any internet-accessible consumer.
- Gated SBOMs: authenticated against the customer portal account; access logged.
- NDA SBOMs: delivered through the procurement integration channel named in the master agreement; access logged with the named recipient.
Version-per-release rule:
- Every named release of every in-scope product has a dedicated SBOM.
- The SBOM URL is stable and addressable for the lifetime of the release plus the retention horizon.
- The SBOM URL is referenced in the release notes, the customer-facing release announcement, and the procurement diligence pack.
Customer delivery channels:
- Procurement diligence pack: SBOM, signed attestation, SSDF self-attestation reference, and the audit-evidence retention horizon.
- Vulnerability advisory pack: the affected SBOM versions, the VEX statement per affected product line (see Section 7), and the remediation guidance.
- Sales engineering pack: SBOM coverage statement, the supported-formats list, and the customer verification guide.
Deprecation handling:
- SBOMs for retired releases remain published for the documented retention horizon (see Section 9).
- The retired SBOM URL carries a notice that the release is end-of-life and links to the active replacement.
- The retired SBOM is archived in accordance with the audit-evidence retention discipline.
6. Inbound third-party SBOM acceptance and ingestion
A policy that only handles outbound generation is half a policy. Inbound SBOMs from third-party vendors are the upstream visibility every security-mature buyer expects to operate against under NIS2 Article 21 supply chain risk, DORA Article 28 third-party ICT risk, and the FAR/DFARS cybersecurity supply chain rules. This section names the request cadence, the accepted formats, the ingestion workflow, and the path for vendors who cannot produce SBOMs.
Inbound third-party SBOM commitments:
{{ENTITY_NAME}} requests SBOMs from third-party software vendors as part of procurement diligence and ingests them into the internal component graph so the upstream supply chain reads the same way as the outbound one.
Request stage:
- Request the SBOM at procurement, not at first incident.
- Capture the SBOM with the vendor contract as a contract attachment.
- Require a contractual commitment to refresh the SBOM at the cadence in Section 3 for the vendor product.
- Require a contractual commitment to notify {{ENTITY_NAME}} of material component changes between scheduled refreshes.
Accepted formats on inbound:
- Primary: CycloneDX 1.5 or SPDX 2.3 in JSON or XML encoding.
- NTIA Minimum Elements coverage required.
- Signing layer requested at SLSA level 2 minimum; SLSA level 3 preferred for tier-1 vendors.
Ingestion workflow:
- Inbound SBOM landing location: {{INBOUND_SBOM_LANDING_LOCATION}}
- Internal canonical representation: {{INTERNAL_CANONICAL_REPRESENTATION}}
- Format-conversion rule for non-primary formats: {{CONVERSION_RULE_REFERENCE}}
- Ingestion review: a named operator validates the inbound SBOM against the vendor product and confirms NTIA Minimum Elements coverage.
- Component-graph merge: the ingested components join the internal component graph and feed the vulnerability matching workflow.
- Refresh cadence: tier-1 vendors {{TIER1_REFRESH_CADENCE}}; tier-2 vendors {{TIER2_REFRESH_CADENCE}}; tier-3 vendors {{TIER3_REFRESH_CADENCE}}.
Vendor cannot produce an SBOM:
- Documented exception with a remediation date is captured in the inbound SBOM exception register.
- A compensating-control narrative is captured (binary scanning, manual component inventory, runtime composition analysis).
- The exception is reviewed at the quarterly governance review and reported to the executive approver.
Inbound SBOM evidence:
- Every inbound SBOM is retained per the retention rule in Section 9.
- Every inbound SBOM has a named operator who acknowledged receipt and confirmed acceptance.
- Every vendor product has an SBOM coverage record in the inbound SBOM register.
7. Vulnerability matching and VEX (Vulnerability Exploitability eXchange)
A VEX statement is the firm assertion that a named vulnerability either does or does not affect a named product version. The four canonical VEX statuses are not_affected, affected, fixed, and under_investigation. This section commits to the matching cadence, the VEX format choice (CSAF or CycloneDX VEX), the justification taxonomy for not_affected, the publication channel, and the customer notification path.
Vulnerability matching and VEX commitments:
{{ENTITY_NAME}} treats the SBOM as the lookup table the vulnerability matching workflow reads against. When an upstream advisory lands against a component in the graph, the firm answers two questions immediately: which products embed the component at the affected version, and what is the deployed digest in production.
Matching cadence:
- Continuous matching against the upstream advisory feed for tier-1 components.
- At-least-weekly matching against the wider component graph.
- Out-of-cycle matching when a vulnerability is added to the CISA KEV Catalog or assigned an EPSS percentile above {{HIGH_EPSS_THRESHOLD}}.
VEX statement production:
- {{ENTITY_NAME}} produces a VEX statement for every public vulnerability that touches a component embedded in a shipped in-scope product, regardless of the firm-side affected status.
- VEX format: {{VEX_FORMAT_CSAF_OR_CYCLONEDX_VEX}}
- VEX status enumeration: not_affected, affected, fixed, under_investigation.
- under_investigation is the default at matching time and prevents silent dropping; the statement is updated as triage completes.
- The not_affected justification taxonomy: component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, inline_mitigations_already_exist.
- The affected status carries a remediation plan: fixed_in_version, workaround_available, or under_review_pending_root_cause.
Publication channels:
- Machine-readable advisory: {{VEX_PUBLICATION_URL}} in {{VEX_FORMAT_CSAF_OR_CYCLONEDX_VEX}}.
- Customer-facing notification: emailed to the named procurement contact for affected_high severity bands; portal-published for all other severity bands.
- Regulator-facing notification: filed under the regulator-specific channel for products in scope of EU CRA Article 14, NIS2 Article 23, FDA post-market cybersecurity, or sector-specific mandates.
Refresh cadence:
- Every published VEX statement is refreshed when material information changes (firm reassessment, customer report contradicting the published status, upstream fix availability, new exploit evidence in CISA KEV).
- Stale under_investigation statements older than {{UNDER_INVESTIGATION_AGE_CAP_DAYS}} days trigger an escalation to the named owner.
Cross-link to the wider programme:
- The matched findings feed the vulnerability prioritisation workflow.
- The matched findings inherit the firm vulnerability remediation SLA.
- The matched findings drive the retesting workflow once a fix lands.
8. Roles, responsibilities, and RACI
A defensible policy names who owns each operating decision. Without explicit roles, the procurement question, the inbound SBOM ingestion failure, and the VEX publication delay reach an inbox rather than a named owner. The RACI section captures the four canonical roles (policy owner, executive approver, engineering production owner, procurement integration owner) and the wider participation map.
Roles and responsibilities:
Policy owner (Responsible):
- Role: {{POLICY_OWNER_ROLE_TITLE}}
- Maintains the document, runs the quarterly review, reports on policy performance to the executive approver.
- Owns the SBOM coverage register, the inbound SBOM exception register, the VEX publication queue, and the framework crosswalk.
Executive approver (Accountable):
- Role: {{EXECUTIVE_APPROVER_ROLE_TITLE}}
- Signs the policy, authorises material revisions, accepts coverage exceptions, signs the annual policy attestation.
Engineering production owner (Responsible for build-side execution):
- Role: {{ENGINEERING_PRODUCTION_OWNER_ROLE_TITLE}}
- Operates the build-time SBOM generation, the signing pipeline, the SLSA attestation flow, and the publication channel.
Procurement integration owner (Responsible for inbound side):
- Role: {{PROCUREMENT_INTEGRATION_OWNER_ROLE_TITLE}}
- Operates the contractual SBOM-request stage, the inbound SBOM landing queue, the vendor exception register, and the inbound coverage reporting.
AppSec engineer (Consulted):
- Reviews SBOM accuracy on a sampling cadence, triages VEX statuses, escalates accuracy defects, runs the vulnerability matching review.
GRC and compliance owner (Consulted):
- Runs the audit-read crosswalk against NIST SSDF, CISA Self-Attestation, EU CRA, NIS2, DORA, FDA, FAR/DFARS as applicable.
Customer-facing function (Informed):
- Delivers SBOMs to enterprise buyers under NDA, runs the procurement diligence pack stage, supports the customer verification workflow.
Internal audit (Informed):
- Reads the SBOM coverage report, the inbound SBOM register, the VEX publication record, and the policy-performance summary at the quarterly governance review.
Acknowledgement (renewed at material revision):
- Heads of product engineering teams in scope: {{PRODUCT_ENGINEERING_ACKNOWLEDGEMENTS}}
- Heads of platform and infrastructure teams: {{PLATFORM_TEAM_ACKNOWLEDGEMENTS}}
- Heads of customer support and customer success: {{CUSTOMER_FACING_ACKNOWLEDGEMENTS}}
- GRC and compliance function: {{GRC_ACKNOWLEDGEMENTS}}
- Internal audit function: {{INTERNAL_AUDIT_ACKNOWLEDGEMENTS}}
9. Retention, archive, and disposal
Retention is the pairing of the SBOM policy with the firm audit-evidence retention policy: SBOMs live under both rules and the longer horizon governs. The retention horizon follows the product end-of-life date plus the firm vulnerability disclosure window, the regulator-mandated retention horizon for the sector, and the contractual retention horizon in customer or vendor agreements.
Retention, archive, and disposal commitments:
Retention horizon per product class:
- Federal-supplier software under EO 14028: product support window plus {{EO_14028_POST_SUPPORT_YEARS}} years post-support archive.
- EU CRA-scoped products: support period (minimum five years) plus {{CRA_DISPOSAL_LAG_MONTHS}} months disposal lag.
- FDA medical-device-class software: device lifecycle plus {{FDA_POST_MARKET_YEARS}} years post-market reporting horizon.
- DORA-scoped financial-services suppliers: contractual ICT third-party arrangement plus {{DORA_SUPERVISORY_REVIEW_YEARS}} years supervisory review horizon.
- Default for products not in a sector-specific horizon: {{DEFAULT_RETENTION_YEARS}} years from end-of-life.
Archive location:
- Active SBOMs: {{ACTIVE_SBOM_STORAGE_LOCATION}}
- Archived SBOMs (retired products): {{ARCHIVED_SBOM_STORAGE_LOCATION}}
- Integrity verification cadence on archived SBOMs: {{ARCHIVE_INTEGRITY_VERIFICATION_CADENCE}}
Inbound SBOM retention:
- Inbound SBOMs are retained for the longer of the vendor contract retention horizon or the product end-of-life plus the firm default.
Disposal rule:
- At the end of the retention horizon, SBOMs are disposed of through the firm secure-deletion process.
- The disposition record is captured in the document management system with the deletion timestamp, the named approver, and the reason.
Hold orders:
- Retention horizons are suspended for SBOMs under legal hold, regulator request, or active customer dispute.
- Hold orders are captured in the firm legal-hold register and reviewed at every material policy revision.
Pairing with the audit-evidence retention policy:
- The SBOM retention rule is read alongside the firm audit-evidence retention policy.
- Where the two rules disagree, the longer horizon governs.
- The pairing is reviewed at each policy revision so the rules stay aligned.
10. Framework crosswalk and audit-read shape
The policy is the artefact the audit reads when the firm is scoped under SSDF, CISA Self-Attestation, EU CRA, NIS2, DORA, FDA pre-market, or sector-specific mandates. This section maps the policy sections to the framework clauses so the audit-read is the firm policy rather than a per-audit reconstruction. The crosswalk also lets the policy owner spot framework changes that need a policy revision.
Framework crosswalk and audit-read shape:
NIST SP 800-218 (SSDF):
- PO.1.3 (define and update software development information): Section 1, Section 2, Section 8.
- PS.3.2 (archive and protect each release): Section 4, Section 5, Section 9.
- PW.4.1 (acquire and maintain well-secured software components): Section 6.
- RV.1.1 (gather information from third parties about vulnerabilities): Section 6, Section 7.
CISA Self-Attestation Common Form (Secure Software Development Attestation):
- The attestation reads the SBOM policy as the artefact behind the SSDF practices.
- Section 4 (signing) is the load-bearing artefact for the integrity attestation.
- Section 5 (publication) is the load-bearing artefact for the buyer access claim.
Executive Order 14028:
- Section 4 of EO 14028 directed federal agencies to require SBOMs from software suppliers and pointed at SSDF.
- The policy section 9 retention horizon maps to the federal-supplier retention rule.
NTIA Minimum Elements of an SBOM:
- The seven minimum elements are mapped to the field-coverage commitment in Section 2.
EU Cyber Resilience Act:
- Article 13 (coordinated vulnerability disclosure): pairs with the firm vulnerability disclosure policy.
- Article 14 (vulnerability handling and reporting): the 24-hour early-warning notification reads the VEX publication commitment in Section 7.
- Annex I, Part II (vulnerability handling): the SBOM is the upstream visibility every Annex I expectation reads against.
NIS2 Directive:
- Article 21(d) (supply chain security): the inbound SBOM commitment in Section 6 is the load-bearing artefact.
DORA Regulation:
- Article 28 (ICT third-party risk management): the inbound SBOM register and the contractual SBOM clause map to the Article 28 contractual commitments.
FDA Premarket Cybersecurity Guidance:
- Section IV (cybersecurity transparency): the published SBOM is the load-bearing artefact.
- Section V (post-market monitoring): the VEX publication channel is the load-bearing artefact.
FAR/DFARS cybersecurity supply chain rules:
- FAR 52.204-23, 52.204-25, and the DFARS 252.204-7012 family: the inbound SBOM register and the procurement integration in Section 6 are the load-bearing artefacts.
CycloneDX 1.5 and SPDX 2.3:
- The format choice and field coverage in Section 2 reads the schema specification directly.
SLSA v1.0 and in-toto:
- The build-provenance attestation in Section 4 maps to the SLSA level commitment.
Sigstore Cosign:
- The signing layer in Section 4 maps to the Cosign sign-verify model.
11. Governance, review cadence, and exception path
Governance keeps the policy on top of the inbound queue. The review cadence is the rhythm at which the policy owner reports performance to the executive approver; the exception path is the rule that turns a temporary deviation into a documented, time-bounded carve-out rather than silent policy drift.
Governance and review:
Review cadence:
- Operational review: {{OPERATIONAL_REVIEW_CADENCE_WEEKLY_OR_BIWEEKLY}}. Surfaces in-flight SBOM coverage gaps, accuracy defects, inbound ingestion failures, and pending VEX statements.
- Tactical review: {{TACTICAL_REVIEW_CADENCE_MONTHLY}}. Surfaces aged coverage exceptions, accuracy-defect republications, vendor cannot-produce-SBOM exceptions, signing-pipeline failures.
- Strategic review: {{STRATEGIC_REVIEW_CADENCE_QUARTERLY}}. Surfaces overall coverage trend, inbound coverage rate, VEX publication trend, framework-crosswalk changes, executive policy attestation.
Exception path:
- Coverage exception: a release that cannot produce an SBOM at GA is logged in the SBOM coverage exception register with a remediation date and a compensating-control narrative.
- Inbound vendor exception: a vendor product that cannot produce an SBOM is logged in the inbound SBOM exception register with a remediation date.
- Accuracy exception: a published SBOM with a known accuracy defect carries a remediation note until the corrective republication ships.
- Signing exception: a release that cannot be signed at the documented SLSA level is logged with a target date for the upgrade.
- Every exception is reviewed at the strategic review and reported to the executive approver.
Material revision triggers:
- A framework version change (NIST SSDF revision, CycloneDX or SPDX schema bump, CSAF version, EU CRA implementing regulation).
- A material estate change (acquisition, divestiture, new product line, new sector regulator).
- A material accuracy defect that surfaces a systemic gap in the policy.
- An audit finding that calls a policy section out of date.
Policy-performance metrics (reported quarterly):
- SBOM coverage rate against in-scope releases.
- Inbound SBOM coverage rate against named vendor list.
- Accuracy-defect rate and republication latency.
- VEX publication latency from CVE landing to statement publication.
- Inbound ingestion latency from vendor delivery to internal canonical representation.
- Signing-pipeline reliability.
- Aged exception count.
12. Document control, version history, and signed approval
Document control is the artefact-management layer that makes the policy auditable. Each revision has a version number, an effective date, a named approver, a difference summary, and a notification record so the audit can reconstruct the policy as it stood at any point in time.
Document control:
Version history table (kept in this section across the policy lifetime):
- {{VERSION_1}} | {{V1_EFFECTIVE_DATE}} | {{V1_APPROVER}} | Initial publication.
- {{VERSION_2}} | {{V2_EFFECTIVE_DATE}} | {{V2_APPROVER}} | {{V2_CHANGE_SUMMARY}}
- {{VERSION_3}} | {{V3_EFFECTIVE_DATE}} | {{V3_APPROVER}} | {{V3_CHANGE_SUMMARY}}
Difference summary template (one entry per material revision):
- Sections changed
- Reason for the change (framework update, audit finding, estate change, internal review)
- Effective date of the new version
- Approver
- Stakeholder notification record (which acknowledgement renewals were collected)
Related documents:
- Audit evidence retention policy
- Vulnerability management policy
- Vulnerability remediation SLA policy
- Vulnerability disclosure policy
- Vulnerability acceptance and exception policy
- Secrets management policy
- Cryptographic key management policy
- Risk acceptance policy
Sign-off panel:
- Policy owner: {{POLICY_OWNER_SIGNATURE_BLOCK}}
- Engineering production owner: {{ENGINEERING_PRODUCTION_OWNER_SIGNATURE_BLOCK}}
- Procurement integration owner: {{PROCUREMENT_INTEGRATION_OWNER_SIGNATURE_BLOCK}}
- Governance approver (executive): {{GOVERNANCE_APPROVER_SIGNATURE_BLOCK}}
- Legal authority: {{LEGAL_AUTHORITY_SIGNATURE_BLOCK}}
Acknowledgement (recorded for stakeholder groups; renewed at material revision):
- Heads of product engineering teams in scope: {{PRODUCT_ENGINEERING_ACKNOWLEDGEMENTS}}
- Heads of platform and infrastructure teams: {{PLATFORM_TEAM_ACKNOWLEDGEMENTS}}
- Heads of customer support and customer success: {{CUSTOMER_FACING_ACKNOWLEDGEMENTS}}
- Procurement and vendor management: {{PROCUREMENT_ACKNOWLEDGEMENTS}}
- GRC and compliance function: {{GRC_ACKNOWLEDGEMENTS}}
- Internal audit function: {{INTERNAL_AUDIT_ACKNOWLEDGEMENTS}}
Effective date once all approval signatures collected: {{EFFECTIVE_DATE_FINAL}}
Acknowledgement evidence:
- Signed acknowledgement records stored with the policy version.
- Acknowledgement renewal cadence: at every material revision plus annual training cycle.
- New stakeholder onboarding includes policy acknowledgement.
Six failure modes the policy has to design against
An SBOM policy fails the procurement read, the regulator read, and the internal vulnerability-matching workflow in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the policy defensible.
SBOMs are produced but not signed
A release ships with a CycloneDX or SPDX file alongside it but no Sigstore Cosign signature, no in-toto attestation, and no published verification path. The first procurement question (how do we verify this is the canonical SBOM for the artefact you shipped) cannot be answered. The buyer either treats the SBOM as untrusted marketing material or escalates the gap as a procurement risk. The fix is the signing layer in Section 4: pick a signing tool, name the key custody model, publish a verification guide, and rotate keys on a documented cadence.
The SBOM and the deployed artefact drift apart
The SBOM that ships with the release announcement reflects the build that left the engineering pipeline; the artefact in production is rebuilt with a different base image, a different patched runtime, or a different transitive dependency resolution. The SBOM and the registry digest drift apart. When a CVE lands against a component the firm thought was not embedded, the matching workflow returns false confidence. The fix is the freshness commitment in Section 3: reconcile the deployed artefact against the published SBOM on a documented cadence and log the drift event when it occurs.
The policy only covers outbound generation
The firm generates SBOMs for its own products but has no rule for inbound SBOMs from third-party vendors. Procurement signs vendor contracts that never ask for SBOMs; the internal component graph reads only the first-party slice; the supplier-side CVE matching is impossible because the upstream component identities are unknown. NIS2 Article 21, DORA Article 28, FAR/DFARS, and the CISA Secure-by-Design supply-chain expectations all read the inbound side. The fix is Section 6: request SBOMs at procurement, ingest them into the internal graph, and run the vendor exception register for vendors that cannot produce SBOMs.
VEX statements are issued case-by-case rather than against a policy
A customer asks whether CVE-X affects Product-Y at version Z and the firm answers through email with a one-off note. There is no published VEX statement, no machine-readable advisory, no justification taxonomy. The next customer asks the same question and gets a different operator answer because the policy never named the under_investigation default, the not_affected justification list, or the publication channel. The fix is Section 7: produce a VEX statement for every public vulnerability that touches a component embedded in a shipped product, publish in CSAF or CycloneDX VEX, and use the published justification taxonomy.
Coverage is reported as one number that hides the exceptions
A quarterly slide says ninety-five percent SBOM coverage for the product portfolio. The number averages across product classes, releases, and inbound vendor SBOMs. It hides the four product lines that have no SBOMs at all, the long-running release line that has not refreshed its SBOM in eighteen months, the inbound vendor list that has SBOMs from twelve percent of contractual partners, and the accuracy-defect republications that did not ship within the documented window. The fix is Section 3 and Section 11: report coverage by tier, by release class, by vendor tier, and surface the aged exception register at every strategic review.
Retention is a default rather than a horizon per product class
The firm retains every SBOM for seven years because that was the default the document management system carried. EU CRA-scoped products needed only the support period plus the disposal lag; FDA medical-device-class products needed the device lifecycle plus the post-market reporting horizon; DORA-scoped products needed the contractual horizon. The default horizon is either too short for one class or too long for another, and disposal cannot happen because the rule is one number rather than a horizon per class. The fix is Section 9: name the horizon per product class, pair with the audit-evidence retention policy, and run the disposal rule when the horizon is met.
Ten questions the quarterly governance review has to answer
Operational review keeps the SBOM pipeline running. Governance review answers whether the policy is delivering durable component-level visibility or accumulating coverage gaps and unresolved VEX statements that the audit will read as policy drift. Run these ten questions at every quarterly review and capture the answers in the governance record.
1.What is the SBOM coverage rate against in-scope releases over the rolling twelve months, broken down by product class and depth tier, and is the trend up, flat, or down.
2.What is the inbound SBOM coverage rate against the named vendor list, broken down by vendor tier, and what does the exception register say about the gap.
3.What is the median and ninety-fifth percentile latency from an upstream advisory landing to a published VEX statement, and how many under_investigation statements aged past the policy cap.
4.What is the accuracy-defect rate per release class, what was the median republication latency for material defects, and what does the post-mortem say about the systemic cause.
5.What is the signing-pipeline reliability over the period, how many releases shipped unsigned, and what is the remediation path for each unsigned release.
6.How many releases reached end-of-life in the period, how many entered the retention archive, and what was the integrity-verification result for the archive sample.
7.Did a framework version change (NIST SSDF revision, CycloneDX or SPDX schema bump, CSAF version, EU CRA implementing regulation) trigger a policy review in the period.
8.Did a material estate change (acquisition, divestiture, new product line, new sector regulator) trigger a policy review in the period.
9.How many coverage exceptions, inbound vendor exceptions, accuracy exceptions, and signing exceptions are currently open, and what is the median age of each.
10.Did the SBOM-derived component graph feed the vulnerability prioritisation workflow during the period, and what is the volume of findings sourced from SBOM matching versus other intake channels.
How the policy pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs SBOM ingestion, the vulnerability matching workflow, and the VEX publication queue on a workspace, the policy commitments become the byproduct of the work rather than a separate tracking project. SecPortal pairs every SBOM-derived finding to a versioned engagement record through findings management, so the affected component, the CVE assignment, the CVSS 3.1 score, the VEX status, and the remediation evidence are one query against the same record rather than a reconstruction from email threads. The inbound third-party SBOM scanner output (CycloneDX, SPDX, Nessus, Burp, custom CSV) lands through bulk finding import with column mapping so the inbound ingestion in Section 6 of the policy runs against the live operating record.
The document management feature carries the signed SBOM artefacts, the policy versions, the framework-crosswalk history, the inbound vendor exception register, the SLSA attestation files, and the disposition record for retired SBOMs. The activity log captures every SBOM publication, every inbound ingestion, every VEX statement change, and every disposition decision with the actor, the timestamp, and the workspace context, so a procurement reviewer or a regulator can reconstruct the policy execution at any historical point with a single CSV export. The code scanning leg via Semgrep against connected GitHub, GitLab, and Bitbucket repositories surfaces the upstream component-level findings that feed the firm-side SBOM. The repository connections feature carries the OAuth-attached source-of-truth so the SBOM coverage register names the repositories the pipeline reads against. The compliance tracking feature carries the framework crosswalk so the audit-read in Section 10 is a query against the live record rather than a reconstruction.
The continuous monitoring feature schedules the recurring scans (daily, weekly, biweekly, monthly) so the accuracy-and-freshness rule in Section 3 has a live signal to read against. The team management RBAC carries the named owners for the policy roles in Section 8 (policy owner, executive approver, engineering production owner, procurement integration owner) so a procurement question or a regulator request reaches a named person on the workspace rather than an inbox. The multi-factor authentication control gates the signing-pipeline and approval-stage access. The AI report generation workflow drafts the leadership briefing, the procurement diligence pack, and the regulator notification text from the same engagement data so the executive review of SBOM performance and the audit read are the same record. The platform does not generate SBOMs, does not produce VEX statements directly, does not publish CSAF advisories to a public regulator channel, and does not connect to Sigstore Cosign or in-toto attestation services; those interfaces sit in the build-side tooling stack (Syft, Anchore Grype, Trivy, CycloneDX CLI, SPDX tools, Cosign, in-toto) the engineering function operates. The policy and SecPortal cover the operating record where the artefacts read against the vulnerability programme.