Replies: 3 comments 5 replies
-
|
Hello @65278 Trivy uses the "debug/buildinfo" package to check information about Go binaries (you can use the
A Go binary doesn’t have any other way to determine its version. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @DmitriyLewen. I have very specifically mentioned that go pseudoversions are "regular", as in can be parsed by a regular grammar. As these cause false positives because trivy handles them incorrectly (I've linked the public docs), I'd like you to handle them properly. I can even provide a patch if so required. Regarding filters, these do not work for us, as we send packages to my government, which uses trivy to determine what CVEs they have. I can not tell my government to filter the CVEs they see in any way. At the moment, the only approach that I can use is binary patching the |
Beta Was this translation helpful? Give feedback.
-
Can you share your ideas on how we can get the correct version for these binaries? |
Beta Was this translation helpful? Give feedback.
-
|
Properly handling them does not equal getting the correct version for these binaries. I've outlined above that a scan of pseudoversions is To show how inconsequential this treatment of dependencies is, have a look at replacing a dependency with a local development checkout. This is fine to trivy: This is not: For those reasons, the proper thing to do is to not treat pseudoversions as anything and not to flag them as CVEs. A proper handling would be a warning about unscannable dependencies. (*)Now I'm going to share ideas on how to get the correct version for these binaries, but you're not going to like it one iota. |
Beta Was this translation helpful? Give feedback.
-
Users use Trivy to generate SBOM files, and not showing the version would be incorrect.
I think false positives are better than false negatives.
Could you elaborate on this? |
Beta Was this translation helpful? Give feedback.
-
|
Is there any other maintainer I can talk to?
I never talked about SBOMs. I don't understand how correctly treating pseudoversions destroys creation of SBOMs. This is a non-sequitur.
In fact why don't show all vulnerabilities for a package, just to be safe. It's better to err on the side of safety. After all Please change this bug report to "trivy doesn't incorrectly flag devel versions as vulnerable, which would be required for consistent behaviour". In fact you're leaving people in the awkward position where they need to change go itself so trivy works correctly: The least you can do for this is to document this behavior so best practices can be established with third parties.
I could elaborate on this, but I don't feel very inclined to explain reverse engineering and I also don't think it's the right approach for trivy to take. This is more of an example of how hard actual CVE detection is. |
Beta Was this translation helpful? Give feedback.
-
Package vs Vulnerability
First, package detection and vulnerability detection should be considered separately. While pseudo-versions should be detected as packages, vulnerability detection has room for discussion. Using pseudo-versions for vulnerability detectionSecond, pseudo-versions are valid versions under semantic versioning as described in the doc, so they can be compared correctly. This means that in most cases, vulnerability detection will also work correctly.
For example, suppose In other words, using pseudo-versions for vulnerability detection has a certain degree of validity, and ignoring them all could result in many false negatives. Of course, we want to reduce false positives, but the balance between precision and recall is important. On the other hand, in the case of versions like Ideal solutionsLike Dmitriy stated, I also believe that ideally, this should be fixed on the project side or the advisory side. In fact, mitigations have been merged in Grafana, and a fundamental fix also appears to be close to completion. If you want to resolve this issue specifically for Grafana, a fixed version should be released soon. Additionally, if we look at the advisory, it considers pseudo-versions as an affected version. If GHSA were to consider pseudo-versions in all advisories, false detections would disappear. However, fixing this will take time, and GitHub may not provide support. That means that, ideally, as Grafana is currently working on fixing this, the handling should be done outside of Trivy. But the problem is not limited to Grafana, and realistically, it is true that users are currently suffering from noise. WorkaroundsAs a compromise, there is an idea to suppress vulnerabilities for pseudo-versions of the form Furthermore, Trivy already has a flag --detection-priority that allows some adjustment of the balance between precision and recall. One idea is to suppress detection by default, and when As another workaround, it is also possible to output the SBOM with |
Beta Was this translation helpful? Give feedback.
-
|
We are seeing the same problem with Github CLI
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Description
Golang has a concept of pseudo versions, which do not actually refer to versions, but to git commits:
https://go.dev/ref/mod#pseudo-versions
These are regularly formatted as
vX.Y.Z-$date-$commit-$info, where X Y Z can be 0 or also semantically correct golang versions (often times it's impossible to properly refer to project versions in go.mod because golang api version differs from project version, i.e. teleport).As an example, grafana alleviated CVE-2025-47907 by releasing a rebuild with golang 1.24.6.
This release has an internal version
github.com/grafana/grafana │ CVE-2018-15727 │ CRITICAL │ fixed │ v0.0.1-test.0.20250723164904-3b49fbaa5c2c+dirtyThis triggers trivy because v0.0.1 < v12.0.4.
This is in Q&A, but this is clearly a bug. Trivy is supposed to parse the golang binary section for versions correctly, and it doesn't. Also, the discussion had no actionable points.
Ref: #6534
Desired Behavior
Trivy ignores golang pseudo-versions because they only introduce false positives and regularly happen in production code because of the reasons stated above.
If so desired, trivy could be extended to recursively link commits to repositories and tags (repositories provided by users).
Actual Behavior
Trivy lists all CVEs since pseudo-version, even if pseudo-version refers to a CVE-free commit.
Reproduction Steps
Target
None
Scanner
Vulnerability
Output Format
None
Mode
Standalone
Debug Output
Operating System
Jamtoe Ganoo Lunix, doesn't matter
Version
felix@lb03035 ~/ionos $ trivy --version Version: v0.65.0 Vulnerability DB: Version: 2 UpdatedAt: 2025-09-05 06:30:47.074373351 +0000 UTC NextUpdate: 2025-09-06 06:30:47.07437308 +0000 UTC DownloadedAt: 2025-09-05 08:28:43.425584925 +0000 UTCChecklist
trivy clean --allBeta Was this translation helpful? Give feedback.
All reactions