rfcs
rfcs copied to clipboard
buildpacks
Add run image SBOM
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)
Hey @aemengo! What's the status of this RFC? I haven't been able to attend the CNB working group meeting. I ask because I am working on a Paketo RFC that relies on this RFC, and wondering if you plan to make more changes and what the timeline is if so? Thanks!!
Hey @aemengo! What's the status of this RFC? I haven't been able to attend the CNB working group meeting. I ask because I am working on a Paketo RFC that relies on this RFC, and wondering if you plan to make more changes and what the timeline is if so? Thanks!!
@sophiewigmore Thank you for asking. Unfortunately, I'm afraid that more changes will be required on this RFC. At the very least, more discussion needs to happen. During our last working group meeting, we had concerns about the workflow of attaching a BOM to an already-built base image, and thereby polluting the image. As of right now, the timeline is unknown. If your Paketo RFC is pending Paketo concerns, it might be more expedient to move at your own pace. Finally, I want remind (in a non-patronizing way) that buildpack RFCs are soon to close when all the core team members have voted and the "Final Comment Period" status is applied.
@aemengo really sorry to be going back and forth on this, but @natalieparellano and I were discussing the genpkgs implementation (https://buildpacks.slack.com/archives/CCP60GJLS/p1639669644077300) and it might make the implementation easier if the output file name did not use the digest - especially for implementing it in pack where the digest for the output run image may not be available until the lifecycle actually goes ahead and exports it (and in this case the lifecycle might have to export the output run image to the registry to get the digest).
The other issue is that image digests are sometimes not preserved across registry transfers which makes it even more of an issue.
I think we should instead solve it this way - use the diffid in the label and have the lifecycle ensure that it loads the bom from that diffid only if it is the last layer in the output image.
Summary of WG Discussion 02/17/22
There is lingering discomfort around storing this SBOM in the run image because:
- special tooling is required to create the image
- it may fall out of date
- there is widespread acknowledgment that the layer solution is temporary pending changes (removal of daemon support) that would allow us to store the SBOM in an annotation or attestation
Although we can solve problem 1 with custom tooling. Problem 2 cannot be completely solved. While the lifecycle can use the layer order as a hint about whether the SBOM is out of date, the lifecycle cannot guarantee accuracy. Efforts to solve for or mitigate problem 1 and mitigate problem 2 feel like a waste of effort given problem 3. It feels especially bad to bake new temporary interfaces into the spec, given that we would like to move towards spec stability.
We discussed moving the SBOM out of the run image, and making it a responsibility of the platform to supply an accurate run-image SBOM to the lifecycle for export, at which point it will be included in the sbom layer with the buildpacks generated SBOM. This free platforms up to be as strict or flexible as they want and to adapt to evolving specifications around sbom and attestation format/storage.
(cc @samj1912 @natalieparellano @jabrown85 @sclevine @jromero )
