About CRA Sentinel

Manufacturers increasingly ship products built from large software dependency chains. A single supported release can contain thousands of components that somebody else wrote, and the organisation is answerable for all of them.

When a vulnerability appears, the hard part is not merely seeing another CVE. It is knowing which shipped product and version is affected, whether public exploitation evidence exists, who assessed it and what they decided, which CRA reporting actions follow and by when — and then being able to prove that history later, including for the vulnerabilities you decided not to report.

Those questions are usually answered across a vulnerability scanner, a spreadsheet, a ticket tracker and somebody’s memory. That works until a regulator asks when you became aware of something, and the answer has to be evidence rather than recollection.

CRA Sentinel is being built to make that operational workflow manageable in one place — the inventory, the monitoring, the human decision, the deadline, and the record.

Say what it cannot check. An SBOM component with no resolvable identifier is reported as a gap rather than counted as clean. Coverage you cannot trust is worse than coverage you know is partial.

Attribute every decision to a person. Machine API keys are refused for triage. A record saying someone assessed a vulnerability should not be producible by a script.

Never quietly rewrite history. Triage decisions are kept as revisions and evidence entries are append-only and hash-chained, so an alteration is detectable rather than invisible.

Do not overclaim. The product does not file reports, does not determine legal reportability, and does not make anyone compliant. Selling record integrity while overstating what the software does would be a strange way to start.