Skip to main content

The Submission Lifecycle

The submission lifecycle takes a vulnerability report from receipt to closure. The audit log records the actions on each report.

Report statuses​

Each report has one of five statuses: New, Acknowledged, In progress, Resolved and Dismissed. A member can acknowledge a report and move it between New, Acknowledged and In progress. Only an admin can resolve or dismiss a report, and each needs a reason. Reopening a resolved report clears its resolved date.

Report handling stages​

The stage bar guides each report through seven stages.

  1. Receive. You acknowledge the report to start coordinated disclosure.
  2. Assess. You set the severity. On a plan with CRA products, you also link the affected product.
  3. Decide Article 14. You record the exploitation status. You can click Record: not actively exploited when no exploitation occurs.
  4. Report to CSIRT. The platform drafts required regulatory notices when statutory reporting triggers apply.
  5. Fix. You record the remediation decision and verify the fix.
  6. Disclose. You publish a coordinated security advisory for users. You can draft it when the Fix stage is done, before you close the report.
  7. Close. An administrator closes the report with a reason, as resolved or dismissed. When the report triggered Article 14 and the 24h early warning or the 72h notification is not filed yet, the close is refused. An unsent final report does not block the close, because it falls due after the fix ships. The page lists the notifications that are not filed. File them first, or give a second reason of at least 20 characters to close anyway. The audit log keeps that reason. An Article 14 stage that is still due stays due after the report closes.