SBOMs and artifact signing: SPDX, CycloneDX, Sigstore and SLSA

The previous lesson ended with two questions every defender faced during SolarWinds and Log4Shell: what is inside the software we run, and can we trust that it was built the way we think? The industry’s answers are the software bill of materials (SBOM), for the first question, and signing with build provenance, for the second.

What an SBOM is

An SBOM is a machine-readable list of the components that make up a piece of software, including open-source libraries and their versions, and how they relate to each other. The usual comparison is an ingredients label on food. When a new flaw is announced in a component, an organisation with SBOMs for its software can search them and know within minutes which products are affected.

In 2021, following US Executive Order 14028, the US National Telecommunications and Information Administration (NTIA) published the minimum elements for an SBOM. They cover three areas: data fields (such as supplier, component name, version, unique identifiers, dependency relationships, the author of the SBOM data and a timestamp), automation support (a machine-readable format) and practices (how often SBOMs are produced, how deep they go and how they are shared). CISA now leads SBOM work in the US.

The two main formats

Both are widely supported by build tools and scanners. The choice matters less than generating SBOMs automatically in the build, storing them with each release and actually using them. OWASP Dependency-Track is an open-source platform that ingests SBOMs and continuously checks the listed components against vulnerability data.

Signing: proving who produced an artifact

An SBOM says what should be inside. A signature proves an artifact, such as a container image, package or binary, was produced by a specific party and has not been altered since. Traditional signing requires managing long-lived private keys, which are themselves valuable targets. Sigstore, an open-source project under the Open Source Security Foundation (OpenSSF), offers an alternative: its cosign tool can sign artifacts with short-lived certificates tied to an identity, such as a CI workload or a developer account, and records signatures in a public transparency log so they can be audited.

Provenance and SLSA

A signature proves who signed, but not how the artifact was built. Build provenance is a signed record of that: which source, which build system, which steps. SLSA (Supply-chain Levels for Software Artifacts) is a framework, also under OpenSSF, that defines increasing levels of assurance for builds. Higher levels require builds on a hosted platform that generates provenance itself, with protections that make it hard for a single person or a compromised build step to forge it. A SolarWinds-style compromise of the build is exactly what these controls aim to make detectable.

• Generate an SBOM in every build, not by hand, and keep it with the release.
• Sign release artifacts and verify signatures before deployment, not just at publication.
• Produce provenance from the build platform and check it at deploy time.
• Ask suppliers for SBOMs and signed artifacts, and check what they send.

Where FireAI fits

On the Mac, Apple’s code signing plays a similar role for apps, and FireAI builds on it. Rules follow each app’s verified code signature, and when an app is not signed by a known developer, or has been modified since it was signed, FireAI’s connection prompt says so plainly before anything connects.