Everything between a component you shipped and a deadline you have to meet

You record the products you place on the market and the individual releases you still support. Everything else in CRA Sentinel hangs off a specific product version, because that is the unit the obligation attaches to — a vulnerability matters to you if it reaches a version you support, not merely if it exists.

• Products, and the supported releases beneath each one.
• A component inventory per version, rather than one inventory for the product as a whole.
• Versions you no longer support stay on the record; historical uploads are retained even when they no longer count as live inventory.

You upload a software bill of materials for each supported version. CRA Sentinel parses CycloneDX and SPDX JSON documents and builds the component inventory from them.

Coverage is reported honestly. An SBOM that names a component without a resolvable identifier or version range cannot be matched against a vulnerability database, and the product says so rather than quietly counting it as checked. Knowing what it cannot see is part of what you are buying.

Installed component versions are range-checked against OSV, so a match means the version you actually ship falls inside an affected range — not merely that a package name appears somewhere in an advisory.

Matches are then cross-referenced against CISA KEV and the ENISA EU Vulnerability Database for evidence of active exploitation. That evidence is what raises a finding’s priority: the CRA reporting duty is keyed to actively exploited vulnerabilities, so a queue sorted by raw CVE count is the wrong queue.

Monitoring is continuous. New advisories are matched against inventory you uploaded months ago, which is the whole point — the duty reaches the installed base you still support.

A match is not a finding about your product until a human says so. A named person reviews each exposure and records one of:

• Affected — the vulnerability reaches this product version.
• Not affected — it does not, with the reasoning recorded.
• Needs information — the question is open and the exposure stays in the queue.

Decisions can be changed as understanding improves. Changing one does not overwrite what came before: each decision is kept as a revision, so the record shows where the assessment moved and why. A regulator asking what you believed in the first 24 hours gets an answer that is not the answer you reached in week three.

Machine API keys can automate ingest and reads, but they are refused for triage. A decision a regulator would attribute to a person is made by a person, and that refusal is enforced by the server rather than by hiding a button.

Where your team’s assessment leads to a reporting duty, a case is opened against the exposure. The case is the working surface: what has been submitted, what is due, and what the next physical action is.

Notification content is prepared in ENISA’s field order for a person to review, complete and submit. CRA Sentinel does not submit anything — there is no automated filing path here, and a person transcribes and sends the report.

Clocks run from the moment awareness is recorded, not from when someone next opens the application. Awareness is itself an editable, recorded field, so a case opened late still measures from when your organisation actually knew.

Every decision is written to an append-only history that is hash-chained: each entry commits to the one before it, so an altered or removed entry breaks the chain and is detectable when the history is exported and verified.

• Exportable as CSV or JSON.
• Includes decisions not to report, and the reasoning behind them — usually the harder thing to evidence later.
• Attributed: each entry records the account that made the decision and when.