Customers find CSAF advisories through a provider-metadata.json file. You advertise it with a CSAF field in security.txt, a well-known URL at /.well-known/csaf/provider-metadata.json, or a DNS name. The CSAF 2.0 standard requires a provider to offer at least one of these three.
The provider metadata file
Requirement 7 in the standard says a party must provide a valid provider-metadata.json following the CSAF provider metadata schema. It describes the publisher and points to your feeds. The standard suggests locations such as the .well-known path, or a directory next to your year folders, changes.csv and index.txt, or next to your ROLIE feed documents.
Three ways to be discovered
| Method | Requirement | What it says |
|---|---|---|
| security.txt | 8 | At least one CSAF field pointing to your provider-metadata.json, and the URI must start with https:// |
| Well-known URL | 9 | The path /.well-known/csaf/provider-metadata.json under your main domain serves the file directly, over HTTPS |
| DNS path | 10 | The DNS record csaf.data.security.domain.tld resolves to a web server serving the file over HTTPS |
A provider must satisfy at least one of requirements 8 to 10. If you use the well-known URL, the standard says that URL must be the first CSAF entry in your security.txt when you also advertise there.
Steps for a small team
- Publish your advisories as valid CSAF documents over HTTPS, with no redirects.
- Create provider-metadata.json with a correct publisher object and a canonical URL.
- Serve it at the well-known path on your main domain.
- Add a CSAF line to your security.txt pointing at the same file.
- Test by fetching the file with a plain HTTP client, from outside your network.
An example security.txt line, taken from the pattern in the standard:
CSAF: https://www.example.com/.well-known/csaf/provider-metadata.json
Things to avoid
The standard says advertising more than one provider-metadata.json is possible, for example after a merger, but should not be done and should be removed as soon as possible. It also notes that the CSAF field in security.txt was, at the time of writing, in the process of being officially added to the security.txt specification, so check the current text of that specification before relying on it in a formal process.
Testing your setup
After publishing, check three things from a machine outside your network. The provider-metadata.json file loads over HTTPS without a redirect. The file is valid JSON that follows the provider metadata schema. Every feed or index it points to also loads. Repeat the test after any change to your web server or DNS, since a broken discovery path is silent: customers simply stop receiving your advisories.
Quick check
Do we need all three discovery methods?
No. A provider needs at least one of requirements 8 to 10. Many vendors choose the well-known URL because it needs no DNS change.
Where should provider-metadata.json live?
The standard suggests the well-known path under your main domain, among other options. The well-known path is the easiest for tools to guess.
Safeguard's asset discovery and SBOM and dependency scanning cover your own side of the supply chain, and the free scan is a quick start.
Sources
Last reviewed: 19 October 2026.
