SBOMs and Signed Artifacts: What They Do (and Do Not) Prove

Software security does not end when an application passes testing or deployment checks. Modern engineering teams also need to know what goes into their software, where it comes from, and whether the delivered artifacts can be trusted across the entire delivery lifecycle.

This is where Software Bills of Materials (SBOMs) and signed software artifacts play an important role. An SBOM provides visibility into software components and dependencies, while signed artifacts verify integrity and signing identity. Both strengthen software supply chain security, but neither guarantees that software is completely secure.

What is an SBOM?

A Software Bill of Materials (SBOM) is a structured, machine-readable inventory of the components, libraries, and modules used to build a software application. Think of it as the complete ingredient list on a nutrition label.

• Direct & transitive dependencies: both explicitly declared third-party libraries and sub-dependencies.
• Component identifiers: exact package names, versions, and unique package URLs (purl).
• Cryptographic checksums: cryptographic hashes of individual components to detect tampering.
• License metadata: open-source license types (e.g. Apache-2.0, MIT, GPL) to prevent compliance risk.
• Supplier information: maintainer details, vendor provenance, and repository sources.

The two primary industry standard formats are SPDX and CycloneDX, both widely supported across enterprise vulnerability scanners and CI/CD tools.

What do SBOMs actually prove?

An SBOM provides verified visibility into the components recorded in a software inventory. When accurately generated and linked to a specific release digest, it enables organizations to:

• Accelerate incident response: instantly identify if a newly disclosed vulnerability (CVE) impacts deployed applications without re-scanning or rebuilding source code.
• Automate license compliance: flag non-compliant, restrictive, or copyleft licenses before shipping code to production.
• Satisfy enterprise compliance: meet stringent regulatory mandates, including US Executive Order 14028, SOC 2 supply chain criteria, and ISO 27001 requirements.

Crucial limitation: an SBOM is only as reliable as the build-time process used to generate it. It proves what components were detected; it does not prove the software is bug-free or safe from zero-day exploits.

What are signed software artifacts?

Software artifacts are packaged deliverables created during the build process - including container images, application packages, executables, and deployment bundles. Digital signatures, using tooling such as Cosign/Sigstore or Notary, verify:

• Integrity: the artifact bitstream has not been modified, corrupted, or backdoored during transmission or registry storage.
• Authenticity: the artifact was produced by an authorized identity or an approved CI/CD runner workflow.
• Non-repudiation: cryptographic proof establishing that the stated entity generated and approved the build output.

Crucial limitation: cryptographic validity is not safety validation. A valid signature will faithfully sign malicious code or vulnerable dependencies if the build runner or source code repository was already compromised.

SBOMs vs. signed artifacts: the key differences

The two controls answer different questions, and neither substitutes for the other:

• Primary focus: an SBOM answers what is inside the software; a signed artifact answers whether the artifact has changed since signing.
• Core function: an SBOM gives component and dependency visibility; a signed artifact gives cryptographic integrity and identity verification.
• Output format: an SBOM is a structured manifest (SPDX / CycloneDX); a signed artifact is a cryptographic signature and attestation.
• Primary benefit: an SBOM drives CVE vulnerability tracking and license audits; a signed artifact drives tamper detection and authorized-origin validation.
• What it does not prove: an SBOM does not prove the software is vulnerability-free; a signed artifact does not prove the artifact is benign or free of security flaws.

What they do not prove, even together

Having both an SBOM and a signed artifact does not automatically ensure that an application is secure. Teams must recognize the distinct boundaries.

An SBOM does not prove:

• Zero vulnerabilities: it lists components; it does not eliminate unpatched flaws or zero-day exploits.
• Code quality & logic: it does not validate proprietary source code against injection bugs or misconfigurations.
• Build-time hygiene: it cannot verify if dependencies were hijacked via network interception during build execution.

And a signed artifact does not prove:

• Code safety: a valid signature verifies only origin and intact bits, not safe runtime behavior.
• Uncompromised runners: a compromised CI runner or leaked key can sign backdoored binaries legitimately.
• Deployment readiness: signatures must be paired with admission controllers to enforce policy gates.

The missing link: build provenance

Knowing what is inside software (SBOM) and verifying its signature is vital, but organizations also need to understand how the artifact was created. This is where build provenance comes in. Frameworks such as SLSA (Supply-chain Levels for Software Artifacts) and in-toto record verifiable build metadata:

• Source control provenance: exact source code repository, branch, and Git commit SHA.
• Execution identity: build system runner, workflow identity, and automation triggers.
• Build parameters: compiler flags, environment variables, dependencies, and build steps.

Together, these controls deliver three essential pillars: visibility, an SBOM-based complete inventory of what is inside; integrity, cryptographic assurance from the signature that the artifact has not changed; and traceability, a verifiable audit trail from provenance of how and where it was built.

Best practices for modern DevSecOps pipelines

• Automate SBOM generation: generate CycloneDX or SPDX manifests automatically during the CI build stage.
• Associate SBOMs with digests: bind SBOMs to immutable container digests (sha256:...) using cryptographic attestations.
• Adopt keyless signing: eliminate static signing keys by leveraging OIDC-based ephemeral certificates (Sigstore/Cosign).
• Enforce cluster admission: use Kubernetes admission controllers (e.g. Kyverno, OPA Gatekeeper) to block un-attested images.
• Continuous vulnerability tracking: query historical SBOM manifests when new CVEs are disclosed without triggering rebuilds.

At Upperthrust Technologies, we help businesses integrate enterprise-grade security practices into their software delivery workflows through comprehensive DevOps and DevSecOps engineering services - transitioning your software supply chain from a compliance checklist into resilient, automated production defense.