Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SBOMs #6

Open
stevehipwell opened this issue Jan 2, 2025 · 8 comments
Open

Add SBOMs #6

stevehipwell opened this issue Jan 2, 2025 · 8 comments

Comments

@stevehipwell
Copy link

@amouat could you demonstrate how to correctly add SBOMs, specifically for the runner pattern?

@amouat
Copy link
Collaborator

amouat commented Jan 2, 2025

Hey Steve!

I'll add it to the list, but it shouldn't be too much work. Honestly Syft works pretty well, even with images (like Chainguard) that already have SBOMs.

@stevehipwell
Copy link
Author

@amouat what I was really interested in was if you'd recommend adding a SBOM for the manifest and if so how you'd do it (merge the two platform SBOMs or create a SBOM with dependencies)?

@amouat
Copy link
Collaborator

amouat commented Jan 3, 2025

I can tell you what we do here, but I'm not sure if that's the best recommendation.

We have separate SPDX documents for the index and platform specific images. This does sometimes cause confusion. For example, if I naively get the SBOM for the python image:

cosign download attestation --predicate-type=https://spdx.dev/Document cgr.dev/chainguard/python:latest-dev | jq -r .payload | base64 -d | jq

It will look largely empty as it is only the manifest for the index.

What you really want is the platform specific image e.g:

cosign download attestation --platform linux/amd64 --predicate-type=https://spdx.dev/Document cgr.dev/chainguard/python:latest-dev | jq -r .payload | base64 -d | jq 

I would venture that merging two platform specific images into one SBOM is a bad idea, as those images may be very different and have different versions of packages, with vulns only being present in one of them. And those vulnerable versions of packages may never hit the host if it's for a different platform.

@stevehipwell
Copy link
Author

@amouat that sounds logical, and a SME should be able to make this pattern work correctly by understanding the OCI spec, the target platform(s) and then running multiple commands. But if we work back from the fact that most images are referenced from the manifest rather than the platform specific images, we have an issue that any command targeting the manifest isn't going to work as expected. IMHO a manifest should have a SBOM representing all platform image dependencies the same way a package SBOM contains all dependencies (last time I spoke to Dan this was where I thought you were going). Given a manifest SBOM representing the worst case scenario the end-user UX is improved and the potential for false negatives is significantly mitigated.

From an end-user perspective, not finding a SBOM for a manifest is likely to result in one of three outcomes; thinking a SBOM doesn't exist, finding a single platform specific SBOM, or finding all platform specific SBOMs. Only the third case here is "safe" and as it requires SME knowledge it's not what I'm getting at here. The first case may cause scanning to be ignored entirely, or it may result in the same outcome as the second case (but potentially with a poorer quality SBOM). The problem with the second case is that it's likely to result in a level of certainty about the "image" that doesn't reflect reality; there are potentially other platform images in the manifest that haven't been scanned and that could be run.

Checking the manifest attestation would help detect some scenarios here, but as the end-user has had to target the platform specific image for the SBOM what are the odds that they will do the same for the attestation?

TL;DR - Without manifest SBOMs "platform confusion" supply chain attacks may be hard to detect.

@amouat
Copy link
Collaborator

amouat commented Jan 3, 2025

Those are all fair points. Let me see if I can get more information for you.

@amouat
Copy link
Collaborator

amouat commented Jan 3, 2025

I talked to a couple of people. We probably don't want to change the index SBOM, as people would complain that it has entries not present in their image. Note that the SBOM does have a relationships element which links to the platform specific SBOMs.

I would like to say there is a tool you can use to create a "mega SBOM", but I don't think anything does it out-of-the-box; you'd have to merge the platform specific SBOMs.

In your case you might well find syft is the best tool; you'll get good results on our images and it will create SBOMs for the host platform by default.

@stevehipwell
Copy link
Author

I've seen the relationships pattern but when I look at the current Chainguard public images I can't see one being created? And AFAIK no tooling currently supports using a SBOM with this pattern? Logically if I pass the manifest SBOM to grype I'd expect it to scan all related SBOMs (maybe with a flag required).

There is also a multi-platform image SPDX semantic pattern (which I think originated from Chainguard). I think it's meant to do the same thing as above but I haven't looked into it for awhile.

I'm not aware of any tools which currently support creating SBOMs of either type (I assume apko does but let's ignore that for now)? Or using them for scanning?

Ref: anchore/syft#1683

@amouat
Copy link
Collaborator

amouat commented Jan 8, 2025

Sorry, I thought I'd replied to this.

The code from apko to generate the SBOM is here I think: https://github.com/chainguard-dev/apko/blob/main/pkg/sbom/generator/spdx/spdx.go#L601

I'm not aware of other approaches or solutions to this.

If you have further questions or asks let me know and I'll do my best to get an answer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants