Wolfi
What is the cadence for wolfi-base builds to include vulnerability patches? #20739
-
|
Question - What is the process for wolfi-base to get rebuilt to have fixes for vulnerabilities For example (5/31/2024) right now in wolfi-base it has 2 vulnerabilities for CVE-2024-4603 but I see a pull request to fix openssl merged in 2 days ago - #20435 which I assumed would fix that CVE? For general knowledge how long does it take for that type of patches to make it into wolfi-base? or am I misunderstanding what that patch fixed? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 7 replies
-
Can you explain how you have established that? Have you used a scanner? Have you cross check advisories? |
Beta Was this translation helpful? Give feedback.
-
|
We use grype and Anchore scanners on our pipelines that are flagging those two vulnerabilities... Also if you click on that link I included for chainguard I'm a little new to this so I may be mis-understanding something? |
Beta Was this translation helpful? Give feedback.
-
|
just wanted to be sure which scanners you use and with which advisory databases. |
Beta Was this translation helpful? Give feedback.
-
|
Our trivy scanner is actually not flagging it but the other two are. |
Beta Was this translation helpful? Give feedback.
-
|
the package and CVE is fixed; but the issues remain with advisory data that we publish; and how/when the scanners consume it. As an example, in worst case scenario, there can be up to 48h lag in advisory data in grype. I don't know about Anchore and Trivy. And there could have been impressions in the advisory data. It is the weekend now, bu the advisories data team will pick this up on Monday - if the scanners don't improve during that time (as in get their advisory data upgraded, and rescanning existing images from days ago would result in them no longer flagged as vulnerable). I wish there was ability to include advisory data inside the package SBOM such that without refreshing vendor advisory metadata the scanner could see that although the version range matches affected one; there is SBOM indication that issue is already resolved. Also it would have helped if upstream openssl would have cut a release - as then we would have upgraded to a new point release and none of this manual advisory data would be needed to be published by us and included in all the scanners. |
Beta Was this translation helpful? Give feedback.
-
|
Also not sure if this is already fixed by https://github.com/wolfi-dev/advisories/pull/5106/files and now awaiting for scanners to pick it up. (which is less than 48 hours old for scanners to know about) |
Beta Was this translation helpful? Give feedback.
-
|
Ok I appreciate the response. I was just curious if it was a lag in the wolfi image building... but makes sense that its a lag in the advisory database picking them up. Thank you! Will check it out on Monday. |
Beta Was this translation helpful? Give feedback.
-
|
in general we rebuild all images every 2 hours, and because they are reproducible most of them don't change, there is some CDN involved but yeah, unless there are CI/gating failures latest tags are pretty much up to date at the speed of cloud builds. |
Beta Was this translation helpful? Give feedback.
the package and CVE is fixed; but the issues remain with advisory data that we publish; and how/when the scanners consume it. As an example, in worst case scenario, there can be up to 48h lag in advisory data in grype. I don't know about Anchore and Trivy. And there could have been impressions in the advisory data. It is the weekend now, bu the advisories data team will pick this up on Monday - if the scanners don't improve during that time (as in get their advisory data upgraded, and rescanning existing images from days ago would result in them no longer flagged as vulnerable).
I wish there was ability to include advisory data inside the package SBOM such that without refreshing vendor a…