Advisories and incidents

This practice covers what you do when a vulnerability in your product affects the people who use it: publish a security advisory that tells them whether they are affected and what to do, and, when the flaw is exploited or a release is compromised, run a product incident response you have rehearsed.

A fix protects only the customers who know to install it. An advisory with exact versions and machine-readable data lets their scanners answer "am I affected?" without a support ticket. A rehearsed plan matters once exploitation starts: since 11 September 2026, the EU Cyber Resilience Act has required manufacturers to send an early warning within 24 hours of becoming aware of an actively exploited vulnerability.

Who: The PSIRT lead writes advisories; an incident commander runs incidents with engineering, communications, legal and support
When: When the fix or mitigation for a customer-affecting flaw is ready, and at once when exploitation or a compromised release is suspected
How often: Per vulnerability and per incident; rehearse the plan periodically, often with a yearly tabletop exercise
You end up with: A web advisory with a CVE record and CSAF or OSV data, an incident timeline and decision log, and a postmortem with owned actions

Do this

Write a short incident plan
Cover scope (exploited vulnerabilities, compromised builds or releases, leaked signing keys, malicious dependencies shipped to customers), severity levels, roles and a first-hour checklist. Name an incident commander who decides but does not debug, and a scribe who keeps the timeline. Agree the hand-off with your corporate IT incident team in writing, and keep the plan where people can find it at 2 a.m.
Record awareness and preserve evidence
Write down when the team became aware, because reporting clocks start there: under the EU Cyber Resilience Act, an early warning within 24 hours and a notification within 72 hours for an actively exploited vulnerability. Preserve logs, images and build records before changing systems, contain with the smallest effective action, such as a feature flag or a revoked token, and ask legal which obligations apply.
Write the advisory from verified facts
Give affected and fixed versions per branch, products confirmed not affected, a CVSS vector with its version, whether exploitation is known, the fix and any workaround with its limits, identifiers, credit and a revision history. The FIRST PSIRT Services Framework's template lists title, summary, CVEs, product impact and status, acknowledgement, references and revision history. Score with CVSS v4.0 calculator.
Publish a CVE record and machine-readable data
Get a CVE ID from the CVE Numbering Authority whose scope covers the product; GitHub is one for repositories it hosts. Publish the record with the advisory. For enterprise customers, publish a CSAF 2.0 document, using the VEX profile for affected, fixed and not-affected statements; for open-source packages, publish a GitHub security advisory or an OSV record. Generate all of them from one case record.
Tell customers in one place
Use one channel of record, the advisory or a status page, and point every other message to it. Say what you know, what you do not know yet, what customers should do now and when the next update will come. Never claim that no data was accessed unless logs covering the whole period prove it; say what period the logs cover instead.
Rehearse with a tabletop exercise
Walk the team through a realistic scenario, such as a researcher's report on a Friday evening that turns into active exploitation, using your real contact lists, chat tools and runbooks. CISA's Tabletop Exercise Packages give adaptable scenarios, discussion questions and an after-action template. Give every gap an owner; NIST SP 800-61 Rev. 3 treats exercises as a source of improvements to the plan.
Close with a blameless postmortem
After each confirmed exploitation, credential or signing-key exposure, or customer notification, write a postmortem that finds contributing causes without blaming people, and file each action as a tracked item with an owner and a date. Have a senior reviewer check it. Feed the causes into Root cause analysis so the same class of flaw does not ship again.

Done when

The incident plan has a named owner and has been exercised, and advisories go out in a standard, machine-readable format.

Mark it in the gap check

Common mistakes

Not recording when the team became aware, so nobody can show that reporting deadlines were met.
Writing "versions before 5.3" when 5.2.4 on a maintenance branch is already fixed. Scanners then flag patched systems, and customers may stop trusting your advisories.
Marking a product known_not_affected in CSAF with no flag or impact statement. The CSAF 2.0 VEX profile requires one, and customers are left guessing why.
Rebuilding or patching the affected system before collecting evidence, which destroys what the investigation needs.
A plan nobody has exercised, with a contact list a year out of date, so the first real incident is also the first test.

Which advisory format reaches whom?

Publish the human page and the formats your customers' tools read, all generated from one case record so versions cannot drift.

Which advisory format reaches whom?: table
Format	Who reads it	Where it goes
Web advisory	People: customers, support, press	Your security advisories page
CVE record	Scanners and vulnerability databases, including NVD	The CVE List, through your CNA
CSAF 2.0 advisory or VEX document	Enterprise customers, CERTs and asset tools that read CSAF	Your CSAF provider directory, listed in `provider-metadata.json`
OSV record or GitHub security advisory	Package scanners such as OSV-Scanner and Dependabot	The GitHub Advisory Database or the ecosystem's OSV database
OpenVEX or CycloneDX VEX	Container and SBOM scanners that read VEX	Alongside your images or SBOMs

Tools and guides

Workflow: Respond to a vulnerability
Tool: CVSS v4.0 calculator
Publish security advisories with CSAF, VEX, CVE records and OSV
What a useful security advisory contains and how to publish it in the formats tools read: a validated CSAF 2.0 VEX document, the CSAF provider files, CVE records through a CNA (CVE Record Format 5.2), and OSV records for open-source packages. Covers the status of CSAF 2.1 as of October 2026.
Respond to product security incidents: plan, tabletop and postmortem
An incident response plan for product security incidents (exploited vulnerabilities, compromised releases, leaked signing keys, malicious dependencies shipped to customers), aligned with NIST SP 800-61 Rev. 3, with reporting clocks, a two-scenario tabletop exercise template and a blameless postmortem template.
Set up a PSIRT: services, intake, triage, SLAs and the CNA role
How to structure and run a product security incident response team on the FIRST PSIRT Services Framework: organizational models, intake channels, triage, response targets, a case record and SLA script, becoming a CVE Numbering Authority under the CNA rules 4.2.0, and coordinating with other vendors.
Build a runbook for CRA vulnerability and incident reporting
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform within 24 and 72 hours. Decide what is reportable, start the clock at the right moment, file through the platform and keep an evidence trail.

Standards

NIST SSDF 1.1: RV.1 Identify and Confirm Vulnerabilities on an Ongoing BasisRV.2 Assess, Prioritize, and Remediate Vulnerabilities
OWASP SAMM 2: Incident Management

Advisories and incidents

Do this

Write a short incident plan

Record awareness and preserve evidence

Write the advisory from verified facts

Publish a CVE record and machine-readable data

Tell customers in one place

Rehearse with a tabletop exercise

Close with a blameless postmortem

Done when

Common mistakes

Which advisory format reaches whom?

Tools and guides

Standards

Sources

Find your next answer