DEV Community: sameh

The 24-hour CRA reporting clock: build the evidence packet before you need it

sameh — Thu, 24 Sep 2026 17:29:53 +0000

A vulnerability report lands at 17:20 on Friday. That is the wrong moment to design your incident process.

Educational material only — this is not legal advice.

A vulnerability report lands at 17:20 on Friday. The reporter says a flaw in a bundled component is being exploited. The maintainer is in another time zone. The last two releases used different versions, customer deployment data is incomplete, and nobody on the team has registered for the reporting platform.

The CRA's reporting duties for manufacturers are now live — they've applied since 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security through ENISA's Single Reporting Platform (SRP): an early warning within 24 hours of awareness, a fuller notification within 72 hours, then a final report — within 14 days of a fix for vulnerabilities, or within a month of the 72-hour notification for severe incidents.

The practical challenge isn't memorizing the clock. It's whether the team can identify the product, affected versions, current facts, decision owner, and next update while information is still incomplete.

Know what starts the workflow

Not every CVE match is an actively exploited vulnerability in your product. Create two intake triggers: credible information that a vulnerability in your product or a component is being actively exploited, and an event that may severely impact product security. At intake, don't wait for certainty — open a timed assessment, preserve the original report, assign an incident lead, and record when the organization became aware. "Awareness" starts the legal clock, so agree with counsel how you interpret and record it before you need it.

Separate facts from assessments

Keep observed facts apart from working assessments. Facts: report time and source, affected versions and platforms, indicators of exploitation, customer impact so far, preserved logs and samples. Assessments: is the issue present in shipped versions, is exploitation credible, does it meet severity criteria, confidence level and the next fact needed. A 24-hour warning can acknowledge uncertainty without blending assumptions into facts.

Pre-build the evidence packet

Create the packet structure before triage opens. Product identity: manufacturer, product and version range, platforms, EU distribution channels, support status, update mechanism. Technical evidence: affected artifacts and hashes, release-linked SBOMs, exploit indicators, reachability assessment, fix status. Decision trail: awareness timestamp, incident lead, reportability assessment, submission receipts, customer communication decisions. Don't alter original evidence — add versions and preserve the decision chain.

Give a five-person process to a two-person team

Assign named primary and backup owners for intake monitoring, technical triage, the reportability decision, SRP submission, customer communication, fix approval, and post-incident review. One escalation rule: if the primary is unreachable, the backup takes control after a defined period. The 24-hour window doesn't pause for holidays.

Rehearse the case most likely to hurt

Run a 60-minute tabletop with your actual product: a critical flaw in a bundled update component, two supported releases affected, a fix that breaks one platform's installer, some customers with auto-updates disabled. Ask the team to record awareness, find the affected releases and their SBOMs, draft the 24-hour warning from known facts only, and plan containment and customer guidance. Score it on retrieval time and decision clarity — the goal is removing avoidable delay, not theater.

Five readiness checks for this month

A security contact that reaches a person, not an abandoned inbox. SRP access for the right people, registered before you need it. Release traceability: component to affected versions, fast. One named decision owner, with a backup. One timed rehearsal producing a draft warning within the first hour. Fix access and ownership gaps before buying another scanner.

Has your team tested a CRA reporting workflow — or discovered it has no workable one? Drop a line or two in the comments about what would break first; I'm collecting practical lessons from small vendors, no call needed.

Sources

Your SBOM should be a release artifact, not a compliance screenshot

sameh — Thu, 24 Sep 2026 17:29:02 +0000

An SBOM you can't tie to a release is a screenshot, not evidence. Here's how to make it a release artifact.

Educational material only — this is not legal advice.

A software bill of materials can be generated in seconds and become unreliable just as quickly.

Run a scanner against a development checkout, save the result as sbom.json, and the team technically has a file. But which release does it describe? Was it generated before or after the lockfile changed? Does it include the bundled runtime, native modules, container base, installer, and vendored code? Can the same binary be tied back to the same component list six months later?

The Cyber Resilience Act makes the operational answer important. Annex I requires manufacturers to identify and document vulnerabilities and components — including by drawing up an SBOM in a commonly used, machine-readable format covering at least the product's top-level dependencies.

That wording sets a minimum. A useful SBOM process goes further by creating a trustworthy relationship between the inventory, the product artifact, and the release decision.

Define the unit of inventory before choosing a tool

"Generate an SBOM" is underspecified. First define what counts as one product release.

For a WordPress plugin, the unit may include PHP dependencies, bundled JavaScript, vendored libraries, and the exact ZIP delivered to customers. For an Electron app, add the Electron and Chromium versions, native Node modules, auto-update components, and per-platform installers.

Write a release inventory contract: product and version identifier, platforms, each build artifact and checksum, package ecosystems and lockfiles, bundled runtimes and vendored components, build commit and workflow run, SBOM format and tool version, and known blind spots. A generator that misses a bundled runtime isn't "mostly complete" if that runtime carries the vulnerability that matters.

Generate from the closest trustworthy point to shipment

Source-only scanning is useful in development, but release evidence should describe what customers receive. Generate or reconcile the SBOM as late in the trusted build pipeline as practical:

The release workflow resolves locked dependencies in a controlled environment.
The application and installers are built.
The SBOM is generated for the final artifact.
Automated checks validate format, identifiers, duplicates, and gaps.
Artifact, checksum, SBOM, test results, and approval are archived under one release identity.
The release ships only after the evidence bundle is complete.

SPDX and CycloneDX are the common formats — pick the one your tools and customers can consume. Preserving identifiers, versions, and provenance accurately matters more than the format choice.

Validate the SBOM like any other build output

An SBOM can be syntactically valid and materially wrong. Check four things: is it complete against your inventory contract? Is it internally consistent — versions, identifiers, duplicates, hashes? Is it tied to the shipped bytes, with hashes and release IDs stored alongside and corrections kept as traceable revisions? And is it reproducible enough to investigate — can you explain material component differences on rebuild?

The inventory feeds triage

A component inventory becomes valuable when it feeds vulnerability triage: inventory → match → assess reachability and exposure → decide → remediate or accept → verify → communicate. A scanner match is not the final risk decision — record the affected releases, whether the vulnerable code is reachable, exploitability in your configuration, the decision owner and rationale, and verification.

Note the CRA doesn't require publishing your SBOM to the public — the recitals explicitly recognize confidentiality concerns. But you must be able to produce, retain, and retrieve it. Store immutable release copies, log disclosures, and test retrieval during an incident exercise.

Review deltas, not full inventories

A 2,000-line inventory is hard to review; a release delta is actionable: components added or removed, dependencies upgraded, new licenses, components leaving support, findings changed since the last release. Keep the full SBOM as the system record; make the delta the human review surface.

The practical test

Pick one production release from six months ago and give a teammate 30 minutes: which components shipped? Which issues were open at release time? What changed from the previous version? If the answers need personal memory or archaeology across systems, the problem isn't the SBOM format — it's missing release evidence.

Where does your SBOM workflow break today — incomplete inventories, noisy matches, or evidence scattered across tools? Drop a line or two in the comments; I'm collecting patterns across small vendors, no call needed.

Sources

The CRA clock has started

sameh — Tue, 22 Sep 2026 15:06:52 +0000

The reporting duties that matter most are already live. If you sell software in the EU, here's what that actually means — and how to be ready without wasting effort.

Educational material only — this is not legal advice.

Two instincts are leading small software vendors astray on the EU's Cyber Resilience Act (CRA).

The first instinct: "The deadline is late 2027 — I have time." The second: "This is only for Microsoft and Siemens."

Both are wrong, and the calendar is the reason. The CRA was adopted on 10 October 2024 and entered into force on 10 December 2024. But it doesn't switch on all at once. The notification duties under Article 14 apply from 11 September 2026 — already in the past. The remaining product requirements — conformity assessments, CE marking, the full documentation package — follow on 11 December 2027.

That split timeline is the whole story. The part of the CRA that can hurt you first isn't the paperwork in 2027. It's the reporting duty that's live right now.

What "already live" actually means

Article 14 requires manufacturers of products with digital elements to notify authorities when they become aware of an actively exploited vulnerability in their product — or a severe incident affecting its security. The timeline is brutal by normal support-desk standards:

An early notification within 24 hours of becoming aware. A fuller notification within 72 hours. A final report within one month.

And this applies to any product with digital elements sold commercially in the EU — your SaaS, your WordPress plugin, your desktop app, your dev tool. Not just the giants.

The penalties underline the point: up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Three things worth doing now

Almost everything the CRA asks of you early is operational, not legal. You don't need a law firm; you need a release process that produces evidence.

1. Build the SBOM into your release pipeline. For every release, generate a machine-readable inventory of what you shipped — every dependency, every version. CycloneDX is the pragmatic format. Do it in CI so it happens whether or not anyone remembers.

2. Keep evidence of what you ship and how long you support it. Archive each release's SBOM, record your stated support period, and keep incident records. When a regulator — or an enterprise customer — asks what was in version 4.8.0 and whether it was still supported, the answer should be a file, not a memory.

3. Set up a vulnerability intake and response process. Publish a security contact point, define who triages reports, and set internal deadlines that beat the regulatory ones. The 24-hour clock starts when you become aware — so "becoming aware" needs to be a defined process, not an accident.

The bottom line

The CRA rewards vendors who can show their work. Start with the release pipeline: if every release produces an SBOM and an archive entry, you're most of the way to the evidence trail the regulation assumes you have.

If you sell software in the EU, what does your current evidence trail look like? Drop a line or two in the comments about how you track releases today — no call, I'm just collecting patterns across small vendors.