From 4bfd552da7e3c150cd76a016556ccafd715cb633 Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Sat, 27 Jun 2026 08:11:42 +0200 Subject: [PATCH] docs(knowledge): TP-ISO27001->CRA gold standard + reference scenario (RS-005 regression) (1) Harden the first Transition Pattern to the gold-standard template per quality checklist: versioned transition_goal (ISO27001:2022 -> CRA, applies 2027-12-11), source_state_variants (certified/isms_introduced/expired/limited_scope), each likely_covered assumption with a typed relationship (supports|partially_supports, never equivalent) + verification + rationale (the Warum) + an auditor-checkable reviewable_claim, delta as missing-capability + needed-info, an explicit rejected_assumptions section, and a determinism_goal. README schema updated to match. (2) New Reference-Suite scenario 4 (Transition): the generator READS the pattern YAML and runs it through the RS-005 Planning Engine + Company 2A -> coverage + question requests. Proves the architecture fully carries the pattern (17 caps -> 17 coverage + 17 requests; 9 HIGH delta = the real CRA gaps, 8 probably-covered from the ISMS). Now a living regression test: every future pattern runs through the same engine. Non-runtime knowledge + reference harness -> no deploy (ADR-001). Next: ISMS->TISAX once approved. Co-Authored-By: Claude Opus 4.7 --- .../knowledge/transition_patterns/README.md | 18 +- ...transition_pattern_iso27001_to_cra_v1.yaml | 255 ++++++++++-------- .../reference_scenarios/generate.py | 54 ++++ .../reference_scenario_suite_v1.md | 38 ++- 4 files changed, 244 insertions(+), 121 deletions(-) diff --git a/backend-compliance/knowledge/transition_patterns/README.md b/backend-compliance/knowledge/transition_patterns/README.md index 71f0fc5c..26369eac 100644 --- a/backend-compliance/knowledge/transition_patterns/README.md +++ b/backend-compliance/knowledge/transition_patterns/README.md @@ -20,11 +20,21 @@ not designed up front (the same identity-machine discipline as Master Controls/O ## File schema (per `transition_pattern__to__v.yaml`) -`id` · `from_state` · `to_state` · `version` · `status` (draft → reviewed → approved) · +`id` · `status` (draft → reviewed → approved) · `version` · +`transition_goal` ({from: standard/edition/nature, to: regulation/reference/applies_from/nature, one_line}) · `provenance` (author/basis/reviewed_by/reviewed_at) · `disclaimer` · -`likely_covered_org_level[]` ({capability, source_basis, target_relevance, reuse_caveat, -confirm_question_intent, priority}) · `delta_requirements[]` ({capability, target_basis, why_delta, -question_intent, expected_evidence, priority}) · `ask_order_rationale` · `review_required[]`. +`source_state_variants` (certified / isms_introduced / expired / limited_scope — how the start changes assumption strength) · +`likely_covered[]` ({capability, source_basis, target, **relationship** (supports|partially_supports, never equivalent), +**verification** (required), expected_evidence, **rationale** (the *Warum* — why this relationship), **reviewable_claim** +(an auditor can agree/disagree)}) · +`delta_requirements[]` ({capability, target_basis, **missing_because**, needed_information (intent), +expected_evidence, priority, **reviewable_claim**}) · +`rejected_assumptions[]` (explicit "does NOT establish …") · `determinism_goal` · `review_checklist[]`. + +**Gold-standard bar:** every line is auditor-checkable (agree/disagree, not "probably"); each assumption +carries a typed `relationship` + a `rationale`; each delta maps to a missing capability + needed info; +explicit `rejected_assumptions` keep the source certificate from being over-read; two auditors should +arrive at the same delta questions (`determinism_goal`). ## Hard rules diff --git a/backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml b/backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml index 95494d0c..1e8f26c8 100644 --- a/backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml +++ b/backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml @@ -1,182 +1,207 @@ # Transition Pattern — ISO/IEC 27001 (ISMS) -> CRA (Cyber Resilience Act, Reg. (EU) 2024/2847) -# Curated expert knowledge (NOT runtime code). Belongs to the Reasoning session's -# Knowledge Acquisition responsibility. Consumed later by the Transition Planning Engine -# (RS-005) and the Question Renderer (RS-005.1); rendered into a Transition Interview. +# GOLD-STANDARD structure (the template all future patterns adopt). Curated expert knowledge, +# NOT runtime code. Consumed later by the Transition Planning Engine (RS-005) and Renderer (RS-005.1). id: TP-ISO27001-CRA-v1 -from_state: ISO27001 # ISO/IEC 27001:2022 (organizational ISMS) -to_state: CRA # Regulation (EU) 2024/2847 (product cybersecurity) +status: draft # draft -> reviewed -> approved (auditor review pending) version: 1 -status: draft # draft -> reviewed -> approved (human/auditor review pending) + +transition_goal: + from: + standard: "ISO/IEC 27001" + edition: "2022" + nature: organizational_isms + to: + regulation: "Cyber Resilience Act" + reference: "Regulation (EU) 2024/2847" + applies_from: "2027-12-11" # main obligations + nature: product_cybersecurity + one_line: "Move a manufacturer with a certified ISMS toward CRA conformity for a product with digital elements." + provenance: - author: "Claude (Reasoning session) — first expert draft" - basis: "ISO/IEC 27001:2022 Annex A controls vs CRA Annex I (Part I security requirements, - Part II vulnerability handling) + reporting (Art. 14) + support period (Art. 13) + - conformity assessment / CE / technical documentation (Annex VII)." + author: "Claude (Reasoning session) — first expert draft, gold-standard structure" + basis: "ISO/IEC 27001:2022 Annex A vs CRA Annex I (Part I security requirements, Part II vulnerability handling), Art. 13 (support period), Art. 14 (reporting), conformity assessment + CE + technical documentation (Annex VII)." reviewed_by: null reviewed_at: null disclaimer: > - Expert DRAFT, not a normative or legal proof that these points exactly represent either - standard. KEY ASYMMETRY: ISO 27001 is ORGANIZATIONAL (an ISMS); the CRA is PRODUCT-level - (security of products with digital elements). Therefore an existing ISO 27001 capability - is at most a Welt-1 hint ("probably covered, organizationally") and ALWAYS needs PRODUCT- - level evidence before it counts for the CRA — it is never automatically "erfüllt". + Expert DRAFT, not a normative or legal proof. KEY ASYMMETRY: ISO 27001 is ORGANIZATIONAL (an ISMS); + the CRA is PRODUCT-level. Every assumption below is Welt-1 — a hint that requires PRODUCT-level + evidence, never automatically "erfüllt". Each line is phrased so an auditor can explicitly AGREE or + DISAGREE (not "probably"). -# ────────────────────────────────────────────────────────────────────────── -# A) LIKELY COVERED at the organizational level by a mature ISMS. -# -> status "probably_covered"; each still needs a PRODUCT-level confirmation question. -# ────────────────────────────────────────────────────────────────────────── -likely_covered_org_level: +# How the starting point changes how strongly the assumptions transfer. +source_state_variants: + certified: "ISO 27001 certificate valid AND scope covers the product's development/operations -> assumptions hold at the stated relationship." + isms_introduced: "ISMS implemented but not certified -> downgrade every 'supports' to needs_confirmation." + expired: "Certificate lapsed -> re-verify; treat all assumptions as needs_confirmation." + limited_scope: "Certified scope excludes the product or its dev unit -> assumptions do NOT transfer; treat as missing until scope is confirmed." + +# ── A) LIKELY COVERED (org level). relationship + verification + rationale + reviewable claim. ── +# relationship vocabulary aligns with the Capability Registry (2C): supports | partially_supports +# (never "equivalent" here — an org control is never product-equivalent on its own). +likely_covered: - capability: incident_management iso27001_basis: [A.5.24, A.5.25, A.5.26, A.5.27, A.5.28] - cra_relevance: [Annex_I_Part_II_handling, Art_14_reporting] - reuse_caveat: "An incident process exists organizationally. The CRA delta is PRODUCT incident - handling AND mandatory reporting of actively exploited vulnerabilities / severe incidents to - the CSIRT/ENISA (Art. 14) — that authority-reporting duty has no ISO 27001 analogue." - confirm_question_intent: verify_product_scope - priority: medium + cra_target: [Annex_I_Part_II, Art_14_reporting] + relationship: supports + verification: required + expected_evidence: [incident_response_procedure] + rationale: "ISO 27001 covers ORGANIZATIONAL incident management; the CRA additionally demands PRODUCT vulnerability handling and statutory reporting to CSIRT/ENISA. Hence 'supports', not 'equivalent'." + reviewable_claim: "A certified ISMS provides an incident-management foundation but does NOT by itself satisfy CRA product incident handling or Art. 14 reporting." - capability: technical_vulnerability_management iso27001_basis: [A.8.8] - cra_relevance: [Annex_I_Part_II_2] - reuse_caveat: "Internal vulnerability management is likely in place. The CRA delta is a PRODUCT- - facing process: PSIRT + coordinated vulnerability disclosure + advisories (below)." - confirm_question_intent: verify_product_scope - priority: medium + cra_target: [Annex_I_Part_II_2] + relationship: supports + verification: required + expected_evidence: [vulnerability_management_procedure] + rationale: "Internal vulnerability management exists; the CRA needs a PRODUCT-facing process (PSIRT, coordinated disclosure). Hence 'supports'." + reviewable_claim: "Internal vulnerability management does NOT establish a product PSIRT or CVD." - capability: supplier_security iso27001_basis: [A.5.19, A.5.20, A.5.21, A.5.22] - cra_relevance: [Annex_I_Part_II_1_components] - reuse_caveat: "Supplier security exists; the CRA delta is component-level transparency (SBOM) - and tracking vulnerabilities in third-party / open-source components." - confirm_question_intent: verify_product_scope - priority: medium + cra_target: [Annex_I_Part_II_1_components] + relationship: supports + verification: required + expected_evidence: [supplier_security_policy] + rationale: "Supplier security exists; the CRA needs component-level transparency (SBOM) and tracking third-party/OSS vulnerabilities. Hence 'supports'." + reviewable_claim: "Supplier security does NOT establish an SBOM or component vulnerability tracking." - capability: access_control_and_authentication - iso27001_basis: [A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.5] - cra_relevance: [Annex_I_Part_I_4] - reuse_caveat: "Org access control is mature; the CRA delta is product authentication, no default - credentials, and protection of the product against unauthorized access." - confirm_question_intent: verify_existence - priority: medium + iso27001_basis: [A.5.15, A.5.16, A.5.17, A.5.18, A.8.5] + cra_target: [Annex_I_Part_I_4] + relationship: supports + verification: required + expected_evidence: [access_control_policy] + rationale: "Org access control is mature; the CRA needs product authentication and no default credentials. Hence 'supports'." + reviewable_claim: "Org access control does NOT guarantee product authentication or absence of default credentials." - capability: cryptography iso27001_basis: [A.8.24] - cra_relevance: [Annex_I_Part_I_5, Annex_I_Part_I_6] - reuse_caveat: "Crypto policy exists; the CRA delta is product-level confidentiality (encryption) - and integrity of data, commands, configuration and code." - confirm_question_intent: verify_existence - priority: low + cra_target: [Annex_I_Part_I_5, Annex_I_Part_I_6] + relationship: partially_supports + verification: required + expected_evidence: [cryptography_policy] + rationale: "A crypto policy exists; whether the PRODUCT actually encrypts data and protects integrity is unproven. Hence 'partially_supports'." + reviewable_claim: "A crypto policy does NOT prove product-level confidentiality/integrity." - capability: security_logging_and_monitoring iso27001_basis: [A.8.15, A.8.16] - cra_relevance: [Annex_I_Part_I_12] - reuse_caveat: "Logging/monitoring exists organizationally; the CRA delta is recording security- - relevant events ON the product (with an opt-out)." - confirm_question_intent: verify_existence - priority: low + cra_target: [Annex_I_Part_I_12] + relationship: supports + verification: required + expected_evidence: [logging_concept] + rationale: "Org logging exists; the CRA needs security-relevant events recorded ON the product (with opt-out). Hence 'supports'." + reviewable_claim: "Org logging does NOT prove product security-event logging." - capability: secure_development_lifecycle iso27001_basis: [A.8.25, A.8.27, A.8.28, A.8.29] - cra_relevance: [Annex_I_Part_I_1, Annex_I_Part_II_3] - reuse_caveat: "Secure development exists; the CRA delta is demonstrating secure-by-design product - properties and regular security tests/reviews of the product." - confirm_question_intent: verify_existence - priority: medium + cra_target: [Annex_I_Part_I_1, Annex_I_Part_II_3] + relationship: supports + verification: required + expected_evidence: [secure_development_policy] + rationale: "Secure development exists; the CRA needs demonstrated secure-by-design product properties + regular product security tests. Hence 'supports'." + reviewable_claim: "A secure-development policy does NOT prove CRA secure-by-design product properties." - capability: asset_and_configuration_management iso27001_basis: [A.5.9, A.5.10, A.5.11, A.8.9] - cra_relevance: [Annex_I_Part_II_1_SBOM] - reuse_caveat: "Asset/config management underpins an SBOM but is NOT an SBOM. The SBOM itself is a - delta item (below)." - confirm_question_intent: verify_existence - priority: low + cra_target: [Annex_I_Part_II_1_SBOM] + relationship: partially_supports + verification: required + expected_evidence: [asset_inventory] + rationale: "Asset/config management UNDERPINS an SBOM but is not one. Hence 'partially_supports'; the SBOM itself is a delta item." + reviewable_claim: "Asset/config management does NOT constitute an SBOM." -# ────────────────────────────────────────────────────────────────────────── -# B) DELTA — CRA-specific requirements with NO ISO 27001 analogue. -# -> status "missing" for an ISO-27001-only company; ask these FIRST. -# ────────────────────────────────────────────────────────────────────────── +# ── B) DELTA — CRA-specific, NO ISO 27001 analogue. missing for an ISO-only company; ask first. ── delta_requirements: - capability: sbom_creation - cra_basis: "Annex I, Part II (1) — identify and document components, incl. a software bill of materials." - why_delta: "ISO 27001 has no SBOM requirement." - question_intent: determine_sbom_maturity # enum: never / manual / automatic / continuous + cra_basis: "Annex I, Part II (1) — document components incl. a software bill of materials." + missing_because: "ISO 27001 contains no SBOM requirement." + needed_information: determine_sbom_maturity # enum: never / manual / automatic / continuous expected_evidence: [sbom] priority: high + reviewable_claim: "An ISO-27001-only manufacturer typically has no SBOM." - capability: security_update_support_period - cra_basis: "Art. 13(8) support period (default >= 5 years) + Annex I Part I (3) / Part II (2,7) — provide security updates." - why_delta: "ISO 27001 defines no product support period or update-provision duty." - question_intent: determine_duration + cra_basis: "Art. 13(8) support period (default >= 5 years) + Annex I Part I (3) / Part II (2,7)." + missing_because: "ISO 27001 defines no product support period or update-provision duty." + needed_information: determine_duration expected_evidence: [support_policy, product_lifecycle_policy] priority: high + reviewable_claim: "ISO 27001 does not define a product security-update support period." - capability: secure_signed_update_distribution - cra_basis: "Annex I, Part II (8) — ensure security updates are disseminated securely (authenticity/integrity)." - why_delta: "ISO integrity controls exist, but signed product update distribution is product-specific." - question_intent: verify_existence + cra_basis: "Annex I, Part II (8) — disseminate updates securely (authenticity/integrity)." + missing_because: "Signed PRODUCT update distribution is product-specific, beyond ISO integrity controls." + needed_information: verify_existence expected_evidence: [config_export, test_report] priority: high + reviewable_claim: "ISO 27001 does not require signed product update distribution." - capability: coordinated_vulnerability_disclosure - cra_basis: "Annex I, Part II (5,6) — CVD policy + a contact address for reporting vulnerabilities." - why_delta: "ISO vulnerability management is internal; a product-facing CVD policy / PSIRT is the delta." - question_intent: verify_existence - expected_evidence: [policy] + cra_basis: "Annex I, Part II (5,6) — CVD policy + a reporting contact address." + missing_because: "ISO vulnerability management is internal, not a product-facing CVD/PSIRT." + needed_information: verify_existence + expected_evidence: [cvd_policy] priority: high + reviewable_claim: "ISO 27001 does not require a coordinated vulnerability disclosure policy." - capability: public_security_advisories - cra_basis: "Annex I, Part II (4,7) — publicly disclose information about fixed vulnerabilities; provide advisories." - why_delta: "No ISO 27001 obligation to publish product security advisories." - question_intent: verify_existence - expected_evidence: [policy] + cra_basis: "Annex I, Part II (4,7) — disclose fixed vulnerabilities; provide advisories." + missing_because: "No ISO obligation to publish product security advisories." + needed_information: verify_existence + expected_evidence: [advisory_process] priority: medium + reviewable_claim: "ISO 27001 does not require public product security advisories." - capability: exploited_vuln_and_incident_reporting - cra_basis: "Art. 14 — report actively exploited vulnerabilities and severe incidents to CSIRT/ENISA (24h early warning, 72h notification, final report)." - why_delta: "No ISO 27001 analogue; this is a statutory authority-reporting duty with fixed deadlines." - question_intent: verify_existence - expected_evidence: [policy, ticket] + cra_basis: "Art. 14 — report actively exploited vulnerabilities + severe incidents to CSIRT/ENISA (24h early warning, 72h notification, final report)." + missing_because: "Statutory authority-reporting with fixed deadlines; no ISO 27001 analogue." + needed_information: verify_existence + expected_evidence: [reporting_procedure] priority: high + reviewable_claim: "ISO 27001 does not establish CRA Art. 14 authority reporting." - capability: secure_by_default_no_default_credentials - cra_basis: "Annex I, Part I (2,4) — secure default configuration; no default passwords / forced change." - why_delta: "A product property, not an ISMS control." - question_intent: verify_existence + cra_basis: "Annex I, Part I (2,4) — secure default configuration; no default passwords." + missing_because: "A product property, not an ISMS control." + needed_information: verify_existence expected_evidence: [config_export, test_report] priority: medium - - - capability: attack_surface_minimization - cra_basis: "Annex I, Part I (10,11) — limit attack surfaces; mitigate exploitation." - why_delta: "Product hardening property; not an ISO 27001 control." - question_intent: verify_existence - expected_evidence: [test_report, pentest] - priority: medium + reviewable_claim: "ISO 27001 does not guarantee secure-by-default product configuration." - capability: product_cyber_risk_assessment - cra_basis: "Annex I + technical documentation — cybersecurity risk assessment of the PRODUCT." - why_delta: "ISO 27001 risk assessment is organizational; the CRA needs a product cyber risk assessment." - question_intent: verify_existence - expected_evidence: [test_report, audit_log] + cra_basis: "Annex I + technical documentation — cybersecurity risk assessment OF THE PRODUCT." + missing_because: "ISO 27001 risk assessment is organizational, not a product cyber risk assessment." + needed_information: verify_existence + expected_evidence: [product_risk_assessment] priority: high + reviewable_claim: "An organizational risk assessment is not a CRA product cyber risk assessment." - capability: ce_conformity_assessment_and_technical_documentation cra_basis: "Conformity assessment + CE marking + EU Declaration of Conformity + technical documentation (Annex VII)." - why_delta: "An ISO 27001 certificate is NOT a CRA conformity assessment; the product-compliance dossier is the delta." - question_intent: request_evidence - expected_evidence: [test_report, audit_log] + missing_because: "An ISO 27001 certificate is NOT a CRA conformity assessment." + needed_information: request_evidence + expected_evidence: [technical_documentation, declaration_of_conformity] priority: high + reviewable_claim: "An ISO 27001 certificate does not satisfy CRA conformity assessment." -# Suggested ask-order for an ISO-27001-only manufacturer moving to the CRA: -ask_order_rationale: > - Ask the delta first — SBOM, support period + secure updates, coordinated vulnerability disclosure, - authority reporting (Art. 14), product cyber risk assessment, and CE conformity / technical - documentation. These have no ISO 27001 analogue and are where the real CRA work sits. The - org-level capabilities above reduce effort but must each be re-scoped and re-evidenced at the - PRODUCT level — never assumed "erfüllt" from the certificate alone. +# ── C) Explicit rejections — keep the certificate from being over-read. ── +rejected_assumptions: + - "ISO 27001 does NOT establish a software bill of materials (SBOM)." + - "ISO 27001 does NOT establish a PSIRT or a coordinated vulnerability disclosure process for the product." + - "ISO 27001 does NOT define a product security-update support period." + - "ISO 27001 does NOT produce CRA conformity assessment / CE marking / technical documentation." + - "ISO 27001 does NOT cover Art. 14 reporting of exploited vulnerabilities to CSIRT/ENISA." + - "ISO 27001 does NOT guarantee secure-by-default product configuration or absence of default credentials." -review_required: - - "Validate CRA Annex/Article references with counsel before customer use (indicative here)." - - "Confirm the MCAP capability ids once the Capability Registry assigns them (placeholders here)." - - "Have an ISO 27001 lead auditor sanity-check the likely_covered vs delta split." +determinism_goal: > + Two independent ISO 27001 lead auditors reading this pattern should arrive at the SAME set of delta + questions for the same product. If they do not, the pattern is not yet gold standard. + +review_checklist: + - "Validate every CRA Annex/Article reference with counsel before customer use (indicative here)." + - "Replace capability ids with the Capability Registry MCAP ids once assigned (placeholders here)." + - "Have an ISO 27001 lead auditor confirm the likely_covered vs delta split + each rationale." + - "Confirm each likely_covered item's relationship (supports vs partially_supports) and verification need." diff --git a/backend-compliance/reference_scenarios/generate.py b/backend-compliance/reference_scenarios/generate.py index 1fd1faff..68e53270 100644 --- a/backend-compliance/reference_scenarios/generate.py +++ b/backend-compliance/reference_scenarios/generate.py @@ -34,6 +34,11 @@ from compliance.capability import ( EvidenceKind, mint_capability, evaluate_relation, ) from compliance.reasoning.enums import Confidence +from compliance.transition_reasoning import ( + TransitionContext, TransitionGoal, TargetType, TargetRequirement, assess_transition, +) +import os +import yaml Row = Tuple[str, str, str] OUT: List[str] = [] @@ -235,6 +240,55 @@ coverage_table([ ("cap ↔ MCAP Linking", "TODO", "zwei Vokabulare unverbunden → RS-003"), ]) +# ── Scenario 4 — Transition (RS-005 Planning Engine + Knowledge Pattern) ─── +w("## Szenario 4 — Transition ISO27001 → CRA (RS-005 + Pattern TP-ISO27001-CRA-v1)") +w("") +w('_Frage: „Ich bin ISO27001-zertifiziert — was fehlt mir für den CRA?"_') +w("") +_pat_path = os.path.join(os.path.dirname(__file__), "..", "knowledge", "transition_patterns", + "transition_pattern_iso27001_to_cra_v1.yaml") +with open(_pat_path, encoding="utf-8") as _f: + PAT = yaml.safe_load(_f) +# „habe": ISO27001 -> the pattern's likely_covered capabilities become INFERRED via Company 2A +_iso_caps = [a["capability"] for a in PAT["likely_covered"]] +_iso_map = {"ISO27001": CapabilityMappingEntry(capability_ids=_iso_caps, confidence=Confidence.MEDIUM)} +_profile = build_company_profile( + CompanyContext(company_id="iso-kunde", certifications=[Certification(certification_id="ISO27001")]), _iso_map) +# „required": likely_covered + delta -> TargetRequirements (here read from the pattern) +_reqs = [TargetRequirement(capability_id=a["capability"], question_intent="verify_existence", + expected_evidence=a.get("expected_evidence", [])) for a in PAT["likely_covered"]] +_reqs += [TargetRequirement(capability_id=d["capability"], question_intent=d.get("needed_information", "verify_existence"), + expected_evidence=d.get("expected_evidence", [])) for d in PAT["delta_requirements"]] +_tc = TransitionContext(company_id="iso-kunde", known_certifications=["ISO27001"], + target=TransitionGoal(target_id="CRA", target_type=TargetType.REGULATION, + label=PAT["transition_goal"]["to"]["regulation"])) +_a = assess_transition(_tc, _reqs, _profile) +w("**Input:** ISO27001-zertifiziert (Pattern TP-ISO27001-CRA-v1) → %d ISMS-Capabilities inferred; Ziel CRA." % len(_iso_caps)) +w("") +w("**Expected Transition Assessment (RS-005 v0 gegen den Pattern):**") +w("> Ziel %s · %s" % (_a.target_id, _a.summary.headline)) +w("") +w("**Delta zuerst (HIGH — fehlt einem ISO-27001-only-Hersteller):**") +for _r in _a.question_requests: + if _r.priority.value == "high": + w("- `%s` — intent=%s, Nachweis=%s" % (_r.capability_id, _r.question_intent, _r.expected_evidence)) +w("") +w("**Aus ISO27001 vermutlich abgedeckt (Produkt-Nachweis bestätigen):** %s" % ", ".join(_a.summary.probably_covered)) +w("") +_carried = len(_a.coverage) == len(_reqs) and len(_a.question_requests) > 0 +_n_high = sum(1 for _r in _a.question_requests if _r.priority.value == "high") +w("**Architektur-Test — trägt RS-005 den Pattern vollständig?** %d Pattern-Capabilities → %d Coverage + %d Question-Requests → **%s**." + % (len(_reqs), len(_a.coverage), len(_a.question_requests), "ja, vollständig getragen" if _carried else "NICHT vollständig")) +w("") +coverage_table([ + ("Pattern-Load (YAML)", "PASS", "TP-ISO27001-CRA-v1 (draft, gold-standard)"), + ("Company 2A (habe)", "PASS", "ISO27001 → %d inferred caps" % len(_a.summary.probably_covered)), + ("RS-005 Planning Engine", "PASS" if _carried else "PARTIAL", "Pattern → TransitionQuestionRequests"), + ("Transition ISO27001→CRA", "PASS" if _carried else "PARTIAL", + "%d Delta-Fragen (HIGH) + %d zu bestätigen" % (_n_high, len(_a.summary.probably_covered))), + ("RS-005.1 Renderer (Fragetext)", "TODO", "verschoben — Engine liefert nur Requests"), +]) + # ── Epics + roll-up ─────────────────────────────────────────────────────── w("## Gaps → Epics (Backlog — nur erfasst, NICHT implementiert)") w("") diff --git a/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md b/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md index 8c8fdabb..607dc560 100644 --- a/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md +++ b/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md @@ -145,6 +145,40 @@ _ILLUSTRATIVES Mapping: ISO27001 -> incident_response, supplier_management, asse | Master Capability Registry | **PASS** | computed confidence, policy-versioniert | | cap ↔ MCAP Linking | **TODO** | zwei Vokabulare unverbunden → RS-003 | +## Szenario 4 — Transition ISO27001 → CRA (RS-005 + Pattern TP-ISO27001-CRA-v1) + +_Frage: „Ich bin ISO27001-zertifiziert — was fehlt mir für den CRA?"_ + +**Input:** ISO27001-zertifiziert (Pattern TP-ISO27001-CRA-v1) → 8 ISMS-Capabilities inferred; Ziel CRA. + +**Expected Transition Assessment (RS-005 v0 gegen den Pattern):** +> Ziel CRA · 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus. + +**Delta zuerst (HIGH — fehlt einem ISO-27001-only-Hersteller):** +- `ce_conformity_assessment_and_technical_documentation` — intent=request_evidence, Nachweis=['technical_documentation', 'declaration_of_conformity'] +- `coordinated_vulnerability_disclosure` — intent=verify_existence, Nachweis=['cvd_policy'] +- `exploited_vuln_and_incident_reporting` — intent=verify_existence, Nachweis=['reporting_procedure'] +- `product_cyber_risk_assessment` — intent=verify_existence, Nachweis=['product_risk_assessment'] +- `public_security_advisories` — intent=verify_existence, Nachweis=['advisory_process'] +- `sbom_creation` — intent=determine_sbom_maturity, Nachweis=['sbom'] +- `secure_by_default_no_default_credentials` — intent=verify_existence, Nachweis=['config_export', 'test_report'] +- `secure_signed_update_distribution` — intent=verify_existence, Nachweis=['config_export', 'test_report'] +- `security_update_support_period` — intent=determine_duration, Nachweis=['support_policy', 'product_lifecycle_policy'] + +**Aus ISO27001 vermutlich abgedeckt (Produkt-Nachweis bestätigen):** incident_management, technical_vulnerability_management, supplier_security, access_control_and_authentication, cryptography, security_logging_and_monitoring, secure_development_lifecycle, asset_and_configuration_management + +**Architektur-Test — trägt RS-005 den Pattern vollständig?** 17 Pattern-Capabilities → 17 Coverage + 17 Question-Requests → **ja, vollständig getragen**. + +**Architecture Coverage** + +| Layer | Status | Hinweis | +|---|---|---| +| Pattern-Load (YAML) | **PASS** | TP-ISO27001-CRA-v1 (draft, gold-standard) | +| Company 2A (habe) | **PASS** | ISO27001 → 8 inferred caps | +| RS-005 Planning Engine | **PASS** | Pattern → TransitionQuestionRequests | +| Transition ISO27001→CRA | **PASS** | 9 Delta-Fragen (HIGH) + 8 zu bestätigen | +| RS-005.1 Renderer (Fragetext) | **TODO** | verschoben — Engine liefert nur Requests | + ## Gaps → Epics (Backlog — nur erfasst, NICHT implementiert) | Epic | Titel | schliesst Coverage-Luecke | @@ -156,6 +190,6 @@ _ILLUSTRATIVES Mapping: ISO27001 -> incident_response, supplier_management, asse ## Suite-Status (Roll-up) -- Coverage-Zellen gesamt: **20** -- PASS: **13** · PARTIAL: 3 · UNSUPPORTED: 1 · TODO: 2 · N/A: 1 · NEEDS_FACTS: 0 +- Coverage-Zellen gesamt: **25** +- PASS: **17** · PARTIAL: 3 · UNSUPPORTED: 1 · TODO: 3 · N/A: 1 · NEEDS_FACTS: 0 - Fortschritt = PASS-Anteil steigt, wenn Epics RS-001…004 landen (objektiver Maßstab, kein LOC).