lifecycle
lifecycle copied to clipboard
buildpacks
Scan dev lifecycle images for vulnerabilities
Description
https://github.com/buildpacks/lifecycle/issues/821 alerted us to a non-impactful but still unsightly high CVE in one of our transitive dependencies. We should run trivy (or other similar tooling) against dev lifecycle images so that we can update any dependencies as necessary. If non-impactful CVEs are flagged and the dependencies cannot be updated or replaced, we should mention it in the release notes to show that we've done our due diligence.
Hi @natalieparellano
I worked a little bit on this issue, I created the following tool to execute the scanning of the docker hub repo for all the 0.X.Y versions of the lifecycle using Trivy I am not sure if the idea is just to get the output of the scanning and then create individuals tickets for fix each dependency fix on each version. In that case, I think the command tool can do the job.
I was planning to upload the output of the scanning in the ticket, but I reached the maximum API calls. Just let me know how to move forward with this one
Very cool @jjbustamante ! I was imagining that we'd add something to our GitHub actions, maybe about here: https://github.com/buildpacks/lifecycle/blob/277f3b2834ed210ddf34ff6c041157cd3efe328c/.github/workflows/build.yml#L199. The invocation could look very similar to what you have. It's a bit annoying that we publish directly to the registry here - we may want to change it to a local build + push (to avoid pushing something that fails the trivy check).
There could be value in scanning all the "old" dev images, though with the passage of enough time they would probably all trip the scanner eventually. But by adding a step to our actions pipeline we can at least ensure that we don't publish something that already has a vulnerability.
Should I assign this issue to you @jjbustamante ?
Hi @samj1912 , @natalieparellano
Yes, you can assign this one to me. Yeah I thought the idea was to added in the GitHub actions but I wasn't sure. So the scope of the issue is to avoid publishing something that have vulnerabilities, right?
Now, are we planning to fix the current release versions that are broken?
Sam, yes, I suppose we can use any other tool, I didn't spend a lot of time with the script, just wanted to play around with it, but I can focus on working with the Github action and use your suggested tools syft/grype
https://github.com/marketplace/actions/anchore-container-scan is the github action that uses grype. You can pass it the lifecycle image directly or the sboms we generate. We can also use syft for the sbom generation if needed as it adds some more metadata that can be used by grype.
Now, are we planning to fix the current release versions that are broken?
I don't think there is anything to do here. People can always upgrade to the newest lifecycle, since all api versions are supported.