docs: add security evidence structure

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: Your Name

.github/copilot-instructions.md

@@ -260,13 +260,13 @@ Diese Regeln gelten für alle Repositories in diesem Workspace. Projektspezifisc
 - 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.
 - Bei Bedrohungsmodellen `STRIDE` als Basis und bei risikoreichen Flows zusätzlich relevante `CAPEC`-Patterns verwenden.
 - Bei Web/API-Features den `ASVS`-Level und den Verifikationsumfang in `docs/security/` oder gleichwertiger Projektdokumentation ablegen.
 - Bei Release-/Artefakt-Arbeit `SBOM`, `VEX`, Provenance/SLSA-Nachweise und gegebenenfalls `OpenSSF Scorecard` in Release- oder Sicherheitsdokumentation einplanen.
 - Bei Architekturänderungen `Zero Trust`-Anwendbarkeit und bei langlebigen Projekten `SAMM`-Folgeaktionen prüfen.
+- Default-Evidenzpfad: `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, `docs/security/samm-assessment.md`; Abweichungen nur mit lokal dokumentierter Begründung.
 
-*Capture the applicable standards and the evidence path in `spec.md`, `plan.md`, and `tasks.md`. Use `STRIDE` as the base for threat modeling and add relevant `CAPEC` patterns for the highest-risk flows. For web/API work, record the chosen `ASVS` level and verification scope in `docs/security/` or equivalent project documentation. For release and artefact work, plan `SBOM`, `VEX`, provenance/SLSA evidence, and `OpenSSF Scorecard` review where applicable. For architectural changes, evaluate `Zero Trust`; for long-lived projects, consider `OWASP SAMM` follow-up actions.*
+*Capture the applicable standards and the evidence path in `spec.md`, `plan.md`, and `tasks.md`. Use `STRIDE` as the base for threat modeling and add relevant `CAPEC` patterns for the highest-risk flows. For web/API work, record the chosen `ASVS` level and verification scope in `docs/security/` or equivalent project documentation. For release and artefact work, plan `SBOM`, `VEX`, provenance/SLSA evidence, and `OpenSSF Scorecard` review where applicable. For architectural changes, evaluate `Zero Trust`; for long-lived projects, consider `OWASP SAMM` follow-up actions. The default evidence path is `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, and `docs/security/samm-assessment.md`, unless the repository documents a justified equivalent location.*

.specify/memory/constitution.md

@@ -1,20 +1,21 @@
 <!--
 Sync Impact Report
-Version change: 1.10.0 -> 1.11.0
+Version change: 1.11.0 -> 1.12.0
 Modified principles:
 - None (purely additive)
 Added sections:
-- XIV. Secure Development Standards & Applicability Matrix
-- XV. Secure SDLC & Verification Standards
-- XVI. Supply-Chain Transparency & Build Integrity
-- XVII. Threat Modeling & Attack Pattern Coverage
-- XVIII. Zero Trust Applicability & Security Program Maturity
+- None
 Removed sections:
 - None
 Templates requiring updates:
 - ✅ .specify/templates/plan-template.md
 - ✅ .specify/templates/spec-template.md
 - ✅ .specify/templates/tasks-template.md
+- ✅ .specify/templates/asvs-verification-template.md
+- ✅ .specify/templates/supply-chain-evidence-template.md
+- ✅ .specify/templates/zero-trust-applicability-template.md
+- ✅ .specify/templates/samm-assessment-template.md
+- ✅ .specify/templates/threat-model-template.md
 Runtime guidance requiring updates:
 - ✅ AGENTS.md
 - ✅ CLAUDE.md
@@ -25,7 +26,7 @@ Follow-up TODOs:
 - None
 -->
 
-# Constitution v1.11.0
+# Constitution v1.12.0
 
 # home-baseline Constitution
 
@@ -514,6 +515,15 @@ Mandatory rules:
 - Where a standard applies, the implementation evidence MUST be reflected in
   the relevant artefacts: `spec.md`, `plan.md`, `tasks.md`, `docs/security/`,
   S-ADRs, release assets, or CI/CD configuration as appropriate.
+- The default evidence location for Level-2 projects is `docs/security/` using
+  the canonical filenames and templates defined in `.specify/templates/`.
+  A repository MAY use an equivalent governance location only when
+  `docs/security/` would be structurally inappropriate; in that case the
+  alternative location MUST be explicitly linked from `docs/security/README.md`
+  or equivalent repository-local index documentation.
+- Level-1 workspaces SHOULD also prefer `docs/security/` for security-governance
+  evidence. If a workspace uses another governance document or directory, the
+  chosen location MUST be stated in its local security index.
 
 **Rationale**: Secure-development standards are often partially remembered and
 selectively applied. A binding applicability matrix keeps teams, agents, and
@@ -544,6 +554,9 @@ Mandatory rules:
 - Web/API projects MUST record the selected ASVS level and verification scope
   in `docs/security/` (for example as an ASVS verification matrix or
   equivalent repository-local format).
+- Web/API projects MUST maintain an ASVS evidence document using
+  `asvs-verification-template.md` or an equivalent repository-local format that
+  captures scope, selected level, covered controls, gaps, and follow-up work.
 - `OWASP Cheat Sheet Series` and `OWASP Proactive Controls` SHOULD be used as
   day-to-day implementation guidance wherever language/framework standards do
   not already provide stricter or more specific rules.
@@ -576,6 +589,10 @@ Mandatory rules:
   source of repository security posture evidence) before release or adoption.
 - 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
+  `supply-chain-evidence-template.md` or an equivalent repository-local format.
+  That document MUST reference the current SBOM, VEX decisions, provenance or
+  SLSA status, and any relevant OpenSSF Scorecard observations.
 
 **Rationale**: A project can follow secure coding rules and still ship opaque
 or tampered artefacts. SBOM, VEX, SLSA, and Scorecard address transparency,
@@ -598,6 +615,9 @@ Mandatory rules:
   sensitive data flows, or third-party integrations materially change.
 - Security-relevant mitigations and residual risks identified through STRIDE
   or CAPEC analysis SHOULD be reflected in S-ADRs, checklists, and tasks.
+- Threat-model evidence SHOULD capture CAPEC references directly in the threat
+  model document, not only in ADRs or tasks, so the attacker-technique mapping
+  stays reviewable in one place.
 
 **Rationale**: STRIDE is strong for systematic coverage of threat categories;
 CAPEC complements it by adding attacker behavior and attack-pattern language.
@@ -626,6 +646,12 @@ Mandatory rules:
 - Findings from incidents, audits, dependency reviews, and SAMM assessments
   SHOULD feed back into templates, checklists, security docs, and AI-agent
   guidance files so improvements become structural rather than one-off fixes.
+- Systems where Zero Trust applicability is material SHOULD maintain a
+  dedicated applicability note using `zero-trust-applicability-template.md` or
+  an equivalent repository-local format.
+- Repositories performing periodic SAMM reviews SHOULD maintain their current
+  assessment snapshot and follow-up actions using `samm-assessment-template.md`
+  or an equivalent repository-local format.
 
 **Rationale**: Zero Trust addresses the realities of remote access, services,
 and cloud deployment; SAMM addresses the maturity of the development program
@@ -722,7 +748,7 @@ allowed path.
 `.github/copilot-instructions.md` for per-agent operational guidance. This
 constitution is the authoritative policy layer above all agent-specific files.
 
-**Version**: 1.11.0 | **Ratified**: 2026-03-31 | **Last Amended**: 2026-04-24
+**Version**: 1.12.0 | **Ratified**: 2026-03-31 | **Last Amended**: 2026-04-24
 
 <!-- EN: constitution.md placeholder
 [DE-Zusammenfassung: constitution.md beschreibt die Prinzipien und Standards für alle home-baseline Workspaces.]

.specify/templates/adr-template.md

@@ -0,0 +1,96 @@
+# ADR-[NNN]: [Titel der Entscheidung / Decision Title]
+
+**Status**: [Vorgeschlagen / Proposed | Akzeptiert / Accepted | Veraltet / Deprecated | Ersetzt / Superseded by ADR-XXX]
+**Datum / Date**: [YYYY-MM-DD]
+**Entscheider / Deciders**: [Namen oder Rollen / Names or roles]
+**Constitution-Referenz / Constitution Reference**: [Principle XII / XIII / I / ...]
+**ISO-Referenz / ISO Reference**: [z. B. A.8.27, A.8.28, A.8.25]
+
+## Kontext / Context
+
+<!--
+  Beschreibe das Problem oder die Situation, die eine architektonische Entscheidung
+  erfordert. Welche Sicherheitsanforderungen sind betroffen? Welche Bedrohungen oder
+  Risiken motivieren die Entscheidung?
+
+  Describe the problem or situation requiring an architectural decision. What security
+  requirements are affected? What threats or risks motivate the decision?
+-->
+
+[Kontext hier beschreiben / Describe context here]
+
+## Entscheidung / Decision
+
+<!--
+  Beschreibe die gewählte Lösung klar und konkret. Verwende aktive Sprache:
+  "Wir verwenden..." / "We use..."
+
+  Describe the chosen solution clearly and concretely. Use active voice:
+  "We use..." / "Wir verwenden..."
+-->
+
+[Entscheidung hier beschreiben / Describe decision here]
+
+## Begründung / Rationale
+
+<!--
+  Warum wurde diese Option gewählt? Wie adressiert sie die Sicherheitsanforderungen?
+  Welche Constitution-Prinzipien werden damit erfüllt?
+
+  Why was this option chosen? How does it address security requirements?
+  Which constitution principles does it satisfy?
+-->
+
+[Begründung hier / Rationale here]
+
+## Alternativen / Alternatives Considered
+
+<!--
+  Welche anderen Optionen wurden betrachtet und warum wurden sie verworfen?
+
+  What other options were considered and why were they rejected?
+-->
+
+### Alternative 1: [Name]
+
+- **Beschreibung / Description**: [Kurzbeschreibung]
+- **Verworfen weil / Rejected because**: [Grund]
+
+### Alternative 2: [Name]
+
+- **Beschreibung / Description**: [Kurzbeschreibung]
+- **Verworfen weil / Rejected because**: [Grund]
+
+## Konsequenzen / Consequences
+
+### Positiv / Positive
+
+- [Sicherheitsvorteil / Security benefit]
+- [Architekturvorteil / Architecture benefit]
+
+### Negativ / Negative
+
+- [Einschränkung oder Aufwand / Limitation or effort]
+- [Technische Schuld / Technical debt]
+
+### Residualrisiken / Residual Risks
+
+- [Verbleibendes Risiko trotz Mitigation / Remaining risk despite mitigation]
+
+## Compliance-Nachweis / Compliance Evidence
+
+| Constitution Principle | Erfüllt / Satisfied | Nachweis / Evidence |
+|---|---|---|
+| I. Security-First | [Ja/Nein/N/A] | [Kurzbeschreibung] |
+| XII. Secure Code Generation | [Ja/Nein/N/A] | [Kurzbeschreibung] |
+| XIII. Secure Software Architecture | [Ja/Nein/N/A] | [Kurzbeschreibung] |
+
+## Verknüpfte Dokumente / Related Documents
+
+- Threat Model: [Link oder Pfad / Link or path]
+- Spec: [Link oder Pfad]
+- Plan: [Link oder Pfad]
+
+<!-- EN: adr-template.md
+[DE-Zusammenfassung: Template fuer Security Architecture Decision Records (S-ADR), ISO 27002 A.8.27, iSAQB-aligned.]
+-->