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

SBOM layer support #278

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

RealHarshThakur
Copy link

@RealHarshThakur RealHarshThakur commented Feb 24, 2023

Signed-off-by: Harsh Thakur <harsh@civo.com>
@buildpack-bot
Copy link
Member

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

(none)

@samj1912
Copy link
Member

@RealHarshThakur thanks for the RFC. Have you had a chance to look at #195 which covers the cosign sbom format as well as storing sboms as attestations.

@RealHarshThakur
Copy link
Author

@samj1912 thanks for pointing it out. Just skimmed through it. I think we're after the same goal. OCI v1.1 draft spec is helping with interoperability.

Re: attestations
Feels like it's easier to support SBOMs as dedicated layers in OCI manifest first. This will set the ground for attestations too but I didn't want to include it here as I haven't seen the popular builder images emitting attestations and there isn't a pack attest subcommand yet. Attestation support might deserve its own RFC IMO.

Re: using cosign as a library
I noticed cosign also relies on go-containerregistry library that Buildpack does. It felt easier to use the underlying library directly than to introduce a new dependency.

Re: similarity to RFC
Is there a notion of sub-RFCs or similar since it feels like this RFC can be a sub-RFC to the one you've proposed? If not, I'm happy to close this one if we can cover the OCI spec progress in the other one

# Migration
[migration]: #migration

N/a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would pack sbom download mytag work if we adopt this RFC?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OCI artifact will have the SBOM embedded during build time. CLI can query the container registry for it filtering by artifact type.
https://github.com/opencontainers/distribution-spec/blob/main/spec.md#api

To remain backward-compaitable, I guess CLI will have to fallback to extracting the layers if it doesn't find any.

@loewenstein
Copy link
Contributor

Should we consider #186 a dependency? Feels like a prerequisite to have complete sbom information before we condense it into an "image sbom"...

@RealHarshThakur
Copy link
Author

@loewenstein Agreed! OCI spec allows annotations to attach metadata like that.

@loewenstein
Copy link
Contributor

@RealHarshThakur well, I primarily meant this to say, we - as the CNB project - should make sure to allow complete application image boms before exposing them via standards. Or was your comment to say there are annotations for "warning: this sbom is incomplete"?

@RealHarshThakur
Copy link
Author

I meant we should provide complete image sboms too but adhere to OCI 1.1 spec on how it suggests on doing it. In future, when we do runtime SBOMs, etc- annotations will help us differentiate it.

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

Successfully merging this pull request may close these issues.

None yet

6 participants