Incorporating Supply Chain Files

[dtimm]

Hello Bosh Community,

I would like to propose a standard way to incorporate supply chain information for components into Bosh releases.

Why

In the wake of supply-chain attacks including the one affecting SolarWinds, companies and governments have accelerated adoption of secure supply chain processes. One of the key requirements that underpins these efforts is collecting and maintaining records of where software components and their dependencies come from. This can include bills of materials, proof of code review, cryptographically signed attestations of build provenance, and many other forms of supply chain data. As a software packaging tool, Bosh has a privileged position in the supply chain, and it can facilitate the use of this data by standardizing its own approach to managing supply chain files.

How

1. Introduce a supply_chain array at the top level of package spec files. It will be a list of file or file globs with formats. The supported formats will be spdx+json, vnd.cyclonedx+json, vnd.syft+json, and vnd.in-toto+json. format will use the IANA names where possible, dropping application/.

   Example supply_chain section for the bpm job of bpm-release:

   supply_chain:
   - name: bpm/sbom.spdx.json
     format: spdx+json
   - name: bpm/*.attest.json
     format: vnd.in-toto+json

   The files will be stored in the src/ directory and included in their package like items from the files list.

2. Add the supply_chain list with all globs expanded to the final release.MF section for each package under packages.

   Example release.MF excerpt:

   packages:
   - name: bpm
     version: be375c78c703cea04667ea7cbbc6d024bb391182
     fingerprint: be375c78c703cea04667ea7cbbc6d024bb391182
     sha1: 6ae70da9768bd7333b883463e089c65bea44c685
     dependencies:
     - golang-1-linux
     - bpm-runc
     - tini
     supply_chain:
     - name: bpm/sbom.json
       format: spdx+json
     - name: bpm/build.attest.json
       format: vnd.in-toto+json
     - name: bpm/source.attest.json
       format: vnd.in-toto+json

This will allow downstream consumers of Bosh releases to easily access these files, and it will also ensure future enhancements to Bosh tooling (aggregating SBoMs, performing attestations directly, etc.) have a stable base to work from.

[rkoster]

@dtimm Thanks for putting this together!! Adding @cloudfoundry/wg-foundational-infrastructure-vm-deployment-lifecycle-bosh-approvers @cloudfoundry/wg-foundational-infrastructure-vm-deployment-lifecycle-bosh-reviewers for wider visibility.

[jpalermo]

My first thought when reading this was that the supply chain files wouldn't be part of the repo, but would be something you supply via additional arguments when creating a release.

It feels like when the files are committed to the repo it gives the impression that any SHA I check out will have accurate information in those files, but we know that's not always going to be true.

I suppose if you didn't want to commit to keeping the files up to date between cutting releases, you could always git ignore the src paths and then put the files there when doing a create-release so they get included in the final release.

Not sure if that will be something people end up doing or not, but if so we might want to build some sort of --skip-supply-chain-files into create-release so it doesn't error out when wanting to create a dev release. Certainly doesn't need to be part of the first iteration though.

[dtimm]

It makes sense for create-release to ignore these files entirely except when creating final releases. A future improvement could be to validate the supply_chain files during create-release, with attestations validated against a set of certificate authorities and bills of materials validated against the code they describe (e.g. an SBoM containing the SHA of the go.mod file it was generated from).

supply_chain files generated by the release maintainers would be checked into the release repository, but they may also be present in vendored code, submodules, or provided alongside binary blobs incorporated in the release. I am hoping to leave room for upstream components that include supply chain data in a code repository to have that called out in a release as well.

[dtimm]

I think that --skip-supply-chain-files is a better approach, and it allows for releases to use a dev release -> bosh finalize-release workflow to function with included provenance.

[rkoster]

Where would a attestation attesting the bosh create-release process go? Would it go in the releases/ directory and be committed into source? This would make it easy for bosh.io to pick it up when creating release tarballs. Alternatively it could go in a GitHub release.

[rkoster]

Alternatively bosh create-release could be responsible for creating an attestation and signing it with co-sign

[dtimm]

In this same vein, it would be valuable to independently track blob provenance files.

1. Add the supply_chain array following the same schema to each blob in config/blobs.yml.
2. Add a new string array flag to bosh add-blob that could be passed multiple times to include provenance files when adding a blob.
3. Automatically include provenance files in any packages created with the given blob.

[beyhan]

When going over this I had following questions:

• how this will work with package vendoring?
• why /src is the chosen place to store the metadata?

Maybe we need a "meta" discussion about how we imagine that bosh can help with supply chain security because the focus here is in adding the supply chain artefacts to the bosh releases.