From SBOM to Vulnerability Management: Why I built Argus SBOM Guard

Did we really need yet another open-source security tool?
A journey from software supply chain visibility to vulnerability management.

Introduction

Let's start with a simple question.

Imagine you are responsible for the security of an organization running several applications, microservices, and third-party software components.

A new critical vulnerability is disclosed. How quickly can you determine whether your systems are affected?

Do you know which applications include the vulnerable dependency? Which versions are affected? Can you track the issue until it is fixed?

This is one of the challenges of modern vulnerability management.

Software supply chains have become increasingly complex. Applications depend on hundreds of open-source libraries and third-party components, often through multiple layers of transitive dependencies.

Knowing what is running in your infrastructure is no longer enough. You also need to understand what your software is made of.

This is where Software Bills of Materials (SBOMs) come into play.

But generating an SBOM is only the beginning.

In this article, I'll explain the relationship between Risk Management, Vulnerability Management, and SBOMs, and introduce Argus SBOM Guard, an open-source project I started to address some of the practical challenges I encountered in this area.

1. Risk Management & Vulnerability Management

Before talking about tools and technologies, I think it is important to clarify one fundamental concept: identifying a vulnerability is not the same as managing a risk.

Risk Management is about understanding and evaluating potential events that could negatively affect an organization.

A simplified way to express this concept is:

Risk = Probability × Impact

The probability of an event occurring and the potential damage it could cause contribute to determining its risk level.

Vulnerability Management is one of the activities that supports this broader process.

Its purpose is to identify security weaknesses, evaluate their potential impact, prioritize remediation, and monitor their evolution over time.

However, a vulnerability scanner alone cannot make all these decisions.

A vulnerability with a high CVSS score is not necessarily the most urgent issue in every environment. Context matters: exposure, exploitability, business criticality, and the role of the affected component all contribute to the final assessment.

The goal is therefore not simply to collect CVEs, but to turn vulnerability information into actionable risk management decisions.

2. The first challenge: knowing what you ship

Consider a typical software environment.

You might have:

• Applications developed internally.
• Third-party services and SaaS platforms.
• Container images and microservices.
• Open-source libraries and frameworks.
• Dependencies managed by different development teams.

Now imagine trying to understand which components are affected by a newly disclosed vulnerability.

Without a reliable software inventory, this can quickly become a difficult and mostly manual activity.

A Software Bill of Materials (SBOM) helps solve this problem.

An SBOM is a machine-readable inventory of the components, libraries, and modules included in a software product.

Think of it as an ingredient list for software.

Depending on the format, an SBOM can contain:

• Component name and version.
• Supplier and author information.
• Unique identifiers such as PURL and CPE.
• Cryptographic hashes.
• Direct and transitive dependencies.
• Licensing information.

Two widely adopted SBOM standards are:

• SPDX, maintained by the Linux Foundation.
• CycloneDX, maintained by OWASP.

SBOM adoption is also becoming increasingly relevant from a regulatory perspective. The European Cyber Resilience Act (CRA), for example, introduces cybersecurity requirements for products with digital elements, including software component documentation and vulnerability handling.

But beyond compliance, the real benefit is visibility.

An SBOM allows us to understand the composition of our software and provides a starting point for identifying potentially vulnerable components.

3. Generating an SBOM

Several open-source tools can generate SBOMs.

One of them is Syft, which can inspect container images and filesystems to identify software packages.

Let's assume we have a Docker image that we want to analyze.

First, build and publish the image, then generate an SBOM from the resulting artifact:

$ docker build --pull --tag registry.example.com/myproject/myapp:1.0 .

$ docker push registry.example.com/myproject/myapp:1.0

$ syft registry.example.com/myproject/myapp:1.0 \
    --output spdx-json=./sbom_spdx.json \
    --output cyclonedx-json=./sbom_cdx.json

We now have two machine-readable inventories describing the software components included in our application.

For example, a CycloneDX document contains component information such as:

$ cat ./sbom_cdx.json
{
    "$schema": "http://cyclonedx.org/schema/bom-1.7.schema.json",
    "bomFormat": "CycloneDX",
    "specVersion": "1.7",
    "metadata": {
        "timestamp": "2026-09-10T10:06:17+02:00",
        …
    },
    "components": [       
        {
            "bom-ref": "pkg:pypi/[email protected]?package-id=1a4c…",
            "type": "library",
            "author": "Sebastian Ramirez <[email protected]>",
            "name": "fastapi",
            "version": "0.141.1",
            "licenses": [ { "license": { "id": "MIT" } } ],
            "cpe": "cpe:2.3:a:python-fastapi:python-fastapi:0.141.1",
            "purl": "pkg:pypi/[email protected]"
        }
        …
    ]
}

This is a simplified example, but it illustrates the kind of information that can be extracted from an SBOM.

At this point, we know what our application contains.

But how do we know whether those components have known vulnerabilities?

4. From SBOM to vulnerability scanning

Once we have an SBOM, we can use vulnerability analysis tools to correlate its components with known security issues.

For example, Grype can analyze an SBOM and identify known vulnerabilities affecting its dependencies.

Using the CycloneDX document generated earlier:

$ grype sbom:./sbom_cdx.json
NAME          INSTALLED     FIXED IN      TYPE       VULNERABILITY         SEVERITY    EPSS          RISK
…
virtualenv     21.7.0       21.7.13      python     GHSA-p58f-9548-mpm2    High        0.2% (4th)    0.1
libcrypto3     3.5.7-r1                  apk        CVE-2026-75805         Medium      0.2% (11th)   0.1
libssl3        3.5.7-r1                  apk        CVE-2026-75805         Medium      0.2% (11th)   0.1
openssl        3.5.7-r1                  apk        CVE-2026-75805         Medium      0.2% (11th)   0.1
…

The output includes information such as:

• Component name.
• Installed version.
• Fixed version, when available.
• Vulnerability identifier.
• Severity.
• EPSS information.
• Risk-related information.

This provides a much clearer picture of our application's security exposure.

However, we have introduced another problem. Running a vulnerability scan once is not enough.

New vulnerabilities are disclosed every day. A component that was considered secure yesterday might be affected by a newly published CVE tomorrow.

Even if the application has not changed, its known security exposure has.

This is why SBOM management should be part of a continuous Vulnerability Management process.

We need a way to:

1. Collect SBOMs from different applications and services.
2. Maintain an inventory and version history.
3. Continuously analyze dependencies against vulnerability information.
4. Track findings and their remediation status.
5. Support risk assessment and prioritization.

And this brings us to the next question.

5. Make or Buy? (Or use an Open Source tool on premise?)

When I started thinking about this problem, I looked at the existing ecosystem.

There are already excellent tools for generating SBOMs and identifying vulnerabilities: Syft, Grype, Trivy, OSV, and many others.

There are also platforms that provide software composition analysis and vulnerability management capabilities.

So, why build another tool?

I wasn't interested in reinventing an SBOM generator.

I didn't want to build yet another CVE database or duplicate the work already done by existing vulnerability scanners.

What I was looking for was something slightly different:

I wanted a lightweight platform that could connect existing tools and provide a centralized place to manage their results.

Something that could be deployed on-premises, integrated into existing workflows, and used without introducing an unnecessarily complex infrastructure.

That's how Argus SBOM Guard started.

6. Meet Argus SBOM Guard

Argus SBOM Guard is an open-source platform for centralized SBOM and vulnerability management.

It is designed to be self-hosted, either on-premises or in your own infrastructure.

Its main goal is simple:

Turn SBOMs into actionable vulnerability management information.

The platform provides several capabilities:

• SBOM ingestion: upload and store CycloneDX and SPDX documents.
• Vulnerability scanning: automatic analysis using Grype and the OSV API.
• Vulnerability tracking: CVE status management, including open, fixed, and won't-fix findings.
• Supply chain visibility: organize projects, services, dependencies, and software versions.
• Historical tracking: maintain SBOM and vulnerability history.
• Dashboards: visualize vulnerability trends and project-level metrics.
• Integrations: REST API and gRPC with API key authentication.
• Alerting: notifications through Slack, Discord, and email.

Who is it for?

I see several potential use cases:

• Platform and SRE teams tracking dependencies across microservices.
• Security engineers monitoring vulnerability exposure over time.
• DevSecOps teams integrating SBOM management into CI/CD pipelines.
• Open-source maintainers managing software dependencies.
• Compliance teams requiring SBOM history and audit trails.

The idea is not to replace existing security tools, but to provide a centralized layer for managing SBOMs and their associated vulnerability information.

7. Under the hood: How does It work?

One of the design principles behind Argus is to reuse existing tools rather than reimplement their functionality.

The architecture is based on a few relatively independent components.

The backend exposes REST and gRPC interfaces, while asynchronous tasks are handled by Celery workers.

This is particularly useful for vulnerability scanning, which should not block the SBOM upload process.

The SBOM ingestion workflow

When a client uploads an SBOM through the API, the following operations take place:

1. The document is parsed according to its format (CycloneDX or SPDX).
2. Its components and dependencies are stored in PostgreSQL.
3. The upload request returns successfully.
4. A background scanning task is dispatched through RabbitMQ.
5. A Celery worker performs the vulnerability analysis.
6. Findings are stored and reconciled against previous vulnerability information.

The important detail is that SBOM ingestion and vulnerability analysis are decoupled.

This makes it possible to process potentially expensive scanning operations asynchronously while keeping the API responsive.

Vulnerability tracking

Argus does not simply store the output of a vulnerability scan.

It also maintains the relationship between SBOM versions, dependencies, and vulnerability findings.

This allows the platform to track how the security posture of a project evolves over time.

For example, when a dependency is upgraded and a new SBOM is uploaded, the platform can reconcile the new findings against previous results.

This provides visibility into vulnerabilities that have been resolved, those that remain open, and those that have been explicitly marked as won't-fix.

8. Integrating Argus into your CI/CD pipeline

A vulnerability management platform becomes much more useful when it is integrated into the software delivery process.

Argus exposes an API that can be used to automate SBOM ingestion.

For example, after generating a CycloneDX document, we can upload it with a simple HTTP request:

$ curl --fail -X POST "${ARGUS_URL}/api/v1/sboms/upload" \
    --header "Authorization: Bearer ${ARGUS_API_KEY}" \
    --form "project_slug=my-project" \
    --form "service_name=my-app" \
    --form "version=1.2.3" \
    --form "file=@sbom_cdx.json"

This makes it possible to integrate SBOM publication into GitHub Actions, GitLab CI, Jenkins, or other automation platforms.

Every software release can generate and publish its own SBOM.

Argus can then process the document and perform vulnerability analysis.

Periodic reassessment provides an additional layer of protection: newly disclosed vulnerabilities can be identified against previously uploaded SBOMs, even when the software itself has not changed.

The result is a workflow that connects software development with continuous vulnerability monitoring.

For more details, see the CI/CD integration documentation.

9. A small side project that became a real tool

Argus SBOM Guard started as a side project.

There was no business strategy, no product roadmap driven by market research, and no intention to create yet another commercial security platform.

It started with curiosity and the desire to build something useful.

As a developer, I enjoy exploring technologies, experimenting with architectures, and getting my hands dirty.

The project was also an opportunity to explore how AI-assisted development could support the implementation process.

The first stable version came together in a little over a month, with a relatively small investment in AI tooling.

The result is an open-source project that can be self-hosted without requiring an entire datacenter or a complex enterprise infrastructure.

And perhaps this is the most important aspect: the project is not intended to be a black box.

The source code is available, the architecture is documented, and contributions are welcome.

Final thoughts: Did we really need another Open Source tool?

Maybe we did. Maybe we didn't.

There are already excellent tools for generating SBOMs and identifying vulnerabilities.

But I believe there is still value in connecting these capabilities through a simple, centralized, and self-hostable vulnerability management workflow.

The objective of Argus SBOM Guard is not to replace existing security solutions.

It is to make the information they produce easier to organize, understand, monitor, and act upon.

Because generating an SBOM is not the end of the process.

It is the beginning.

Don't just generate SBOMs. Make them useful.

Try Argus SBOM Guard

The project is open source, and I'd be happy to receive feedback, suggestions, and contributions.

• GitHub: https://github.com/trottomv/argus-sbomguard/
• Documentation: https://trottomv.github.io/argus-sbomguard/latest/
• Contributors, early adopters and beta testers are welcome.

If you work with SBOMs, software supply chain security, or vulnerability management, I'd love to hear your thoughts.

Did we really need another open-source tool? Let me know what you think!