We’re back with the Anchore Open Source team running a live stream to discuss issues, pull requests, and future roadmap planning in our SBOM and vulnerability tools.
Starts at 2025-05-01T19:00:00Z for about an hour.
Expect engineering and project management discussions, a bit of GitHub issue gardening on Syft, Grype, and the rest of the family.
Join us today for a relaxed, educational, and productive live stream.
Topics
Issues - Open issues with “needs-discussion” label
Pull Requests - Open PRs with “needs-discussion” label
Summary: Grype was reporting false positives when GitHub Actions used commit hashes instead of version tags, as it didn’t parse the version number commented out after the hash.
Action: A fix was merged into Syft (PR #3776) to parse these version comments. This should resolve the false positive once the Syft update is included in a Grype release. It was noted that the version comment needs to be SemVer compliant (e.g., v46.0.0, not just v46). There’s also a potential future enhancement to use the GitHub API to resolve versions from hashes directly.
Issue #2630: Grype does not handle purl file input with packages from different distributions
Summary: When scanning a file containing Package URLs (purls) from multiple Linux distributions (e.g., Ubuntu and Oracle Linux), Grype fails to identify vulnerabilities for all packages. This is because Grype currently expects a single distribution context for the scan, even though the distribution information is present in the individual purls.
Action: The underlying issue is understood; Grype’s internal package representation now supports per-package distribution information, but the purl provider needs updating to utilize this. The issue was marked as ready and a good candidate for a first contribution. Until fixed, users should provide separate input files for each distribution.
Issue #2607: Pull Requests: Automated reviews with coderabbit.ai
Summary: A suggestion was made to use CodeRabbit (an AI tool) for automated PR reviews to potentially speed up the process. A philosophical discussion ensued about the role of AI in code review versus human oversight, especially concerning security projects and the potential impact on contributor diligence.
Action: The issue was marked as “needs discussion” for the wider team to weigh in on the pros and cons before making a decision.
Issue #2462: Support embedded CycloneDX VEX documents
Summary: Grype currently errors when attempting to use a CycloneDX SBOM file as a VEX document because it only supports the OpenVEX format.
Action: This was accepted as a feature request to add support for reading VEX information embedded within CycloneDX documents, similar to how OpenVEX is handled. Marked as ready.
Issue #2471: Support using VEX documents with directory scans and SBOMs
Summary: When using an OpenVEX document with Grype for scans originating from a directory source (or an SBOM generated from one), an error occurs because the VEX matching logic currently only supports container image sources.
Action: Needs further investigation/discussion, particularly around how VEX subjects should map to directory sources. Deferred until Alex Goodman can provide more input.
Summary: A request to upgrade the base Docker image used for Syft releases from Debian 11 to Debian 12 (specifically the distroless static variant).
Action: Accepted and marked as ready. The team will investigate updating the base image, potentially considering even smaller/more performant alternatives than Debian 12 static, while ensuring compatibility (e.g., with GitLab runners needing a debug shell).
Issue #3831: Propagate error in FileSourceProvider instead of warn log
Summary: When Syft encounters an archive it cannot unpack (e.g., a RAR file renamed to .tar.gz), it currently only logs a warning and potentially produces an incomplete/incorrect SBOM, rather than propagating an error. This primarily affects library users.
Action: Agreed this is a bug; the error should be bubbled up. Marked as ready and a good first issue. The necessary code change was identified during the stream.
Issue #3781: Support embedding file hashes directly within components in CycloneDX-JSON SBOM output
Summary: Request to embed file hashes directly within the component data in CycloneDX output, rather than just in the separate “files” section. Discussion occurred around whether the user expected the hash of the file as found by Syft or the hash of the original installable package (like a .deb or .rpm).
Action: Marked as “needs investigation.” Awaiting clarification from the original author on the exact requirement.
Issue #3780: Return full license string instead of SHA256 hash when license string exceeds 64 characters.
Summary: Syft currently hashes license strings longer than 64 characters when generating SPDX output, making it hard to trace non-standard licenses. A recent PR (#3450) added support for full license text, but further work is needed for the SPDX output. The specific example provided (“LGPLv2+ and LGPLv2+ with exceptions…”) is also not a valid SPDX expression.
Action: The related full-text PR (#3450) is merged. Developer spiffcs is actively working on ensuring these long/non-standard license strings populate the correct field (full text) instead of being hashed or incorrectly placed in the SPDX ID/expression field. A configuration option might be added to control this behavior to avoid unexpectedly increasing SBOM size for existing users.
Hello everyone!
Starts at 2025-05-01T19:00:00Z for about an hour.