Conversation
Signed-off-by: Harsh Thakur <harsh@civo.com>
|
Maintainers, As you review this RFC please queue up issues to be created using the following commands: Issues(none) |
|
@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. |
|
@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 Re: using cosign as a library Re: similarity to RFC |
| # Migration | ||
| [migration]: #migration | ||
|
|
||
| N/a |
There was a problem hiding this comment.
How would pack sbom download mytag work if we adopt this RFC?
There was a problem hiding this comment.
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.
|
Should we consider #186 a dependency? Feels like a prerequisite to have complete sbom information before we condense it into an "image sbom"... |
|
@loewenstein Agreed! OCI spec allows annotations to attach metadata like that. |
|
@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"? |
|
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. |
Related : buildpacks/spec#350