SBOM’s: The essential foundation of open source security

Getting started with open source SBOM power tools Syft and Grype.

In my years working with open source software, I’ve seen our community go through many phases–from “move fast and break things” to our current (and much-needed) shift toward “secure by design.” But there’s one thing that hasn’t changed: You can’t secure what you don’t know you have. This brings us to Software Bills of Materials, or SBOMs–the most important security tool you’re not using yet.

Think of an SBOM as a comprehensive list of ingredients for your software. Just like you’d want to know if there’s peanuts in your chocolate bar if you have an allergy, you need to know if there’s a vulnerable version of log4j in your application before it causes an allergic reaction in your production environment!

Why SBOMs matter (more than ever)

Remember the Log4j apocalypse of 2021? Organizations worldwide scrambled to figure out if they were vulnerable. Those with proper SBOMs could quickly identify if and where they were using the compromised component. Those without them? Well, they spent weeks frantically grepping through codebases and crossing their fingers.

This isn’t just a nice-to-have anymore. Executive Order 14028 in the US and the EU Cyber Resilience Act are prompting organizations to adopt SBOMs as standard practice. Even if regulatory compliance isn’t a concern for you as a self-hosted or small project maintainer, the security benefits alone make SBOMs worth implementing.

Read more: DevSecOps demystified: Leveraging Software Bill of Materials for enhanced security

SBOM formats: A quick overview

Before diving into the tools, let’s quickly cover the two main SBOM formats you’ll encounter:

Feature	SPDX (Software Package Data Exchange)	CycloneDX
Origin / steward	Linux Foundation	OWASP (Open Web Application Security Project)
Initial focus	Primarily focused on software licensing and provenance.	Primarily focused on security vulnerabilities and risk.
Scope	Broader scope, covering licensing, security, provenance, build information, etc.	Initially more focused on security, but has expanded. Designed to be lean and flexible.
Use cases	Strong for license compliance tracking, copyright management, and overall software transparency.	Strong for vulnerability identification, risk management, and integration with security tools.
Data formats	Supports multiple formats like RDF/XML, tag-value, JSON, YAML, XLSX.	Primarily uses JSON and XML.
Standard body	ISO/IEC 5962:2021	ECMA-424

Both formats are well-supported by modern tools, including the ones we’ll be looking at today.

Enter Syft and Grype: Open source SBOM power tools

Syft and Grype are two open source tools from Anchore that make working with SBOMs surprisingly painless:

• Syft generates SBOMs from various sources (container images, directories, etc.)
• Grype scans those SBOMs for known vulnerabilities.

The best part? They’re both single Go binaries with no API keys or accounts required. You can run them locally, in CI/CD pipelines, or anywhere else you need them.

Getting started with Syft and Grype

Let’s get our hands dirty. First, you’ll need to install both tools:

Installation

On Linux or macOS:

curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin
curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin

For Windows or other options, check the Syft and Grype documentation.

Generating your first SBOM

Let’s generate an SBOM for the Alpine Linux container:

syft alpine:latest -o json > alpine-latest.sbom.json

That’s it! You now have a complete inventory of what’s in that container. View that in your favorite text editor. Let’s take a peek at the (default) human-readable output:

syft alpine:latest -o table

You’ll see a nicely formatted list of all packages in the image, including their versions and the type of software package (e.g. deb, rpm, apk, etc).

Scanning for vulnerabilities

Now, let’s check if our Alpine container has any vulnerabilities:

grype alpine-latest.sbom.json

If you’re using the latest Alpine image, you might see something like:

✔ Scanned for vulnerabilities     [0 vulnerability matches]
  ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
  └── by status:   0 fixed, 0 not-fixed, 0 ignored
No vulnerabilities found

That’s great! But what about an older version?

grype alpine:3.17

Uh oh – now we’re seeing some issues:

 ✔ Loaded image alpine:3.17
✔ Parsed image sha256:577bd1e3e5…a53f175103
✔ Cataloged contents  aa6337e1bb…9df483163a
 ├── ✔ Packages                   [15 packages]
 ├── ✔ File digests               [78 files]
 ├── ✔ File metadata              [78 locations]
 └── ✔ Executables                [17 executables]
✔ Scanned for vulnerabilities     [9 vulnerability matches]
  ├── by severity: 3 critical, 2 high, 4 medium, 0 low, 0 negligible
  └── by status:   4 fixed, 5 not-fixed, 0 ignored
NAME           INSTALLED   FIXED-IN   TYPE  VULNERABILITY   SEVERITY
busybox        1.35.0-r31             apk   CVE-2022-48174  Critical
busybox-binsh  1.35.0-r31             apk   CVE-2022-48174  Critical
libcrypto3     3.0.15-r0              apk   CVE-2024-13176  Medium
libcrypto3     3.0.15-r0   3.0.15-r1  apk   CVE-2024-9143   Medium
libssl3        3.0.15-r0              apk   CVE-2024-13176  Medium
libssl3        3.0.15-r0   3.0.15-r1  apk   CVE-2024-9143   Medium
musl           1.2.3-r5    1.2.3-r6   apk   CVE-2025-26519  High
musl-utils     1.2.3-r5    1.2.3-r6   apk   CVE-2025-26519  High
ssl_client     1.35.0-r31             apk   CVE-2022-48174  Critical

This showcases one of the most important aspects of vulnerability management – keeping your dependencies updated!

Integrating with CI/CD

The real power lies in automating this process. Here’s a simple GitHub Actions workflow that will regularly build a container, generate an SBOM, and scan for vulnerabilities:

name: "Vulnerability 🐞 scan 🔍 container"

on:
 schedule:
   - cron: "0 10 * * 2"
 workflow_dispatch:

jobs:
 vulnerability-scan:
   name: "Build and scan"
   runs-on: ubuntu-24.04
   steps:
     - name: Checkout code
       uses: actions/checkout@v4

     - name: Set up Docker Buildx
       uses: docker/setup-buildx-action@v3

     - name: Build local container
       uses: docker/build-push-action@v6
       with:
         context: .
         file: ./Containerfile
         tags: localbuild/testimage:latest
         push: false
         load: true

     - name: Scan image
       uses: anchore/scan-action@v5
       with:
         image: "localbuild/testimage:latest"
         output-format: table

     - name: Inspect action report
       run: cat ${{ steps.scan.outputs.table }}

You can further customize it to fail builds on critical vulnerabilities or upload the SBOM as an artifact. (The above example assumes you have a ./Containerfile)

Setting up a home lab vulnerability management system

For the home lab enthusiast or small team, here’s a simple yet effective workflow. I’ve started you off, and I’ll leave it as an exercise for you to complete the process:

1. Generate baseline SBOMs for all your container images.

#!/bin/bash
mkdir -p ~/sboms/$(date +%Y-%m-%d)
for image in $(docker image --format "{{.Repository}}:{{.Tag}}" | grep -v "<none>"); do
 echo ${image}
 syft ${image} -o spdx-json > ~/sboms/$(date +%Y-%m-%d)/${image}.json
done

2. Set up a simple update check script.

Create a script that:

• Generates a new SBOM for your containers
• Runs Grype against the SBOM
• Alerts you of any High or Critical vulnerabilities
• Optionally checks if newer versions are available

3. Run before deployment.

Before incorporating a new container into your environment, make it standard practice to generate an SBOM, or at least run grype against the image directly:

For the Nextcloud enthusiasts out there, let’s see what scanning a real-world container looks like:

This might show several vulnerabilities across different components. The key is not to panic, but to assess:

 grype ghcr.io/nextcloud-releases/all-in-one:latest
✔ Loaded image ghcr.io/nextcloud-releases/all-in-one:latest
✔ Parsed image sha256:8bd2e9e7ec…215f13ffd6
✔ Cataloged contents 6f8ab6170a…c9a90688d1
  ├── ✔ Packages                 [260 packages]
  ├── ✔ File metadata            [2,884 locations]
  ├── ✔ Executables              [506 executables]
  └── ✔ File digests             [2,884 files]
✔ Scanned for vulnerabilities     [17 vulnerability matches]
  ├── by severity: 0 critical, 1 high, 11 medium, 3 low, 0 negligible (2 unknown)
  └── by status:   10 fixed, 7 not-fixed, 0 ignored
NAME                           INSTALLED   FIXED-IN                      TYPE       VULNERABILITY        SEVERITY
apache2                        2.4.62-r0                                 apk        CVE-2007-6422        Medium
apache2                        2.4.62-r0                                 apk        CVE-2008-2168        Medium
apache2                        2.4.62-r0                                 apk        CVE-2007-6421        Low
flock                          2.40.4-r0                                 apk        CVE-2010-3262        Medium
github.com/go-jose/go-jose/v3  v3.0.3      3.0.4                         go-module  GHSA-c6gw-w398-hv78  Medium
golang.org/x/crypto            v0.31.0     0.35.0                        go-module  GHSA-hcg3-q754-cr77  High
golang.org/x/net               v0.33.0     0.36.0                        go-module  GHSA-qxp5-gwg8-xv66  Medium
golang.org/x/net               v0.33.0     0.38.0                        go-module  GHSA-vvgc-356p-c3xw  Medium
linux-pam                      1.6.1-r1                                  apk        CVE-2024-10041       Medium
python3                        3.12.10-r0                                apk        CVE-2024-3220        Low
sqlite-libs                    3.48.0-r0                                 apk        CVE-2025-3277        Medium
sqlite-libs                    3.48.0-r0   3.48.0-r1                     apk        CVE-2025-29087       Low
stdlib                         go1.23.4    1.22.11, 1.23.5, 1.24.0-rc.2  go-module  CVE-2024-45336       Medium
stdlib                         go1.23.4    1.22.11, 1.23.5, 1.24.0-rc.2  go-module  CVE-2024-45341       Medium
stdlib                         go1.23.4    1.22.12, 1.23.6, 1.24.0-rc.3  go-module  CVE-2025-22866       Medium
stdlib                         go1.23.4    1.23.8, 1.24.2                go-module  CVE-2025-22871       Unknown
stdlib                         go1.23.7    1.23.8, 1.24.2                go-module  CVE-2025-22871       Unknown

1. How severe are they?
2. Are they in components you actually use?
3. Is there a fix available?
4. What’s your update plan?

Read more: NextCloud’s long-term vision, data privacy, AI features, and more

Beyond scanning: Building a security-first culture

SBOMs and vulnerability scanning are just the beginning. Here’s what you can do next:

1. Keep historical SBOMs–When a new vulnerability is announced, you can quickly scan your historical SBOMs to see when you might have become vulnerable
2. Implement policies–Define what vulnerabilities are acceptable in your environment and which require immediate action
3. Contribute back–Both Syft and Grype are open source. As you use them, consider contributing back improvements or reporting issues
4. Stay informed–Join communities like CISA’s Secure by Design initiative to stay updated on best practices

Limitations and challenges

No tool is perfect, and it’s important to understand the limitations:

• Syft can struggle with components in containers where public source code isn’t available.
• There will always be “unknown unknowns”–components that tools simply can’t identify.
• Very large containers may require significant memory and time to generate an SBOM.
• An SBOM tells you what’s there, but not necessarily how it’s used or exposed.

Conclusion: Security through transparency

SBOMs represent a fundamental shift in how we approach software security–from reactive to proactive, from opacity to transparency. By knowing exactly what’s in your software supply chain, you gain the power to make informed security decisions.

The tools are ready, they’re open source, and they’re easier to use than ever. Whether you’re running a home lab, maintaining an open source project, or working in an enterprise environment, implementing SBOMs with tools like Syft and Grype is one of the most impactful security steps you can take in 2025.

In a future post, we’ll explore what to do when you actually find vulnerabilities in your software – because finding them is just the beginning of the journey.

More from We Love Open Source

• Why open source matters in your project management tool
• 10 open source tools you can start using today
• Leveraging Software Bill of Materials for enhanced security
• What is prompt engineering?
• What is OpenTelemetry?