# September 18th | Open Source Gardening | Live Stream **URL:** \ **Category:** General\ **Tags:** video, gardening\ **Created:** [September 15, 2025, 10:57am UTC](https://anchorecommunity.discourse.group/t/september-18th-open-source-gardening-live-stream/561 "2025-09-15T10:57:10Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![popey](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/popey/32/429_2.png) [@popey](https://anchorecommunity.discourse.group/u/popey)\ **Post date:** [September 15, 2025, 10:57am UTC](https://anchorecommunity.discourse.group/t/september-18th-open-source-gardening-live-stream/561/1 "2025-09-15T10:57:10Z")
September 18th | Open Source Gardening | Live Stream # 👋 Hello everyone! We’re back with the Anchore Open Source team running a [live stream](https://www.youtube.com/live/9xbpxA4DSNY) to discuss issues, pull requests, and future [roadmap](https://github.com/orgs/anchore/projects/22/views/18) planning in our [SBOM](https://anchore.com/sbom) and [vulnerability](https://anchore.com/container-vulnerability-scanning/) tools. ⏰ Starts at 2025-09-18T19:00:00Z for about an hour. Expect engineering and project management discussions, a bit of GitHub issue gardening on [Syft](https://github.com/anchore/syft), [Grype](https://github.com/anchore/grype), and the rest of the [family](https://github.com/anchore). Join us today for a relaxed, educational, and productive live stream. [![](https://global.discourse-cdn.com/free1/uploads/anchorecommunity/original/1X/2756cae5f9b0d29d80173281e3904712fb13a8a8.jpeg "Live SBOM & Security Fixes: Anchore Devs Improve Syft & Grype (September 18th)") ](https://www.youtube.com/watch?v=9xbpxA4DSNY) ## Topics - [Issues](https://github.com/search?q=org%3Aanchore+label%3Aneeds-discussion&type=issues&s=updated&o=desc) - Open issues with “needs-discussion” label - [Pull Requests](https://github.com/search?q=org%3Aanchore+label%3Aneeds-discussion&type=pullrequests&s=updated&o=desc) - Open PRs with “needs-discussion” label - [Discourse topics](https://anchorecommunity.discourse.group/filter?q=posts-max:2%20category%3Asyft%2Cgrype%2Cgeneral%20status%3Aopen%20status%3Apublic%20order%3Alatest-post) - Open topics from #General #Syft and #Grype with few or no replies - Questions from the audience ---
**Author:** ![popey](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/popey/32/429_2.png) [@popey](https://anchorecommunity.discourse.group/u/popey)\ **Post date:** [September 20, 2025, 3:03pm UTC](https://anchorecommunity.discourse.group/t/september-18th-open-source-gardening-live-stream/561/2 "2025-09-20T15:03:49Z")
Hello community! Here is the summary of our open-source gardening session from September 18th, 2025. This week, we were joined by Alan, Chris, Keith, Dan, and Will. We covered a major update for our license compliance tool, Grant, and then dove into some interesting issues for Syft and Grype related to proxies, what “fixed” really means, and discovering statically-linked dependencies. A recording of the session is available on YouTube. ### Grant License Compliance Tool Update Chris kicked off the session with an exciting update on **Grant** , our tool for license compliance. There has been a flurry of activity recently, with rapid releases moving from v0.3.0 to v0.3.2 to address bugs and add new features. Key changes include: - **Simplified Configuration** : The configuration for defining license rules has been significantly minified, reducing 4-5 lines of configuration down to a single line. You can get a default config file to start with by running `grant config`. - **New Workflow** : A new workflow makes it easier to drill down into license information. You can list all licenses in a project, select specific licenses to inspect the associated packages, and then filter by a specific package to see all of its licenses. - **Clickable Links** : The terminal output now includes clickable links that take you directly to the relevant SPDX license page for more details. - **Custom Risk Scores** : While the risk score for each license is currently compiled into Grant, a future goal for v0.4.0 is to allow users to override the default scores with their own, for example, to align with their organization’s legal guidance. - **We’re Using It!** : The team is “dog-fooding” Grant by using it to check its own licenses in a GitHub Actions workflow, which serves as a great example for anyone wanting to integrate it into their CI/CD pipeline. - **New Mascot** : Grant now has its own mascot, a friendly monster who fits right in with the Syft and Grype family! A webinar demonstrating Grant was also held earlier that day. Here’s the recording: [![](https://global.discourse-cdn.com/free1/uploads/anchorecommunity/original/1X/dcca9dd5f61823e458243d87bcb0e4b5eddd5544.jpeg "Packages, Policies, and Performance: What’s New in Grant") ](https://www.youtube.com/watch?v=RVyryb8f5GQ) ### [Syft Issue #4226](https://github.com/anchore/syft/issues/4226) & [Stereoscope #458](https://github.com/anchore/stereoscope/issues/458): Syft fails pull images through tunnels or proxies The first triage item was a bug where Syft fails to pull container images through a proxy. The user is using the `registry:` source to point Syft at a proxy URL. The registry sends a redirect, but Stereoscope (the library Syft uses to pull images) then tries to access the new URL directly, bypassing the proxy, which fails. The team acknowledged this is a valid bug and something they’d like to support. However, none of the team members regularly work behind corporate proxies, making it difficult to reproduce and test a fix. There was a discussion around potential workarounds and testing strategies: - It was suggested that the user might be able to use Go’s built-in support for proxies by setting the standard `HTTP_PROXY` or `HTTPS_PROXY` environment variables, which would cause all of Go’s HTTP traffic to go through the proxy transparently. - To properly test a fix, a dedicated environment would be needed. Will suggested setting up a local, non-internet-accessible container registry and placing a proxy in front of it to simulate the user’s environment accurately. **Outcome** : Keith agreed to comment on the issue, suggesting the environment variable workaround and outlining the team’s thoughts on how to approach a fix. The issue was deemed `ready` for implementation, pending the setup of a reliable testing environment. ### [Grype Issue #2852](https://github.com/anchore/grype/issues/2852): `only-fixed` should not suggest fixes that require a language major/minor version bump This discussion centered on the behavior of the `--only-fixed` flag in Grype. A user reported that for a vulnerability in Python 3.12, Grype suggests a fix is available in Python 3.14.0b3, a pre-release of a future version. The user argued this is not a practical or reasonable fix, as upgrading the language interpreter is a significant undertaking, unlike updating a library. The team agreed this was a valid point. Will noted an inconsistency in Grype’s logic: it correctly constrains fixes to the current operating system distribution (e.g., it won’t suggest an upgrade to the next Ubuntu LTS), but it doesn’t apply the same logic to language runtimes. The discussion explored how to make this behavior more configurable and useful: - The team liked the user’s suggestion for a flag like `--do-not-suggest-minor-version-bump=python`. - This behavior is common for runtimes like Python and the JDK, where upgrading is a major task. For other ecosystems like Go, developers often upgrade the compiler with minimal friction. - The discussion referenced Dependabot’s configuration, which allows users to define a `remediation-strategy` for specific dependencies, as a good model to follow. This would allow users to tell Grype that for certain packages (like the Python interpreter), a fix is only considered “available” if it doesn’t cross a minor or major version boundary. **Outcome** : The team concluded that an enhancement is needed to allow users to configure what constitutes an “available” fix, especially for foundational components like language runtimes. The approach will likely involve adding a configuration option similar to Dependabot’s. ### [Syft Issue #3063](https://github.com/anchore/syft/issues/3063): Syft still finds packages that have been removed with `apt remove` The team discussed a scenario where Syft reports packages that have been removed using `apt remove` but not `apt purge`. In Debian-based systems, `apt remove` uninstalls the package’s binaries but leaves behind configuration files. An entry for the package remains in the `/var/lib/dpkg/status` file, which is what Syft was reading. The team quickly came to a consensus that this is a bug. - If the package’s binaries are gone, it should not be listed as an installed package in the SBOM by default. - Users who are interested in finding these leftover, “orphaned” configuration files can do so by enabling the file metadata cataloger to list all files in the image, but the package itself should not be reported. **Outcome** : The team agreed this is a straightforward bug. The `needs-discussion` label was removed, and the issue is ready to be fixed. Syft should be updated to ignore these de-installed package entries in the dpkg status file. ### [Syft Issue #4195](https://github.com/anchore/syft/issues/4195): Parse `Static-Built-Using` field in DPKG metadata The final issue was an enhancement request to have Syft parse a specific metadata field in Debian/Ubuntu package manifests called `Static-Built-Using` (and its older variants like `X-Cargo-Built-Using`). This field lists dependencies that were statically linked into the package’s binaries, such as Rust crates or Go modules. For example, the `ripgrep` package in Ubuntu lists all the Rust crates it was built with in this field. The team agreed this is a valuable source of information that Syft should use. The discussion highlighted some implementation complexities: - **Conflict Resolution** : What happens if Syft’s binary analysis (e.g., parsing Go module info from a binary) finds a different version of a dependency than what’s listed in the `Static-Built-Using` field? The consensus leaned toward trusting the binary analysis as it’s likely more accurate and complete, but this needs further investigation. - **Package Representation** : Should these statically linked dependencies be reported as first-class packages in the SBOM? The team felt they should be, as this would make them discoverable for vulnerability scanning. Simply listing them as metadata on the parent package would be less useful. **Outcome** : This is a great enhancement idea. The implementation needs to consider how to handle potential data conflicts and how to best represent these discovered dependencies in the final SBOM.