Here is a summary of our recent open source community triage session. We reviewed a pull request, investigated a performance issue, and had an in-depth discussion about some exciting upcoming changes for Grype.
The team reviewed a community-contributed pull request from H. Victor that adds functionality to Syft for parsing Go test binaries and resolving their dependencies. This was identified as a substantial pull request with changes across 28 files.
The discussion clarified that a “test binary” is the executable generated when running go test. The implementation leverages the go packages library to achieve this. A significant part of the conversation focused on the use of symbol analysis to extract information from the binary. The team noted the similarity of this approach to another recent pull request that used Go binary symbols for more accurate license data extraction. This led to a broader point about the increasing use of symbol analysis and the need to consider common, reusable solutions for these types of features.
Outcome: Given the complexity of the changes, the team decided that a live review was not feasible. Alex Goodman and Keith Zantow will conduct a more thorough offline review.
A user reported an issue where a Grype scan against a provided SBOM was taking two hours to complete. They had also attempted to use a parallelism setting in their configuration file with no effect on performance.
The team identified two distinct aspects of this issue:
- Performance: A two-hour scan time for an existing SBOM is highly anomalous. The most time-consuming part of the process is typically the generation of the SBOM, not the vulnerability scan itself. The team hypothesized that the user’s local Grype vulnerability database might be corrupted or lack the necessary indexes, which could account for the significant slowdown. It was also pointed out that the user had disabled automatic database updates, potentially leaving them with a faulty database.
- Parallelism Option: Grype does not currently support a parallelism option, which is why the user’s configuration had no effect. While this feature exists in Syft and is planned for a future Grype 1.0 release, it is not yet implemented. The team agreed that Grype should ideally warn users about unknown configuration options to prevent such confusion.
Interesting Sidebar: During the stream, Alan Pope conducted a quick test to validate the database index theory. A Grype scan that initially took 3 seconds took 12 minutes after he manually deleted the indexes from the SQLite database, confirming the significant performance impact.
Outcome: Alex Goodman had already reached out to the user on the GitHub issue for more details. Alan suggested that the user run grype db check and grype db update and will follow up with them directly. The issue has been repurposed as the official feature request for adding parallelism to Grype and has been added to the Grype 1.0 milestone.
Grype 1.0 Planning Discussion
The team engaged in a detailed discussion about the architectural enhancements planned for Grype 1.0, with a focus on improving the clarity and accuracy of scan results.
A key area of discussion was the evolution of “match details.” Currently, this feature provides some context on how a vulnerability was identified. The proposal is to expand this into a more comprehensive “audit log” or a collection of “evidence” for each match. This would offer a clearer rationale for why a vulnerability is reported or not.
This led to a conversation about “negative matches.” At present, if Grype confirms that a package is not vulnerable (for instance, due to a patch), it is simply excluded from the results, making it indistinguishable from a “search miss” where no information is available. The team aims to explicitly report these “negative matches” to provide users with high confidence that a CVE has been confirmed as fixed.
Another significant proposed change is to the matching process’s control flow. Instead of the current parallel but separate execution of matchers, the new approach would first group related packages (like a curl binary and its corresponding dpkg package). Subsequently, all relevant matchers would provide a “verdict” (e.g., ‘vulnerable’, ‘fixed’, or ‘search miss’) for each group. A final determination would be based on the precedence of the collected evidence, which would help in resolving many current false positives.
This new architecture would also facilitate reporting on remediations that go beyond simple package upgrades, such as recommending an upgrade of the base operating system.
This in-depth discussion included contributions from Alex Goodman, Will Murphy, Keith Zantow, and Christopher Phillips, who collectively explored these forward-looking concepts for Grype.
Hello everyone!
Starts at 2025-07-17T19:00:00Z for about an hour.