@blamejs/exceptd-skills 0.20.1 → 0.21.0

package/data/playbooks/post-quantum-migration.json

@@ -158,7 +158,7 @@
         },
         {
           "jurisdiction": "AU",
-          "regulation": "ACSC ISM-1546 / ISM-0457",
+          "regulation": "ACSC ISM-0471 / ISM-2073",
           "obligation": "submit_approved_algorithm_attestation",
           "window_hours": 8760,
           "clock_starts": "manual",
@@ -232,7 +232,7 @@
         }
       ],
       "framework_context": {
-        "gap_summary": "Frameworks treat PQC migration as policy + algorithm-selection rather than as a per-asset migration programme with enforceable deadlines. NIST 800-53 SC-13 cites FIPS-validated modules without distinguishing classical-only validations from FIPS 203/204/205 PQC validations; SC-8 does not require hybrid KEX. ISO 27001:2022 A.8.24 was published before FIPS 203/204/205 finalisation and has no scheduled amendment. PCI DSS 4.0 §3.6/§4.2.1 defines 'strong cryptography' with classical minimums, no PQC obligation for cardholder data with > 10y retention. NIS2 Art.21(2)(h) names cryptography as essential measure but defers algorithm specifics to implementing acts not yet published. DORA Art.9 inherits NIS2's gap. EU CRA Annex I uses 'state-of-the-art' as the standard, leaving PQC binding to interpretation. The US federal cycle is further along (CNSA 2.0 2027 deadline, OMB M-23-02 annual inventory, NIST SP 800-227 PQC-transition recommendations, NIST IR 8547 published migration roadmap) but the 800-53 control catalogue is unchanged. AU ISM-1546 transitions to PQC quarterly via approved-algorithm list updates but ISM remains advisory rather than binding for non-federal entities. The result: an organisation with no asset inventory, no per-asset migration plan, no vendor SLA, and no exposure-window analysis can satisfy every framework's literal language while being HNDL-vulnerable today across its long-retention data surface.",
+        "gap_summary": "Frameworks treat PQC migration as policy + algorithm-selection rather than as a per-asset migration programme with enforceable deadlines. NIST 800-53 SC-13 cites FIPS-validated modules without distinguishing classical-only validations from FIPS 203/204/205 PQC validations; SC-8 does not require hybrid KEX. ISO 27001:2022 A.8.24 was published before FIPS 203/204/205 finalisation and has no scheduled amendment. PCI DSS 4.0 §3.6/§4.2.1 defines 'strong cryptography' with classical minimums, no PQC obligation for cardholder data with > 10y retention. NIS2 Art.21(2)(h) names cryptography as essential measure but defers algorithm specifics to implementing acts not yet published. DORA Art.9 inherits NIS2's gap. EU CRA Annex I uses 'state-of-the-art' as the standard, leaving PQC binding to interpretation. The US federal cycle is further along (CNSA 2.0 2027 deadline, OMB M-23-02 annual inventory, NIST SP 800-227 PQC-transition recommendations, NIST IR 8547 published migration roadmap) but the 800-53 control catalogue is unchanged. AU ISM-1917 requires new cryptographic products to support ML-DSA-87 and ML-KEM-1024 by 2030 and ISM-2073 requires a transition plan, but neither sets a date for systems already deployed, and the ISM binds Australian Government entities while remaining voluntary for private organizations. The result: an organisation with no asset inventory, no per-asset migration plan, no vendor SLA, and no exposure-window analysis can satisfy every framework's literal language while being HNDL-vulnerable today across its long-retention data surface.",
         "lag_score": 365,
         "per_framework_gaps": [
           {
@@ -297,9 +297,9 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-0457 / ISM-1546",
-            "designed_for": "Approved cryptographic algorithms for protecting Australian Government information.",
-            "insufficient_because": "ISM transition guidance is advisory in 2026-05. Quarterly publishing cadence lags FIPS 203/204/205 finalisation. Approved-algorithm list mixes classical and PQC entries without binding migration deadlines."
+            "control_id": "ISM-0471 / ISM-2073",
+            "designed_for": "ISM-0471 requires cryptographic equipment, applications and libraries to use only ASD-Approved Cryptographic Algorithms or high assurance algorithms; ISM-2073 requires a post-quantum cryptography transition plan, and ISM-1917 requires new cryptographic products to support ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by no later than 2030.",
+            "insufficient_because": "ISM-0471 still accepts classical approved algorithms, ISM-1917's 2030 date binds new development and procurement only, and ISM-2073 requires a plan without a date for deployed systems, so an organization with classical key exchange everywhere is compliant today while its long-retention data is exposed to harvest-now-decrypt-later collection. None of the three is in an Essential Eight maturity profile."
           },
           {
             "framework": "sg-mas-trm",
@@ -337,7 +337,7 @@
         "monitor": 45,
         "close": 25
       },
-      "framework_lag_declaration": "NIST 800-53 SC-12/SC-13, ISO 27001:2022 A.8.24/A.8.25, PCI DSS 4.0 §3.6/§4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I, UK CAF B3, AU ISM-0457/1546, SG MAS TRM §11.1, HIPAA §164.312(a)(2)(iv) all permit fully-classical cryptographic posture as compliant. NIST itself is the exception via NIST IR 8547 + FIPS 203/204/205 + OMB M-23-02 + CNSA 2.0 — but the 800-53 control catalogue is unchanged. ISO 27001:2022 was published before PQC finalisation and has no scheduled amendment. PCI Council and EU regulators publicly aware but have not amended binding controls. Lag = ~365 days behind operational PQC readiness (FIPS 203/204/205 finalised 2024-08-13) and 5-15 years behind the CRQC horizon that drives HNDL. Compensating controls (per-asset inventory + per-asset migration plan + vendor SLA + exposure-window analysis + downgrade-detection monitoring) must close this programme-level gap before SLA-only compliance can be accepted. None of the frameworks in scope require any of those five compensating controls.",
+      "framework_lag_declaration": "NIST 800-53 SC-12/SC-13, ISO 27001:2022 A.8.24/A.8.25, PCI DSS 4.0 §3.6/§4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I, UK CAF B3, AU ISM-0471/2073, SG MAS TRM §11.1, HIPAA §164.312(a)(2)(iv) all permit fully-classical cryptographic posture as compliant. NIST itself is the exception via NIST IR 8547 + FIPS 203/204/205 + OMB M-23-02 + CNSA 2.0 — but the 800-53 control catalogue is unchanged. ISO 27001:2022 was published before PQC finalisation and has no scheduled amendment. PCI Council and EU regulators publicly aware but have not amended binding controls. Lag = ~365 days behind operational PQC readiness (FIPS 203/204/205 finalised 2024-08-13) and 5-15 years behind the CRQC horizon that drives HNDL. Compensating controls (per-asset inventory + per-asset migration plan + vendor SLA + exposure-window analysis + downgrade-detection monitoring) must close this programme-level gap before SLA-only compliance can be accepted. None of the frameworks in scope require any of those five compensating controls.",
       "skill_chain": [
         {
           "skill": "pqc-first",
@@ -803,7 +803,7 @@
         {
           "finding_id": "pqc-migration-programme-failure",
           "framework": "au-ism",
-          "claimed_control": "ISM-0457 / ISM-1546 — Approved cryptographic algorithms / Transition",
+          "claimed_control": "ISM-0471 / ISM-2073: approved cryptographic algorithms / post-quantum transition plan",
           "actual_gap": "ISM transition guidance advisory; quarterly cadence lags FIPS 203/204/205. Mixed classical + PQC approved-algorithm list without binding migration deadlines.",
           "required_control": "ISM update binding PQC migration deadlines per data classification + per asset class; per-Department register submission cadence aligned to ACSC quarterly cycle."
         },
@@ -1120,7 +1120,7 @@
         "lesson_template": {
           "attack_vector": "Harvest-now-decrypt-later at the programme level: operator has no per-asset register, no per-asset migration target, no vendor SLA, no downgrade detection, no regulator-deadline orchestration. Adversary records classical-encrypted traffic against operator's whole estate today; CRQC-day decryption recovers data across the full retention horizon.",
           "control_gap": "Frameworks treat PQC migration as policy + algorithm selection rather than as a per-asset migration programme. None require per-asset register + sunset dates + vendor SLAs + downgrade detection as a binding control set.",
-          "framework_gap": "NIST SC-12/SC-13, ISO A.8.24/A.8.25, PCI 3.6/4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I, UK CAF B3, AU ISM-0457/1546, SG MAS TRM §11.1, HIPAA §164.312(a)(2)(iv) all permit classical-only posture as compliant. Federal cycle (CNSA 2.0, OMB M-23-02, NIST SP 800-227, NIST IR 8547) further along but commercial framework cadence ~365 days behind operational PQC readiness.",
+          "framework_gap": "NIST SC-12/SC-13, ISO A.8.24/A.8.25, PCI 3.6/4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I, UK CAF B3, AU ISM-0471/2073, SG MAS TRM §11.1, HIPAA §164.312(a)(2)(iv) all permit classical-only posture as compliant. Federal cycle (CNSA 2.0, OMB M-23-02, NIST SP 800-227, NIST IR 8547) further along but commercial framework cadence ~365 days behind operational PQC readiness.",
           "new_control_requirement": "Add a 'cryptographic migration programme' sub-control across the eleven framework controls listed above requiring: (a) per-asset cryptographic register with mandatory fields, (b) per-vendor SLA naming PQC delivery date, (c) per-asset classical sunset date preceding retention horizon, (d) downgrade-detection control on every hybrid-configured asset, (e) per-jurisdiction regulator-deadline tracker refreshed at publication cadence, (f) annual programme review against published CRQC estimates and FIPS PQC standard amendments."
         },
         "feeds_back_to_skills": [
@@ -1188,14 +1188,14 @@
           "draft_notification": "CNSA 2.0 NSS PQC migration attestation: ${nss_entity} attests PQC migration status for NSS systems. Systems migrated: ${nss_migrated_count}. Systems on documented exception register: ${nss_exception_count}. Remediation milestones for unmigrated systems: ${remediation_milestones}."
         },
         {
-          "obligation_ref": "AU/ACSC ISM-1546 / ISM-0457 8760h",
+          "obligation_ref": "AU/ACSC ISM-0471 / ISM-2073 8760h",
           "deadline": "computed_at_runtime",
           "recipient": "internal_legal",
           "evidence_attached": [
             "approved_algorithm_register",
             "transition_plan_for_non_approved_algorithms"
           ],
-          "draft_notification": "ACSC ISM approved-algorithm attestation: ${au_entity} attests per-asset alignment with ISM-0457 approved-algorithm list and ISM-1546 transition guidance. Assets on approved-algorithm list: ${approved_count}. Assets with documented transition plan: ${transition_plan_count}. Quarterly review cycle: ${quarterly_cycle_date}."
+          "draft_notification": "ACSC ISM approved-algorithm attestation: ${au_entity} attests per-asset alignment with the ISM-0471 approved-algorithm requirement and the ISM-2073 post-quantum transition plan. Assets on approved-algorithm list: ${approved_count}. Assets with documented transition plan: ${transition_plan_count}. Quarterly review cycle: ${quarterly_cycle_date}."
         },
         {
           "obligation_ref": "DE/BSI TR-02102 (German Federal Office for Information Security) 8760h",

package/data/playbooks/ransomware.json

@@ -351,9 +351,9 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1554 (Incident response plan is exercised)",
-            "designed_for": "Tabletop / live exercise of the incident response plan.",
-            "insufficient_because": "Exercise frequency is named; exercise content is not. A generic IR tabletop satisfies ISM-1554 without ever rehearsing the sanctions-screening blocker on a ransom decision."
+            "control_id": "ISM-1784 (incident response plan exercised at least annually)",
+            "designed_for": "ISM-1784 requires the cyber security incident management policy, including its incident response plan, to be exercised at least annually.",
+            "insufficient_because": "Exercise frequency is named; exercise content is not. A generic IR tabletop satisfies ISM-1784 without ever rehearsing the sanctions-screening blocker on a ransom decision."
           },
           {
             "framework": "hipaa",

package/data/playbooks/runtime.json

@@ -213,8 +213,8 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1382",
-            "designed_for": "Australian Government ISM control on privileged-account management and audit.",
+            "control_id": "ISM-1509",
+            "designed_for": "ISM-1509 requires privileged access events to be centrally logged, and is in the Essential Eight profile from Maturity Level Two.",
             "insufficient_because": "Audit cadence anchors on account creation/modification events. Persistent SUID/cron drift between audits does not trigger an event, so the control's audit trail can be clean while the host state is not."
           }
         ]
@@ -235,7 +235,7 @@
         "monitor": 65,
         "close": 35
       },
-      "framework_lag_declaration": "NIST CM-7 + AC-6, ISO A.8.2 + A.8.18, and NIS2 Art.21(2)(i) treat least-privilege and least-functionality as policy outcomes reviewable annually. They do not require programmatic enumeration of the specific primitives (sudoers NOPASSWD, non-baseline SUID, world-writable cron, host-mounted systemd services, listening sockets on non-loopback) that attackers use to convert foothold into root. A host can be CM-7/AC-6 compliant on paper while presenting dozens of LPE primitives to a landed attacker. Gap = ~21 days between drift and policy review at typical orgs; for fast-moving environments (containerized + GitOps-deployed), drift accumulates faster than annual review can catch. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat least-privilege as a system-security outcome assessable through control-design evidence, without binding to per-host enumeration of LPE primitives (sudoers NOPASSWD, non-baseline SUID, writable cron, host-mount services). AU Essential 8 ML2 Restrict Admin Privileges (E8 M.5) + Patch Operating Systems (E8 M.2) plus ACSC ISM-1175 (privilege management) and ISM-1490 (application control) cover admin-account and application-execution policy, but Essential 8 maturity evidence does not enumerate the specific runtime primitives that convert foothold into root.",
+      "framework_lag_declaration": "NIST CM-7 + AC-6, ISO A.8.2 + A.8.18, and NIS2 Art.21(2)(i) treat least-privilege and least-functionality as policy outcomes reviewable annually. They do not require programmatic enumeration of the specific primitives (sudoers NOPASSWD, non-baseline SUID, world-writable cron, host-mounted systemd services, listening sockets on non-loopback) that attackers use to convert foothold into root. A host can be CM-7/AC-6 compliant on paper while presenting dozens of LPE primitives to a landed attacker. Gap = ~21 days between drift and policy review at typical orgs; for fast-moving environments (containerized + GitOps-deployed), drift accumulates faster than annual review can catch. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat least-privilege as a system-security outcome assessable through control-design evidence, without binding to per-host enumeration of LPE primitives (sudoers NOPASSWD, non-baseline SUID, writable cron, host-mount services). AU Essential 8 ML2 Restrict Admin Privileges (E8 M.5) + Patch Operating Systems (E8 M.2) plus ACSC ISM-1175 (privileged accounts kept off the internet, email and web services) and ISM-1490 (application control on internet-facing servers) cover admin-account and application-execution policy, but Essential 8 maturity evidence does not enumerate the specific runtime primitives that convert foothold into root.",
       "skill_chain": [
         {
           "skill": "attack-surface-pentest",

package/data/playbooks/sbom.json

@@ -427,8 +427,8 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1546",
-            "designed_for": "Australian Government ISM control on software supply-chain risk management for sourced software.",
+            "control_id": "ISM-1452",
+            "designed_for": "ISM-1452 requires a supply chain risk assessment for suppliers of operating systems, applications, IT equipment, OT equipment and services, to assess their impact on a system's security risk profile.",
             "insufficient_because": "Control evidence is sourced-software-centric. Open-source transitive dependencies and AI-coding-assistant-emitted code are not 'sourced' under the ISM's evidence model; the control cannot bind their integrity."
           }
         ]
@@ -448,7 +448,7 @@
         "monitor": 50,
         "close": 30
       },
-      "framework_lag_declaration": "Supply-chain frameworks have advanced fastest of any class in this exceptd release, but implementation gaps are pervasive. NIST 800-53 SA-12, NIST 800-218 SSDF, ISO 27001:2022 A.8.30/A.5.20, SOC 2 CC9.2, PCI DSS 4.0 sect.6.3, NIS2 Art.21(2)(d), DORA Art.28, EU CRA Art.13/14 all permit (a) SBOM as deliverable without continuous correlation, (b) lockfile-pinning without integrity hash, (c) direct-deps-only SBOM, (d) absence of VEX statements, (e) absence of AI-generated-code provenance, (f) model weights treated as content blobs. Lag = ~90 days behind operational tooling (SLSA / Sigstore / in-toto / VEX-CSAF) and ~210 days behind AI-coding-assistant adoption tempo. Compensating controls (continuous CVE correlation, integrity-pinned lockfiles, transitive SBOM completeness, VEX maintenance, AI-code provenance, model weight signature verification + safetensors-only loading) MUST close the gap before SBOM-as-deliverable compliance can be accepted. UK CAF Principles B5 (Resilient Networks & Systems) and D1 (Response and Recovery Planning) treat supply-chain assurance and recovery readiness as outcomes, with no Principle binding continuous CVE correlation against the shipped SBOM or VEX maintenance as evidence. AU Essential 8 ML2 Patch Applications (E8 M.2) plus ACSC ISM-0717 (supply-chain risk management) and ISM-1657 (vendor assessment) cover supply-chain due diligence, but Essential 8 patch-tempo evidence accepts vendor advisories without requiring SBOM-driven transitive-CVE correlation or AI-generated-code provenance.",
+      "framework_lag_declaration": "Supply-chain frameworks have advanced fastest of any class in this exceptd release, but implementation gaps are pervasive. NIST 800-53 SA-12, NIST 800-218 SSDF, ISO 27001:2022 A.8.30/A.5.20, SOC 2 CC9.2, PCI DSS 4.0 sect.6.3, NIS2 Art.21(2)(d), DORA Art.28, EU CRA Art.13/14 all permit (a) SBOM as deliverable without continuous correlation, (b) lockfile-pinning without integrity hash, (c) direct-deps-only SBOM, (d) absence of VEX statements, (e) absence of AI-generated-code provenance, (f) model weights treated as content blobs. Lag = ~90 days behind operational tooling (SLSA / Sigstore / in-toto / VEX-CSAF) and ~210 days behind AI-coding-assistant adoption tempo. Compensating controls (continuous CVE correlation, integrity-pinned lockfiles, transitive SBOM completeness, VEX maintenance, AI-code provenance, model weight signature verification + safetensors-only loading) MUST close the gap before SBOM-as-deliverable compliance can be accepted. UK CAF Principles B5 (Resilient Networks & Systems) and D1 (Response and Recovery Planning) treat supply-chain assurance and recovery readiness as outcomes, with no Principle binding continuous CVE correlation against the shipped SBOM or VEX maintenance as evidence. AU Essential 8 ML2 Patch Applications (E8 M.2) plus ACSC ISM-1452 (supply chain risk assessment) and ISM-1567 (suppliers rated high risk are not used) cover supply-chain due diligence, but Essential 8 patch-tempo evidence accepts vendor advisories without requiring SBOM-driven transitive-CVE correlation or AI-generated-code provenance.",
       "skill_chain": [
         {
           "skill": "supply-chain-integrity",

package/data/playbooks/secrets.json

@@ -247,15 +247,15 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1546",
-            "designed_for": "Multi-factor authentication for privileged users and remote access.",
-            "insufficient_because": "ISM-1546 covers human authentication; CI/CD service identities (which now hold the actual privileges) are out of scope. Stolen GitHub Actions OIDC tokens grant identical blast radius without ever crossing the human-MFA gate. Compliance-theater test: list CI runner OIDC token TTLs and audience scopes; any token with TTL > 1h or wildcard audience defeats ISM-1546's intent."
+            "control_id": "ISM-1173",
+            "designed_for": "ISM-1173 requires multi-factor authentication for privileged human users of systems, and is in the Essential Eight profile from Maturity Level Two.",
+            "insufficient_because": "ISM-1173 covers human users; CI/CD service identities (which now hold the actual privileges) are out of scope. Stolen GitHub Actions OIDC tokens grant identical blast radius without ever crossing the human-MFA gate. Compliance-theater test: list CI runner OIDC token TTLs and audience scopes; any token with TTL > 1h or wildcard audience defeats ISM-1173's intent."
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1559",
-            "designed_for": "Privileged account credential management.",
-            "insufficient_because": "ISM-1559 names key/credential storage but treats source-code-embedded credentials as a policy violation, not a detection control. Modern exfiltration reads credentials post-decryption from /proc, container layers, or build artifacts. Compliance-theater test: run a process listing inside one production container and grep env for tokens; any hit means storage encryption was bypassed at the runtime boundary."
+            "control_id": "ISM-2142",
+            "designed_for": "ISM-2142 requires static credentials used by applications and workloads to be centrally managed using a credential or secrets management solution.",
+            "insufficient_because": "ISM-2142 names credential storage but treats source-code-embedded credentials as a policy violation, not a detection control. Modern exfiltration reads credentials post-decryption from /proc, container layers, or build artifacts. Compliance-theater test: run a process listing inside one production container and grep env for tokens; any hit means storage encryption was bypassed at the runtime boundary."
           }
         ]
       },
@@ -273,7 +273,7 @@
         "monitor": 60,
         "close": 30
       },
-      "framework_lag_declaration": "GDPR Art.32, ISO A.8.24, PCI-DSS Req.3, SOC 2 CC6.1 collectively cover encryption + key management + access control in production storage backends. None of them name 'secret in source artifact' as a distinct exposure category, despite this being the dominant 2025-2026 cloud-compromise vector. NIST 800-53 IA-5 (Authenticator Management) lags because it mandates authenticator protection in storage but does not require detection of authenticators committed to source repositories or build artifacts — IA-5 evidence is satisfied by a vault inventory while bearer tokens leak through `.env`, IaC tfvars, and CI logs unscanned. NIS2 Art.21(2)(j) names cryptography but not development-workflow exposure. Gap = ~30 days between developer commit and framework's quarterly access-review cadence; in practice, scraper bots exploit faster than any framework cadence. UK CAF Principle B2 (Identity and Access Control) treats credential lifecycle as an outcome reviewable on cycle, not as a per-commit scanning obligation — secrets embedded in source artifacts do not register against B2 evidence. AU Essential 8 Strategy 1 (Application Control, E8 M.1) is the relevant lever — restricting build agents from accessing arbitrary secret stores or environment variables at build time — but Essential 8 evidence does not enumerate CI-runner secret-store reachability as a sub-control; ISM-1546 covers MFA + admin-account hygiene but bearer tokens / API keys / OAuth refresh tokens in source artifacts bypass MFA entirely, never crossing the interactive auth surface ISM-1546 protects.",
+      "framework_lag_declaration": "GDPR Art.32, ISO A.8.24, PCI-DSS Req.3, SOC 2 CC6.1 collectively cover encryption + key management + access control in production storage backends. None of them name 'secret in source artifact' as a distinct exposure category, despite this being the dominant 2025-2026 cloud-compromise vector. NIST 800-53 IA-5 (Authenticator Management) lags because it mandates authenticator protection in storage but does not require detection of authenticators committed to source repositories or build artifacts — IA-5 evidence is satisfied by a vault inventory while bearer tokens leak through `.env`, IaC tfvars, and CI logs unscanned. NIS2 Art.21(2)(j) names cryptography but not development-workflow exposure. Gap = ~30 days between developer commit and framework's quarterly access-review cadence; in practice, scraper bots exploit faster than any framework cadence. UK CAF Principle B2 (Identity and Access Control) treats credential lifecycle as an outcome reviewable on cycle, not as a per-commit scanning obligation — secrets embedded in source artifacts do not register against B2 evidence. AU Essential 8 Strategy 1 (Application Control, E8 M.1) is the relevant lever — restricting build agents from accessing arbitrary secret stores or environment variables at build time — but Essential 8 evidence does not enumerate CI-runner secret-store reachability as a sub-control; ISM-1173 covers MFA for privileged human users, but bearer tokens / API keys / OAuth refresh tokens in source artifacts bypass MFA entirely, never crossing the interactive auth surface ISM-1173 protects.",
       "skill_chain": [
         {
           "skill": "dlp-gap-analysis",

package/data/playbooks/supply-chain-recovery.json

@@ -80,8 +80,7 @@
     "name": "Post-compromise supply-chain recovery",
     "attack_class": "supply-chain",
     "atlas_refs": [
-      "AML.T0010",
-      "AML.T0016"
+      "AML.T0010"
     ],
     "attack_refs": [
       "T1195.002",

package/data/playbooks/webhook-callback-abuse.json

@@ -233,7 +233,7 @@
         "monitor": 65,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-53 IA-9 + AC-4, ISO 27001 A.5.16, NIS2 Art.21(2)(d), and SOC 2 CC6.6 collectively underspecify the inbound-callback trust boundary. None mandate redirect_uri allowlist hygiene, OAuth state-parameter binding, webhook-signature replay-window enforcement, or per-app webhook-secret isolation. The 2024-2025 Snowflake / Salt Typhoon / GitHub-Apps-secret-leak class incidents would all satisfy a literal reading of these controls. UK CAF B3 (Data security) treats inbound endpoints as part of the perimeter but does not require behaviour-tested signature validation. AU ISM-1551 (web application authentication) names HMAC signatures but not the replay-window + secret-rotation discipline that turns a signature into a real authentication boundary.",
+      "framework_lag_declaration": "NIST 800-53 IA-9 + AC-4, ISO 27001 A.5.16, NIS2 Art.21(2)(d), and SOC 2 CC6.6 collectively underspecify the inbound-callback trust boundary. None mandate redirect_uri allowlist hygiene, OAuth state-parameter binding, webhook-signature replay-window enforcement, or per-app webhook-secret isolation. The 2024-2025 Snowflake / Salt Typhoon / GitHub-Apps-secret-leak class incidents would all satisfy a literal reading of these controls. UK CAF B3 (Data security) treats inbound endpoints as part of the perimeter but does not require behaviour-tested signature validation. AU ISM-1817 requires clients calling internet-facing network APIs to be authenticated and authorized, which a webhook receiver meets with a shared-secret signature, but it names no replay window or secret-rotation discipline, and those are what turn a signature into a real authentication boundary.",
       "skill_chain": [
         {
           "skill": "identity-assurance",