Vulnerability readiness policy

CRA Evidence separates two things that look the same but are not. One is the CRA legal floor: the conformity requirement you cannot relax. The other is CRA Evidence's own default policy: a conservative layer we apply on top of the floor to keep you safe. This page explains both, where each one shows up, and how to read the status fields.

The CRA legal floor

The floor comes straight from the regulation. The CRA bars making a product available on the market with known exploitable vulnerabilities. It defines an exploitable vulnerability as one that has the potential to be effectively used by an adversary under practical operational conditions. An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.

So the floor blockers in CRA Evidence are:

A published VEX statement of Not Affected or Fixed clears the related finding. That is the correct way to resolve a floor blocker when your product is genuinely not affected.

The CRA Evidence default policy

The default policy is stricter than the floor on purpose. "Unknown" is not the same as "known exploitable". A critical finding that nobody has assessed yet is unknown, not proven exploitable, so the law does not block on it by itself. We still hold the release, because shipping an unassessed critical is a poor default.

You clear a default-policy blocker the same way you clear any finding: decide it, remediate it, or write a VEX. The difference is conceptual. These sit above the legal line, so they are relaxable in principle. Configurable policies are on the roadmap (see below).

How the two statuses relate

Today CRA Evidence reports three values for a version:

• cra_status: the overall verdict. Ready only when the floor, the default policy, and every other CRA requirement are all met. This is unchanged from before and still drives the badge, the gate, and the Declaration of Conformity.
• cra_floor_status: ready when only the legal floor is considered. It ignores the relaxable default-policy vulnerability blockers, but it still reflects every other CRA requirement (SBOM, risk assessment, declaration, and so on).
• release_policy_status: the release-policy verdict. Right now it is identical to cra_status.

A worked example. A version has all its documents in place and no exploitable or KEV findings, but it has three critical findings still waiting for a triage decision. Then:

• cra_floor_status is ready. The legal floor is met.
• cra_status is incomplete. The default policy holds the release until those criticals are decided.
• release_policy_status matches cra_status: incomplete.

The same example with one KEV match instead of the three undecided criticals flips it: the floor itself is now incomplete, because a KEV match is a floor blocker.

Where you see the labels

Version readiness. The technical file view groups vulnerability blockers and tags each group. Floor blockers show a "CRA required" badge. Default-policy blockers show a "CRA Evidence default policy" badge.

Security events. In the triage queue, each pending finding shows which layer it blocks. KEV items are tagged "CRA required". Critical non-KEV items are tagged "CRA Evidence default policy".

CLI. The status command prints blockers grouped by layer:

craevidence status --product my-product --version 1.2.3

Vulnerability blockers by policy layer
  CRA required (legal floor):
    • CVE-2021-44228: Listed in the CISA Known Exploited Vulnerabilities catalogue
  CRA Evidence default policy (above the floor):
    • CVE-2022-42889: Critical scanner finding pending review
  CRA legal-floor status: incomplete

API. The CI status response carries the structured fields:

curl "https://api.craevidence.com/api/v1/ci/status?product=my-product&version=1.2.3" \
  -H "Authorization: Bearer $API_TOKEN"

{
  "cra_status": "incomplete",
  "cra_floor_status": "ready",
  "release_policy_status": "incomplete",
  "vuln_blockers": [
    {"cve_id": "CVE-2022-42889", "reason": "Critical scanner finding pending review",
     "source": "default_policy", "kind": "pending_review_critical"}
  ]
}

Each entry in vuln_blockers carries a source of either cra_required or default_policy, so your pipeline can decide what to gate on.

The public conformity claim

Today the public "CRA conformity" badge and the Declaration of Conformity follow cra_status. Because cra_status always sits at or above the legal floor, the public claim is never weaker than the CRA requires. It is not a statement about any internal release preference. This keeps the public claim honest: it says the product meets the CRA, not that it passed a private policy.

Configuring your own policy

Organisation admins can set a release policy for the whole organisation. Today it has one switch: enforce the conservative default, or accept the CRA legal floor only.

• Default (recommended): block release on unconfirmed criticals (undecided criticals and pending non-KEV critical findings). This is how every organisation starts.
• Floor only: stop blocking on those unconfirmed criticals. Release is then gated by the legal floor alone. The badge and the Declaration of Conformity are unaffected, because they already track the floor.

Two rules always hold, by design:

1. The floor stays fixed. No policy can drop a release below the CRA legal floor.
2. A relaxed policy never changes the public conformity claim. The badge and the Declaration of Conformity continue to track the floor.

When a policy accepts the floor only, auto-release is turned off for the affected products. A relaxed policy should not silently ship a version that still carries unconfirmed criticals, so the final release stays a manual step.

More controls (a higher severity floor, requiring a fix even when a finding is not exploitable, an EPSS threshold, and zero known CVEs) are planned. They are not active yet, so the settings only show the switch above.

FAQ

Does the default policy change what the CRA requires? No. The CRA floor is fixed by the regulation. The default policy is a choice CRA Evidence makes on top of it.

A critical finding is blocking my release. Is that the law? Not on its own. A critical that nobody has assessed blocks under the default policy, not the floor. Mark it exploitable, mark it not exploitable, or publish a VEX, and the block clears. If the finding is a KEV match or you mark it exploitable, then it does block the floor.

Why is a KEV match treated as a floor blocker? A KEV listing is reliable evidence that the vulnerability is being exploited in the wild. That matches what the CRA means by an actively exploited vulnerability, so we treat it as a floor concern.

Can I gate my CI pipeline on the floor only? Read cra_floor_status and the vuln_blockers source tags from the CI status response and decide in your pipeline. The CLI --fail-on gate still tracks cra_status today.

Related documentation

• Vulnerabilities, the full scan-to-report lifecycle
• VEX Management, how to clear a finding with a VEX statement
• Technical File, the compliance bundle
• CLI, the command-line tool
• API Reference, the REST API