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 presence and SBOM quality gate (SbomPresenceGate)Policy architecture, signed SBOM archiveI.II.1, I.II.2, I.I.2.bdeclaredControls, evidenceLinks, and CRA tech-file sections/07-sbom.jsonRequires an actual SBOM ref, accepted format, schema validation, and preferably signed archive evidence for production.
Signature-required evidence gate (SignatureRequiredGate)Policy architecture, policy verdict attestations, evidence hooksI.I.2.b, I.I.2.g, I.II.3Evidence integrity control and audit-signature supportSignature-looking metadata is not enough; verifier and trust roots must succeed or the evidence is incomplete.
CVSS threshold gate (CvssThresholdGate)Policy architecture, CVSS v4 policy notesI.II.2, I.II.3Vulnerability triage and risk-assessment evidenceCVSS alone is a severity signal. It must be paired with affectedness, reachability, and disposition evidence for release decisions.
Reachability requirement and reachable CVE gatesReachable CVE gate, Policy architecture, hybrid reachability attestationsI.II.2, I.II.3, I.I.2.jExploitability and mitigation evidence for Module A controlsMissing or stale reachability evidence must be recorded as unknown or blocked, not converted into an allow decision.
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 gate (EvidenceFreshnessGate)Policy architecture, runtime guide, feed snapshot thresholdsI.II.2, I.II.3, I.I.2.gFreshness and replayability evidenceFreshness uses pinned snapshots and explicit timestamps. Do not call live feeds during dossier generation.
Minimum confidence gate and Unknowns budget gatePolicy architecture, budget attestation, determinization architectureI.I.1, I.II.2, I.II.3Unknown-risk and confidence control evidenceUnknowns are first-class. If the budget is exceeded, the dossier should cite the blocker or accepted exception.
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.
VEX trust and verdict rationale evidenceVEX trust model, verdict rationale, verdict attestationsI.II.2, I.II.3Affectedness and justification evidenceVEX conflicts must preserve source provenance; do not merge away disagreement.

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