chore: propagate security guidance from home-baseline v1.12.0

- Sicherheitsdokumentation section updated to (XII-XVIII Extensions) with all 10 templates
- Sicherheitsstandards section expanded with Principle XIX (EU Cyber Resilience Act)
- setup-git-identity Known Pitfall added to CLAUDE.md
- constitution.md: Principles XVI (SBOM all levels + automated tooling),
  XVII (CIA matrix mandatory), XIX (EU CRA) synced

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: hindermath

.github/copilot-instructions.md

@@ -228,18 +228,23 @@ Diese Regeln gelten für alle Repositories in diesem Workspace. Projektspezifisc
 - Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
 
 *AI-generated and human-written software architecture MUST follow secure-architecture principles. Authoritative rules: `constitution.md`, Principle XIII. Core principles: trust boundaries (validate all input at system boundaries), defense in depth (at least two independent security layers), least privilege (minimum required permissions), fail-safe defaults (deny by default), attack surface reduction (disable unused features), separation of concerns (auth/logging/validation as cross-cutting concerns), secure configuration (secrets in secret stores, never in code or Git), supply-chain security (verified registries, lock files, no known-vulnerable dependencies). Principles XII + XIII together form the complete secure-development approach: XII = tactical code-level security, XIII = strategic architecture-level security. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
-## Sicherheitsdokumentation / Security Documentation (XII/XIII Extensions)
+## Sicherheitsdokumentation / Security Documentation (XII–XVIII Extensions)
 
 - Jedes Level-2-Projekt MUSS die folgenden Sicherheitsdokumente pflegen, basierend auf den Templates in `.specify/templates/`:
-  - **Bedrohungsmodell / Threat Model** (`threat-model-template.md`) — STRIDE-Methodik, Trust Boundaries, Risikobewertung (Prinzip XIII)
+  - **Bedrohungsmodell / Threat Model** (`threat-model-template.md`) — STRIDE-Methodik, Trust Boundaries, Risikobewertung, CAPEC-Referenzen (Prinzip XIII + XVII)
   - **Security Architecture Decision Records (S-ADR)** (`adr-template.md`) — architektonische Sicherheitsentscheidungen mit Compliance-Nachweis (Prinzip XIII)
   - **arc42 Section 8 Sicherheits-Querschnittskonzepte** (`arc42-security-template.md`) — Authentifizierung, Autorisierung, Verschlüsselung, Eingabevalidierung, Fehlerbehandlung, Logging, Abhängigkeiten, Deployment (Prinzip XIII)
   - **Sicherheits-Checkliste / Security Checklist** (`security-checklist-template.md`) — sprachspezifische Code-Review-Checkliste (Prinzip XII)
   - **Abhängigkeits-Audit / Dependency Audit** (`dependency-audit-template.md`) — CVE-Tracking, Lizenz-Compliance, Supply-Chain-Sicherheit (Prinzip XII)
   - **Sicherheits-Qualitätsszenarien / Security Quality Scenarios** (`security-quality-scenarios-template.md`) — iSAQB CPSA-F Qualitätsszenario-Methodik (Prinzip XII + XIII, SHOULD)
+  - **ASVS-Verifikation / ASVS Verification** (`asvs-verification-template.md`) — OWASP ASVS Level, Scope und Evidenz (Prinzip XV, Web-/API-Projekte MUST)
+  - **Supply-Chain-Evidenz / Supply Chain Evidence** (`supply-chain-evidence-template.md`) — SBOM, VEX, SLSA, OpenSSF Scorecard (Prinzip XVI, releasefähige Projekte MUST)
+  - **Zero-Trust-Anwendbarkeit / Zero Trust Applicability** (`zero-trust-applicability-template.md`) — NIST SP 800-207-Bewertung (Prinzip XVIII, verteilte Systeme SHOULD)
+  - **SAMM-Bewertung / SAMM Assessment** (`samm-assessment-template.md`) — OWASP SAMM Reifegrad und Verbesserungsplan (Prinzip XVIII, langlebige Projekte SHOULD)
 - Projektspezifische Instanzen werden in `docs/security/` gepflegt; S-ADRs als einzelne Dateien in `docs/security/adr/`.
 
-*Every Level-2 project MUST maintain security documents based on templates in `.specify/templates/`: threat model (STRIDE), S-ADRs, arc42 Section 8 security concepts, security checklist, dependency audit, and security quality scenarios (SHOULD). Project-specific instances live in `docs/security/`; S-ADRs in `docs/security/adr/`. See `constitution.md`, Principles XII and XIII for authoritative requirements.*
+*Every Level-2 project MUST maintain security documents based on templates in `.specify/templates/`: threat model (STRIDE+CAPEC), S-ADRs, arc42 Section 8 security concepts, security checklist, dependency audit, security quality scenarios (SHOULD), ASVS verification (web/API MUST), supply-chain evidence (release-capable MUST), Zero Trust applicability note (distributed systems SHOULD), and SAMM assessment (long-lived projects SHOULD). Project-specific instances live in `docs/security/`; S-ADRs in `docs/security/adr/`. See `constitution.md`, Principles XII–XVIII for authoritative requirements.*
+
 ## Gemeinsame Governance-Ergaenzung / Shared Governance Addendum
 
 - Alle nutzerseitigen Artefakte muessen barrierefrei gedacht und geprueft werden: CLI-Ausgaben, Dokumentation, HTML, UI und generierte Templates; WCAG 2.2 Level AA ist die Standard-Basis, sobald die Kriterien auf das Artefakt anwendbar sind.

.specify/memory/constitution.md

@@ -572,9 +572,13 @@ Secure development MUST include transparency about what is shipped and how it
 was produced.
 
 Mandatory rules:
-- Every release-capable or distributable Level-2 project MUST generate a
-  machine-readable `SBOM` for each released artefact set. The SBOM MAY be
-  stored as a release asset and/or mirrored in `docs/security/`.
+- Every release-capable or distributable project at ALL workspace levels
+  (Level-0, Level-1, Level-2) MUST generate a machine-readable `SBOM` for
+  each released artefact set. SBOM generation is mandatory regardless of
+  whether the SBOM is published externally. The SBOM MAY be stored as a
+  release asset and/or in `docs/security/`. This reflects the forthcoming
+  requirements of the EU Cyber Resilience Act (CRA) and established industry
+  best practice.
 - When a released or evaluated component has a known vulnerability that is
   relevant to consumers or reviewers, the project MUST publish or record a
   `VEX`-style status statement indicating whether the product is affected,
@@ -587,6 +591,18 @@ Mandatory rules:
 - Public OSS repositories and the adoption of high-impact external
   dependencies SHOULD consider `OpenSSF Scorecard` findings (or an equivalent
   source of repository security posture evidence) before release or adoption.
+- Dependency tracking SHOULD use automated tooling in preference to manual
+  static documentation. Preferred approaches:
+  - **Automated update PRs**: Renovatebot or Dependabot SHOULD be configured
+    to open PRs automatically for outdated or vulnerable dependencies. This is
+    established best practice for all projects regardless of level.
+  - **Continuous SBOM/CVE tracking**: Tools such as Dependency Track (which
+    accepts SBOM artefacts from CI pipelines and continuously monitors CVE
+    status and license compliance) SHOULD be preferred over periodic manual
+    audits wherever the project's hosting infrastructure supports it.
+  - Static dependency audit documents (`dependency-audit-template.md`) serve
+    as supplementary evidence for release decisions, exceptions, and risk
+    acceptance — not as a replacement for automated tooling.
 - Dependency, SBOM, VEX, provenance, and Scorecard evidence MUST feed into the
   repository's dependency audit and release review process.
 - Release-capable projects MUST maintain a supply-chain evidence document using
@@ -597,13 +613,21 @@ Mandatory rules:
 **Rationale**: A project can follow secure coding rules and still ship opaque
 or tampered artefacts. SBOM, VEX, SLSA, and Scorecard address transparency,
 integrity, and supplier trustworthiness across the software supply chain.
+Automated tooling (Renovatebot/Dependabot, Dependency Track) dramatically
+reduces the manual overhead of dependency management and removes the gap
+between policy and enforcement that static documentation cannot close.
 
 ### XVII. Threat Modeling & Attack Pattern Coverage
 
 Threat modeling MUST describe both what the system values and how it can be
 attacked.
 
 Mandatory rules:
+- Every Level-2 threat model MUST include an **asset inventory with a CIA
+  matrix** (Confidentiality/Integrity/Availability, rated High/Medium/Low/Not
+  applicable). The CIA rating determines protection requirements and informs
+  STRIDE prioritisation: assets rated High in Confidentiality or Integrity
+  MUST be addressed with at least Defense-in-Depth controls (Principle XIII).
 - Every Level-2 threat model MUST use `STRIDE` as the base categorization
   scheme, as already required by Principle XIII.
 - Threat models SHOULD reference relevant `CAPEC` attack patterns for the
@@ -658,6 +682,46 @@ and cloud deployment; SAMM addresses the maturity of the development program
 itself. Together they keep security architecture and security process moving
 forward instead of freezing at a one-time baseline.
 
+### XIX. EU Cyber Resilience Act (CRA) Compliance Awareness
+
+Software placed on the EU market is subject to the Cyber Resilience Act
+(Regulation (EU) 2024/2847), which establishes mandatory cybersecurity
+requirements for products with digital elements. This principle requires
+that all workspace projects maintain awareness of CRA applicability and
+align their practices accordingly.
+
+Mandatory rules:
+- All projects MUST assess whether their software qualifies as a "product
+  with digital elements" under the CRA (commercial sale, licensing, or
+  free distribution for economic purposes within the EU market). Even
+  open-source projects distributed for economic benefit may fall in scope.
+- CRA-scoped projects MUST generate SBOMs for each released version (see
+  Principle XVI — this requirement applies at all levels for this reason).
+- CRA-scoped projects MUST implement a documented vulnerability disclosure
+  and handling process. Actively exploited vulnerabilities MUST be reported
+  to relevant authorities within 24 hours and patched within established
+  deadlines per the CRA.
+- CRA-scoped projects MUST document their conformity assessment approach
+  (self-assessment for most products; third-party assessment for critical
+  or important products under Annex III/IV of the CRA).
+- All projects SHOULD align security practices with CRA principles
+  regardless of formal scope applicability, as the CRA reflects emerging
+  industry baseline expectations for secure software development:
+  secure-by-design, secure-by-default, vulnerability management, lifecycle
+  transparency, and SBOM availability.
+- The CRA applicability decision MUST be recorded in `docs/security/` or
+  equivalent governance documentation (e.g., as a note in the supply-chain
+  evidence document or a dedicated S-ADR).
+
+**Rationale**: The EU Cyber Resilience Act (in force since December 2024,
+with compliance deadlines phased through 2027) is the most significant
+EU regulatory development in software security since GDPR. It codifies
+many existing best practices — SBOM, vulnerability disclosure, secure
+development lifecycle, security-by-design — as legal obligations for
+software placed on the EU market. Recording CRA applicability and aligning
+practices proactively reduces legal and reputational risk and builds on the
+security work already required by Principles XII–XVIII.
+
 ## Level-2 Project Environment Registry / Level-2-Projektumgebungsregister
 
 This registry consolidates the constitution-relevant Level-2 project facts

AGENTS.md

@@ -213,18 +213,23 @@ Each machine runs InventarWorkerService (REST agent)
 - Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
 
 *AI-generated and human-written software architecture MUST follow secure-architecture principles. Authoritative rules: `constitution.md`, Principle XIII. Core principles: trust boundaries (validate all input at system boundaries), defense in depth (at least two independent security layers), least privilege (minimum required permissions), fail-safe defaults (deny by default), attack surface reduction (disable unused features), separation of concerns (auth/logging/validation as cross-cutting concerns), secure configuration (secrets in secret stores, never in code or Git), supply-chain security (verified registries, lock files, no known-vulnerable dependencies). Principles XII + XIII together form the complete secure-development approach: XII = tactical code-level security, XIII = strategic architecture-level security. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
-## Sicherheitsdokumentation / Security Documentation (XII/XIII Extensions)
+## Sicherheitsdokumentation / Security Documentation (XII–XVIII Extensions)
 
 - Jedes Level-2-Projekt MUSS die folgenden Sicherheitsdokumente pflegen, basierend auf den Templates in `.specify/templates/`:
-  - **Bedrohungsmodell / Threat Model** (`threat-model-template.md`) — STRIDE-Methodik, Trust Boundaries, Risikobewertung (Prinzip XIII)
+  - **Bedrohungsmodell / Threat Model** (`threat-model-template.md`) — STRIDE-Methodik, Trust Boundaries, Risikobewertung, CAPEC-Referenzen (Prinzip XIII + XVII)
   - **Security Architecture Decision Records (S-ADR)** (`adr-template.md`) — architektonische Sicherheitsentscheidungen mit Compliance-Nachweis (Prinzip XIII)
   - **arc42 Section 8 Sicherheits-Querschnittskonzepte** (`arc42-security-template.md`) — Authentifizierung, Autorisierung, Verschlüsselung, Eingabevalidierung, Fehlerbehandlung, Logging, Abhängigkeiten, Deployment (Prinzip XIII)
   - **Sicherheits-Checkliste / Security Checklist** (`security-checklist-template.md`) — sprachspezifische Code-Review-Checkliste (Prinzip XII)
   - **Abhängigkeits-Audit / Dependency Audit** (`dependency-audit-template.md`) — CVE-Tracking, Lizenz-Compliance, Supply-Chain-Sicherheit (Prinzip XII)
   - **Sicherheits-Qualitätsszenarien / Security Quality Scenarios** (`security-quality-scenarios-template.md`) — iSAQB CPSA-F Qualitätsszenario-Methodik (Prinzip XII + XIII, SHOULD)
+  - **ASVS-Verifikation / ASVS Verification** (`asvs-verification-template.md`) — OWASP ASVS Level, Scope und Evidenz (Prinzip XV, Web-/API-Projekte MUST)
+  - **Supply-Chain-Evidenz / Supply Chain Evidence** (`supply-chain-evidence-template.md`) — SBOM, VEX, SLSA, OpenSSF Scorecard (Prinzip XVI, releasefähige Projekte MUST)
+  - **Zero-Trust-Anwendbarkeit / Zero Trust Applicability** (`zero-trust-applicability-template.md`) — NIST SP 800-207-Bewertung (Prinzip XVIII, verteilte Systeme SHOULD)
+  - **SAMM-Bewertung / SAMM Assessment** (`samm-assessment-template.md`) — OWASP SAMM Reifegrad und Verbesserungsplan (Prinzip XVIII, langlebige Projekte SHOULD)
 - Projektspezifische Instanzen werden in `docs/security/` gepflegt; S-ADRs als einzelne Dateien in `docs/security/adr/`.
 
-*Every Level-2 project MUST maintain security documents based on templates in `.specify/templates/`: threat model (STRIDE), S-ADRs, arc42 Section 8 security concepts, security checklist, dependency audit, and security quality scenarios (SHOULD). Project-specific instances live in `docs/security/`; S-ADRs in `docs/security/adr/`. See `constitution.md`, Principles XII and XIII for authoritative requirements.*
+*Every Level-2 project MUST maintain security documents based on templates in `.specify/templates/`: threat model (STRIDE+CAPEC), S-ADRs, arc42 Section 8 security concepts, security checklist, dependency audit, security quality scenarios (SHOULD), ASVS verification (web/API MUST), supply-chain evidence (release-capable MUST), Zero Trust applicability note (distributed systems SHOULD), and SAMM assessment (long-lived projects SHOULD). Project-specific instances live in `docs/security/`; S-ADRs in `docs/security/adr/`. See `constitution.md`, Principles XII–XVIII for authoritative requirements.*
+
 ## Sicherheitsstandards & Anwendbarkeit / Security Standards & Applicability
 
 - Vor jeder Level-2-Aufgabe die anwendbaren Sicherheitsstandards aus `constitution.md`, Prinzipien XIV-XVIII bestimmen und explizit benennen.
@@ -237,6 +242,7 @@ Each machine runs InventarWorkerService (REST agent)
 - Nichtanwendbarkeit immer als `N/A` mit kurzer Begründung dokumentieren; keine stillschweigende Auslassung.
 
 *At the start of every Level-2 task, determine and name the applicable security standards from `constitution.md`, Principles XIV-XVIII. `NIST SSDF` and `CWE Top 25` always apply. `OWASP ASVS` applies to web/API/HTTP/auth-bearing services; `SBOM` applies to releasable or distributable artefacts; `VEX` applies when known vulnerabilities in shipped/evaluated components need a disposition statement. `SLSA` is the target model for CI/CD and published artefacts; `Zero Trust` must be explicitly evaluated for distributed, service-based, cloud, or remotely managed systems. `CAPEC`, `OWASP SAMM`, `OWASP Cheat Sheet Series`, `OWASP Proactive Controls`, and `OpenSSF Scorecard` are supporting references where relevant. Record non-applicability as `N/A` with justification rather than omitting it silently.*
+
 ## Agentischer Security-Workflow / Agentic Security Workflow
 
 - In `spec.md`, `plan.md` und `tasks.md` die anwendbaren Standards samt Evidenzpfad festhalten.