anchore
For Python:3.12 image it is showing the fixed version as use python:3.14
What would you like to be added: If the image of python:3.12 and it has vulnerability then it should suggest same image with different digest. I mean same tag with another digest.
Why is this needed: Because we use python:3.12 image and it says vulnerability is present. And the fixed version it suggests is go and upgrade to python:3.14 version. That will be big change for us. Bumping python version involves lot of code change etc.,
Additional context:
grype python:3.12 --only-fixed
✔ Pulled image
✔ Parsed image sha256:4571a487646b9fa98498c02f7e5ef7e38c71afeb79d8b586c277244c52e591aa
✔ Cataloged contents 3fd471b0ebdffbcc1fb56da77bb3f7cb385c7fc1ad9313a1a0d5854904ee3b5c
├── ✔ Packages [438 packages]
├── ✔ Executables [1,425 executables]
├── ✔ File metadata [20,091 locations]
└── ✔ File digests [20,091 files]
✔ Scanned for vulnerabilities [1 vulnerability matches]
├── by severity: 11 critical, 132 high, 317 medium, 79 low, 673 negligible (474 unknown)
└── by status: 1 fixed, 1685 not-fixed, 1685 ignored (1 dropped)
NAME INSTALLED FIXED IN TYPE VULNERABILITY SEVERITY EPSS RISK
python 3.12.11 3.14.0b3 binary CVE-2025-6069 Medium < 0.1% (23rd) < 0.1
The issue is that there isn't yet a fix released in the 3.12.x branch. There was a release for the 3.13.x branch yesterday, so that will be reflected in our data soon. Grype will attempt to show the closest fix to the branch that you are on, but there are currently not any fixes released for 3.12.x. They have backported the changes to prior release branches, but they haven't released them yet. Once that happens and the data propogates through everywhere then grype will suggest a 3.12.x fix
Would it be possible to get a flag or config option to stop grype from suggesting minor version bumps, f.e. for python 3.14 when python 3.12 is being scanned? This happens very consistently that a fix is available for the latest "minor" version of python but has not been back ported to previous versions yet.
Which for us results in scans being noisy, for weeks usually, and CVEs end up going in the ignore list sooner rather than later and once the fix for the version we want is released we have to rely on email notifications from the relevant git projects to update, which is not as nice as having the build pipeline tell us when a fix is available and ready.
Something like:
grype <image> --only fixed --do-not-suggest-minor-version-bump="python,go"
maybe?
Probably less verbose.
This is (tangentially) related to the discussion at https://github.com/anchore/grype/issues/2615.
I think we're a little bit inconsistent on the difference between distro and language framework here. Grype will happily suggest jumping to a brand new version of Java or Python, which might be a huge change for the application, but will not suggest jumping to say, a new version of Ubuntu, which might also be a huge change, but depending on the tooling used might be a minor change. I think it would be interesting to have both config options: ask grype to tell you that CVEs are on a later distro version, and ask grype not to tell you that CVEs are fixed on a much later version of Java or Python, because of course you know that but getting there is a big ask. This is further complicated because distros and packages all have different ways of representing their versions.
I've added needs-discussion to this so we can talk about it at an upcoming livestream
What I'm envisioning for the future is something similar to dependabot, where you can configure which remediation strategy to use (major version, minor version, only stable releases, etc), as well as whether or not to consider specific commercial vendor backports, etc but we aren't really ready for all of that yet
There was another attempt to address this with https://github.com/anchore/grype/issues/2264, which basically says, "if you're scanning a Java 11 app, and there are CVEs against the JDK, please highlight the fix in the Java 11 JDK, rather than suggesting Java 17 or Java 8 fixes, even if they exist." Basically, grype tries to suggest a version that is (1) newer and (2) crosses the fewest semver boundaries (so a patch on the current version is shown before a minor update on the current major is shown before a different major version is shown before a downgrade). In the present example, in the row of grype output:
python 3.12.11 3.13.6, 3.14.0b3 binary CVE-2025-6069 Medium < 0.1% (26th) < 0.1
The fix in 3.13.6 is the best fix grype knows about, and it is display first and, in terminals that support it, a brighter font than 3.14.0b3.
I think the current request is interesting, becuase we don't want to make the UX of that match more clearly show which version to upgrade to, rather, we want to make that match be suppressed, because there's no fix available that doesn't require a new minor version of the python interpreter.
Yes, you would be configuring the remediation strategy, so it would be changing how the suggested fix is calculated as well as modifying which matches that are displayed in the results when used in combination with --only-fixed. It shouldn't really be changing how matching happens, only which ones are supressed in the main part of the output
We discussed this on the livestream, I'm not sure if anyone was leaving a comment, I just thought I would summarize a couple things, I believe we mostly agreed about:
- we could have a configuration including with some defaults and/or db entries to identify language packages such as java, python, and go so these can be treated differently in regards to "good upgrade" suggestions
- we could have a mode that shows "safe" upgrades, e.g. no major versions, only patch versions for language packages, etc.
