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

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
Github, this is where the human, manual review of changes from (1) takes place, as well as the final publication of a release
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:

Jenkins - We assume this actor to be secure, because it exists behind our firewall and is generally inaccessible to the public
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
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.

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.
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.

Uh oh!

Generate and validate an SBOM release artifact during the release process #1716

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions