SBOM: The “X-Ray” for Dependency Analysis and Vulnerability Scanning with Syft & Grype – ITFROMZERO

Table of Contents

The Disaster of “Invisible” Components in Containers

2:00 AM. The phone rings incessantly. The Security team sends an urgent alert: “Log4j vulnerability detected on Production.” I jump out of bed, cold sweat running down my face. The challenge isn’t how to fix it—the problem is how to find exactly which microservice is “harboring” that malicious library among hundreds of running containers.

My server had been SSH brute-forced before, so I always set up security meticulously from the start. But this time was different. The vulnerability wasn’t in the server configuration but deep within the dependencies that the developers installed. Looking at the Dockerfile, everything seemed clean. However, hidden behind the image layers was a “tangled mess” of packages that you can almost never control manually.

This is where SBOM (Software Bill of Materials) comes in. Think of it as a detailed ingredient list for everything that makes up your software. To manage SBOMs professionally like a true SRE, you must know this duo: Syft and Grype.

SBOM, Syft, and Grype: Understanding Them Right to Use Them Well

Imagine an SBOM is like the ingredients list on a pack of instant noodles. It tells you exactly how much salt, MSG, or preservatives are inside. In technical terms, an SBOM lists library names, versions, licenses, and even transitive dependencies—things you didn’t install directly but still appear in your code.

Syft: This tool acts as the “scanner.” It scans container images or source code to extract an SBOM. Syft is incredibly fast, usually taking only 5-10 seconds for an image several hundred MBs in size.
Grype: If Syft is the scanner, Grype is the “expert inspector.” It takes the list from the SBOM to cross-reference it with global vulnerability databases (CVEs).

This pair creates a solid shield for your Software Supply Chain. You know what you have, and you know if what you have is “poisoned.”

Practical Implementation: Controlling Dependencies in 5 Minutes

1. Installing the Tools

Both are developed by Anchore, so installing them on Linux is extremely quick via the official scripts:

# Install Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Install Grype
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

Type syft --version to check. If the version appears, you’re ready to go.

2. Exporting Your First SBOM

Try inspecting the “innards” of any container image, for example, nginx:latest:

syft nginx:latest

You will see dozens, even hundreds of packages appear. For long-term storage or use with other tools, I recommend exporting to a standard format like JSON or CycloneDX:

syft webapp:v1.0 -o json > webapp-sbom.json

This JSON file is the “birth certificate” of your container. When a new vulnerability emerges (like Log4j or Heartbleed), you just need to grep this file to know if you’re affected. No need to SSH into the server, no need to restart the container.

3. Hunting Vulnerabilities with Grype

Now, let Grype do its job. It will automatically download the latest vulnerability database before scanning.

grype webapp:v1.0

Results will be categorized by severity: Low, Medium, High, Critical. If you see a Critical line with a CVE ID, that’s a red alert requiring an immediate update.

A quick tip: Instead of scanning the image (which consumes bandwidth), scan the SBOM file you created in the previous step directly:

grype sbom:./webapp-sbom.json

4. Response Workflow When Trouble Is Found

Don’t panic when you see a long list of vulnerabilities. Focus on the “Fixed In” column. This is the secure version you need to upgrade to. My typical workflow is: Identify the faulty package -> Update package.json or the Dockerfile -> Rebuild the image -> Perform a final scan.

Automation: Don’t Wait Until It’s Too Late

A fatal mistake is only scanning when you remember to. Turn security into part of your pipeline (Shift-left Security). Every time a developer pushes code, the system should automatically generate an SBOM and scan for vulnerabilities immediately.

Here is how I configure GitHub Actions to block images with critical vulnerabilities:

- name: Scan image
  uses: anchore/scan-action@v3
  with:
    image: "webapp:latest"
    fail-build: true
    severity-cutoff: critical

With fail-build: true, if a Critical vulnerability is detected, the pipeline will stop immediately. Vulnerable code is never allowed to reach Production. This way, I can sleep soundly without worrying about the phone ringing at midnight.

Conclusion

Security is not a destination but a journey of continuous control. With Syft and Grype in hand, you have X-ray vision into your system. An SBOM is not just a dry security compliance requirement; it is a rapid response tool against any attack on the supply chain. Get into the habit of creating SBOMs today. Happy system managing and sleep well!