CRA security advisory generator for apps
The public advisory for a vulnerability you fixed in an app, in the structure of ENISA's draft template, plus the short note that goes with the update.
Once a security update is available, the manufacturer of an app has to share and publicly disclose information about the fixed vulnerabilities: a description, information that lets users identify the affected app, the impacts and severity, and clear and accessible information helping users to remediate (Annex I, Part II, point 4 of the Cyber Resilience Act). Security updates also go out with advisory messages telling users what to do (point 8). Fill in the form below for one vulnerability and get the advisory as Markdown and HTML, ready to put on your advisories page.
What the CRA asks
| Rule | What it means for an app |
|---|---|
| Disclose fixed vulnerabilities Annex I, Part II, point 4 | Once a security update is available, share and publicly disclose information about the fixed vulnerabilities: a description, what lets users identify the affected app, the impacts, the severity and clear and accessible information helping users to remediate the vulnerabilities. In duly justified cases, where the security risks of publication outweigh the benefits, publication may be delayed until users have had the possibility to apply the patch. |
| Updates with advisory messages Annex I, Part II, point 8 | Security updates are disseminated without delay and free of charge (unless otherwise agreed with a business user for a tailor-made product), accompanied by advisory messages with the relevant information, including potential action to be taken. |
| Actively exploited Article 14(8) | After becoming aware of an actively exploited vulnerability or a severe incident, inform the impacted users, and where appropriate all users, and where necessary of risk mitigation and corrective measures they can deploy, where appropriate in a structured, machine-readable format. This can come before a fix exists. The same vulnerability is also reported under Article 14(1) and (2); see the reporting deadlines calculator. |
| Third-party components Article 13(6), Annex I, Part II, point 6 | A vulnerability found in a component, including open source, is reported to whoever manufactures or maintains it, and you facilitate the sharing of information about vulnerabilities in third-party components in your app. |
| Coordinated disclosure Annex I, Part II, point 5 | Your coordinated vulnerability disclosure policy sets when advisories are published; publish at the disclosure date it promises. |
How ENISA suggests publishing advisories
ENISA's draft Technical Advisory on security.txt, CVD Policies and Security Advisories (October 2026, the "SME Vulnerability Kit") gives an advisory template, which this generator follows: title with an advisory number, identifiers, severity and CVSS, dates and audience, affected and fixed versions, a plain-language summary, remediation with supporting measures, a timeline, credit and contact. It also recommends:
- Publish an advisory for each resolved vulnerability once the coordinated disclosure date is reached, through the channel named in your disclosure policy, and keep a public index of all advisories as a record of disclosure.
- Where customers are known, notify them directly as well; where they are not, use a dedicated page on your website.
- Publish a human-readable advisory and, where feasible, a machine-readable one. ENISA points to CSAF (ISO/IEC 20153:2025), whose VEX profile can also state that a product is not affected.
- Update the advisory when new information or fixes become available and record the change in the timeline; outdated advice misleads users.
- Avoid unclear descriptions, missing affected versions, missing severity or remediation, broken links or missing contact details, and premature or late publication.
For an app agency, the advisory is published under the name of the manufacturer, usually the client (see who the manufacturer is). The disclosure policy guide explains the policy that sets the timeline, and the reporting guide covers what goes to the authorities when a vulnerability is actively exploited. Save the answers as a file to start the next advisory from them.
Want to know about vulnerable dependencies before someone reports them? Shipmark checks the SBOM of every client app for known vulnerabilities every day. Founding agencies use it free until 1 April 2027.
Join the free betaSources
- ENISA: Technical Advisory on security.txt, CVD Policies and Security Advisories (SME Vulnerability Kit), draft for public consultation, October 2026 (PDF), section 3.3 on security advisories.
- Regulation (EU) 2024/2847, Annex I: essential cybersecurity requirements, Part II points 4 to 8 (StreamLex).
- Article 14: reporting obligations of manufacturers, paragraphs 1, 2 and 8, and Article 13, paragraph 6 (StreamLex).
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: the authentic text.
The generator runs in your browser: what you type is not sent anywhere, and nothing is stored unless you save the answers as a file on your own device. It writes a draft that follows ENISA's draft template; ENISA may change the template after its consultation. Not legal advice. Related: security.txt generator · Reporting deadlines · ENISA's SME Vulnerability Kit