October 16th 2025 | Open Source Gardening | Live Stream

General
,
1

Hello, Anchore community!

Here’s a summary of our recent Open Source Gardening session from October 16, 2025. The team (Dan, Will, Chris, Keith, and Alex) gathered to discuss several key issues and pull requests from the community.

We covered a lot of ground, from long-term feature planning in Grype to the nuances of Windows path handling and data fidelity in vulnerability feeds.

Syft Issue #572

Will kicked off the session with a feature request to add dependency graph information to Syft, but focused the discussion on how this data could be used in Grype to provide more actionable feedback.

  • The Problem: When scanning an old project, Grype can return thousands of vulnerabilities. This is “hard feedback to act on,” especially since many findings are in transitive dependencies, not packages the user installed directly.
  • The “Hard” Solution (and why it’s hard): The ideal feature would be Grype telling a user, “If you upgrade direct dependency ‘foo’, you will resolve 300 CVEs.” Will and Alex explained this is extremely difficult because it would require Grype to:
    1. Know what the “latest” version of ‘foo’ is.
    2. Hypothetically resolve the entire dependency graph for that new version.
    3. Scan that new hypothetical graph for vulnerabilities.
      This is effectively re-implementing the version resolution logic for every package manager (Go, Python, Java, etc.), which isn’t feasible.
  • The “Simpler” Solution: Instead, Will proposed a “roll-up” feature. Grype wouldn’t recommend a specific upgrade. It would simply analyze the current SBOM’s dependency graph and tell the user, “Your direct dependency ‘foo’ is the root of a sub-tree that contains 300 vulnerabilities.” This is just a new presentation of data Syft and Grype already have.
  • Team Discussion:
    • Alex noted this fits perfectly with plans for Grype 1.0, which aims to move beyond a flat list of matches and allow “biasing” the output (e.g., group by package, by vulnerability, or by “actionable remediation”).
    • Alex also raised the “Log4Shell problem”: the sorting can’t just be by count. A dependency that brings in 100 “moderate” CVEs is different from one that brings in one critical, exploited CVE like Log4Shell. The final feature would need to be multi-faceted, balancing vulnerability count with severity (CVSS, EPSS, etc.).
  • Outcome: The team agreed this is a valuable feature to pursue, even in its “simpler” form. Dan noted that anyone interested in helping should check the issue, as ecosystems with a checkmark have better dependency data to build this feature.

Syft PR #3932

Next, the team reviewed a pull request from the community to enable deterministic output for SPDX SBOMs.

  • The PR: This PR introduces options to make SPDX output deterministic by allowing the user to set a specific creation timestamp and use a deterministic UUID for the document namespace.
  • The Discussion: The team had discussed this PR on a previous stream. Chris, who is assigned to it, summarized the remaining work. The main point is to ensure “feature parity” with CycloneDX.
  • Alex raised a good point about the configuration: the PR introduces two separate options (spdx-json.deterministic-uuid and spdx-json.created-time). He argued that a user setting one but not the other is “probably a mistake” and that a single, higher-level config option (like be-deterministic) might be a better user experience.
  • Keith pointed out the challenge: a simple boolean flag isn’t enough, as the user needs to be able to pass in a specific value for the timestamp.
  • Outcome: Chris removed the “needs discussion” label. He will move forward with the SPDX-specific changes in this PR and open a new issue to track adding the equivalent functionality for CycloneDX, which will allow the team to design a more unified configuration experience later.

Syft PR #4075

The team moved on to another community PR to fix a bug where Syft fails to scan UNC (network) paths on Windows (e.g., \\hostname\share).

  • The PR: The contributor provided a fix for scanning these network paths.
  • The Discussion: Chris had put the “needs discussion” label on this himself. He tested the PR on his Windows VM with a network mount, and it “looked good,” but he wanted more eyes on it because he’s been “bitten before by solo merging path things.”
  • Will and Alex highlighted the core risk: Syft has “no tests on Windows” in CI. Path handling is “really subtle” in Syft because it constantly deals with mixed environments (e.g., running on a Windows host scanning a Linux container image). A change could easily cause a regression in other Windows path handling, and the team would have no way of knowing.
  • The team discussed the ongoing, larger effort to port their taskfile.yml scripts to Go, which would enable cross-platform CI (including Windows).
  • Outcome: The team decided not to block this valuable community PR on the larger CI effort. Chris (who still has his Windows VM) volunteered to manually run the full unit and CLI test suites on his Windows machine to “smoke test” for any regressions. If those pass, the PR will be merged. Chris removed the “needs discussion” label.

Grype Issue #2993

Finally, the team looked at an issue concerning false positives for httpd-tools on RPM-based distros.

  • The Issue: A user noted that httpd-tools (which contains command-line utilities) is getting vulnerabilities reported against it that belong to httpd (the web server).
  • The Discussion: This is a long-standing, known problem related to data fidelity. Will and Dan explained that distros like Red Hat often release vulnerabilities against the source RPM (e.g., httpd) from which many binary RPMs (httpd, httpd-tools, httpd-devel, etc.) are built. The vulnerability data doesn’t specify which of the binary packages are affected, so Grype must conservatively assume they all are.
  • The team has considered heuristics (e.g., ignoring -tools or -debuginfo packages), but these are unreliable. Dan pointed out a vulnerability in a pre-install script would, in fact, be present in all the binary packages, making such a heuristic dangerous.
  • Potential Solutions:
    1. Reachability: Alex connected this to the symbol-level reachability analysis discussed last week. If Grype could prove the vulnerable code (e.g., a specific function) isn’t present in the httpd-tools binary, it could suppress the false positive.
    2. VEX: Dan suggested that VEX (Vulnerability Exploitability eXchange) is the correct long-term solution. He proposed asking the Red Hat security team if they would consider publishing VEX data to formally state which binary packages are not affected by a source RPM’s vulnerability.
  • Outcome: This is a complex data problem with no immediate fix. The “needs discussion” label will remain on the issue.

Thanks to everyone for joining the stream and for all the community contributions. We’ll see you next week!