The Challenge with Ad-hoc Vulnerability Notifications
Who hasn’t experienced it: a critical vulnerability becomes public, and shortly thereafter a PDF file lands in your inbox – formatted to the taste of the respective vendor, sometimes with a CVSS score, sometimes without, sometimes with affected versions, sometimes not. Security teams have to read, interpret and transfer this information manually into their own systems. This costs time, introduces errors and delays exactly what matters: a fast, well-founded response.
The real problem is the media break. Between the arrival of a notification and the moment when a ticket is opened in the SIEM or an affected component is flagged in the SBOM inventory, there are often hours or days of manual work. In a world where attackers exploit vulnerabilities within hours of publication, this is a structural risk.
Unstructured notifications are not a niche problem. They are the normal state in most supply chains – and they do not scale. The more suppliers, the more software components, the greater the noise. This is exactly where CSAF comes in.
What CSAF Is and Why It Matters
CSAF stands for Common Security Advisory Framework and is an open, machine-readable standard for security advisories. It was developed by OASIS Open and is the direct successor to the older CVRF standard (Common Vulnerability Reporting Framework). While CVRF was still XML-based and comparatively rigid, CSAF relies on JSON and offers a significantly more flexible, tool-friendly structure.
The current version is CSAF 2.0. It defines several profiles that cover different use cases – from a simple informational advisory to the security-critical VEX document (Vulnerability Exploitability eXchange), which explicitly states whether a product is affected by a known vulnerability or not. These profiles make CSAF more than just a document format: they establish a common language between vendors, CERTs and consumers.
In the coming weeks, CSAF 2.1 is expected. The new version brings, among other things, extensions around metrics, improved support for remediation information and further profile refinements. Those who start with CSAF now are investing in an infrastructure that is future-proof.
The CVE Ecosystem and Coordinated Vulnerability Disclosure (CVD)
Before CSAF documents can be meaningfully used, you need an understanding of how vulnerabilities are created and communicated in the first place. At the center is the CVE system (Common Vulnerabilities and Exposures): a public database in which vulnerabilities are referenced with a unique identifier (e.g., CVE-2024-12345).
Vulnerabilities are not assigned directly by a central authority. Instead, so-called CNAs (CVE Numbering Authorities) exist worldwide – authorized organizations that assign CVE IDs for their respective area of responsibility. These can be vendors, security researchers or national CERTs.
Due to the funding problems of the National Vulnerability Database (NVD) earlier this year, the idea of global-CVE emerged, driven by CIRCL (CERT Luxembourg), an alternative concept that enables a more decentralized approach with CNA-specific number ranges, so-called GNAs, see also https://gcve.eu/gna/. These assign numbers on their own authority, ideally following the best practices, see https://gcve.eu/bcp/. This extends the CVE with a GNA identifier, for example 102 for EACG or 0 for NVD, and leads to an ID such as gCVE-102-2026-00001.
Coordinated Vulnerability Disclosure (CVD) describes the process in which a vulnerability is not immediately made public, but is first handled in a coordinated manner between the discoverer (researcher), the affected vendor and, where applicable, a coordinating CERT. The goal is to give the vendor enough time to develop and deliver a patch before the public – and thus also potential attackers – is informed.
This model offers clear advantages over unilateral publication: users are better protected, vendors can respond in a controlled manner, and researchers still receive recognition for their work. CVD is not altruism – it is structured responsibility sharing.
How CSAF Accelerates Incident Response in Practice
The decisive advantage of CSAF lies in its automatability. A machine-readable JSON document can be processed directly by tools – without human intermediate steps.
In concrete terms, this means:
- Automated ingestion into SIEM/SOAR: An incoming CSAF feed can automatically generate tickets, set severity levels and trigger escalations – based on structured fields such as CVSS score, product list or remediation status.
- Direct matching against SBOM inventories: If a CSAF advisory contains an affected component (e.g.,
libssl 3.0.2), a tool can automatically compare this entry against the organization’s software inventory and identify affected products – in seconds rather than hours. - Shortened time-to-triage: Because fields are standardized, interpretation is no longer needed. Security teams see immediately whether a vulnerability is relevant to them, which versions are affected and which countermeasures are recommended.
- Reduced manual effort: Less copy-paste, fewer misinterpretations, fewer follow-up questions to the vendor.
In short: CSAF shifts effort away from reading and interpreting towards acting.
Inbound vs. Outbound: Two Sides of CSAF Usage
CSAF usage can be distinguished in two directions, which bring different roles and responsibilities.
Inbound refers to the receipt of advisories from external suppliers. Here, your own organization is the consumer: you subscribe to CSAF feeds, process incoming documents and match them against your own software inventory. This presupposes that suppliers actually provide CSAF documents at all – and that is one of the biggest current challenges.
The situation is particularly difficult with open source projects. Very few open source maintainers have the capacity or knowledge to create structured CSAF advisories. It is currently not foreseeable that this will change broadly. For organizations that rely heavily on open source components, this means: the inbound channel via CSAF primarily works for commercial vendors; for open source dependencies, manual review (e.g., via NVD or OSV databases) remains unavoidable for the time being.
Outbound refers to the creation and publication of your own advisories as a vendor or supplier. Here, your own organization is the producer: you describe vulnerabilities in your own products, define affected versions, provide patches and publish the advisory in a standardized format – ideally via a CSAF provider endpoint that can be automatically retrieved by customers and aggregators.
This distinction is important for internal responsibility: inbound typically belongs in the Security Operations Center, outbound in the Product Security area or a dedicated PSIRT (Product Security Incident Response Team).
TrustSource v3: CSAF and CVD Support in Practice
With TrustSource v3, both inbound and outbound CSAF support are brought into an integrated platform – complemented by a native CVD function.
On the inbound side, TrustSource v3 can import external CSAF advisories and automatically match them against the known component inventory. If an affected dependency is identified, the advisory is directly linked to the corresponding projects and products. Security teams see at a glance which systems are affected and which measures are recommended.
On the outbound side, the platform supports the creation of valid CSAF documents. Vendors can capture advisories in a structured manner, fill in the relevant fields – including product tree, vulnerability description, CVSS scoring and remediation – and publish the finished document or route it internally.
The CVD workflow in TrustSource v3 coordinates the entire process between reporters (researchers) and vendors: from the initial report through the internal assessment to the coordinated publication. Deadlines, status updates and communication histories are documented in a traceable manner – an important aspect when it later comes to compliance or liability questions.
First Steps: What Security Teams Should Do Now
Getting started with structured vulnerability management does not have to be complex. The following steps help to structure the process:
-
Evaluate CSAF tooling: Tools such as
csaf-validator(OASIS) or commercial platforms such as TrustSource enable you to get started without much effort. Existing workflows can be supplemented or extended step by step. -
Establish an SBOM foundation: CSAF only unfolds its full benefit in interaction with a maintained SBOM inventory. Those who do not yet create SBOMs for their products should tackle this in parallel.
-
Define a CVD process: Independent of tooling, clear responsibilities are needed: Who receives reports? Which SLAs apply to the response? Who decides on the publication date?
-
Query suppliers: Which commercial suppliers already offer CSAF feeds? These should preferably be subscribed to.
-
Start with outbound: Those who develop and distribute software themselves should start providing advisories in CSAF format early on; also to get ahead of regulatory requirements (e.g., in the context of the Cyber Resilience Act).
Conclusion
Three key takeaways from this article:
- CSAF replaces the PDF chaos with machine-readable, standardized advisories – and thereby makes automated incident response possible in the first place.
- Coordinated Vulnerability Disclosure protects all parties involved – users, vendors and researchers – and works best with clear processes and suitable tooling.
- TrustSource v3 offers an integrated solution for inbound processing, outbound creation and CVD coordination – and enables security teams to get started directly without in-house development.
The time to act is now: With CSAF 2.1 just around the corner and growing regulatory pressure, structured vulnerability disclosure will shift in the coming months from a differentiator to a basic requirement.