CRA Conformity Assessment Policy Mapping

Status: Draft Owner: Policy + Documentation Last updated: 2026-04-30

Purpose

This guide maps Stella Policy gates, scopes, metrics, and attestations to CRA control evidence used by the conformity-dossier-v1 export. It is a mapping contract for evidence assembly, not a legal conclusion and not a harmonised standards claim.

Authoritative bundle contracts:

Planning and route decisions:

Operating Boundary

CRA Reference Vocabulary

Use these identifiers in declaredControls[].craRequirements and evidenceLinks[].craRequirements in the conformity dossier:

IdentifierLocal meaning
I.I.1Secure-by-design and secure-by-default baseline.
I.I.2.aConfidentiality protection, including cryptographic protection where configured.
I.I.2.bIntegrity of stored, transmitted, and processed evidence.
I.I.2.dData minimisation and exposure reduction.
I.I.2.eAvailability, resilience, and operational continuity evidence.
I.I.2.gLogging of security-relevant internal activity.
I.I.2.hSecurity update integrity and support-lifecycle evidence.
I.I.2.jVulnerability mitigation techniques and exploitability reduction.
I.II.1Machine-readable SBOM availability.
I.II.2Vulnerability handling without delay.
I.II.3Security testing, review, and effectiveness evidence.
I.II.4Public disclosure of fixed vulnerabilities.
I.II.5Coordinated vulnerability disclosure policy.
I.II.6Vulnerability information sharing and reachable security contact.

Mapping Contract

Policy-sourced mappings MUST be represented in the conformity dossier as declared controls plus evidence links. The minimum shape is:

{
  "controlId": "CRA-POLICY-REACHABLE-CVE",
  "title": "Reachability-aware vulnerability release gate",
  "ownerRole": "policy-owner",
  "craRequirements": ["I.II.2", "I.II.3", "I.I.2.j"],
  "evidenceRefs": [
    "evidence://policy/verdicts/reachable-cve/latest",
    "evidence://scanner/reachability/latest-release"
  ],
  "status": "declared"
}

Evidence links for the same control MUST carry matching controlIds[], craRequirements[], content hash, media type, and an immutable ref.

Gate And Evidence Mapping

Stella control sourceLocal contract or guideCRA refsDossier useConservative limit
SBOM evidencesigned SBOM archive, withdrawn gate boundaryI.II.1, I.II.2, I.I.2.bActual SBOM material references and quality evidenceThe former SBOM gate class is withdrawn; an interop boolean assessment is not a promotion or independent schema-verification receipt.
Signature verification evidencepolicy verdict attestations, evidence hooks, withdrawn gate boundaryI.I.2.b, I.I.2.g, I.II.3Attributable verifier and custody resultsThe former signature gate class is withdrawn; caller-supplied interop verification flags are not cryptographic verification.
CVSS assessment evidenceCVSS v4 policy notes, withdrawn gate boundaryI.II.2, I.II.3Severity assessment paired with affectedness and actual promotion evidenceThe interop CVSS comparison remains available; it is not a registered promotion gate.
Reachability evidenceReachable CVE contract, hybrid reachability attestations, withdrawn gate boundaryI.II.2, I.II.3, I.I.2.jActual reachability evidence and registered gate resultsThe former reachability-requirement class is withdrawn. A caller-supplied interop status is not a promotion receipt.
KEV blocker gateKEV blocker gateI.II.2Actively exploited vulnerability handling evidenceKEV membership is a prioritisation signal. It does not replace product-specific affectedness analysis.
EPSS threshold gateEPSS threshold gateI.II.2Vulnerability prioritisation evidenceEPSS is predictive risk input, not conformity proof. Keep the score snapshot and feed timestamp in evidence.
CVE delta gateCVE delta gate, SBOM/VEX diff rulesI.II.2, I.II.3, I.I.1Regression prevention and release comparison evidenceBaseline identity is mandatory. First-release bootstrap must be explicit in the policy evidence.
Release aggregate CVE gateRelease aggregate CVE gateI.II.2, I.I.1Release-level vulnerability posture evidenceAggregate counts must not hide reachable critical issues; pair with per-finding gates.
Evidence freshness evidenceruntime guide, feed snapshot thresholds, withdrawn gate boundaryI.II.2, I.II.3, I.I.2.gPinned snapshot times and attributable freshness checksThe former freshness class is withdrawn; the interop assessment reads supplied fields rather than verifying a live producer.
Unknown-risk evidencebudget attestation, determinization architecture, withdrawn gate boundaryI.I.1, I.II.2, I.II.3Actual uncertainty records and accepted exceptionsThe old classes are withdrawn. The on-demand interop algorithms do not establish enforced promotion controls.
Execution evidence gateExecution evidence gate, execution evidence contractI.II.3, I.I.2.g, I.I.2.jRuntime test/observation evidenceProduction promotion evidence should name the source environment and trace-quality thresholds.
Beacon verification rate gateBeacon rate gate, execution evidence gateI.II.3, I.I.2.e, I.I.2.gRuntime coverage and canary-observation evidenceLow sample sizes must be represented as insufficient evidence, not a full pass.
Policy lifecycle shadow, coverage, reviewer, determinism, and publication gatesPolicy lifecycle, policy runs, policy verdict attestationsI.II.3, I.I.2.g, I.I.2.bControl-effectiveness and approval evidenceLifecycle evidence proves Policy governance, not product conformity by itself.
Effective VEX status and verdict rationale evidenceVEX consensus operations, verdict rationale, verdict attestationsI.II.2, I.II.3Projected tenant affectedness and justification evidencePreserve issuer provenance, the conflict flag, tenant overlays and decision hash. A hash alone is not an attestation.

Non-Policy Evidence Needed In The Same Dossier

Some CRA controls are not Policy gates. The conformity dossier should link these local contracts or legal docs directly instead of forcing them into Policy metadata:

Evidence areaCRA refsLocal source
Product CVD policy and security contactI.II.5, I.II.6Product CVD policy contract, product security metadata contract
Public product advisory or fixed-vulnerability disclosure feedI.II.4, I.II.6CRA gap closure plan A1
Support lifecycle and security update policyI.I.2.hProduct lifecycle contract, product support policy, EOL policy
CRA technical file sections outside PolicyVaries by sectionCRA technical file v1
Offline verification and attestation proof chainI.I.2.b, I.I.2.g, I.II.3Attestor proof chain, offline verification

Module-Specific Use

Module A

Use this guide to populate overlays/common/declared-controls.json and overlays/common/evidence-links.json. A Module A dossier is only complete when each declared Policy control has:

Module B+C

Use the same Policy mappings for production-conformity evidence. The EU type-examination overlay still requires certificate or test-report refs under testCertificates[]; Policy evidence cannot satisfy that requirement alone.

Module H

Use Policy mappings as the control-effectiveness slice for QMS evidence. Module H still requires full QMS process evidence and, where used, the ISO/IEC 27001 control-effectiveness mapping. Do not claim Module H completeness from Policy gates alone.

Optional Gate Frontmatter

The CRA gap plan references future gate-doc metadata in this shape:

crm:
  cra:
    - I.II.2

The current gate docs under Policy gates do not contain comparable machine-readable frontmatter. Their --- markers are markdown section separators near the footer, not metadata blocks. Until a Policy docs metadata schema is introduced, this guide is the authoritative mapping source.

Follow-up scope when a metadata schema is approved:

  1. Add frontmatter to each focused gate doc using the mapping table above.
  2. Keep the crm.cra[] values identical to this guide unless a reviewed mapping update lands first.
  3. Add a markdown lint or doc sanity check that confirms every frontmatter CRA identifier is present in the vocabulary table above.

Export Checklist