@metasession.co/devaudit-cli 0.1.35 → 0.1.37

package/sdlc/files/_common/skills/governance-doc-author/references/incident-classification.md

@@ -0,0 +1,84 @@
+# Incident Classification — framework attribution decision tree
+
+Used by both `e2e-test-engineer` (when filing defects) and `governance-doc-author` (when authoring the project-level incident-report template). Single source of truth so the two skills don't drift.
+
+## Decision tree
+
+Every `incident_report` evidence row closes `ISO29119.3.5.4` (baseline). Additional clauses depend on the incident's scope.
+
+| Defect / incident characteristic | Frameworks/clauses attributed |
+|---|---|
+| **Any test failure / defect** (baseline — always) | `ISO29119.3.5.4` Test incident report |
+| **Ops impact** (downtime, persistent errors, perf regression, data corruption) | + `SOC2.CC7.2` System monitoring and incident response |
+| **Security vulnerability** (auth bypass, injection, data exposure beyond GDPR scope) | + `SOC2.CC7.2` + relevant ISO 27001 controls |
+| **Personal data exposed / lost / mishandled** | + `GDPR.Art-33` (always — supervisory authority within 72h) + `GDPR.Art-34` (when data subjects need notification per Art. 34(1)) |
+| **AI/ML failure** (model hallucination, biased output, oversight bypass, transparency failure) | + relevant EU AI Act articles (`Art-9` risk, `Art-14` human oversight, `Art-15` accuracy/robustness) |
+
+## Baseline rule
+
+The first row is **mandatory**: every incident_report attributes to `ISO29119.3.5.4` no matter what else applies. The "no specific framework impact" case (a regular bug with no PII, no security, no ops impact) still produces a valid incident_report closing the baseline — never a silently-dropped report.
+
+## Conditional rules
+
+The remaining rows are conditional. Tick the matching characteristic; ensure the corresponding section of the incident-report template is non-stub before commit.
+
+### Ops impact
+
+Signals: production downtime, sustained error-rate elevation, perf regression measured in p95 or SLO breaches, data corruption.
+
+If yes:
+- §1 Summary must name the affected systems + duration
+- §3 Affected scope must include user-count estimate
+- §6 Containment must name what was done to mitigate
+
+### Security vulnerability
+
+Signals: auth bypass, injection (SQL / NoSQL / template / OS), broken access control, secrets in logs / git, dependency CVE exploit path.
+
+If yes:
+- §5 Root cause must name the vulnerability class (OWASP / CWE id where applicable)
+- §7 Follow-up actions must include the regression test that prevents recurrence
+- Security lead listed in §8 Sign-off
+
+### Personal data exposed / lost / mishandled (GDPR)
+
+Signals: any unauthorised disclosure of personal data, data loss without backup, data sent to unintended recipients, retention exceeded, lawful-basis collapse.
+
+If yes:
+- §4 GDPR triage **must** be fully filled: data subject count, data categories, special-category-data Y/N
+- Art. 33: notification to supervisory authority within 72h of awareness → document timestamp + sent-to in §2 Timeline
+- Art. 34: notification to data subjects when likely to result in HIGH risk → document the decision (with rationale) in §4
+- DPO listed in §8 Sign-off
+
+### AI/ML failure (EU AI Act)
+
+Signals: model produced incorrect / biased / harmful output that reached a user; oversight gate bypassed; accuracy / robustness regression in production.
+
+If yes:
+- §5 Root cause must name the model + invocation path + what guardrail failed
+- §7 Follow-up actions must include the change to the AI oversight path (Art. 14)
+- Cross-link to `compliance/governance/ai-disclosure.md` from §1 Summary
+
+## Worked examples
+
+### Example 1 — Non-PII, non-security defect
+
+A unit-conversion bug in a public-facing page rounds metric prices incorrectly. Discovered via failing e2e. No data exposure, no ops impact beyond cosmetic, no AI involved.
+
+**Attribution:** `ISO29119.3.5.4` only.
+
+The incident-report is still valid and load-bearing — without it the test incident clause stays MISSING. Don't pad with false GDPR / security ticks.
+
+### Example 2 — PII exposure via misconfigured RLS policy
+
+A Supabase RLS policy was deployed with a typo causing users to see other users' application details (name, email, application status). Found by an e2e regression test. No financial impact, no service downtime — but ~3,000 users were affected over a 6-hour window.
+
+**Attribution:** `ISO29119.3.5.4` + `SOC2.CC7.2` (incident response invoked) + `GDPR.Art-33` (supervisory authority notified within 72h) + `GDPR.Art-34` (data subjects notified — risk threshold met).
+
+§4 GDPR triage filled: 3,000 affected, categories = name + email + application metadata, no special-category data, Art-34 notification sent within 72h via in-app banner + email.
+
+## Cross-references
+
+- `e2e-test-engineer/SKILL.md` Phase 6 (Filing defects) — uses this table when filing a defect that meets incident criteria.
+- `governance-doc-author/SKILL.md` Phase 6 — uses this table when authoring the project-level `incident-report.md` template.
+- `compliance/governance/incident-report.md.template` — Framework attribution section embeds the same conditional checklist.

package/sdlc/files/_common/skills/sdlc-implementer/SKILL.md

@@ -148,7 +148,18 @@ Reached only on the **tracked** route from Phase 0 (the issue is already fetched
 2. **Classify risk** per `Test_Policy.md` §Risk-Based Testing. Emit a one-paragraph rationale citing the signals you used (auth surface, financial calc, data egress, RBAC, AI decisioning, etc.).
 3. **Assign REQ-XXX.** Inspect `compliance/RTM.md` for existing entries; take the next free number. If the issue references an existing REQ, use that instead.
 4. **Detect over-scoping.** If the issue spans clearly distinct deliverables (e.g. "build SAML SSO + reorganise the admin dashboard + migrate from Postgres 14 to 16"), halt with a clear message asking the user to split the issue into separate ones. Do not proceed past Phase 1.
-5. **Write the implementation plan.** Create `compliance/plans/REQ-XXX/implementation-plan.md` per the stage-1 template (sections: context, acceptance criteria, technical approach, security considerations, dependencies, test scope). For HIGH/CRITICAL also include: threat model (against STRIDE categories applicable to the touched surfaces), four-eyes attestation slot, rollback plan.
+5. **Write the implementation plan.** Create `compliance/plans/REQ-XXX/implementation-plan.md` from `sdlc/files/_common/Implementation_Plan_TEMPLATE.md` (synced into the consumer's `SDLC/` directory at install). The template's shape is load-bearing — it carries the **Framework attribution** section that closes four framework clauses on upload:
+
+   | Clause | What the plan must contain |
+   |---|---|
+   | **ISO 29119 §3.4** Test Plan | Acceptance criteria + verification strategy per AC. |
+   | **ISO 27001 A.8.25** Secure SDLC | Threat model + secrets / dependency considerations. |
+   | **GDPR Art. 25** Data protection by design | Per-purpose data flows + lawful basis + retention. Explicit "no personal data" callout if not applicable. |
+   | **EU AI Act Art. 11** Technical documentation | Model provenance + oversight path when AI is in scope. Explicit "no AI in scope" callout if not. |
+
+   For HIGH/CRITICAL also include: threat model (against STRIDE categories applicable to the touched surfaces), four-eyes attestation slot, rollback plan — the template has slots for all of these.
+
+   **Don't delete sections** — mark with `N/A — <reason>` if a clause genuinely doesn't apply (e.g. UI-only change with no personal-data scope). Empty stubs commit-then-upload as placeholder evidence and break the audit trail.
 6. **Update `compliance/RTM.md`** with the new entry: REQ-XXX, title, risk class, linked issue, linked test cases (placeholder).
 7. **Post plan summary as an issue comment.** Format: TL;DR; Risk class + signals; Acceptance criteria; Technical approach (one paragraph); Dependencies; Test scope.
 8. **Checkpoint** — pause for human approval **iff** risk class is HIGH or CRITICAL. LOW and MEDIUM pass through to Phase 2 automatically. The checkpoint can be forced on for all classes via the `--require-plan-approval` flag (or `DEVAUDIT_REQUIRE_PLAN_APPROVAL=1` env var) for orgs that want it always-on.

package/sdlc/files/ci/periodic-review.yml.template

@@ -210,9 +210,62 @@ jobs:
           # Open PR (or update existing).
           EXISTING=$(gh pr list --head "${BRANCH}" --json number --jq '.[0].number' || true)
           if [ -z "$EXISTING" ]; then
+            # Two-part PR body:
+            # 1. The 60% operator-fill checklist with per-clause attribution
+            # 2. The auto-filled section list (40% workflow-derived)
+            # Both are inline so the reviewer can tick boxes and the
+            # auto-generated half stays visible. Per-clause links use the
+            # consumer's portal base URL — fall back to the SDLC docs when
+            # DEVAUDIT_BASE_URL isn't set in the workflow env.
+            BASE="${DEVAUDIT_BASE_URL:-https://github.com/metasession-dev/DevAudit-Installer/blob/main/docs/governance-templates.md}"
+            PR_BODY=$(cat <<PRBODY
+Auto-generated quarterly periodic-review for **${REVIEW_ID}** by the \`Periodic Review\` workflow.
+
+## What auto-filled (~40%)
+
+- Review-period metrics: releases shipped, gate pass rate, SAST + dependency findings, audit-log volume, open issues
+- Frontmatter (\`review_id\`, period dates, generated_at)
+- Section 2 control-area headers wired to the right framework clauses
+
+## What still needs the operator (~60%)
+
+Each item below corresponds to a section of the doc. **Tick the box once the section is non-stub** — leaving REPLACE markers in place will fail audit review and the merge bar.
+
+### §3 Review notes
+- [ ] Qualitative observations on the review period (≥2 sentences; no \`REPLACE\` text remaining)
+- [ ] Cross-reference any incidents from this period (\`compliance/governance/incident-report-*.md\`)
+
+### §4 Control-effectiveness judgement
+*Closes \`SOC2.CC4.1\` + \`ISO27001.A.12.1\` only when ALL control areas have a non-stub judgement.*
+
+- [ ] Access control (ISO 27001 A.5.15) — effective / partially / not + 1-line evidence
+- [ ] Secure SDLC (ISO 27001 A.8.25) — judgement + evidence
+- [ ] Secure coding (ISO 27001 A.8.28) — judgement + evidence (SAST + dep-audit pass rate)
+- [ ] Security testing (ISO 27001 A.8.29) — judgement + evidence (E2E pass rate)
+- [ ] Change management (ISO 27001 A.8.32 + SOC 2 CC8.1) — judgement + evidence (four-eyes approvals count)
+- [ ] Monitoring activities (ISO 27001 A.8.16 + EU AI Act Art. 12) — judgement + evidence (audit-log volume / coverage)
+
+### §5 Follow-up actions
+- [ ] Each material finding → owner → due date (or "none for this period" stated explicitly)
+- [ ] Carry-over actions from last quarter's review → status updated
+
+### §6 Sign-off
+- [ ] Reviewer name + date (must be different from the actor who made code changes that the review is judging)
+- [ ] Approver name + date (when \`risk_tier\` is medium or higher — dual-actor required)
+
+## Closes once merged
+
+- \`SOC2.CC4.1\` (Monitoring of internal controls)
+- \`ISO27001.A.12.1\` (Operational procedures and responsibilities)
+
+Verify at \`${BASE}/projects/<slug>/compliance\` after the PR-merge push lands on develop — both clauses should flip MISSING → COVERED within ~2 minutes. Stays COVERED for 365 days (portal's \`freshnessDays\`), then flips to EXPIRED until the next quarterly review.
+
+See [\`docs/governance-templates.md\`](https://github.com/metasession-dev/DevAudit-Installer/blob/main/docs/governance-templates.md#soc-2--trust-services-criteria) for full guidance.
+PRBODY
+)
             gh pr create --base develop --head "${BRANCH}" \
               --title "chore(compliance): periodic review ${REVIEW_ID}" \
-              --body "Auto-generated quarterly periodic-review for **${REVIEW_ID}** by the \`Periodic Review\` workflow.\n\n**Required before merge:**\n- [ ] Replace \`REPLACE — …\` markers in the **Review notes** section\n- [ ] Fill in control-effectiveness judgement for each control area\n- [ ] Add reviewer + approver names (dual-actor)\n- [ ] List follow-up actions with owners + dates\n\nSee [\`docs/governance-templates.md\`](https://github.com/metasession-dev/DevAudit-Installer/blob/main/docs/governance-templates.md#soc-2--trust-services-criteria) (SDLC repo) for guidance.\n\nCloses \`SOC2.CC4.1\` + \`ISO27001.A.12.1\` for the period once the PR lands on develop."
+              --body "$PR_BODY"
           else
             echo "PR #${EXISTING} already open for this period — branch updated in place."
           fi