Generate and validate an SBOM release artifact during the release process

[nhorman]

[nhorman]

NIST SP800-218 is calling for the use of software bills of materials as release artifacts for software components to help create an audit trail for various purposes, which may be needed by our customers in the future, and would also help us defend against various supply chain attacks. We should look at including an SBOM in our release artifact set.

Current Illustration of our Release Process:

Currently our release process takes place in 3 primary locations

1. Jenkins - This is where we preform both a test build to ensure that the build is sane and generate commits in preparation for a release
2. Github, this is where the human, manual review of changes from (1) takes place, as well as the final publication of a release
3. Our Releaser CI runner - This is where archiving of the git tree takes place, as well as signing of the release artifacts and the creation of a draft release to appear on github.

Notes on the security of the above actors:

1. Jenkins - We assume this actor to be secure, because it exists behind our firewall and is generally inaccessible to the public
2. Github - We trust the security of github, as we, for lack of a better description, have to. We have little to no insight as to the inner workings of this infrastructure so we are left with little recourse but to assume the integrity of our git tree is in tact
3. Releaser CI runner - Much like jenkins, we assume this to be secure as it is inaccessible to the public.

(1) and (3) represent potential supply chain attack vectors, in manners similar to the solarwinds and lzma attacks, in that if by some mechanism our private network is compromised, or if via social engineering attack, and individual gains legitimate access to these systems, malicious code may be introduced between the time code is cloned in Jenkins from CI and the time the archive is generated on the CI runner.

Proposed hardening
I would like to propose the following changes to our release process to harden our release pipeline against such attacks.

1. During the Archive/artifact generation phase, we additionally generate an SBOM file, which contains the SHA256 hashes of each file in the archive (among other information relevant to downstream consumers). This SBOM file is signed in the same manner as the archive itself and included in the artifact set when the draft release is generated.

2. Prior to publication of the release on github, a minimum of two people involved in the release process should run a script locally on their machines which:
   a) Downloads the release artifacts
   b) clones the openssl git tree and checks out the corresponding release tag
   c) validates the signatures of the release artifacts
   d) extracts the release from the release tarball generated in step 6 above
   e) For each file listed in the SBOM artifact, the recorded sha256sum is compared to the locally computed sha256sum of the corresponding file in the extracted archive AND the corresponding file in the git tree
   f) only if all participants doing the validation agree that the release matches the recorded values in the SBOM file, is the release published.

Reasoning
The comparsions of the sha256 sums in both the archive and the git tree let us detect the situation in which an attacker may have introduced code between the initial git clone and the archiving during the release process. The use of at least two local validations of that data helps move us in a direction of independent confirmation. That is to say, by using independent systems to preform this validation, successfully releasing compromised code without detection would require the compromise of several systems in different locations, the identity of those locations being unknown until shortly before the release.

[levitte]

I'm a bit surprised by the result...

So far, I've seen SBOMs generated on installed files (binaries, in our case) rather the source tree files. Such an SBOM wouldn't be generated with a source tarball, but with a build of OpenSSL, and typically by packagers. I know that syft (which is what you've used) can scan a source tree, but normal use is for it to figure out dependencies on other packages (like syft's release workflow does, by only looking at go.mod) rather than cite all the source files.

[levitte]

You might want to look at https://github.com/anchore/syft/releases/tag/v1.37.0 . It's quite apparent that they generate SBOMs on binary releases, rather than source releases.

[levitte]

Does any other project make SBOMs on source file releases, or will we end up pioneering that?

[nhorman]

yes, lots of companies build SBOMS for a wide variety of purposes, to create a chain of provenance for the origin of the components used in their software (both in their builds and deployments).

Much of this idea was taken from the talks I attended on Wednesday at FedCertWeek:
https://fedcertweek.org/wp-content/uploads/2025/11/W00c-SrivastavaGK.pptx.pdf
https://fedcertweek.org/wp-content/uploads/2025/11/W00a-BrownT.pptx.pdf
https://fedcertweek.org/wp-content/uploads/2025/11/W01b-BartolanzoA.pptx.pdf

And yes, many vendors provide SBOMs for their binary releases. I think thats more an artifact of the fact that many vendors provide binary releases, or don't provide public releases at all (i.e. the private nature of the software many vendors consume and distribute implies that, likewise those vendors privately distribute their SBOMS). For instance, Solarwinds doesn't publish their SBOMS, but from talking with them, they produce source and binary SBOMS that they give to their customers, who create deployment SBOMS for cloud services that use solarwinds, etc. If we distributed binary releases (which we may do if we ever get to releasing windows binaries), would also release a build SBOM documenting the provenance of those binaries, and linking to this source SBOM to create a chain of provenance between those binaries and the sources that created them.

We (I think) occupy something of a unique space in this environment, in that we:
a) currently only distribute source code
and
b) are consumed by many entities that incorporate builds of our releases in their components, which also have (or will have) a need to establish such a chain of provenance, of which we can be one root link.

So, to the question "Do other projects make source SBOMS?", I think the best answer is "I don't know". The answer to that question is somewhat impeded by the nature of the environment we are working in (i.e. companies that, while they might use open source components, generally don't disclose the assets that they produce to the public at large). I don't think that lessens the value that this addition provides however. Providing an attestable bill of materials gives those consumers another link in the provenance chain to detect points at which anomalies in software may have been introduced. It also gives us another tool with which to validate the integrity of our release process, should our systems become compromised in a fashion similar to those compromises that occured with solarwinds or lzma.