# October 16th 2025 | Open Source Gardening | Live Stream

**URL:** <https://anchorecommunity.discourse.group/t/october-16th-2025-open-source-gardening-live-stream/581>\
**Category:** General\
**Tags:** video, gardening\
**Created:** [October 30, 2025, 11:53pm UTC](https://anchorecommunity.discourse.group/t/october-16th-2025-open-source-gardening-live-stream/581 "2025-10-30T23:53:43Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![nurmi](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/nurmi/32/95_2.png) [@nurmi](https://anchorecommunity.discourse.group/u/nurmi)\
**Post date:** [October 30, 2025, 11:53pm UTC](https://anchorecommunity.discourse.group/t/october-16th-2025-open-source-gardening-live-stream/581/1 "2025-10-30T23:53:43Z")

</div>

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](https://github.com/anchore/syft/issues/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](https://github.com/anchore/syft/pull/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](https://github.com/anchore/syft/pull/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](https://github.com/anchore/grype/issues/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!