We don't scan your code, and here's why that's the right call

The first question most engineers ask about a CRA reporting tool is some version of "what does it scan, and how deeply." The honest answer is: nothing. We don't scan your code, your containers, or your dependencies. We read the SBOM you already generate with a tool built for that job — syft, cdxgen, whatever your pipeline already produces — and we do exactly one thing with it: watch it against exploitation feeds and help you file the report Article 14 requires when something in it is being actively exploited.

The short answer

Scanning and reporting are two different jobs, done well by different kinds of tools, and a product that tries to do both usually does neither convincingly. Declara does one job — the reporting clock, the triage, the filing packet — and refuses to do the other, on purpose, not as a missing feature.

Why we defer scanning to tools built for it

SBOM generation and vulnerability scanning are mature, competitive fields — syft and cdxgen for inventory, Trivy and Grype for matching, each maintained by people whose whole job is keeping pace with new ecosystems, new package formats and new evasion techniques. Building a second, worse version of that inside a compliance product would mean asking customers to trust our scanner's coverage instead of a tool purpose-built for it, for no benefit — the SBOM format is already a standard interchange (CycloneDX, SPDX), and a reporting product's job starts at "here is the inventory," not "let me go find it myself." So we don't. Upload the SBOM your pipeline already builds; we start from there.

Why we refuse conformity assessment and CE marking too

The same instinct applies further along the Regulation. Conformity assessment, Annex I essential requirements, CE marking — these become mandatory for the full Act in December 2027, and for Class II and critical products they require a notified body, months of lead time, and a level of legal liability that sits with whoever signs the declaration. That is a different kind of work, done by people with liability for the answer, and a SaaS product cannot discharge that liability on your behalf no matter how confident its UI looks. What we can do — and do — is compute which class your product falls into and what conformity route that implies, so you know what you're walking into and when, without pretending we've done the assessment for you.

Assess versus report, made concrete

Here's where the distinction actually bites. Your SBOM shows a library that just appeared in the CISA Known Exploited Vulnerabilities catalogue. That is a strong signal to check: is the vulnerable code path in the version you ship, is it reachable from anything an attacker can reach, is there any indication your specific deployment has been targeted. It is not, on its own, a reportable event — the CRA's duty is triggered by exploitation of your product, not by a dependency's presence in a catalogue.Art. 14⁠(1)⁠ Treating every KEV hit as an automatic filing either buries your team in reports you didn't owe, or trains everyone to ignore the alerts entirely by the third false positive — and the second outcome is the one that eventually lets a real filing slip.

Declara's tiering exists to hold that line mechanically rather than by discipline alone: a KEV listing or high exploitation probability raises an interruptive alert worth assessing now; a merely severe vulnerability with no exploitation signal goes in a weekly digest instead of your inbox. See how that tiering works in KEV match ≠ reportable incident, or read the fuller version of what we do and refuse to do on the about page.