search

slsa-framework / slsa

Supply-chain Levels for Software Artifacts
https://slsa.dev
Other
1.53k stars 221 forks source link

Recommend SPDX and CycloneDX for BOM links in `byproducts` #691

Open MarkLodato opened 1 year ago

MarkLodato commented 1 year ago

Feedback from @mrutkows: it would be valuable to call out explicitly putting a link to a BOM in byproducts. This is similar to #669 from @chitrangpatel that it's not clear where to put the build spec.

I'm thinking of guidelines that, if you want to describe more details about the runtime environment, we recommend using a well established format like SPDX or CycloneDX to represent these details.

laurentsimon commented 1 year ago

Would this replace the resolvedDependencies?

MarkLodato commented 1 year ago

No, at least not for this issue. resolvedDependencies (and buildDefinition in general) is about the inputs to the build. That does overlap with Software Bill of Materials, but is not the intention here. If you ran this build on another service, the buildDefinition (and most of the SBOM) would remain the same.

Rather, this issue is about describing the runDetails, i.e. the specific invocation of this build. The BOM here would be a "Service" Bill of Materials. For example, what version and configuration of Tekton was running on the build cluster.

laurentsimon commented 1 year ago

Got it, thanks for the clarification

mrutkows commented 1 year ago

and the SBOM would include the in per-instance workflow/pipeline/task information for that build. The formulation can also link the per-instance (referenced) SBOMs for the "stack" as well e.g., run on Frsca + Spire (built on Tekton SBOM), run on K8s, hosted on Virtual Private Cloud (VPC SBOM), built in hardware (HBOM). Instances of each service/component usage can include per-instance info. as variances of inputs/outputs.

mattfarina commented 1 year ago

It was brought to my attention today that nothing about SLSA says one should or must have an SBOM.

Is this intentional?

MarkLodato commented 1 year ago

SBOM is intentionally not part of the Build track, though perhaps might be part of a future Vulnerabilities track. We really need a FAQ on this.

My quick take:

In other words, Provenance and SBOM are operating at different levels of abstraction. Furthermore, Provenance can cover the trustworthiness of the SBOM, i.e. how the SBOM was generated.

joshuagl commented 1 year ago

SBOM is intentionally not part of the Build track, though perhaps might be part of a future Vulnerabilities track. We really need a FAQ on this.

I've attempted to add a FAQ entry in https://github.com/slsa-framework/slsa/pull/827 based on Mark's quick take in https://github.com/slsa-framework/slsa/issues/691#issuecomment-1504083988

MarkLodato commented 8 months ago

Looking at this again after half a year of experience, what is the recommendation for where to put SBOMs, byproducts or subject? Does it matter how the SBOM was produced? Should the SBOM have its own, separate provenance?

Any thoughts? Overall I think I'd actually lean towards putting it in subject just for simplicity, but wanted to hear other opinions.

laurentsimon commented 8 months ago

putting in subject SGTM, and it's how most people do it today, afaik. It also provides a smooth upgrade path from signing to SLSA for the SBOM itself, as the very same tooling can be used during upgrade (verify_sig -> verify_slsa) for both build artifacts and SBOM artifacts.

arewm commented 7 months ago

While I don't have a preference either way, I suspect that this is hard to generalize.

If there is a task where the build platform generates the SBOM at the same time as the artifact itself, would it not be considered a direct output of the build? In this situation, even if the SBOM is not signed itself, if its immutable reference (i.e. OCI digest) is captured in the signed provenance, then trust can be extended to the SBOM content via the provenance.