October 23rd 2025 | Open Source Gardening | Live Stream

General
,
1

Hello, Anchore community!

Here’s a summary of our Open Source Gardening session from October 23, 2025. This week, Will, Keith, Chris, and Alex gathered to discuss a major update to the Grype database, a nuanced bug fix for Syft’s dpkg cataloger, and two large feature discussions for Grype.

:rocket: Grype Database Update: AlmaLinux

Will started the meeting with an important update for Grype users scanning AlmaLinux images.

  • The Change: Starting tomorrow (October 24), the public Grype database will include vulnerability advisories sourced directly from AlmaLinux.
  • Why it Matters: Previously, Grype treated AlmaLinux as a 1:1 binary clone of Red Hat and used Red Hat’s vulnerability data for Alma scans. While mostly accurate, this approach created false positives in cases where AlmaLinux patched a package at a different version than Red Hat.
  • The Result: This change will increase the accuracy of AlmaLinux scans and should resolve a known class of false positives.

Uninstalled DPKGs Topic

The team dove into a pull request to change how Syft’s Debian (dpkg) cataloger handles uninstalled packages.

  • The Bug: Will provided context that when a user runs apt remove on a Debian-based system without the --purge flag, the package’s config files and metadata are left behind. The package is marked with a “de-installed” status. Syft was incorrectly identifying these “de-installed” package remnants as fully installed packages.
  • The Debate: The team’s main discussion was whether this should be a simple bug fix or a new configurable feature.
    • Is it a risk? Will questioned if leftover config files could pose a security risk, which might justify reporting them.
    • Is it a package? Alex argued that Syft’s job is to report packages, and these remnants are “package fragments,” not complete packages. Reporting them as full packages is misleading.
    • What about history? Chris noted that in a past job, this “de-installed” status was a useful signal that a machine was “dirty” and needed a full rebuild. Alex suggested a “magic wand” solution might be for Syft to add a metadata flag (e.g., deinstalled: true) to the package, making the SBOM more accurate while allowing Grype to make a risk decision.
  • The Resolution: The team ultimately agreed this is a bug in Syft. Syft’s core job is to answer “what is installed?” and a “de-installed” package is, by definition, not installed.
  • Outcome: Will suggested they simplify the PR to remove the configuration option and just fix the bug. He then issued a “listener challenge” to the community: if anyone can find a real-world CVE that is exploitable only from the leftover files of a de-installed package, they’d love to see it.

Multiple Scan Targets with Grype

Next, the team discussed a long-standing feature request to allow Grype to scan multiple targets at once (e.g., grype image:1 image:2).

  • The Use Case: Users want to scan multiple images or a multi-architecture manifest list (which contains many images) in a single command, rather than writing a bash loop to scan each one individually.
  • The “Easy” Part: For Grype’s default table and JSON formats, Alex suggested a path forward: the JSON output could be extended with a top-level sources array, and each artifact in the matches list would simply reference a source ID.
  • The “Hard” Part: The real problem is SBOM formats. Keith pointed out that formats like CycloneDX don’t have a clear, standardized way to represent vulnerability findings for multiple top-level components (sources) in a single document. Tools like Dependency-Track are often very strict about document structure and might reject a non-standard “multi-bomb”.
  • The Blocker: Will raised a key concern: if Grype defines a new “multi-source” vulnerability format, it could “paint Syft into a corner” by forcing Syft to adopt a matching multi-source SBOM format, even if that wasn’t the best design for Syft.
  • Outcome: This feature is desirable but complex. It needs a concrete proposal for the output formats, especially with Grype 1.0 on the horizon. Alex suggested a possible path would be to implement the feature only for Grype’s native JSON/table formats first and disable SBOM outputs (-o cyclonedx) when scanning multiple targets.

Red Hat EUS Handling

The final discussion centered on a nuanced issue with Red Hat EUS (Extended Update Support) and Grype’s --only-fixed flag.

  • The Problem: Red Hat EUS is a paid product allowing users to stay on a specific minor release (e.g., RHEL 9.4) and receive backported security fixes, rather than upgrading to the latest minor (e.g., RHEL 9.6).
  • Grype’s --only-fixed flag currently tells this EUS user to upgrade to 9.6, which is exactly what the user is paying Red Hat to avoid doing.
  • The “Real” Issue: Will framed this as a much broader problem with Grype’s “baked-in assumption” about what users are willing to upgrade.
    • Grype assumes you’ll update a package (e.g., java-11 to java-21) but not a distro (e.g., RHEL 8 to RHEL 9).
    • This EUS issue proves the assumption is even more granular: some users won’t even update minor distro versions.
  • The Solution: The team agreed that Grype needs a more sophisticated configuration knob to define “actionability”. Users need a way to tell Grype their tolerance for upgrades (e.g., “show me patch fixes only,” “show me minor fixes,” or “never suggest a new language interpreter”).
  • Outcome: This is a key design consideration for Grype 1.0 and its “action-based orientation”. The feature would allow Grype to group vulnerabilities by the action needed to fix them (e.g., “this one OS upgrade remediates these 90 things”). This issue needs more discussion and a full proposal.

That’s all for this week! Thanks for tuning in. We encourage everyone to join the conversation on these issues on GitHub or in our community Discourse.