@blamejs/exceptd-skills 0.12.24 → 0.12.26

package/data/global-frameworks.json

@@ -2,7 +2,7 @@
   "_meta": {
     "schema_version": "1.3.0",
     "version": "1.3.0",
-    "last_updated": "2026-05-11",
+    "last_updated": "2026-05-15",
     "note": "Multi-jurisdiction framework registry. patch_sla in hours. notification_sla in hours. source field must be primary regulatory source. v1.3.0 expansion: NO, MX, AR, TR, TH, PH, US_CALIFORNIA top-level jurisdictions added; EU member-state sub-regulator blocks added for Germany (BSI), France (ANSSI), Spain (AEPD + AESIA), Italy (ACN + AgID); EU-level technical body ENISA added as cross-cutting reference. v1.2.0 expansion: IL, CH, HK, TW, ID, VN, US_NYDFS added; JP expanded with APPI/PPC, FISC, NISC, METI, Economic Security Promotion Act, AI Strategy Council guidance. v1.1.0 expansion: BR, CN, ZA, AE, SA, NZ, KR, CL added; IN and CA enriched with data-protection law entries (DPDPA, Quebec Law 25, PIPEDA).",
     "tlp": "CLEAR",
     "source_confidence": {
@@ -79,7 +79,7 @@
       },
       "DORA": {
         "full_name": "Digital Operational Resilience Act",
-        "authority": "ESAs (EBA, EIOPA, ESMA)",
+        "authority": "ESAs (EBA, EIOPA, ESMA) + Lead Overseers (CTPP regime from H2 2026)",
         "source": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554",
         "effective_date": "2025-01-17",
         "version": "2022/2554",
@@ -92,33 +92,55 @@
           "Art. 9 — ICT risk management framework",
           "Art. 10 — identification of ICT assets and dependencies",
           "Art. 11 — ICT business continuity",
-          "Art. 19 — major incident classification and reporting (4h initial, 24h intermediate, 30d final)",
-          "Art. 28-30 — ICT third-party risk (DORA extends to all ICT providers including cloud)"
+          "Art. 19 — major incident classification and reporting (4h initial, 24h intermediate, 30d final; classification per Commission Delegated Regulation (EU) 2024/1772)",
+          "Art. 26 — threat-led penetration testing (ITS active 2026-Q3)",
+          "Art. 28-30 — ICT third-party risk register (RTS on subcontracting active 2026-01-17)",
+          "Art. 31-44 — Critical Third-Party Provider oversight regime (first designations H2 2026)"
+        ],
+        "implementing_measures_2026": [
+          "RTS on subcontracting of ICT services supporting critical or important functions (Commission Delegated Regulation (EU) 2025/420) — active 2026-01-17",
+          "RTS on classification of major ICT-related incidents (Commission Delegated Regulation (EU) 2024/1772) — in force",
+          "ITS on threat-led penetration testing under Art. 26 — active 2026-Q3",
+          "Implementing acts designating critical ICT third-party service providers — first wave H2 2026"
         ],
         "framework_gaps": [
           "Patch SLA not specified — risk-based interpretation required",
-          "AI/ML systems in scope but no AI-specific controls",
-          "MCP servers: 'ICT third-party service providers' may apply but no specific guidance",
-          "PQC: not addressed; 'appropriate level of security' standard"
+          "AI/ML systems in scope as ICT third-party service providers; no AI-specific obligations beyond generic ICT-risk language",
+          "Frontier-AI providers not on initial CTPP designation candidate list despite material concentration risk",
+          "MCP servers + agent runtimes: classifiable as ICT third-party but no specific oversight guidance",
+          "PQC: not addressed; 'appropriate level of security' standard",
+          "Incident-classification RTS does not enumerate AI-specific incident classes"
         ],
-        "ai_coverage": "AI systems providing ICT services to financial entities are in scope as ICT third-party service providers",
+        "ai_coverage": "AI systems providing ICT services to financial entities are in scope as ICT third-party service providers; frontier-AI provider designation under the CTPP regime remains open as of 2026-05",
         "pqc_coverage": "Implicit in Art. 9 risk management; no explicit requirement",
-        "theater_risk": "low-medium — DORA has strong third-party oversight; patching gap remains"
+        "theater_risk": "low-medium — DORA has strong third-party oversight; AI-specific obligations still maturing through 2026 implementing measures"
       },
       "EU_AI_ACT": {
         "full_name": "EU Artificial Intelligence Act",
-        "authority": "EU AI Office + National Market Surveillance Authorities",
+        "authority": "EU AI Office + National Market Surveillance Authorities + Notified Bodies (Annex IX conformity)",
         "source": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689",
         "effective_date": "2024-08-01",
-        "full_application_date": "2026-08-01",
+        "full_application_date": "2026-08-02",
+        "gpai_obligations_date": "2026-08-02",
+        "high_risk_obligations_date": "2026-08-02",
+        "prohibited_practices_date": "2025-02-02",
         "version": "2024/1689",
-        "security_article": "Article 9 — Risk Management System (High-Risk AI)",
+        "security_article": "Article 9 — Risk Management System (High-Risk AI); Article 15 — Cybersecurity; Article 55 — GPAI Systemic Risk",
         "critical_controls": [
+          "Art. 5 — prohibited AI practices (in force 2025-02-02)",
           "Art. 9 — mandatory risk management system for high-risk AI (ongoing, not one-time)",
           "Art. 10 — data governance requirements for training/validation/testing data",
           "Art. 12 — technical documentation and logging requirements",
           "Art. 15 — accuracy, robustness, and cybersecurity requirements for high-risk AI",
-          "Art. 72 — GPAI model adversarial testing requirements"
+          "Art. 43 + Annex IX — conformity assessment route (internal control vs. notified body) for high-risk AI",
+          "Art. 53 — GPAI provider obligations: technical documentation, downstream-provider info package, copyright policy, training-content summary (active 2026-08-02)",
+          "Art. 55 — GPAI with systemic risk: adversarial evaluation, systemic-risk assessment, serious-incident reporting, cybersecurity of model layer (active 2026-08-02)"
+        ],
+        "implementing_measures_2026": [
+          "GPAI Code of Practice signed 2026-02 — presumed-compliance route for Art. 53 + 55 until harmonised standards published",
+          "GPAI obligations full application 2026-08-02",
+          "High-risk obligations full application 2026-08-02",
+          "Harmonised standards under Art. 40 — CEN-CENELEC JTC 21 deliverables tracked through 2026-2027"
         ],
         "high_risk_categories": [
           "Biometric identification",
@@ -131,13 +153,16 @@
         ],
         "framework_gaps": [
           "Art. 15 'cybersecurity' is undefined — no technical specification",
-          "Prompt injection not addressed in Art. 15 or implementing measures",
-          "Supply chain security for GPAI models: Art. 72 adversarial testing but no signing requirements",
-          "MCP servers/agent tools: not contemplated in implementing regulations"
-        ],
-        "ai_coverage": "Specific AI security requirements for high-risk AI and GPAI models — most complete AI security framework globally",
+          "Prompt injection not addressed in Art. 15 or current implementing measures",
+          "Supply chain security for GPAI models: Art. 55 adversarial evaluation but no signing / SLSA-equivalent requirement",
+          "MCP servers/agent tools: not contemplated in implementing regulations",
+          "Annex IX internal-control conformity is self-attestation for most high-risk AI; notified-body capacity is constrained",
+          "Art. 53 training-content summary granularity is operationally undefined",
+          "Art. 55 incident-reporting clock (15-day) misaligned with DORA Art. 19 (4h) and NIS2 Art. 23 (24h)"
+        ],
+        "ai_coverage": "Specific AI security requirements for high-risk AI and GPAI models — most complete AI security framework globally; GPAI + high-risk obligations active 2026-08-02",
         "pqc_coverage": "Not addressed",
-        "theater_risk": "unknown — implementing measures still developing as of 2026-05"
+        "theater_risk": "medium — Code of Practice provides presumed-compliance route but adversarial-evaluation methodology + energy-reporting cadence remain provider-defined as of 2026-05"
       },
       "EU_CRA": {
         "full_name": "EU Cyber Resilience Act",

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,20 @@
     ],
     "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",
+      "sector-telecom"
+    ],
+    "last_verified": "2026-05-15"
+  },
   "RFC-9700": {
     "number": 9700,
     "title": "Best Current Practice for OAuth 2.0 Security",