CSAF advisory hosting

When you approve a security advisory in Resilic, we can publish it as a CSAF 2.0 provider on a domain you control — a machine-readable feed that vulnerability tools, downstream integrators, and national databases can poll automatically.

What this is, and isn’t. CSAF (Common Security Advisory Framework) is an interoperability format, not a legal requirement. The CRA does not mandate CSAF, a “provider”, custom-domain hosting, ROLIE, or any particular discovery route by name. What the CRA expects is that you can inform users about vulnerabilities and remediations (Annex II item 2, and the coordinated vulnerability disclosure duty). Publishing a CSAF feed is one clean, widely-supported way to do that — it makes your advisories consumable at scale — but it is a readiness/interoperability choice, not a compliance determination. Resilic drafts and structures the feed; you approve every advisory before it publishes.

The hosting domain

Your advisories are served on a host under a domain you own — csaf.<your-domain> — with its own managed HTTPS certificate. The domain also establishes your publisher namespace, the stable identifier that says “these advisories come from us”. Identity and serving are deliberately separate: the namespace is your apex domain (https://<your-domain>), while the bundle is served from https://csaf.<your-domain>.

Setting it up is three steps: register → verify → serve.

1. Register

In Security advisories → CSAF hosting domain, enter the domain you want to publish under (for example acme.example). Resilic issues a one-time verification token and shows you the DNS records to add.

2. Verify — prove you control the domain

You prove control with DNS. Two records are involved, and they do different jobs — the app labels which is which:

• CNAME (serving) — csaf.<your-domain> → the hosting target Resilic shows you. This is required to publish over HTTPS: it delegates the serving host to us so the certificate can be issued and your advisories are actually reachable.
• TXT (proof) — _aegis-csaf.<your-domain> → the verification token. This is proof of control. It is optional once the CNAME is in place — the delegating CNAME already proves you control the host — but you can use it instead if you prefer not to add the CNAME immediately.

Add the records at your registrar, then click Verify. Once verified, the domain namespace supersedes any self-declared namespace, closing the door on anyone spoofing your identity.

3. Serve — verified vs live

“Verified” is not the same as “live.” Verification confirms you control the domain; the certificate then has to finish issuing before the endpoint actually serves. The hosting card shows the two states separately:

• Live over HTTPS — the certificate is active and your advisories are reachable.
• Certificate issuing… — verified, but the certificate is still validating. This normally clears within a few minutes to a few hours after the CNAME is correct.
• Not reachable — check the CNAME — the certificate has not gone live. Confirm the csaf.<your-domain> CNAME exists and points at the hosting target.

Resilic re-checks verified domains on a schedule. If the delegation later disappears, we stop asserting your namespace, email you, and give you a grace window to fix DNS before the host is torn down — so a lapsed record never silently keeps a certificate alive for a domain you no longer control.

Being found: publish security.txt at your company domain

Serving your advisories is only half of being discoverable. Researchers, scanners, and aggregators start at your company domain, not at csaf.<your-domain> — RFC 9116 says the discovery file lives at your domain root:

scanner → https://<your-domain>/.well-known/security.txt → its CSAF: line → https://csaf.<your-domain>/.well-known/csaf/provider-metadata.json → your advisories

We serve a copy of security.txt on the CSAF host, but the first link in that chain is yours to host — we can’t place a file at your company domain root, because that’s your website’s authority, not ours. So a domain can be fully verified and serving, yet still be undiscoverable from your company domain until you publish that first file.

The hosting card gives you the exact file to publish. Once your domain is verified it shows a “Publish security.txt at your company domain” block with:

• the exact security.txt content to copy (its Canonical points at your apex; its CSAF: line points at us),
• where to put it — https://<your-domain>/.well-known/security.txt.

Two things to get right:

• HTTPS is required. RFC 9116 discovery only works over https:// at your domain root. If your apex serves plain HTTP only, fix that first — an HTTP-only security.txt won’t be trusted.
• Keep it current. The file carries an Expires date and, if you’ve set a signing key, an Encryption pointer. Re-copy it if your contact or key changes.

Once you’ve published it, the hosting card checks your company domain and shows a badge — Discoverable from your domain when your apex security.txt is live and points at us, or a nudge if it’s missing or doesn’t point back yet. So you don’t have to guess whether your half of the chain is actually in place. Your dashboard carries the same readiness at a glance, so a missing step is visible without opening this screen.

If touching your company domain root isn’t practical, the DNS-path route below is the other way to be found from your domain without publishing anything at the apex.

Optional: DNS-path discovery

CSAF describes several ways a consumer can discover your provider. By default Resilic serves the well-known route. You can additionally turn on the DNS-path route: a second host, csaf.data.security.<your-domain>, whose address a tool can guess from your domain alone and fetch your provider metadata without any prior configuration.

It is opt-in because it needs a second CNAME and a second certificate. Turn on “Also serve the DNS-path discovery route” in the hosting card, then add the extra record it shows you:

• CNAME — csaf.data.security.<your-domain> → the same hosting target as your primary host.

Leave it off and only the well-known route is served — which is fully valid on its own. Turn it on when you want the extra discoverability; turn it back off and the second host is removed.

What gets published

Each approved advisory is published as a CSAF 2.0 document with its detached signature and hashes, alongside the discovery files a consumer needs — the provider metadata, the index, the changes feed, and a ROLIE feed with its service and category documents so a ROLIE client can discover the feed on its own. Withdrawing an advisory removes it from the feed and refreshes the discovery files at the edge, so a correction or withdrawal propagates promptly rather than waiting out a cache.

Signing keys, publisher contact details, and the advisory workflow itself are covered on the Security advisories screen and in Reports & deadlines.

Your CVD policy, served publicly

Once you approve your Coordinated Vulnerability Disclosure (CVD) policy, it is served on the same host at https://csaf.<your-domain>/cvd-policy (a readable web page) and …/cvd-policy.pdf (the branded PDF), and your security.txt Policy: field points at it — so a researcher who finds your disclosure surface can read how to report a vulnerability. Only an approved policy is served; a draft is never published, and editing an approved policy returns it to draft until you sign it again. The served page carries the same readiness note as the export — a CVD policy is a CRA Annex I / Article 13 element that applies from 11 December 2027, and hosting one is not, by itself, evidence of compliance. If you have no verified CSAF domain, the policy stays export-only, as before.

Policy documents exist per language: the English and German variants are drafted, edited and approved independently (a translation nobody reviewed is not evidence). The English variant owns the canonical /cvd-policy URLs; an approved German variant is additionally served at …/cvd-policy.de and …/cvd-policy.de.pdf.

We also check daily that your published policy stays reachable. If an approved policy stops being served at its URL — the “signed in-app, 404 in public” case — the policy screen flags it and we email you (a notification you can turn off under Notifications), so a broken disclosure surface doesn’t go unnoticed.