You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases, when running an automated scanner against a Paketo builder, Paketo buildpack, or an application image generated by Paketo buildpacks, you may see the tool report the software as vulnerable to certain CVEs. These are usually either Ubuntu USNs or Go CVEs.
In the case of Ubuntu CVEs, there may be a few reasons why you're seeing this.
Ubuntu has yet to release a fix. We are downstream from Ubuntu, so we cannot and do not patch anything directly. We rely on Ubuntu to patch first. Please check with Ubuntu to confirm that the particular vulnerability has been patched.
It could be a timing issue. Our pipelines do not get immediately notified when Ubuntu has patched a CVE. They run on a schedule and publish new releases with whatever is available at the time. In general, you should see a fix for high and critical CVEs within 48 hours. Lower severity issues may take up to two weeks. If you are seeing an issue that has been fixed by Ubuntu for longer than this period of time, please reach out by opening a Discussion thread, here or on the Paketo Slack.
The Ubuntu base images that Paketo uses for our stacks & builders are NOT guaranteed to be zero-CVE. This means that Ubuntu, at its discretion, may opt to not patch certain lower severity CVEs. In this case, there is nothing we can do as a downstream consumer of the Ubuntu images. This tends to amplify as the Ubuntu base image gets older, and in some cases updating to the latest Ubuntu LTS release will clear up the CVEs.
In the case of Go CVEs, there are a couple of causes for this.
If you are scanning a builder or buildpack, the Paketo team uses Go to produce its buildpacks and both of these images contain the binaries that we produce. Since these are statically compiled Go binaries, there is a Go runtime embedded in the binary, and if the Go runtime is found to have a CVE, then these Go binaries will be flagged as potentially vulnerable to that CVE.
If you are scanning an application image, you may see Go vulnerabilities reported against the launcher or against the small helper (also called exec.d) binaries that are embedded in your application image. Again, these are statically compiled Go binaries so there is a Go runtime embedded in them. If the Go runtime is found to have a CVE, then these Go binaries will be flagged as potentially vulnerable to that CVE.
In the case of the Go CVEs, there is a problem with most scanner tools in that they are simply reporting that the binary has a Go runtime in it of a vulnerable version. They do NOT verify that the Go binary in question is actually using the vulnerable code or that it could in any way be exploited.
For Paketo buildpacks, these CVEs are almost always false positives. This is because the helper/exec.d binaries that we embed in the images are very basic. In most cases, they are simply reading environment variables and adjusting configuration settings. In addition to that, the likelihood of them being exploited is minimal. This is because most users are running app images in protected environments and are not allowing untrusted individuals to feed in configuration settings to the app images.
Given the very low risk that these present, even ones that are flagged as high or critical, the Paketo team patches these as part of their normal release cycle. We automatically update our CI builds to run with the latest patched Go versions, so as soon as the next release happens, these binaries will be compiled with a Go runtime that's patched against the CVEs.
If you have a question about when the next regularly scheduled release will be or if you're not seeing the regularly scheduled release, please reach out by opening a Discussion thread, here or on the Paketo Slack.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
In some cases, when running an automated scanner against a Paketo builder, Paketo buildpack, or an application image generated by Paketo buildpacks, you may see the tool report the software as vulnerable to certain CVEs. These are usually either Ubuntu USNs or Go CVEs.
In the case of Ubuntu CVEs, there may be a few reasons why you're seeing this.
Ubuntu has yet to release a fix. We are downstream from Ubuntu, so we cannot and do not patch anything directly. We rely on Ubuntu to patch first. Please check with Ubuntu to confirm that the particular vulnerability has been patched.
It could be a timing issue. Our pipelines do not get immediately notified when Ubuntu has patched a CVE. They run on a schedule and publish new releases with whatever is available at the time. In general, you should see a fix for high and critical CVEs within 48 hours. Lower severity issues may take up to two weeks. If you are seeing an issue that has been fixed by Ubuntu for longer than this period of time, please reach out by opening a Discussion thread, here or on the Paketo Slack.
The Ubuntu base images that Paketo uses for our stacks & builders are NOT guaranteed to be zero-CVE. This means that Ubuntu, at its discretion, may opt to not patch certain lower severity CVEs. In this case, there is nothing we can do as a downstream consumer of the Ubuntu images. This tends to amplify as the Ubuntu base image gets older, and in some cases updating to the latest Ubuntu LTS release will clear up the CVEs.
In the case of Go CVEs, there are a couple of causes for this.
If you are scanning a builder or buildpack, the Paketo team uses Go to produce its buildpacks and both of these images contain the binaries that we produce. Since these are statically compiled Go binaries, there is a Go runtime embedded in the binary, and if the Go runtime is found to have a CVE, then these Go binaries will be flagged as potentially vulnerable to that CVE.
If you are scanning an application image, you may see Go vulnerabilities reported against the launcher or against the small helper (also called exec.d) binaries that are embedded in your application image. Again, these are statically compiled Go binaries so there is a Go runtime embedded in them. If the Go runtime is found to have a CVE, then these Go binaries will be flagged as potentially vulnerable to that CVE.
In the case of the Go CVEs, there is a problem with most scanner tools in that they are simply reporting that the binary has a Go runtime in it of a vulnerable version. They do NOT verify that the Go binary in question is actually using the vulnerable code or that it could in any way be exploited.
For Paketo buildpacks, these CVEs are almost always false positives. This is because the helper/exec.d binaries that we embed in the images are very basic. In most cases, they are simply reading environment variables and adjusting configuration settings. In addition to that, the likelihood of them being exploited is minimal. This is because most users are running app images in protected environments and are not allowing untrusted individuals to feed in configuration settings to the app images.
Given the very low risk that these present, even ones that are flagged as high or critical, the Paketo team patches these as part of their normal release cycle. We automatically update our CI builds to run with the latest patched Go versions, so as soon as the next release happens, these binaries will be compiled with a Go runtime that's patched against the CVEs.
If you believe that there is a particular CVE that impacts buildpacks and can be exploited, please follow the security policy and responsibly disclose the issue.
If you have a question about when the next regularly scheduled release will be or if you're not seeing the regularly scheduled release, please reach out by opening a Discussion thread, here or on the Paketo Slack.
Beta Was this translation helpful? Give feedback.
All reactions