The Gap in Vulnerability Communication — Why Disclosure Workflows Are Broken
Anyone running vulnerability management in a mid-sized software company today knows the problem from daily experience: a new CVE appears in the NVD, someone happens to read about it in a newsletter, a ticket is manually created, three teams are notified by email — and two weeks later it turns out the same library is embedded in five products no one knew about. This is not an isolated case; it is structural reality.
Classic disclosure processes all suffer from the same fundamental problems: communication channels are fragmented, CVEs are tracked manually, and there are hardly any standardised formats between vendors, internal security teams and upstream suppliers. Anyone receiving an advisory must first parse, interpret and manually compare it against their own component base. Anyone wanting to publish one themselves wrestles with proprietary templates and unclear responsibilities. This gap between receiving and sending vulnerability information costs time, introduces errors — and, in regulated environments, increasingly creates compliance risks as well.
TrustSource v3 closes exactly this gap. With its revamped vulnerability infrastructure, the platform supports CSAF on both the inbound and the outbound side. This article explains what that means in concrete terms and what difference it makes in the day-to-day work of security teams.
CSAF 101 — The Standard for Machine-Readable Security Advisories
The Common Security Advisory Framework (CSAF) 2.1 (still brand new) is an open standard under the auspices of OASIS Open that defines machine-readable security advisories in a structured JSON format. CSAF replaces the older CVRF format (Common Vulnerability Reporting Framework, XML-based) and addresses its central weakness: CVRF documents were formally structured, but in practice they could hardly be processed in an automated way.
CSAF 2.1 defines clearly separated roles within the advisory ecosystem:
- Publisher: Organisations that create and publish their own advisories
- Provider: Entities that make CSAF documents available via standardised feeds
- Aggregator: Services that bundle feeds from multiple sources and redistribute them
This role separation and the strict JSON structure make it possible to pass advisories through fully automatically from publication to processing — without manual intermediate steps. Authorities such as the BSI in Germany or CISA in the USA already use CSAF as the preferred format for their advisories. EU requirements under the Cyber Resilience Act (CRA) also explicitly reference machine-readable disclosure formats. CSAF is therefore on its way to becoming the de facto standard for structured security advisories — and it is only a matter of time before it becomes a regulatory obligation.
Image – CSAF-specific communication flow between Consumer & Provider
---
Inbound CSAF — How TrustSource v3 Processes External Advisories
On the receiving side, TrustSource v3 enables automated ingestion of CSAF feeds from external sources. These include public aggregators such as the NVD, government sources such as the BSI, and vendor-specific advisory feeds from the likes of Red Hat, Microsoft or Siemens.
The process runs in several steps:
-
Feed subscription and normalisation: TrustSource subscribes to configured CSAF providers and normalises incoming documents into its internal data model. CVE references, CVSS scores, affected products and fix information are extracted in the process.
-
SBOM matching: Incoming advisories are automatically matched against your own SBOM data base. TrustSource identifies which of your own products and software versions are affected by an advisory — without a security engineer having to search manually.
-
Prioritisation and triage support: Based on CVSS score, exploitability data and the actual vulnerability in your own environment (reachability, context), TrustSource sorts findings by urgency of action. Teams receive not an undifferentiated list of CVEs, but prioritised work packages.
-
Alerting and ticketing integration: Relevant findings automatically trigger notifications or create tickets in connected systems such as Jira or ServiceNow.
The result: security teams are no longer flooded. They receive targeted, contextualised information about the components that are actually relevant in their products.
Outbound CSAF — Publishing Your Own Advisories Directly from TrustSource
The other side of the disclosure cycle is the publication of your own advisories. Especially for vendors who, under coordinated vulnerability disclosure (CVD), must communicate security issues in their products, this process is time-consuming and error-prone without tool support.
TrustSource v3 integrates a structured CVD workflow that operates directly from the platform’s vulnerability data base:
- Advisory creation: Product owners and security teams create CSAF documents based on existing vulnerability data in TrustSource. Components, affected versions and CVSS ratings are automatically taken from the SBOM data base.
- CVE referencing: Existing CVE IDs are embedded, and for new vulnerabilities the CVE request process can be triggered from within the workflow — with TrustSource acting as a CNA support tool.
- Validation: Before publication, TrustSource validates the generated CSAF document against the official JSON schema and the CSAF validator rules. Faulty or incomplete advisories are flagged before they leave the company.
- Publication: Finished advisories can be published via configured channels — whether that is your own CSAF provider directory, a government portal or a public website with the appropriate metadata.
This outbound process creates traceability: who made which decision about a vulnerability and when is fully documented and auditable.
Closing the Loop — Inbound and Outbound in One Workflow
The real added value of TrustSource v3 lies not in inbound or outbound on their own — but in connecting both directions on a common platform.
A typical sequence looks like this: an incoming CSAF advisory from an upstream vendor identifies a critical vulnerability in a library that is built into three of your own products. TrustSource automatically raises an alert, prioritises the finding and initiates an internal vulnerability assessment. The security team analyses whether their own products are actually exposed. The result of this analysis — including the measures taken and mitigations — flows directly into your own CSAF advisory, which is then communicated to customers, authorities or the open-source community.
Until now, this cycle could only be realised with considerable manual effort or by using several disconnected tools. Integration into a single platform reduces hand-off friction, shortens time-to-advisory and makes the entire process traceable for external auditors.
Practical Relevance — What This Means for Security Teams and Compliance
The impact is concrete:
Time savings through automation: The manual comparison of incoming CVEs against your own component base is eliminated. SBOM-based matching runs continuously and delivers precise results — without an engineer having to maintain triage lists every day.
Auditability: Disclosure decisions are documented without gaps. When an advisory came in, when it was assessed internally, which measures were decided on and when your own advisory was published — all of this is available for audits and regulatory reviews.
Regulatory compliance: Both NIS2 and the Cyber Resilience Act impose stricter requirements on incident reporting obligations and transparency towards authorities. Machine-readable CSAF advisories meet these requirements better than proprietary email communication. TrustSource v3 helps teams meet these requirements in a structured and demonstrable way.
Customer communication: Customers increasingly expect transparent and timely information about security issues. CSAF advisories from TrustSource can be integrated directly into customer communication channels — professionally formatted and machine-readable for customers who consume CSAF feeds themselves.
Getting Started — Migrating to TrustSource v3 and Enabling CSAF
For teams migrating from TrustSource v2 or starting fresh, the following approach is recommended:
Step 1 — Configure CSAF inbound: In the v3 admin area, external CSAF provider feeds can be registered. Standard sources such as NVD and BSI are available as pre-configured options; your own or proprietary feeds can be added via URL and an optional API key.
Step 2 — Update the SBOM data base: The quality of SBOM matching depends directly on the completeness of the stored components. For migrating teams, an SBOM audit at the start is recommended to close any gaps.
Step 3 — Set up outbound templates and the CVD workflow: TrustSource v3 ships with advisory templates that can be adapted to your own disclosure policy document. Responsibilities, escalation paths and publication channels are configured once and are then available for all future advisories.
Step 4 — Use documentation and support: The official TrustSource documentation at docs.trustsource.io contains dedicated sections on CSAF inbound, CSAF outbound and the CVD workflow. For complex migration scenarios, the support team is available for a guided rollout.
Conclusion
CSAF closes the structural gaps in classic vulnerability disclosure processes — but only if it is practised on both sides. TrustSource v3 is one of the few platforms to offer full inbound-and-outbound integration in a closed workflow. The three key takeaways:
- SBOM-based CSAF matching on the inbound side replaces manual CVE triage with automated, contextualised prioritisation.
- An integrated CVD workflow on the outbound side enables structured, validated and auditable publication of your own advisories.
- Connecting both sides in a single platform is the decisive operational advantage — and a solid foundation for meeting NIS2 and CRA requirements.