EU CRA runbook maps 24-hour and 72-hour vulnerability reporting for small teams

A step-by-step runbook published on dev.to by Oleksandr Kuryzhev tackles a problem many small engineering teams now face: meeting the EU Cyber Resilience Act's vulnerability reporting duties, which according to the article have been mandatory since 11 September 2026. The guide converts a legal obligation — an early warning within 24 hours and a fuller notification within 72 hours for actively exploited vulnerabilities — into concrete tooling built around GitHub issues, SBOMs and a few shell commands.

What the rules require

According to the dev.to article, manufacturers that place products with digital elements on the EU market must report actively exploited vulnerabilities. The early warning is due within 24 hours and must, where applicable, name the member states where the product is known to be available. A fuller notification follows within 72 hours, covering general product information, the nature of the vulnerability and the exploit, corrective or mitigating measures taken, and measures users can take themselves. Reports route through a single reporting platform established by ENISA, with submissions reaching the designated coordinating CSIRT and ENISA. The article's checklist also points to a final report due within 14 days of a corrective measure, cross-referencing Article 14 of the regulation.

The post frames the pressure with a scenario: a customer emails a proof-of-concept for a firmware update daemon at 18:40 on a Friday, with exploitation already visible on a public forum. The deadlines count in hours, weekends included. Large vendors have compliance staff for this; small teams have whoever is on call, which is why the author argues the runbook must exist before the report arrives.

Groundwork before an incident

The article lists prerequisites it considers essential. First, a scope decision: which products count as products with digital elements under Regulation (EU) 2024/2847 — the post notes that pure hosted SaaS is generally handled differently and open-source stewards carry lighter obligations. Second, an account on the ENISA reporting platform, created in advance rather than mid-incident. Third, two named people — a decider and a submitter — each with a deputy, because one person cannot cover a 72-hour window.

On intake, the author recommends publishing a SECURITY.md file and a security.txt at the standard well-known path, enabling GitHub's private vulnerability reporting, and routing the security mailbox to the same pager as production alerts, since an unread report over a weekend may still start the clock. The runbook should also define awareness in writing — the article suggests the timestamp when the decider records credible evidence of exploitation, not when the first email landed — while noting that whether such a definition holds up is a question for counsel.

Starting the clock with one command

The core automation is a small bash script that records the awareness time, computes both deadlines using epoch arithmetic rather than date-string parsing, and opens a GitHub issue via the gh CLI. The issue carries the awareness timestamp, the 24-hour and 72-hour due times, and a checklist spanning decider confirmation, the member-state list, both submissions, and the eventual corrective release. GitHub then supplies a durable, timestamped record. One gotcha the post flags: macOS ships BSD date, which lacks the flags the script needs, so teams should install GNU coreutils or the script will fail at the worst moment.

Building the evidence

For the notification content, the article assembles an evidence pipeline: generate an SBOM of the artifact actually shipped using syft, match components against vulnerabilities with grype, then intersect the resulting CVE identifiers with CISA's Known Exploited Vulnerabilities catalog using jq. Any CVE appearing in both sets is one in shipped components known to be exploited somewhere — which the author treats as a strong trigger for the decider, not a legal test: telemetry and customer reports also count, and absence from the catalog proves nothing. The post also recommends keeping Markdown templates for both reports so submission becomes fill-in-the-blanks rather than prose written under pressure, and re-checking tool flags against current documentation because output formats change between releases.

Costs and caveats

The article is explicit that it is engineering guidance rather than legal advice, and that scope should be verified with counsel. It also acknowledges the cost side: added on-call duty and process weight, which teams shipping nothing to the EU market can reasonably skip.

Why it matters

The CRA's reporting duties land on teams that often have no legal or compliance function. What makes this runbook notable is that it turns a regulatory clock into artifacts engineers already operate — an issue tracker as a timestamped compliance record, an SBOM pipeline as evidence, a shell alias as the trigger. It also isolates the genuinely hard part: awareness of active exploitation is an operational event that someone must own and timestamp, and ambiguity there is where a 24-hour deadline is won or lost. As disclosure obligations with hour-based deadlines spread beyond the EU, this pattern of encoding regulation as scripts and checklists is one small teams are likely to keep reusing.