Executive Order 14028, signed in May 2021, made SBOMs a federal procurement requirement, and five years later most organizations have solved the generation problem — CycloneDX 1.6 shipped in April 2024, SPDX moved to its 3.0 line the same month, and CI plugins now produce one on every build. Almost none of them have solved the storage and distribution problem. An SBOM is a complete, machine-readable map of every component in your software, which makes it exactly the kind of asset that should never sit in an unauthenticated S3 bucket or get emailed as a plain JSON attachment: it tells an attacker precisely which libraries, versions, and internal build tooling to target. In August 2025, CISA released its "2025 Minimum Elements for a Software Bill of Materials" as a public-comment draft — still pre-decisional as of this writing — proposing to add Component Hash, License, Tool Name, and Generation Context to the 2021 NTIA baseline of seven fields. More fields per document means more reasons to control who can read one. This piece covers the two problems generation guidance never touches: who gets to see an SBOM once it exists, and how you prove nobody altered it in transit.
Why does an SBOM need access control at all?
An SBOM needs access control because it is a reconnaissance document by design, listing every dependency, version, and often build-environment detail an attacker needs to find your weakest link without scanning your infrastructure first. The NTIA's 2021 Minimum Elements baseline requires seven fields — Supplier Name, Component Name, Version, Unique Identifiers, Dependency Relationship, SBOM Author, and Timestamp — and every one of those fields is also useful to an adversary planning a targeted exploit against a specific pinned version. Treating an SBOM like public documentation, because the EO 14028 push framed SBOMs as a transparency tool, misreads the mandate: transparency to your customer and auditor is not the same as publication to the internet. A defensible policy separates SBOM readers by role — engineering needs full detail, a customer under NDA needs the components relevant to their contract, and a public trust-center page needs, at most, a high-level attestation that scanning happened, not the raw component list.
What does least-privilege access actually look like for SBOMs?
Least-privilege access for SBOMs means tiered permission levels rather than a binary "can see it or can't." A workable model has at least three tiers: view-only access for auditors who need to confirm a component's presence without downloading the full inventory, download access for partners integrating your software who need the file for their own compliance chain, and full re-share rights reserved for internal teams. Safeguard's Portal implements exactly this split — View, Download, and Full permission levels attached to individual recipients or to shareable links that can carry an expiration date, a download cap, and a password, with organization-level policy able to force authentication or restrict sharing to approved email domains. The same repository should also support per-SBOM overrides, because a defense contractor's SBOM for a classified-adjacent build has different sharing rules than a public SaaS product's SBOM, even inside the same company. Revocation matters as much as granting: access must be terminable immediately, not on the next scheduled review.
How do you verify an SBOM hasn't been tampered with in transit or storage?
You verify integrity by signing the SBOM at generation time and checking that signature at every consumption point, not by trusting whoever handed it to you. The mechanism with the widest real-world adoption is Sigstore: Fulcio issues short-lived certificates bound to a workload's OIDC identity — a GitHub Actions run, a GitLab CI job — so there's no long-lived private key to leak, and Rekor records the signing event in a public, append-only transparency log that anyone can audit independently of the vendor who produced the artifact. Wrapping the SBOM itself in an in-toto attestation, rather than shipping a bare JSON file, adds a cryptographic binding between the SBOM's SHA-256 digest, the signer's certificate chain, and a Rekor inclusion proof — so any modification to the SBOM after signing invalidates the attestation outright, and any attempt to re-sign under a different identity produces a second, visibly anomalous Rekor entry. Safeguard implements this pattern with Sigstore as the default signing backend and an X.509/Notation path for environments that require traditional PKI, publishing to the public Rekor log or, for enterprise tenants, a private Rekor instance at a dedicated subdomain.
What does SLSA provenance add that a signature alone doesn't?
A signature proves who signed the SBOM; SLSA provenance proves how the underlying artifact was actually built, which is the question an attacker exploits when they compromise a build pipeline rather than forging a signature. The SLSA framework, an OpenSSF specification, defines three build-track levels in its current v1.0 revision: Level 1 requires only that provenance exists, Level 2 requires it come from a tamper-resistant, dedicated build service, and Level 3 requires an isolated, parameterless build so one job can't read another's secrets or environment. An earlier v0.1 draft included a fourth level combining hermetic builds with two-person review; SLSA v1.0 dropped that as a build-track requirement and moved mandatory two-party review into its separate source track instead, so "SLSA 4" isn't part of the current build-level numbering. A signed SBOM attestation that includes SLSA provenance lets a consumer's admission controller check both facts at once before allowing a deployment: does a valid signature exist, and was it built at or above a required level. Safeguard's attestation pipeline produces SLSA provenance alongside CycloneDX and SPDX SBOM predicates for every build, and its Kubernetes admission controller enforces a configurable minimum level — defaulting to Level 3 — denying admission to any artifact that falls short, which turns "we require SLSA 3" from a policy document into a runtime gate.
How should retention and audit logging factor into SBOM security?
Retention and audit logging matter because an SBOM's value doesn't expire when the software ships — a new CVE disclosed two years later still needs to be checked against every SBOM version that was ever in production, and a breach investigation needs to reconstruct exactly who accessed which SBOM and when. A defensible logging schema captures actor, action, resource, timestamp, source IP, user agent, result, and supporting detail for every SBOM create, view, download, share, and permission change, which is the eight-field structure Safeguard's Portal audit trail applies to SBOM activity specifically. Retention periods should be tiered rather than uniform: access logs typically need a shorter window (Safeguard defaults to two years) than administrative and security-event logs, which commonly need seven years to satisfy SOC 2 and similar frameworks, with enterprise customers able to extend either. Feeding those logs into a SIEM — Splunk, Elastic, Datadog — closes the loop, turning "someone downloaded the SBOM for our unreleased product" from a question you can't answer into an alert that fires the moment it happens.
How Safeguard helps
Safeguard treats SBOM storage as a first-class access-control problem rather than a file-hosting afterthought: every SBOM in the Portal repository carries View, Download, and Full permission tiers, expiring and password-protected share links, and org- or SBOM-level policy overrides, all logged in an eight-field audit trail retained for two to seven years depending on log type. Every SBOM Safeguard generates is wrapped in a signed in-toto attestation — Sigstore keyless signing by default, X.509/Notation for regulated environments — published to a public or private Rekor transparency log alongside SLSA provenance, so a consumer can verify both the signer's identity and the build's isolation level before trusting the file. The admission controller enforces that chain automatically, denying deployment to any artifact missing a valid, sufficiently-provenanced SBOM, which is what turns SBOM security from a document you generate and forget into a control that actually gates what runs in production.