I chat with Alan Pope about the open source security tools Syft, Grype, and Grant. These tools help create Software Bills of Materials (SBOMs) and scan for vulnerabilities. Learn why generating and storing SBOMs is crucial for understanding your software supply chain and quickly responding to new threats like Log4Shell.
Episode Links
This episode is also available as a podcast, search for “Open Source Security” on your favorite podcast player.
Unpacking the Open Source Toolbox: Syft, Grype, and the SBOM Revolution
Talking about open source security often leads down interesting paths. Recently, I had a chance to chat with Alan, a long-time open source veteran currently focused on developer relations for some security tools at Anchore. We dove into the world of Software Bills of Materials (SBOMs) and vulnerability scanning, exploring not just the what, but also the why behind some key open source projects in this space.
Meet the Tools: Syft and Grype
At the heart of our discussion were two core tools: Syft and Grype. For those unfamiliar, Syft tackles the challenge of generating an SBOM. Think of it as a tool that meticulously digs through a container image, a directory, or even source code repositories to figure out precisely what software components are present. It doesn’t just list top-level items; it delves deep to identify packages and libraries, ultimately producing a detailed SBOM document. It also supports standard formats like SPDX or CycloneDX. Alan rightly pointed out that Syft is considered a top-tier SBOM generator.
Once you have this SBOM document, which is essentially a detailed inventory, Grype enters the picture. Grype is a vulnerability scanner. You can feed it an SBOM, and it cross-references the listed components and their versions against a comprehensive vulnerability database. This database aggregates information from numerous sources like NVD, GitHub, and various distribution-specific feeds (Red Hat, Debian, Ubuntu, etc.). Grype then reports any known vulnerabilities associated with the software identified in the SBOM. There’s also a companion tool, Grant, which specifically focuses on identifying the licenses of all discovered packages, a useful capability for organizations managing license compliance or performing due diligence, such as during mergers and acquisitions.
Why Open Source the tools?
A natural question arises: why give away such useful tools? Alan offered perspectives rooted in his decades of open source experience. From a personal standpoint, the value of community feedback and contribution is immense. Whether it’s bug reports highlighting edge cases where a tool fails, or actual code contributions, the collaborative nature of open source leads to more robust and reliable software. There’s also an ethical dimension, a desire to contribute useful code back to the community and leave a positive footprint.
From an organizational perspective, open source makes tremendous sense for tools like Syft and Grype. The scope of software packaging and deployment is vast, far too broad for any single entity to cover exhaustively. By open-sourcing the tools under a permissive license like Apache 2.0, it encourages wider adoption and contribution [cite: discussion]. People can integrate Syft’s library into their own products, fostering an ecosystem. Crucially, it builds trust. Users can inspect the source code, build it themselves, and even manage their own vulnerability data feeds if needed, ensuring transparency and avoiding concerns about proprietary data leakage. This community-driven approach helps create the high-quality, reliable, and secure tools that the ecosystem needs for essential tasks like SBOM generation and vulnerability scanning.
The Devil’s in the Details: Generating SBOMs
Creating an accurate SBOM sounds simpler than it is. Alan shed light on the complexities, especially with container images. You often don’t know the image’s provenance or build process. Containers can have intricate layers where software was installed and perhaps later removed, leaving behind artifacts or making the final state difficult to figure out.
Syft’s approach involves deep inspection. Critically, it avoids executing package managers (like rpm or dpkg) within the scanned target because those tools might be missing, their databases deleted during image optimization, or they simply can’t be trusted in an unknown environment. Instead, Syft reads the file system directly, fingerprinting files and looking for tell-tale signs to identify software components. This method is more resilient but also highlights the challenge that sometimes components are packaged in non-standard ways or come from sources Syft can’t definitively identify (like bespoke binaries compiled internally by a vendor). This led to the concept of “known unknowns” in Syft, where the tool acknowledges files it found but couldn’t classify, which is more helpful than ignoring them entirely.
Don’t Just Scan, Keep the SBOM
An essential piece of advice that emerged was the importance of keeping the generated SBOMs. Generating an SBOM, especially for a large, complex container, can be computationally intensive. Storing the resulting JSON document, however, is trivial compared to storing the potentially multi-gigabyte container image itself.
Why keep them? Because new vulnerabilities (CVEs) are discovered constantly. When a critical vulnerability emerges, the kind with its own name and logo, having a history of SBOMs allows for rapid retrospective analysis. Instead of needing to rescan potentially archived or inaccessible container images, you can run Grype against your stored SBOMs in milliseconds. This allows you to quickly determine not just if you are currently affected, but when a vulnerable component might have first entered your environment. The Log4Shell incident served as a stark reminder of this; organizations with SBOMs could query their inventory almost instantly, while others faced months of uncertainty trying to locate the vulnerable library. Alan’s point was clear: the best time to start generating and storing SBOMs was yesterday; the second-best time is right now. While Grype can scan a container directly (it bundles the Syft library), scanning a pre-existing SBOM is significantly faster and more efficient for ongoing monitoring. We’re very good at storing and searching JSON, we’re not really good at storing containers forever.
Understanding the contents of our software is not optional. Open source tools like Syft and Grype provide accessible, transparent ways to generate SBOMs and scan for vulnerabilities. Using these tools and the practice of maintaining SBOMs is a critical step towards a more secure software supply chain.