SBOMs and Build Pipelines (small change to ADR-0063)

[Adam Kaplan]

Hi folks,

I want to broadcast a small change to ADR-0063, which I proposed yesterday [1] in light of the conversation around the "generalized release pipeline" requirements ADR [2]. I would have put this on the community call agenda, however, I often cannot present content at this meeting because the current schedule falls outside typical North American working hours.

SBOMs are tricky because we produce them in Konflux build pipelines, but lack a reliable means of distributing them in release pipelines for non-container builds. I am not aware of any non-container package ecosystem that has a standard mechanism for distributing SBOMs (I'd love to be proved wrong here).

The ADR update is intended to future-proof our build pipelines if/when package ecosystems adopt standards for SBOMs.

[1] https://github.com/konflux-ci/architecture/pull/337

[2] https://github.com/konflux-ci/architecture/pull/323

--

Adam Kaplan

He/Him

Senior Principal Software Engineer

Red Hat

100 E. Davie Street

adam....@redhat.com    

[Adam Cmiel]

I am not aware of any non-container package ecosystem that has a standard mechanism for distributing SBOMs (I'd love to be proved wrong here).

One ecosystem that does have a standard is Python, where SBOMs go directly into the artifacts: https://peps.python.org/pep-0770/#specification

--
You received this message because you are subscribed to the Google Groups "Konflux CI" group.
To unsubscribe from this group and stop receiving emails from it, send an email to konflux+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/konflux/CADmLb%2BmKezbDTLTeftpUrb8PaXrx-BSzjTWcNy1eyo9j_5kqTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Kaplan]

Good to know I am wrong! My initial search found the proof of concept repos for Python SBOMs, glad to see this is an official standard.

--
Adam Kaplan

[Adam Cmiel]

It may be worth noting that following this standard limits what we can do with the SBOM. The SBOM from the build pipeline must be in its final form, we can't make post-build adjustments like we currently do in release pipelines. Because making adjustments would require that we re-inject the SBOM into the built artifact, which would change its digest, which would break the provenance.

[Adam Kaplan]

Because making adjustments would require that we re-inject the SBOM into the built artifact, which would change its digest, which would break the provenance

Do we include SBOMs in container images today? I thought we used separate OCI artifacts and the OCI referrers API for SBOMs instead. This enables the workflow you describe: release pipelines that "enrich" the build-time SBOM. Perhaps SBOM enrichment needs to be captured in the "general release pipeline" ADR draft, too [1]?

For software artifacts that aren't containers, there is no digest to compare against when we publish content. We still preserve the chain of custody, so to speak, through the input Snapshot and its OCI references.

[1] https://github.com/konflux-ci/architecture/pull/323

[Adam Cmiel]

Do we include SBOMs in container images today?

We don't. I should have clarified that the limitations would apply if we wanted to follow the Python standard when publishing Python packages.

For software artifacts that aren't containers, there is no digest to compare against when we publish content.

I don't think this is true, any artifact has a digest. This is what the PyPA specs have to say about attestations [1]:

• subject[0].name is the distribution’s filename, which MUST be a valid source distribution or wheel distribution filename.

• subject[0].digest MUST contain a SHA-256 digest. Other digests MAY be present. The digests MUST be represented as hexadecimal strings.

[1]: https://packaging.python.org/en/latest/specifications/index-hosted-attestations/#attestation-statement-and-signature-generation

To view this discussion visit https://groups.google.com/d/msgid/konflux/CADmLb%2B%3D_h%2BCrcx09NLhbbHW9SfEPeq-%3DLq3t57pt2gG4ZzEwpQ%40mail.gmail.com.

[Adam Kaplan]

Thanks for clarifying this Adam - now I understand the root issue you described. Any modification to the SBOM for Python breaks the digest and our ability to provide a SLSA 3 attestation.

Can we avoid modifying the SBOMs in release pipelines? What sort of features need to "shift left" here?

[Andrew McNamara]

Not all build systems and artifacts are capable of generating a SLSA build L3 provenance attestation. The gap here isn't that we don't have the provenance but that the digest is changed because of the SBOM and the provenance-generating identity (Chains) is not in play here. In this case, could we generate a VSA to claim that an artifact is SLSA build L3 using _release time_ keys? If we do this, users would still be able to release the artifacts as SLSA Build L3 and acknowledge it 

Strictly speaking the v1.* SLSA provenance attestations don't have the SLSA level in them. The SLSA level is defined by the builder.id which (for Konflux), we do not customize. Therefore, our builder.id would not be sufficient to claim any higher levels of SLSA. We can, however, use a Conforma policy evaluation at release time as input for the VSA generation so that we can claim an appropriate SLSA build level. I had a talk about doing something along these lines at OpenSourceSecurity Con EU: https://www.youtube.com/watch?v=1Z0Vp0YbINA&list=PL-W3mvmFLwxEiSmmVSHNiRw06Ybk2Z_a9

Andrew McNamara

He / Him / His

Grab some time to chat: Office hours

To view this discussion visit https://groups.google.com/d/msgid/konflux/CADmLb%2Bm71zKTg6B7WKkBd2_4bos9DyGMHdErBnnGJYHDxe5Zyg%40mail.gmail.com.