@blamejs/exceptd-skills 0.12.23 → 0.12.25

package/data/playbooks/library-author.json

@@ -477,7 +477,7 @@
         "monitor": 50,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-53 SR-3/4/5, NIST 800-218 SSDF PS.3.2 / PW.4 / RV.2, ISO 27001:2022 A.8.30 / A.5.20, SOC 2 CC8.1 / CC9.2, NIS2 Art.21(2)(d), DORA Art.28, UK CAF C1.b, AU Essential 8 E1, and CMMC SI.L2-3.4.4 all permit publisher posture that omits (a) OIDC-based publish, (b) Sigstore / Rekor transparency-log entries per release, (c) signed + distributed SBOM, (d) transitive completeness, (e) VEX feed for filed CVEs, (f) coordinated-disclosure intake at /.well-known/security.txt, (g) tag-protection on release refs, (h) reproducible builds, (i) skill / plugin signature verification gated in the install path. Operational tooling for (a)-(i) shipped 2023-2025; framework lag = ~540 days behind tooling and ~18 months ahead of EU CRA Art.10/13/14 binding (2027). Compensating controls MUST close (a)-(i) before SSDF-only compliance can be accepted as CRA-readiness.",
+      "framework_lag_declaration": "NIST 800-53 SR-3/4/5, NIST 800-218 SSDF PS.3.2 / PW.4 / RV.2, ISO 27001:2022 A.8.30 / A.5.20, SOC 2 CC8.1 / CC9.2, NIS2 Art.21(2)(d), DORA Art.28, and CMMC SI.L2-3.4.4 all permit publisher posture that omits (a) OIDC-based publish, (b) Sigstore / Rekor transparency-log entries per release, (c) signed + distributed SBOM, (d) transitive completeness, (e) VEX feed for filed CVEs, (f) coordinated-disclosure intake at /.well-known/security.txt, (g) tag-protection on release refs, (h) reproducible builds, (i) skill / plugin signature verification gated in the install path. Operational tooling for (a)-(i) shipped 2023-2025; framework lag = ~540 days behind tooling and ~18 months ahead of EU CRA Art.10/13/14 binding (2027). UK CAF C1.b (Identity and Access Management — Privileged user management) is designed to govern human privileged users and does not require SLSA L3+ provenance attestation on every release artifact; the gap is that a compromised publisher token (no human-MFA gate, no provenance attestation) yields an attacker-signed release that passes C1.b's evidence surface. AU Essential 8 Strategy 5 (Restrict Admin Privileges, E8 M.5) is designed for runtime admin-account scoping and does not reach build-time admin privileges on signing-key material: a CI runner holding the publish credential is a build-time admin that E8 M.5 evidence does not enumerate. Compensating controls MUST close (a)-(i) before SSDF-only compliance can be accepted as CRA-readiness.",
       "skill_chain": [
         {
           "skill": "supply-chain-integrity",

package/data/playbooks/secrets.json

@@ -224,6 +224,30 @@
             "control_id": "B3 — Data security",
             "designed_for": "NCSC CAF outcome that data important to the essential function is protected from compromise, including credential and key material.",
             "insufficient_because": "Outcome can be assessed against managed secret-store contents. Plaintext credentials leaked into source-code repositories, CI logs, IaC files, and AI assistant context windows do not register on the outcome's evidence surface."
+          },
+          {
+            "framework": "au-essential-8",
+            "control_id": "Strategy 4 — Multi-factor authentication (E8 M.4)",
+            "designed_for": "MFA on privileged + internet-facing accounts.",
+            "insufficient_because": "MFA defends the interactive auth flow; bearer tokens / API keys / OAuth refresh tokens committed to source artifacts bypass MFA entirely — scraper-bot exploitation against cloud-provider APIs uses the static credential and never reaches an interactive auth surface. Compliance-theater test: audit the last 90 days of admin actions and count those executed by service-account tokens vs human-MFA sessions; if service tokens dominate, Strategy 4 compliance is paper."
+          },
+          {
+            "framework": "au-essential-8",
+            "control_id": "Strategy 1 — Application Control (E8 M.1)",
+            "designed_for": "Execution allowlisting on workstations and servers.",
+            "insufficient_because": "Application Control governs runtime execution but does not constrain build agents reading from arbitrary secret stores or environment variables at build time — CI runners with broad env-var access defeat the intent. Compliance-theater test: inventory CI runner environment variables; any token-shaped string (regex /[A-Za-z0-9]{32,}/) means ML2 compliance leaks at build time."
+          },
+          {
+            "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."
+          },
+          {
+            "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."
           }
         ]
       },
@@ -241,7 +265,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. 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 ML2 MFA (E8 M.4) + Restrict Admin Privileges (E8 M.5) and ISM-1546 cover MFA + admin-account hygiene but provide no signal on long-lived bearer-token exposure inside developer repositories.",
+      "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.",
       "skill_chain": [
         {
           "skill": "dlp-gap-analysis",

package/data/rfc-references.json

@@ -1,7 +1,7 @@
 {
   "_meta": {
     "schema_version": "1.0.0",
-    "last_updated": "2026-05-11",
+    "last_updated": "2026-05-15",
     "note": "IETF RFCs and Internet-Drafts that exceptd skills depend on. RFCs are the layer beneath compliance frameworks: a control like 'TLS 1.3 required' implicitly references RFC 8446; a 'use strong KEM' control depends on whatever draft-ietf-tls-ecdhe-mlkem settles into. Frameworks lag RFCs; RFCs lag attacker innovation. This catalog tracks both kinds of lag.",
     "status_values": [
       "Internet Standard",
@@ -161,6 +161,19 @@
     ],
     "last_verified": "2026-05-11"
   },
+  "RFC-7644": {
+    "number": 7644,
+    "title": "System for Cross-domain Identity Management (SCIM) 2.0: Protocol",
+    "status": "Proposed Standard",
+    "published": "2015-09",
+    "tracker": "https://www.rfc-editor.org/info/rfc7644",
+    "relevance": "SCIM 2.0 is the dominant standard for federated identity-store synchronisation between IdPs and downstream applications (Okta, Entra ID, Workday → SaaS). Operator-facing: SCIM endpoints are a recurring credential-store soft target — bearer-token misconfigurations expose full directory enumeration + write access. AI-agent contexts add a new class: agent-identity provisioning at scale via SCIM, where over-broad attribute filters expose human identity data to agent-tenants. Pair with RFC 7643 (SCIM Schema) when implementing.",
+    "skills_referencing": [
+      "identity-assurance",
+      "cred-stores"
+    ],
+    "last_verified": "2026-05-15"
+  },
   "RFC-7970": {
     "number": 7970,
     "title": "The Incident Object Description Exchange Format Version 2",
@@ -217,6 +230,18 @@
     ],
     "last_verified": "2026-05-11"
   },
+  "RFC-8460": {
+    "number": 8460,
+    "title": "SMTP TLS Reporting (TLSRPT)",
+    "status": "Proposed Standard",
+    "published": "2018-09",
+    "tracker": "https://www.rfc-editor.org/info/rfc8460",
+    "relevance": "Defines a DNS-published TLSRPT policy and an aggregate-reporting mechanism (RUA endpoint) where receiving MTAs report success / failure of inbound TLS negotiation. Operator-facing: TLSRPT is the monitoring half of the MTA-STS pair (RFC 8461) — without it, an MTA-STS `enforce` policy silently degrades when downgrade attempts occur or receiver-side TLS configurations break. Phishing-defense relevance is indirect but load-bearing: visibility into STARTTLS-stripping attempts is otherwise absent.",
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
+    "last_verified": "2026-05-15"
+  },
   "RFC-8461": {
     "number": 8461,
     "title": "SMTP MTA Strict Transport Security (MTA-STS)",
@@ -241,6 +266,31 @@
     ],
     "last_verified": "2026-05-13"
   },
+  "RFC-8617": {
+    "number": 8617,
+    "title": "The Authenticated Received Chain (ARC) Protocol",
+    "status": "Experimental",
+    "published": "2019-07",
+    "tracker": "https://www.rfc-editor.org/info/rfc8617",
+    "relevance": "ARC preserves authentication results across legitimate forwarding paths (mailing lists, alias services) where SPF + DKIM alignment would otherwise break, producing false DMARC failures. Operator-facing: ARC is the load-bearing complement to DMARC for organisations that receive mail via forwarders — anti-phishing programs that publish `p=reject` without an ARC strategy face increased false-positive bounce rates that pressure operators to relax DMARC. The skill-update-loop tracks ARC adoption signals as a forward-watch indicator for email-authentication posture changes.",
+    "skills_referencing": [
+      "email-security-anti-phishing",
+      "skill-update-loop"
+    ],
+    "last_verified": "2026-05-15"
+  },
+  "RFC-8705": {
+    "number": 8705,
+    "title": "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens",
+    "status": "Proposed Standard",
+    "published": "2020-02",
+    "tracker": "https://www.rfc-editor.org/info/rfc8705",
+    "relevance": "Defines two mechanisms: mTLS client authentication to OAuth authorisation servers, and certificate-bound access tokens that prevent token theft from being exploitable without the original mTLS client certificate. Operator-facing: mTLS-bound tokens are the canonical mitigation for bearer-token theft in high-assurance contexts (open-banking under PSD2 / UK FCA SCA-RTS, FAPI 2.0, government SSO). DPoP (RFC 9449) is the lighter-weight alternative for browser / mobile contexts where client TLS certificates are impractical.",
+    "skills_referencing": [
+      "identity-assurance"
+    ],
+    "last_verified": "2026-05-15"
+  },
   "RFC-8725": {
     "number": 8725,
     "title": "JSON Web Token Best Current Practices",
@@ -285,6 +335,22 @@
     ],
     "last_verified": "2026-05-11"
   },
+  "RFC-9112": {
+    "number": 9112,
+    "title": "HTTP/1.1",
+    "status": "Internet Standard",
+    "published": "2022-06",
+    "std_number": 99,
+    "tracker": "https://www.rfc-editor.org/info/rfc9112",
+    "relevance": "The current authoritative HTTP/1.1 specification, supersedes RFC 7230. Operator-facing: every HTTP/1.1 deployment — including MCP server transports, AI-API client libraries, and legacy webapp middle-tiers — should reference RFC 9112 rather than the older RFC 7230. Re-specification clarified request/response framing in ways that affect smuggling-class attack surfaces (CL.TE / TE.CL / CL.CL desync) which remain the dominant HTTP/1.1 vulnerability class.",
+    "lag_notes": "Supersedes RFC 7230. Many security-tool rulesets still cite the obsolete number; check any control mapping that references 'RFC 7230' as the HTTP/1.1 authority and update to 9112.",
+    "skills_referencing": [
+      "api-security",
+      "webapp-security",
+      "mcp-agent-trust"
+    ],
+    "last_verified": "2026-05-15"
+  },
   "RFC-9114": {
     "number": 9114,
     "title": "HTTP/3",
@@ -361,6 +427,19 @@
     ],
     "last_verified": "2026-05-11"
   },
+  "RFC-9449": {
+    "number": 9449,
+    "title": "OAuth 2.0 Demonstrating Proof of Possession (DPoP)",
+    "status": "Proposed Standard",
+    "published": "2023-09",
+    "tracker": "https://www.rfc-editor.org/info/rfc9449",
+    "relevance": "DPoP binds OAuth access + refresh tokens to a client-held key pair via per-request JWTs, defending against bearer-token theft in contexts where mTLS (RFC 8705) is impractical (single-page apps, mobile apps, AI-agent runtimes lacking client-certificate infrastructure). Operator-facing: DPoP is the recommended sender-constraint for FAPI 2.0 + MCP server-to-client OAuth flows where the client cannot present a TLS client certificate. Pairs with RFC 9700 (OAuth 2.0 Security BCP) recommendations.",
+    "skills_referencing": [
+      "identity-assurance",
+      "api-security"
+    ],
+    "last_verified": "2026-05-15"
+  },
   "RFC-9458": {
     "number": 9458,
     "title": "Oblivious HTTP",
@@ -375,6 +454,19 @@
     ],
     "last_verified": "2026-05-11"
   },
+  "RFC-9622": {
+    "number": 9622,
+    "title": "An Architecture for Transport Services",
+    "status": "Proposed Standard",
+    "published": "2024-08",
+    "tracker": "https://www.rfc-editor.org/info/rfc9622",
+    "relevance": "Transport Services (TAPS) architecture — abstracts the choice of underlying transport (TCP, QUIC, SCTP) behind a unified API that selects the protocol at runtime based on path conditions. Forward-watch relevance: webapp / AI-API client libraries that adopt TAPS may transparently shift between TCP-HTTP/2 and QUIC-HTTP/3 mid-session, complicating boundary inspection assumptions that pin to a single transport. Currently tracked as a deployment-watch item rather than an operational control point.",
+    "lag_notes": "Architecture document; companion documents (TAPS implementation, TAPS programming interface) are still in progress at IETF TAPS WG. Enterprise tooling impact is forward-looking.",
+    "skills_referencing": [
+      "webapp-security"
+    ],
+    "last_verified": "2026-05-15"
+  },
   "RFC-9700": {
     "number": 9700,
     "title": "Best Current Practice for OAuth 2.0 Security",