CSAF in DevGuard

Enabling CSAF Reports

To start publishing CSAF reports for your assets, follow these steps:

Navigate to your Repository Settings
Go to the Vulnerability Management section
Enable “Enable public access to vulnerability data”

Once enabled, your organization will be registered as a CSAF provider and your vulnerability data will be available through standardized CSAF endpoints.

Accessing CSAF Data

After enabling CSAF reports, your organization’s vulnerability data becomes accessible through a hierarchical structure:

Instance Lister

On the instance level all organizations providing CSAF reports are listed:

Primary endpoint: https://api.main.devguard.org/api/v1/.well-known/csaf-aggregator/aggregator.json
Alternative endpoint: https://main.devguard.org/.well-known/csaf-aggregator/aggregator.json

Your organization will be listed publicly as a provider in this list once you enable public access to vulnerability data.

Provider Metadata

Each organization has a provider metadata file that lists all repositories (assets) with CSAF reports available:

https://api.main.devguard.org/api/v1/organizations/{org-name}/csaf/provider-metadata.json

This file contains a distributions array listing directory_url your repositories (assets) that have CSAF reports enabled.

Asset Reports

Individual vulnerability reports for each asset are organized by year and TLP (Traffic Light Protocol) (DevGuard currently only supports TLP:WHITE) level:

https://api.main.devguard.org/api/v1/organizations/{org-name}/projects/{project-name}/assets/{asset-name}/csaf/white/{year}/

Each asset will have a separate CSAF report for every vulnerability that has been detected throughout its lifetime.

Example Index of the DevGuard backend repository.

Consuming CSAF Reports as Upstream Data

DevGuard allows you to consume CSAF reports from other organizations as upstream vulnerability data. This is particularly useful for tracking vulnerabilities in your dependencies. And it enabled sharing assessment results between different teams and organizations.

Configuration

When creating or updating an artifact, you can configure CSAF as an upstream source by saving an upstreams CSAF URL and PURL to one of your assets:

Provider Metadata URL: The organization’s CSAF provider metadata endpoint

https://api.main.devguard.org/api/v1/organizations/{org-name}/csaf/provider-metadata.json

Package URL (PURL): The identifier for the specific asset you want to track. You usally get that PURL from your upstream. Examples how that PURL can look like:
- A npm package:
```
pkg:npm/next@15.4.7
```
- For OCI containers:
```
pkg:oci/devguard@v0.19.0?repository_url=ghcr.io/l3montree-dev/devguard&tag=v0.19.0
```
- For DevGuard repositories:
```
pkg:devguard/{org}/{repo}@{ref}
```

Upstream Event Handling

Once configured, CSAF upstream sources are processed using the same event handling mechanism as other upstream information sources. For more details, see the Ingesting Upstream Information guide - especially the section on processing rules and behaviour.

What is CSAF?

The Common Security Advisory Framework (CSAF) is an open standard for publishing security advisories in a structured, machine-readable format. Unlike traditional free-form text advisories, CSAF uses well-defined JSON documents to communicate vulnerability information consistently and precisely.

Benefits of CSAF

Automated Processing: Security information can be automatically consumed by vulnerability management tools and security dashboards
Reduced Manual Effort: Eliminates the need to manually parse and interpret advisory information
Faster Response Times: Organizations can respond more quickly and reliably to security risks
Standardized Format: Consistent structure across different vendors and organizations

CSAF in DevGuard

DevGuard leverages CSAF to provide comprehensive information about dependency vulnerabilities in your assets. Key features include:

Individual CVE Reports: Each CVE affecting your asset gets its own dedicated CSAF report
Historical Tracking: Complete history of each vulnerability throughout its lifetime
Rich Metadata: Additional information including VEX states, affected packages, and detailed descriptions
Trusted Provider: Organizations using DevGuard can become CSAF trusted providers once they’ve scanned their repositories

What to Find in DevGuard’s CSAF Reports?

Each CSAF report in DevGuard covers a single vulnerability affecting your asset. Reports follow the CSAF VEX (Vulnerability Exploitability eXchange) profile and consist of two main components: the Document object and the Vulnerabilities object.

A key difference between CSAF VEX & CycloneDX VEX

CSAF VEX has a product-centric view: You have a single product and communicate vulnerabilies of used dependencies affecting that product without detailing the dependency graph. So the reciepient of the CSAF report “just” sees product A is affected by vulnerability CVE-2025-1234, without details about which dependencies of product A are affected.

CSAF VEX Extract

{
  "vulnerabilities": [
    {
      "cve": "CVE-2024-53382",
      "discovery_date": "2025-10-06T18:19:46Z",
      "notes": [...],
      "product_status": {
        "under_investigation": [
          "pkg:oci/devguard-web@main" // <- product PURL without details on affected dependency
        ]
      },
      "title": "CVE-2024-53382"
    }
  ]
}

In contrast, CycloneDX VEX takes a component-centric approach, detailing vulnerabilities at the component level. It provides the precise location of the affected dependency using the PURL of the affected package inside the product.

CycloneDX VEX Extract

{
  ...
  "vulnerabilities": [
    {
      "id": "CVE-2024-53382",
      "source": {
        ...
      },
      "ratings": [...],
      "analysis": {
        "state": "in_triage",
        ...
      },
      "affects": [
        {
          "ref": "pkg:npm/prismjs@1.27.0" // <- Detailed location PURL
        }
      ]
    }
  ]
}

Both are obviously correct in terms of content, but in case you get a SBOM next to the vulnerability reports, DevGuard has to try to match via the CVE-ID instead of a direct mapping via PURL.

Ingesting Upstream Information Discovering Base Image Attestations