Publish advisories and VEX files at a stable HTTPS address on your own domain, link them from your security contact page and security.txt, and, if you use CSAF, serve provider-metadata.json at the well-known path so customers' tools can discover everything without a human pointing the way.
Definitions
CSAF is the Common Security Advisory Framework, an OASIS standard for machine readable advisories. A CSAF provider is an organisation that publishes CSAF documents. The provider-metadata.json file is the entry point that tells consumers where those documents live. VEX, the Vulnerability Exploitability eXchange, states whether a product is affected by a vulnerability.
Three layers of discovery
| Layer | Who it serves | What to publish |
|---|---|---|
| Human page | Admins and managers | An advisories index with dates and links |
| Machine feed | Customer tooling | CSAF documents, OpenVEX or CycloneDX VEX files at stable URLs |
| Pointer | Researchers and tools | security.txt with a Contact, and for CSAF a CSAF field |
What the CSAF specification says
CSAF 2.0, section 7.1, lists distribution requirements. Requirement 9 says the path /.well-known/csaf/provider-metadata.json under the main domain serves the metadata directly, over HTTPS. Requirement 8 says security.txt must contain at least one CSAF field that points to provider-metadata.json, as an HTTPS URI. Requirement 10 offers a DNS path, csaf.data.security.domain.tld, as another route. Documents are placed in one folder per year, based on the initial release date.
You do not have to adopt all of CSAF to publish well. But the pattern, a fixed discovery path plus a signed, dated index, is worth copying for any format.
Steps
- Pick the base URL and commit to it. Moving it breaks every link you have sent.
- Publish an index page listing each advisory, its date, affected products and status.
- Publish one file per advisory in a machine readable format, and name it by identifier.
- Add a changelog or revision date, so consumers can detect updates.
- Sign what you publish, or publish hashes, so copies can be verified.
- Reference the location from security.txt, which RFC 9116 places at /.well-known/security.txt and requires to carry Contact and Expires fields.
- Test as a customer would: fetch the files with a script, from outside your network.
Mistakes
- Putting advisories behind a login. Customers cannot automate that, and researchers cannot see them.
- Publishing PDFs only. Tools cannot read them reliably.
- Editing a file in place without bumping its version or date.
- Letting security.txt expire, which signals neglect.
Where VEX fits
A VEX statement is most useful when a customer can match it to an SBOM component, as described in matching VEX statements to SBOM components. A good place for it is next to the advisory it relates to, with the same identifier.
Quick check
Is CSAF mandatory for publishing VEX?
No. CSAF has a VEX profile, but OpenVEX and CycloneDX VEX are also used. Choose a format your customers' tools can read.
Can the advisory page live on a third party site?
It can, but your own domain gives customers a stable address and a clear owner.
Safeguard's compliance and evidence automation and SBOM scanning can help keep the inventory behind published advisories consistent. A free scan is available.
Sources
- CSAF 2.0 specification, OASIS, section 7.1
- RFC 9116, security.txt
Last reviewed: 19 October 2026.
