Hello, Anchore community!
Here’s a summary of our recent Open Source Gardening session from October 9, 2025. The team (Dan, Alex, Will, Chris, and Keith) went through several community-raised issues and pull requests for Grype and Syft.
We started by discussing a few topics that came up in our community session earlier in the day before moving on to our “needs discussion” queue.
Grype Issue #1378
The team kicked off with a topic from the morning’s community call: providing more control over vulnerability severity.
The Issue: Grype’s current default behavior is to prefer severity information from the vendor that provided the vulnerability data (e.g., Debian, Red Hat) over data from NVD. The reasoning is that vendors have more context, such as OS-specific compiler flags or backported fixes, that can change a vulnerability’s practical severity.
The Discussion: Users have expressed a strong desire for more control. For example, some organizations have compliance requirements that mandate using NVD as the single source of truth. The request is to add configuration “knobs” to control which severity source is used in both the table and JSON outputs. Will pointed out the underlying complexity: NVD itself isn’t simple, as a single CVE can have multiple CVSS scores from different sources.
Outcome: This issue needs a concrete design proposal. The team is looking for more community feedback on what kind of configuration controls would be most useful.
Discourse Topic #575
Next, Dan brought up a post from our Discourse forum where a user reported Grype was not finding vulnerabilities for a project using PNPM.
The Issue: The team was initially confused, as Syft has support for PNPM lock files (with Chris noting that support for the newer v9 lock file format is in progress).
The Discussion: Will quickly diagnosed the core problem: the user wasn’t scanning a lock file with Syft. Instead, they were using the “Export SBOM” button on GitHub and piping that SPDX file directly into Grype.
The Investigation: Will and the team inspected the GitHub-generated SBOM and found it to have unexpected characteristics. It contained unusually formatted version strings, such as including the ^ (caret) character (which represents a version constraint, not a concrete installed version) or even the literal string “catalog:” in the version field.
Because this malformed data was fed into Grype, Grype’s matchers couldn’t find any vulnerabilities. Will noted this was a good example of an “SBOM quality” issue. The tool was falling back to its “fuzzy matcher” for every package, which is a strong indicator that the input SBOM is malformed.
Outcome: Keith planned to respond to the user on Discourse. The recommendation is to use Syft to scan the repository’s lock file directly, which will produce a valid SBOM, rather than using the problematic GitHub-generated file. The team also had a side-bar discussion about how Grype could potentially warn users when it detects it’s being fed a low-quality or malformed SBOM.
Grype Issue #2960
Alex introduced a significant issue from the community session proposing a new method to reduce false positives using symbol-level analysis.
The Proposal: The idea is to enhance vulnerability matching by checking for the presence of specific vulnerable symbols (like function names), not just the package version. If vulnerability data indicates a specific function is vulnerable, Grype could check the binary for that symbol. If the symbol isn’t present, the vulnerability can be confidently filtered out.
The Discussion: The community member is planning to create a proof-of-concept (PoC) targeting the Golang ecosystem. The team strongly supported this “PoC-first” approach to prove the value before tackling the difficult “data plumbing problem” of how to efficiently get symbol information into an SBOM.
This feature would be especially powerful for Go, as it could solve major classes of false positives:
Standard Library: A Go binary is bundled with the standard library, so Grype reports all stdlib vulnerabilities (e.g., in html/template). Symbol analysis could confirm the binary doesn’t actually use that vulnerable package.
Toolchain: Vulnerabilities in the Go toolchain itself (e.g., in the cmd/go compiler) are often reported against every binary built with that Go version. Symbol analysis could confirm the compiled binary doesn’t contain the compiler’s code.
Alex mentioned he had prototyped this over a year ago but was stopped by the massive size of the resulting SBOMs. The team now agrees that this should be an opt-in feature in Syft, allowing users to choose to create these larger, more detailed SBOMs if they need this level of accuracy.
Outcome: The community member is proceeding with the PoC, and the team is excited to support this initiative. A successful PoC for Go (which provides rich, structured vulnerability data) could be used to advocate for other ecosystems like Python to provide symbol-level data as well.
Syft PR
Chris brought up a pull request from a community member to fix a long-standing issue in Syft’s Java cataloger.
The Issue: The PR addresses a problem where Syft’s archive parser incorrectly prefers information from a JAR’s MANIFEST.MF file over its pom.xml file. This leads to incorrect groupIds being cataloged.
The Discussion: Keith and Alex provided historical context, noting this was likely due to a “bad assumption” made when the parser was first written. There was a long-standing quirk where Syft would only parse a pom.xml if it contained a tag. This was probably a workaround before Syft’s Maven parser was robust enough to handle variable substitution (e.g., ${project.version}). Now that the parser is much better, this logic is no longer needed and is causing bugs.
Chris also commented that the Java cataloger is one of the most complex in the codebase due to the many different ways metadata can be embedded (POMs, manifests, nested JARs, etc.).
Outcome: The team agrees with the fix. Keith pinged the contributor to ask them to re-target the PR from their fork to the main anchore/syft repository so it can be reviewed and merged.
Grype Issue #1454
In the final few minutes, the team discussed an older, complex issue about Grype’s --by-cve flag.
The Issue: Grype’s default behavior is to show the vulnerability ID from the source that found the match (e.g., GHSA for a Python package). The --by-cve flag was added for users who, often for regulatory reasons, need to see only CVEs.
The Discussion: Will described this flag as a “big hammer.” Alex explained that it works by “transposing” the data: if Grype finds a GHSA, it looks for a related CVE and reports that instead. This has downsides: it can lose “fixed-in” data that was present on the GHSA, and it can multiply the number of results (e.g., one advisory fixing 10 CVEs becomes 10 rows).
The discussion broadened: What should happen if a GHSA has no related CVE? Should it be dropped? Keith also mentioned that “by-location” (e.g., grouping by file path or JAR) is another common request to help users prioritize fixes.
Outcome: This is a very important discussion that affects how users consume Grype’s data. Will “foreshadowed” that this topic is central to the design of Grype 1.0, as it will fundamentally impact the JSON output format. The team encourages anyone with strong opinions on this to add their use cases to the issue.
That’s all for this week! Thanks to everyone who contributed issues and pull requests. We’ll see you at the next session.