Advisories are a decision, not a scan result
Tell customers that a product they own is affected and what to do about it. Advisories sit downstream of triage, scoped to the releases actually involved, and they are a different duty from reporting to authorities.
Two notify paths, two different duties
This is the distinction most CRA messaging gets wrong. September 2026 is a report to CSIRT and ENISA. Informing your customers is a separate path with a different trigger and a different clock.
Notify
Authorities
- Trigger
- A finding is actively exploited in a release you already placed on the market.
- Clock
- The Article 14 clock: 24 hours, 72 hours, then 14 days, from 11 September 2026.
- Goes to
- ENISA SRP or your national CSIRT. You file it; alloy-it prepares the packet and does not submit.
Notify
Customers
- Trigger
- Triage confirms the product is exploitable and a fix, a mitigation, or a documented reason to inform without one exists.
- Clock
- Your schedule. This sits with vulnerability handling and coordinated disclosure, toward full application in December 2027.
- Goes to
- Advisories scoped to the affected products and releases, delivered by email and optionally published to a public portal.
You cannot send one on an untriaged finding
A scanner result is not a reason to email your customers. Delivering an advisory is refused unless a linked finding has been triaged to an exploitable state, and unless you have either set a recommended version or explicitly recorded that you are informing without a fix.
The effect is that an advisory always carries a decision behind it. That is what makes it a controlled notification rather than a CVE firehose, and what makes the decision defensible later.
How triage produces that decision →A structured document, not a text blob
Prefill populates the draft from what alloy-it already knows: the release, its findings, the affected components and versions, and the fixed versions where they exist. Each section maps onto the shape a CSAF consumer expects.
Summary
What happened, in two sentences.
Affected products
Which products and releases are in scope.
Vulnerable products
The subset that is actually vulnerable.
Not vulnerable
Explicitly out of scope, and as valuable to a customer as the affected list.
Details
The technical description.
Workarounds
What to do before the fix lands.
Fixed software
Where the patched version is.
Exploitation
Known exploitation status.
Source
Credit and references.
Alongside these, a CVE table carries per-CVE rows with score, severity, affected component and version, and fixed version. Recommended version, apply-by date, and guidance are kept separate from the document, because they are operational fields rather than published prose.
A public portal, off by default
Published advisories can be read without a login at your own organisation URL, branded with your logo. It stays disabled until you turn it on, and while disabled every public route returns a plain 404 rather than an error that would confirm the organisation exists.
Publishing and sending are independent. An advisory can be published without ever being emailed, or emailed without being published.
CSAF and PDF export
Every published advisory is available as CSAF JSON and as a rendered PDF. The machine-readable form matters twice over: downstream consumers can ingest it automatically, and CRA Annex I Part II expects machine-readable vulnerability information rather than a PDF a human has to read.
Material changes increment the document version and are kept in a revision history on the public page.
Where this sits in the loop
Monitoring finds the component. Triage decides whether the product is genuinely affected. If it is actively exploited in something you shipped, the authority path opens on the Article 14 clock. The customer advisory comes after, once there is something useful to tell them.
Run disclosure without guessing at scope
Start with a product inventory so an advisory can name the releases that are actually affected, and the ones that are not.