@blamejs/exceptd-skills 0.12.40 → 0.13.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +17 -0
- package/ARCHITECTURE.md +7 -4
- package/CHANGELOG.md +215 -248
- package/CONTEXT.md +2 -2
- package/README.md +2 -8
- package/agents/threat-researcher.md +2 -2
- package/bin/exceptd.js +179 -81
- package/data/_indexes/_meta.json +50 -50
- package/data/_indexes/activity-feed.json +1 -1
- package/data/_indexes/catalog-summaries.json +1 -1
- package/data/_indexes/chains.json +485 -13
- package/data/_indexes/frequency.json +4 -0
- package/data/_indexes/jurisdiction-map.json +15 -4
- package/data/_indexes/section-offsets.json +1224 -1224
- package/data/_indexes/token-budget.json +170 -170
- package/data/atlas-ttps.json +54 -11
- package/data/attack-techniques.json +113 -17
- package/data/cve-catalog.json +38 -52
- package/data/cwe-catalog.json +8 -2
- package/data/exploit-availability.json +1 -0
- package/data/framework-control-gaps.json +149 -6
- package/data/global-frameworks.json +1 -0
- package/data/playbooks/ai-api.json +5 -0
- package/data/playbooks/cicd-pipeline-compromise.json +970 -0
- package/data/playbooks/cloud-iam-incident.json +4 -1
- package/data/playbooks/cred-stores.json +10 -0
- package/data/playbooks/crypto-codebase.json +13 -0
- package/data/playbooks/framework.json +16 -0
- package/data/playbooks/hardening.json +4 -0
- package/data/playbooks/identity-sso-compromise.json +951 -0
- package/data/playbooks/idp-incident.json +3 -0
- package/data/playbooks/kernel.json +6 -0
- package/data/playbooks/llm-tool-use-exfil.json +963 -0
- package/data/playbooks/mcp.json +6 -0
- package/data/playbooks/runtime.json +4 -0
- package/data/playbooks/sbom.json +13 -0
- package/data/playbooks/secrets.json +6 -0
- package/data/playbooks/webhook-callback-abuse.json +916 -0
- package/data/zeroday-lessons.json +1 -0
- package/lib/cross-ref-api.js +33 -13
- package/lib/cve-curation.js +12 -1
- package/lib/exit-codes.js +29 -0
- package/lib/lint-skills.js +25 -3
- package/lib/playbook-runner.js +8 -4
- package/lib/refresh-external.js +10 -1
- package/lib/scoring.js +64 -1
- package/lib/sign.js +40 -7
- package/lib/verify.js +5 -5
- package/manifest.json +83 -83
- package/orchestrator/README.md +7 -7
- package/orchestrator/index.js +46 -25
- package/orchestrator/scheduler.js +2 -2
- package/package.json +1 -1
- package/sbom.cdx.json +135 -91
- package/scripts/check-test-coverage.js +6 -6
- package/scripts/predeploy.js +7 -13
- package/scripts/refresh-reverse-refs.js +107 -20
- package/scripts/refresh-sbom.js +21 -4
- package/skills/age-gates-child-safety/skill.md +1 -5
- package/skills/ai-attack-surface/skill.md +11 -4
- package/skills/ai-c2-detection/skill.md +11 -2
- package/skills/ai-risk-management/skill.md +4 -2
- package/skills/api-security/skill.md +7 -8
- package/skills/attack-surface-pentest/skill.md +2 -2
- package/skills/cloud-iam-incident/skill.md +1 -5
- package/skills/cloud-security/skill.md +0 -4
- package/skills/compliance-theater/skill.md +10 -2
- package/skills/container-runtime-security/skill.md +1 -3
- package/skills/dlp-gap-analysis/skill.md +3 -4
- package/skills/email-security-anti-phishing/skill.md +1 -8
- package/skills/exploit-scoring/skill.md +7 -2
- package/skills/framework-gap-analysis/skill.md +1 -1
- package/skills/fuzz-testing-strategy/skill.md +1 -2
- package/skills/global-grc/skill.md +3 -2
- package/skills/identity-assurance/skill.md +1 -3
- package/skills/idp-incident-response/skill.md +1 -4
- package/skills/incident-response-playbook/skill.md +1 -5
- package/skills/kernel-lpe-triage/skill.md +2 -2
- package/skills/mcp-agent-trust/skill.md +13 -3
- package/skills/mlops-security/skill.md +3 -4
- package/skills/ot-ics-security/skill.md +0 -3
- package/skills/policy-exception-gen/skill.md +11 -3
- package/skills/pqc-first/skill.md +4 -2
- package/skills/rag-pipeline-security/skill.md +2 -0
- package/skills/ransomware-response/skill.md +1 -5
- package/skills/researcher/skill.md +4 -3
- package/skills/sector-energy/skill.md +0 -4
- package/skills/sector-federal-government/skill.md +2 -3
- package/skills/sector-financial/skill.md +1 -4
- package/skills/sector-healthcare/skill.md +0 -5
- package/skills/sector-telecom/skill.md +0 -4
- package/skills/security-maturity-tiers/skill.md +1 -2
- package/skills/skill-update-loop/skill.md +4 -3
- package/skills/supply-chain-integrity/skill.md +4 -3
- package/skills/threat-model-currency/skill.md +1 -1
- package/skills/threat-modeling-methodology/skill.md +2 -1
- package/skills/webapp-security/skill.md +0 -5
|
@@ -193,9 +193,9 @@ const DOCS_ALWAYS_GREEN = new Set([
|
|
|
193
193
|
"CLAUDE.md", "SUPPORT.md", ".gitignore", ".npmrc", ".editorconfig",
|
|
194
194
|
]);
|
|
195
195
|
|
|
196
|
-
//
|
|
197
|
-
//
|
|
198
|
-
//
|
|
196
|
+
// Operator-facing docs (release notes, install instructions, security
|
|
197
|
+
// disclosure policy, migration guides, AI-assistant ground truth) must not
|
|
198
|
+
// auto-green — a PR could otherwise land deceptive copy here without any
|
|
199
199
|
// reviewer signal. Downgrade to manual-review so the diff surfaces in the
|
|
200
200
|
// gate output — a human (or the maintainer reviewing the bot summary) at
|
|
201
201
|
// least sees the change exists.
|
|
@@ -478,9 +478,9 @@ function coversCveIoc(corpus, cveId) {
|
|
|
478
478
|
// assert.notEqual(foo.status, 2, 'must not be unknown-cmd') ← also refused
|
|
479
479
|
// unless the same line ends with `// allow-notEqual: <reason>`.
|
|
480
480
|
//
|
|
481
|
-
//
|
|
482
|
-
//
|
|
483
|
-
//
|
|
481
|
+
// Structural lint replaces a per-instance hunt across 25+ test sites — keeps
|
|
482
|
+
// new tests / new ports from regressing into coincidence-passing assertions.
|
|
483
|
+
// Fix the class, not the instance.
|
|
484
484
|
function scanForCoincidenceAsserts(cwd) {
|
|
485
485
|
const out = [];
|
|
486
486
|
const testsDir = path.join(cwd, "tests");
|
package/scripts/predeploy.js
CHANGED
|
@@ -166,22 +166,16 @@ const GATES = [
|
|
|
166
166
|
ciJobName: "Diff coverage",
|
|
167
167
|
},
|
|
168
168
|
{
|
|
169
|
-
//
|
|
170
|
-
//
|
|
171
|
-
//
|
|
172
|
-
//
|
|
173
|
-
//
|
|
174
|
-
//
|
|
175
|
-
name: "Validate playbooks (schema + cross-refs
|
|
169
|
+
// Validate every playbook in data/playbooks/ against the JSON schema
|
|
170
|
+
// + cross-playbook + cross-catalog references. v0.12.12 first wired
|
|
171
|
+
// this as informational so the patch-class release could land without
|
|
172
|
+
// retroactively breaking schema-drift cases; v0.13.0 flips it to
|
|
173
|
+
// required because the 20-playbook canonical set (including the 4
|
|
174
|
+
// v0.13.0 additions) all validate cleanly.
|
|
175
|
+
name: "Validate playbooks (schema + cross-refs)",
|
|
176
176
|
command: process.execPath,
|
|
177
177
|
args: [path.join(ROOT, "lib", "validate-playbooks.js")],
|
|
178
178
|
ciJobName: "Validate playbooks",
|
|
179
|
-
informational: true,
|
|
180
|
-
// cap informational acceptance at exit 1 so a CRASH (137 OOM,
|
|
181
|
-
// 139 SIGSEGV, 134 SIGABRT, etc.) surfaces as a real failure instead of
|
|
182
|
-
// being absorbed under the informational bucket. Matches the
|
|
183
|
-
// forward-watch gate (line ~111) which already pins the same ceiling.
|
|
184
|
-
informationalMaxExitCode: 1,
|
|
185
179
|
},
|
|
186
180
|
];
|
|
187
181
|
|
|
@@ -10,7 +10,8 @@
|
|
|
10
10
|
* atlas-ttps, `skills_referencing` for the other three) listing every
|
|
11
11
|
* skill that points at that entry. The reverse field drifts whenever a
|
|
12
12
|
* skill adds or removes a forward ref without the catalog being updated
|
|
13
|
-
* in lockstep —
|
|
13
|
+
* in lockstep — this script rebuilds the reverse direction from the
|
|
14
|
+
* forward source of truth so the two never disagree.
|
|
14
15
|
*
|
|
15
16
|
* Behaviour. For each catalog file:
|
|
16
17
|
* 1. Walk every skill's relevant forward-ref array in manifest.json.
|
|
@@ -22,7 +23,7 @@
|
|
|
22
23
|
*
|
|
23
24
|
* The script does NOT touch playbooks_referencing — that field carries
|
|
24
25
|
* playbook ids (data/playbooks/*.json), not skill names; it has its own
|
|
25
|
-
* source of truth and is out of scope for this
|
|
26
|
+
* source of truth and is out of scope for this refresh.
|
|
26
27
|
*
|
|
27
28
|
* Run: node scripts/refresh-reverse-refs.js
|
|
28
29
|
* npm run refresh-reverse-refs
|
|
@@ -46,8 +47,8 @@ const DATA_DIR = path.join(REPO_ROOT, 'data');
|
|
|
46
47
|
* forwardField source-collection[].* array name
|
|
47
48
|
* reverseField per-entry reverse field name in the catalog
|
|
48
49
|
* source 'manifest.skills' (default) — walk every skill's forward ref
|
|
49
|
-
* 'cve.entries' — walk every CVE's forward ref (
|
|
50
|
-
*
|
|
50
|
+
* 'cve.entries' — walk every CVE's forward ref (added in
|
|
51
|
+
* v0.12.32); contributes CVE-IDs (skipping `_draft: true`
|
|
51
52
|
* entries so the reverse direction tracks operator-queryable
|
|
52
53
|
* truth, not in-progress curation state)
|
|
53
54
|
* entryKey field on the source object used as the reverse-list value
|
|
@@ -83,12 +84,12 @@ const CATALOGS = [
|
|
|
83
84
|
source: 'manifest.skills',
|
|
84
85
|
entryKey: 'name',
|
|
85
86
|
},
|
|
86
|
-
//
|
|
87
|
-
//
|
|
88
|
-
//
|
|
89
|
-
//
|
|
90
|
-
//
|
|
91
|
-
//
|
|
87
|
+
// v0.12.32: CVE → CWE reverse direction. CWE entries declare
|
|
88
|
+
// `evidence_cves` as the operator-facing "which CVEs land here" index;
|
|
89
|
+
// previously hand-maintained and drifted whenever a new CVE landed
|
|
90
|
+
// without the matching CWE's evidence_cves being updated. Now mirrors
|
|
91
|
+
// `cve.cwe_refs` → `cwe.evidence_cves` automatically. Drafts excluded
|
|
92
|
+
// (they're invisible to default consumers anyway).
|
|
92
93
|
{
|
|
93
94
|
file: 'cwe-catalog.json',
|
|
94
95
|
forwardField: 'cwe_refs',
|
|
@@ -96,13 +97,13 @@ const CATALOGS = [
|
|
|
96
97
|
source: 'cve.entries',
|
|
97
98
|
entryKey: null, // value is the iterating CVE id
|
|
98
99
|
},
|
|
99
|
-
//
|
|
100
|
-
//
|
|
101
|
-
//
|
|
102
|
-
//
|
|
103
|
-
//
|
|
104
|
-
//
|
|
105
|
-
//
|
|
100
|
+
// v0.12.40: CVE → framework-gap reverse direction. Resolved 137
|
|
101
|
+
// directional mismatches between cve.framework_control_gaps (dict-keyed
|
|
102
|
+
// by gap-id) and gap.evidence_cves (array of CVE ids). The forward
|
|
103
|
+
// shape on the CVE side is an OBJECT not an array — keys are the gap
|
|
104
|
+
// ids, values are per-CVE narrative. The reverse direction (which CVEs
|
|
105
|
+
// cite this gap) is a simple set of CVE ids on the gap entry. The
|
|
106
|
+
// helper handles the dict-keyed forward field via the
|
|
106
107
|
// `forwardFieldShape: 'object-keys'` flag.
|
|
107
108
|
{
|
|
108
109
|
file: 'framework-control-gaps.json',
|
|
@@ -112,6 +113,26 @@ const CATALOGS = [
|
|
|
112
113
|
source: 'cve.entries',
|
|
113
114
|
entryKey: null, // value is the iterating CVE id
|
|
114
115
|
},
|
|
116
|
+
// v0.13.0: ATLAS / ATT&CK back-edge — every ATLAS TTP and ATT&CK
|
|
117
|
+
// technique gets a `cve_refs` array carrying the CVE ids that cite it.
|
|
118
|
+
// Pre-v0.13 these catalogs had only forward refs (CVE → TTP); operators
|
|
119
|
+
// reading an ATLAS / ATT&CK entry could not see which CVEs cite it
|
|
120
|
+
// without grepping the whole catalog. New back-edges close the
|
|
121
|
+
// asymmetric-edges cluster the cycle 20 audit B flagged.
|
|
122
|
+
{
|
|
123
|
+
file: 'atlas-ttps.json',
|
|
124
|
+
forwardField: 'atlas_refs',
|
|
125
|
+
reverseField: 'cve_refs',
|
|
126
|
+
source: 'cve.entries',
|
|
127
|
+
entryKey: null,
|
|
128
|
+
},
|
|
129
|
+
{
|
|
130
|
+
file: 'attack-techniques.json',
|
|
131
|
+
forwardField: 'attack_refs',
|
|
132
|
+
reverseField: 'cve_refs',
|
|
133
|
+
source: 'cve.entries',
|
|
134
|
+
entryKey: null,
|
|
135
|
+
},
|
|
115
136
|
];
|
|
116
137
|
|
|
117
138
|
function readJson(p) {
|
|
@@ -131,14 +152,14 @@ function buildReverseIndex(skills, forwardField) {
|
|
|
131
152
|
return index;
|
|
132
153
|
}
|
|
133
154
|
|
|
134
|
-
//
|
|
135
|
-
//
|
|
155
|
+
// v0.12.32: build a reverse index keyed by catalog ID from the CVE
|
|
156
|
+
// catalog's forward refs. Each CVE entry has cwe_refs / attack_refs
|
|
136
157
|
// arrays; the reverse side is the CVE ID, indexed by the catalog entry.
|
|
137
158
|
// Draft entries are skipped — drafts are invisible to default consumers
|
|
138
159
|
// via cross-ref-api, so the reverse direction should track operator-
|
|
139
160
|
// queryable truth, not in-progress curation state.
|
|
140
161
|
//
|
|
141
|
-
//
|
|
162
|
+
// v0.12.40: forwardFieldShape parameter handles the
|
|
142
163
|
// CVE.framework_control_gaps case where the forward field is a dict
|
|
143
164
|
// (gap-id → narrative) rather than an array.
|
|
144
165
|
function buildCveReverseIndex(cveCatalog, forwardField, forwardFieldShape) {
|
|
@@ -222,6 +243,71 @@ function rebuildCatalog(cfg, manifest, cveCatalog) {
|
|
|
222
243
|
};
|
|
223
244
|
}
|
|
224
245
|
|
|
246
|
+
/**
|
|
247
|
+
* v0.13.0: playbook `fed_by` reverse direction. Every playbook declares
|
|
248
|
+
* `feeds_into[]` listing playbook ids it chains TO; `fed_by[]` is the
|
|
249
|
+
* symmetric "which playbooks chain into me." Pre-v0.13 operators reading
|
|
250
|
+
* a playbook couldn't see what fed it without grepping every other
|
|
251
|
+
* playbook's feeds_into. The reverse field lives on the playbook's
|
|
252
|
+
* top-level under `_meta.fed_by` (paired with the existing _meta.feeds_into
|
|
253
|
+
* for shape symmetry).
|
|
254
|
+
*/
|
|
255
|
+
function rebuildPlaybookReverse() {
|
|
256
|
+
const playbooksDir = path.join(DATA_DIR, 'playbooks');
|
|
257
|
+
if (!fs.existsSync(playbooksDir)) return { file: 'playbooks/*.json', source: 'playbook.feeds_into', reverseField: 'fed_by', changed: 0, added: 0, removed: 0, unchanged: 0, orphans: [] };
|
|
258
|
+
const files = fs.readdirSync(playbooksDir).filter((n) => n.endsWith('.json'));
|
|
259
|
+
const playbookEntries = [];
|
|
260
|
+
for (const f of files) {
|
|
261
|
+
const filePath = path.join(playbooksDir, f);
|
|
262
|
+
let data;
|
|
263
|
+
try { data = JSON.parse(fs.readFileSync(filePath, 'utf8')); }
|
|
264
|
+
catch (e) { continue; }
|
|
265
|
+
if (!data || !data._meta || !data._meta.id) continue;
|
|
266
|
+
playbookEntries.push({ file: f, filePath, data });
|
|
267
|
+
}
|
|
268
|
+
// Build reverse index: target-id -> Set<source-id>
|
|
269
|
+
// feeds_into entries are objects with `playbook_id` + `condition`.
|
|
270
|
+
// The fed_by reverse is a simple array of source playbook ids (the
|
|
271
|
+
// condition is per-edge; preserved on feeds_into, not duplicated on
|
|
272
|
+
// fed_by — operators read fed_by to find candidates, then look at the
|
|
273
|
+
// source playbook's feeds_into for the gating condition).
|
|
274
|
+
const index = new Map();
|
|
275
|
+
for (const { data } of playbookEntries) {
|
|
276
|
+
const meta = data._meta;
|
|
277
|
+
const targets = Array.isArray(meta.feeds_into) ? meta.feeds_into : [];
|
|
278
|
+
for (const t of targets) {
|
|
279
|
+
const targetId = (t && typeof t === 'object') ? t.playbook_id : t;
|
|
280
|
+
if (!targetId || typeof targetId !== 'string') continue;
|
|
281
|
+
if (!index.has(targetId)) index.set(targetId, new Set());
|
|
282
|
+
index.get(targetId).add(meta.id);
|
|
283
|
+
}
|
|
284
|
+
}
|
|
285
|
+
let changed = 0, added = 0, removed = 0, unchanged = 0;
|
|
286
|
+
const orphans = [];
|
|
287
|
+
const knownIds = new Set(playbookEntries.map((e) => e.data._meta.id));
|
|
288
|
+
for (const { filePath, data } of playbookEntries) {
|
|
289
|
+
const meta = data._meta;
|
|
290
|
+
const before = Array.isArray(meta.fed_by) ? [...meta.fed_by] : [];
|
|
291
|
+
const computed = index.has(meta.id) ? Array.from(index.get(meta.id)).sort() : [];
|
|
292
|
+
const beforeSet = new Set(before);
|
|
293
|
+
const computedSet = new Set(computed);
|
|
294
|
+
const sameContent = before.length === computed.length && before.every((x, i) => x === computed[i]);
|
|
295
|
+
if (!sameContent) {
|
|
296
|
+
meta.fed_by = computed;
|
|
297
|
+
fs.writeFileSync(filePath, JSON.stringify(data, null, 2) + '\n', 'utf8');
|
|
298
|
+
changed += 1;
|
|
299
|
+
for (const s of computed) if (!beforeSet.has(s)) added += 1;
|
|
300
|
+
for (const s of before) if (!computedSet.has(s)) removed += 1;
|
|
301
|
+
} else {
|
|
302
|
+
unchanged += 1;
|
|
303
|
+
}
|
|
304
|
+
}
|
|
305
|
+
for (const targetId of index.keys()) {
|
|
306
|
+
if (!knownIds.has(targetId)) orphans.push(targetId);
|
|
307
|
+
}
|
|
308
|
+
return { file: 'playbooks/*.json', source: 'playbook.feeds_into', reverseField: 'fed_by', changed, added, removed, unchanged, orphans };
|
|
309
|
+
}
|
|
310
|
+
|
|
225
311
|
function main() {
|
|
226
312
|
const manifest = readJson(MANIFEST_PATH);
|
|
227
313
|
const cveCatalog = readJson(CVE_CATALOG_PATH);
|
|
@@ -229,6 +315,7 @@ function main() {
|
|
|
229
315
|
for (const cfg of CATALOGS) {
|
|
230
316
|
results.push(rebuildCatalog(cfg, manifest, cveCatalog));
|
|
231
317
|
}
|
|
318
|
+
results.push(rebuildPlaybookReverse());
|
|
232
319
|
for (const r of results) {
|
|
233
320
|
process.stdout.write(
|
|
234
321
|
`${r.file} (${r.source || 'skills'} → ${r.reverseField}): ${r.changed} entries changed ` +
|
package/scripts/refresh-sbom.js
CHANGED
|
@@ -249,7 +249,6 @@ function buildSbom() {
|
|
|
249
249
|
const pkg = readJson(PACKAGE_PATH);
|
|
250
250
|
const manifest = readJson(MANIFEST_PATH);
|
|
251
251
|
const catalogs = countDataCatalogs(DATA_DIR);
|
|
252
|
-
const timestamp = new Date().toISOString();
|
|
253
252
|
const skillCount = Array.isArray(manifest.skills) ? manifest.skills.length : 0;
|
|
254
253
|
const catalogCount = catalogs.length;
|
|
255
254
|
const vendorProv = loadVendorProvenance();
|
|
@@ -263,9 +262,27 @@ function buildSbom() {
|
|
|
263
262
|
a['bom-ref'] < b['bom-ref'] ? -1 : a['bom-ref'] > b['bom-ref'] ? 1 : 0,
|
|
264
263
|
);
|
|
265
264
|
|
|
266
|
-
|
|
267
|
-
|
|
268
|
-
|
|
265
|
+
// v0.13.0: derive both serialNumber and metadata.timestamp from the
|
|
266
|
+
// bundle content hash, not wall-clock. Pre-v0.13 every refresh produced
|
|
267
|
+
// a new UUID + timestamp even when the bundle content was byte-identical,
|
|
268
|
+
// so the SBOM-currency gate produced noisy diffs and the predeploy
|
|
269
|
+
// comparison could not rely on stable byte-identity. The comment at the
|
|
270
|
+
// top of this file says "stable across observers" — the implementation
|
|
271
|
+
// contradicted it. Now: identical content → identical SBOM.
|
|
272
|
+
//
|
|
273
|
+
// The synthetic timestamp uses the bundle SHA folded into a date string
|
|
274
|
+
// anchored at the Unix epoch + a deterministic offset; this is NOT a
|
|
275
|
+
// real audit timestamp (the `metadata.lifecycles[]` block carries the
|
|
276
|
+
// intended-lifecycle phase for that). Operators wanting the wall-clock
|
|
277
|
+
// time of a refresh should read the file's mtime or refresh-report.json.
|
|
278
|
+
const seed = `${pkg.name}@${pkg.version}@${bundleSha}`;
|
|
279
|
+
const serialNumber = 'urn:uuid:' + uuidV4FromSeed(seed);
|
|
280
|
+
// Synthetic ISO timestamp derived from the seed — preserves the
|
|
281
|
+
// CycloneDX 1.6 metadata.timestamp schema requirement (must be an
|
|
282
|
+
// ISO-8601 string) while remaining content-stable.
|
|
283
|
+
const seedHash = crypto.createHash('sha256').update(seed).digest();
|
|
284
|
+
const offsetSeconds = seedHash.readUInt32BE(0); // deterministic offset
|
|
285
|
+
const timestamp = new Date(Date.UTC(2026, 0, 1) + offsetSeconds * 1000).toISOString();
|
|
269
286
|
|
|
270
287
|
const dataflowInput = catalogs
|
|
271
288
|
.map((c) => `data/${c}`)
|
|
@@ -24,13 +24,9 @@ triggers:
|
|
|
24
24
|
- ofcom
|
|
25
25
|
- esafety
|
|
26
26
|
data_deps:
|
|
27
|
-
- cve-catalog.json
|
|
28
|
-
- atlas-ttps.json
|
|
29
|
-
- framework-control-gaps.json
|
|
30
|
-
- global-frameworks.json
|
|
31
27
|
- cwe-catalog.json
|
|
32
28
|
- d3fend-catalog.json
|
|
33
|
-
-
|
|
29
|
+
- framework-control-gaps.json
|
|
34
30
|
atlas_refs: []
|
|
35
31
|
attack_refs:
|
|
36
32
|
- T1078
|
|
@@ -13,9 +13,7 @@ triggers:
|
|
|
13
13
|
- promptsteal
|
|
14
14
|
- promptflux
|
|
15
15
|
data_deps:
|
|
16
|
-
-
|
|
17
|
-
- atlas-ttps.json
|
|
18
|
-
- framework-control-gaps.json
|
|
16
|
+
- d3fend-catalog.json
|
|
19
17
|
atlas_refs:
|
|
20
18
|
- AML.T0043
|
|
21
19
|
- AML.T0051
|
|
@@ -61,7 +59,7 @@ forward_watch:
|
|
|
61
59
|
- Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — Chroma vector DB CWE-190 + CWE-362 chain by haehae; impacts RAG vector store integrity; track patch and downstream RAG advisory
|
|
62
60
|
- Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — NVIDIA Megatron Bridge overly permissive allowed list by Satoki Tsuji; AI training-stack supply-chain exposure; track patch and SBOM advisory
|
|
63
61
|
- Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — NVIDIA Megatron Bridge path traversal by haehae; AI training-stack file-system trust boundary; track patch and SBOM advisory
|
|
64
|
-
last_threat_review: "2026-05-
|
|
62
|
+
last_threat_review: "2026-05-17"
|
|
65
63
|
---
|
|
66
64
|
|
|
67
65
|
# AI Attack Surface Assessment
|
|
@@ -160,6 +158,15 @@ AI-assisted reconnaissance is observed at 36,000 probes per second per campaign.
|
|
|
160
158
|
| PCI DSS 4.0 | 6.4.1 | Web application protection (WAF). WAFs operate on HTTP request/response patterns. They have no semantic understanding of prompt injection embedded in JSON `message` fields. |
|
|
161
159
|
| MITRE ATT&CK | Enterprise | Does not include prompt injection as a technique. AI-as-C2 (SesameOp) is not in ATT&CK as of mid-2026. ATLAS v5.4.0 covers these but is not part of SOC detection engineering programs that are ATT&CK-mapped. |
|
|
162
160
|
| NIST AI RMF | MEASURE 2.5 | Measure AI risks during operation. Provides a framework for thinking about AI risk but no specific controls for prompt injection, MCP supply chain, or AI-as-C2. |
|
|
161
|
+
| EU NIS2 | Art. 21(2)(d) (supply-chain security) + Art. 21(2)(e) (security in acquisition, development and maintenance) | "Appropriate and proportionate" supply-chain language. Member-state transpositions (BSI IT-SiG 2.0, ANSSI) do not enumerate MCP servers or LLM API providers as in-scope supply-chain components. An essential entity can meet NIS2 supplier-management obligations with traditional SaaS vendor reviews while having zero coverage of AI-assistant tool ecosystems. |
|
|
162
|
+
| EU DORA | Art. 8 (ICT asset management) + Art. 28 (ICT third-party register) + Art. 30 (key contractual provisions) | Financial-entity ICT third-party language scoped to traditional ICT providers. LLM API providers acting as data processors for prompt content and developer-environment MCP servers are not enumerated as ICT third-party service providers. ESAs RTS on subcontracting (JC 2024/53) is silent on AI/ML SaaS dependency classes. |
|
|
163
|
+
| EU AI Act (Regulation 2024/1689) | Art. 15 (accuracy, robustness, cybersecurity) for high-risk AI + Art. 9 (risk management) | High-risk AI cybersecurity language refers to "state of the art" without naming prompt injection, MCP supply chain, or AI-as-C2 as scoped attack classes. Conformity assessments (Annex VI/VII) accept documentation completeness; harmonized standards (CEN-CENELEC JTC 21) through 2026-2027 may operationalize this. |
|
|
164
|
+
| UK NCSC CAF | Principle A4 (Supply Chain), B2 (Identity and Access Control), B4 (System Security), C1 (Security Monitoring) | Outcome-based language. NCSC's 2024 guidance on securing AI systems and the DSIT AI Cyber Code of Practice (2025) name the attack classes at the principle level (prompt injection, model supply chain, monitoring), but the CAF outcome statements are unchanged. An organisation achieves CAF outcomes at Achieved level with zero MCP-trust controls and zero prompt-injection detection. |
|
|
165
|
+
| UK DSIT AI Cyber Code of Practice (2025) | 13 principles for secure AI development and deployment | Principles-based. Names training-data integrity, model-deployment security, monitoring, and supply chain — but as principles, not testable controls. No technical floor for prompt-injection defence, MCP allowlisting, or AI-as-C2 detection. |
|
|
166
|
+
| AU ASD Essential 8 | Strategy: Application Control + User Application Hardening + Restrict Administrative Privileges | Application Control (allowlisting) covers what runs locally; it does not cover AI-assistant tool-use chains where the AI agent dynamically composes the executed action. None of the eight strategies address prompt injection, model supply chain, or LLM-as-C2 channel. |
|
|
167
|
+
| AU ASD ISM | ISM-1808 (cloud consumer responsibilities) + ISM-1728 (supply chain risk) + ISM-1228 (event monitoring) | ISM-1728 supply-chain control is scoped to traditional vendor classes; LLM APIs and MCP servers fall outside enumerated supply-chain categories. ISM-1228 event-log monitoring assumes signature-or-rule detection over known indicators — AI API egress as C2 and prompt-injection-coerced actions produce no traditional indicator. |
|
|
168
|
+
| AU Voluntary AI Safety Standard (10 guardrails, 2024) | Guardrails 5 (test and monitor), 6 (transparency), 8 (record-keeping) | Voluntary, principles-language. Operationally identical to the UK DSIT AI Cyber Code lag — names the right concerns at the principle layer without testable controls for prompt injection, MCP trust, or AI-as-C2 detection. |
|
|
169
|
+
| AU APRA CPS 234 | Para 27 (information security capability proportional to vulnerabilities and threats) + APRA CPG 235 (managing data risk) | "Proportional" capability language. APRA-regulated entities deploying AI assistants meet CPS 234 attestation with traditional information-security capability; AI-specific attack surface is not an examined capability class. APRA Information Paper on AI (2024) names the risks at the supervisory level without altering CPS 234 obligations. |
|
|
163
170
|
|
|
164
171
|
---
|
|
165
172
|
|
|
@@ -13,9 +13,10 @@ triggers:
|
|
|
13
13
|
- covert channel ai
|
|
14
14
|
- aml.t0096
|
|
15
15
|
data_deps:
|
|
16
|
-
- atlas-ttps.json
|
|
17
16
|
- cve-catalog.json
|
|
17
|
+
- d3fend-catalog.json
|
|
18
18
|
- framework-control-gaps.json
|
|
19
|
+
- rfc-references.json
|
|
19
20
|
atlas_refs:
|
|
20
21
|
- AML.T0096
|
|
21
22
|
- AML.T0017
|
|
@@ -48,7 +49,7 @@ d3fend_refs:
|
|
|
48
49
|
- D3-NI
|
|
49
50
|
- D3-NTA
|
|
50
51
|
- D3-NTPM
|
|
51
|
-
last_threat_review: "2026-05-
|
|
52
|
+
last_threat_review: "2026-05-17"
|
|
52
53
|
---
|
|
53
54
|
|
|
54
55
|
# AI C2 Detection
|
|
@@ -153,6 +154,14 @@ PROMPTSTEAL uses LLMs as live intelligence analysts for exfiltration targeting.
|
|
|
153
154
|
| ISO 27001:2022 A.8.16 | Monitoring Activities | Monitoring of systems, networks, and applications. No guidance for AI API behavioral baseline, no mention of AI traffic as a monitoring concern. |
|
|
154
155
|
| SOC 2 CC7 | System Operations (Anomaly Detection) | Detect and respond to security events. CC7 implementations baseline network traffic and system events. AI API calls are typically in the same anomaly detection blind spot as other SaaS traffic. |
|
|
155
156
|
| ATT&CK T1071 | Application Layer Protocol | ATT&CK documents C2 over application protocols. AI API as C2 fits the technique but detection guidance doesn't address legitimate-endpoint C2 specifically. |
|
|
157
|
+
| EU NIS2 | Art. 21(2)(b) (incident handling) + Art. 21(2)(g) (network and information systems security including monitoring) | "Appropriate and proportionate" monitoring language. Member-state transpositions (BSI IT-SiG 2.0, ANSSI, ENISA) do not enumerate AI-API egress baselining as an expected monitoring control. An essential entity meets the NIS2 monitoring obligation with traditional SIEM coverage while leaving AI-as-C2 entirely undetected. |
|
|
158
|
+
| EU DORA | Art. 10 (detection) + Art. 17 (ICT-related incident management) | Detection obligation for financial entities. RTS on threat-led penetration testing (TIBER-EU JC 2024/40) does not include AI-as-C2 scenarios in the TT&P inventory as of mid-2026. CBEST / iCAST scenario libraries lag by 12-18 months. |
|
|
159
|
+
| EU AI Act (Regulation 2024/1689) | Art. 15 (cybersecurity for high-risk AI systems) + Art. 72 (post-market monitoring) | High-risk AI cybersecurity language addresses adversarial robustness and integrity of the AI system itself. AI APIs being abused as a C2 channel by non-AI malware is outside the scoped attack surface — providers do not log per-prompt to detect attacker use, and operators have no mandated detection control for legitimate-endpoint C2. |
|
|
160
|
+
| UK NCSC CAF | Principle C1 (Security Monitoring) + Principle C2 (Proactive Security Event Discovery) | Outcome-based monitoring language. NCSC's 2024 guidance on monitoring egress to SaaS APIs recommends behavioural baselining but the CAF outcome statements are satisfied by traditional endpoint and network monitoring. An organisation can meet C1 / C2 at Achieved level with zero AI-API egress baselining. |
|
|
161
|
+
| UK NCSC Cyber Assessment Framework — sectoral profiles (Telecoms Security Code of Practice, Energy CAF profile) | Sector-specific monitoring obligations | Sectoral CAF profiles inherit C1/C2 outcomes; none enumerate AI API egress as an in-scope monitored channel. Telecoms operators meeting the TSA 2021 Code monitoring obligations have the same blind spot. |
|
|
162
|
+
| AU ASD Essential 8 | Strategy: Application Control + User Application Hardening | Application Control (allowlisting) covers what runs locally; it does not cover what allowed applications connect to. A whitelisted browser or IDE making AI API calls passes Application Control while operating as a C2 channel. Essential 8 does not include an egress-control strategy. |
|
|
163
|
+
| AU ASD ISM | ISM-1228 (event log monitoring) + ISM-0859 (network access controls) + ISM-1729 (data loss prevention) | Event-log monitoring assumes signature-or-rule detection over known malicious indicators. ISM-1729 DLP addresses outbound sensitive-data flows but is content-pattern based — AI-API egress with attacker-controlled prompts is data-flowing-to-a-trusted-vendor from the DLP perspective. |
|
|
164
|
+
| AU APRA CPS 234 | Para 27(b) (capability to detect and respond to information security incidents in a timely manner) | "Timely" detection capability. APRA CPS 234 attestations are satisfied by SIEM/SOC capability over traditional indicators. AI-as-C2 detection capability is not a CPS 234 examined control. |
|
|
156
165
|
|
|
157
166
|
---
|
|
158
167
|
|
|
@@ -18,10 +18,12 @@ triggers:
|
|
|
18
18
|
- ai management system
|
|
19
19
|
data_deps:
|
|
20
20
|
- atlas-ttps.json
|
|
21
|
-
-
|
|
22
|
-
- global-frameworks.json
|
|
21
|
+
- cve-catalog.json
|
|
23
22
|
- cwe-catalog.json
|
|
24
23
|
- d3fend-catalog.json
|
|
24
|
+
- exploit-availability.json
|
|
25
|
+
- framework-control-gaps.json
|
|
26
|
+
- global-frameworks.json
|
|
25
27
|
- zeroday-lessons.json
|
|
26
28
|
atlas_refs:
|
|
27
29
|
- AML.T0051
|
|
@@ -17,13 +17,7 @@ triggers:
|
|
|
17
17
|
- ai api security
|
|
18
18
|
- mcp transport
|
|
19
19
|
- openapi security
|
|
20
|
-
data_deps:
|
|
21
|
-
- cve-catalog.json
|
|
22
|
-
- atlas-ttps.json
|
|
23
|
-
- framework-control-gaps.json
|
|
24
|
-
- cwe-catalog.json
|
|
25
|
-
- d3fend-catalog.json
|
|
26
|
-
- rfc-references.json
|
|
20
|
+
data_deps: []
|
|
27
21
|
atlas_refs:
|
|
28
22
|
- AML.T0096
|
|
29
23
|
- AML.T0017
|
|
@@ -67,7 +61,7 @@ forward_watch:
|
|
|
67
61
|
- NGINX Rift CVE-2026-42945 (disclosed 2026-05-13, source depthfirst) — KEV-watch predicted CISA KEV listing by 2026-05-29; track for active-exploitation confirmation and patch advisory affecting API gateway / reverse-proxy deployments
|
|
68
62
|
- Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — LiteLLM 3-bug SSRF + Code Injection chain by k3vg3n; LLM-proxy API surface; track upstream patch and CVE assignments
|
|
69
63
|
- Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — LiteLLM full SSRF + Code Injection by Out Of Bounds (Byung Young Yi); duplicate-class with the k3vg3n entry; track unified patch advisory
|
|
70
|
-
last_threat_review: "2026-05-
|
|
64
|
+
last_threat_review: "2026-05-17"
|
|
71
65
|
---
|
|
72
66
|
|
|
73
67
|
# API Security Assessment
|
|
@@ -118,6 +112,11 @@ APIs are now the integration substrate of every non-trivial system. The mid-2026
|
|
|
118
112
|
| BR Open Finance (Bacen) | FAPI 2.0 derivative | Banking-API auth surface only. |
|
|
119
113
|
| IN UPI / Account Aggregator (NPCI / RBI) | Payments + AA security framework | Sector-specific payment-API + consent-API surface. AI-API egress out of scope. |
|
|
120
114
|
| NYDFS 23 NYCRR 500 | §500.5 penetration testing | APIs are in scope for the annual pen test where they expose covered data. "Annual" is structurally inadequate against agentic API-exploit timelines. |
|
|
115
|
+
| UK NCSC CAF | Principle B2 (Identity and Access Control), B4 (System Security), C1 (Security Monitoring) | Outcome-based assessment. CAF outcomes are silent on BOLA / BFLA / BOPLA as testable surfaces and silent on AI-API egress baselining. An organisation can achieve CAF outcomes at Achieved level with zero per-object authorisation testing and zero AI-API consumer monitoring. NCSC API Security Guidance (2024) recommends per-object scoping but is not a CAF outcome statement. |
|
|
116
|
+
| UK FCA / PRA SS1/21 (Operational Resilience) + CBEST | Important Business Service tolerance + threat-led pen testing | CBEST scenario libraries lag adversary capability 12-18 months and rarely include BOLA/BFLA-by-AI-agent or AI-API-as-C2 test cases. An FCA-attested operational-resilience programme can be "compliant" with zero exercised coverage of agentic API exploitation. |
|
|
117
|
+
| AU ASD Essential 8 | Strategy: Restrict Administrative Privileges + Application Control + MFA | None of the eight strategies address API-level authorisation (per-object scoping, per-field scoping) or AI-API egress monitoring. Essential 8 ML3 attestation does not bind any API security control surface. |
|
|
118
|
+
| AU ASD ISM | ISM-1228 (event log monitoring) + ISM-1546 (MFA on privileged access) + ISM-1808 (cloud consumer responsibilities) | Event-log monitoring assumes traditional indicators; BOLA / BFLA exploitation produces authenticated, authorised log entries with attacker-supplied object IDs. ISM-1808 cloud-consumer language does not address AI-API consumer scope. |
|
|
119
|
+
| AU APRA CPS 234 + CPS 230 | Para 27 (information security capability) + CPS 230 ICT-service-provider obligations | "Proportional capability" language. APRA-regulated entities meet CPS 234 attestation with traditional API gateway + WAF posture; per-object authorisation testing depth and AI-API consumer monitoring are not examined capability classes. CPS 230 third-party-arrangements obligations do not enumerate AI-API providers as in-scope material service providers. |
|
|
121
120
|
|
|
122
121
|
---
|
|
123
122
|
|
|
@@ -16,10 +16,10 @@ triggers:
|
|
|
16
16
|
- asm
|
|
17
17
|
data_deps:
|
|
18
18
|
- cve-catalog.json
|
|
19
|
-
- atlas-ttps.json
|
|
20
|
-
- framework-control-gaps.json
|
|
21
19
|
- cwe-catalog.json
|
|
22
20
|
- d3fend-catalog.json
|
|
21
|
+
- exploit-availability.json
|
|
22
|
+
- framework-control-gaps.json
|
|
23
23
|
atlas_refs:
|
|
24
24
|
- AML.T0043
|
|
25
25
|
- AML.T0051
|
|
@@ -23,12 +23,8 @@ triggers:
|
|
|
23
23
|
- access key public repo
|
|
24
24
|
data_deps:
|
|
25
25
|
- cve-catalog.json
|
|
26
|
-
- atlas-ttps.json
|
|
27
|
-
- attack-techniques.json
|
|
28
|
-
- framework-control-gaps.json
|
|
29
|
-
- global-frameworks.json
|
|
30
|
-
- cwe-catalog.json
|
|
31
26
|
- d3fend-catalog.json
|
|
27
|
+
- framework-control-gaps.json
|
|
32
28
|
atlas_refs:
|
|
33
29
|
- AML.T0051
|
|
34
30
|
attack_refs:
|
|
@@ -11,7 +11,7 @@ triggers:
|
|
|
11
11
|
- checkbox security
|
|
12
12
|
- audit theater
|
|
13
13
|
data_deps:
|
|
14
|
-
-
|
|
14
|
+
- atlas-ttps.json
|
|
15
15
|
- cve-catalog.json
|
|
16
16
|
- exploit-availability.json
|
|
17
17
|
atlas_refs: []
|
|
@@ -21,7 +21,7 @@ framework_gaps:
|
|
|
21
21
|
- ALL-PROMPT-INJECTION-ACCESS-CONTROL
|
|
22
22
|
- FedRAMP-Rev5-Moderate
|
|
23
23
|
- CMMC-2.0-Level-2
|
|
24
|
-
last_threat_review: "2026-05-
|
|
24
|
+
last_threat_review: "2026-05-17"
|
|
25
25
|
---
|
|
26
26
|
|
|
27
27
|
# Compliance Theater Detection
|
|
@@ -65,6 +65,14 @@ Compliance theater is the operational shadow of framework lag. Per-framework lag
|
|
|
65
65
|
| NIST 800-53 | AT-2 (Security Awareness Training) | Drafted against human-template phishing. 82.6% of phishing emails now contain AI-generated content. Grammar/style heuristics are no longer reliable detectors. A < 5% click rate on human-generated simulations says nothing about resistance to AI-generated highly personalized spear-phishing. |
|
|
66
66
|
| US FedRAMP | Rev 5 Moderate baseline | Authorization-as-evidence pattern. A current ATO certifies that the CSP's control implementation was assessed against the Rev 5 Moderate baseline at a point in time. It does not certify that the CSP has any control over MCP servers running in tenant developer environments, prompt-injection attack surface in AI features, or AI-API providers used downstream. The Authority To Operate is treated by procurement as a security guarantee — Pattern 6 (Vendor/Third-Party Risk Theater) recurs at the federal-cloud layer. |
|
|
67
67
|
| US DoD | CMMC 2.0 Level 2 (110 NIST 800-171 practices) | Certification-as-evidence pattern. A Level 2 certificate attests to assessor-verified implementation of the 110 practices at the time of assessment. It does not cover AI coding-assistant supply chain, MCP server trust on engineering workstations developing CUI-touching software, or model-update change control. The same Pattern 5 (Change Management Theater) and Pattern 6 (Vendor Management Theater) patterns recur with sharper consequences because CMMC gates DoD contract eligibility. |
|
|
68
|
+
| EU NIS2 | Art. 21(2)(c) (vulnerability handling and disclosure) + Art. 21(2)(d) (supply-chain security) | "Appropriate and proportionate" measures language. Member-state transpositions (BSI IT-SiG 2.0, ANSSI, CNIL, ENISA technical guidance) typically pin remediation to CVSS bands with month-scale SLAs. NIS2 does not operationalize CISA-KEV-class urgency, AI-discovery weighting, or MCP/LLM third-party scope. An essential entity can be NIS2-compliant on paper while leaving CVE-2026-31431 and CVE-2026-30615 class exposures unaddressed inside the regulator's expected remediation window. |
|
|
69
|
+
| EU DORA | Art. 6 (ICT risk-management framework) + Art. 28 (ICT third-party risk) | Financial-entity ICT risk language scoped to traditional ICT providers and cloud outsourcing. Does not enumerate LLM API providers as ICT third-party service providers requiring the Art. 28 register, contractual safeguards, and exit-strategy obligations. ESAs RTS on subcontracting (JC 2024/53) is silent on MCP servers running inside trading-desk developer environments. Pattern 6 (Vendor Management Theater) recurs cleanly inside a DORA-compliant TPRM programme. |
|
|
70
|
+
| EU AI Act (Regulation 2024/1689) | Art. 9 (risk management) + Art. 15 (accuracy, robustness, cybersecurity) for high-risk AI | High-risk AI cybersecurity language refers to "state of the art" without naming prompt injection, model-update change control, or MCP supply chain as scoped attack classes. Conformity assessments under Annex VI/VII can pass on documentation completeness while leaving Pattern 3 (Access Control Theater) and Pattern 5 (Change Management Theater) wide open. Implementing acts and harmonized standards (CEN-CENELEC JTC 21) through 2026-2027 may tighten this. |
|
|
71
|
+
| UK NCSC CAF | Principle A2 (Risk Management), B2 (Identity and Access Control), B4 (System Security), D1 (Response and Recovery) | Outcome-based assessment language ("Risks are identified, assessed and understood"; "Access is appropriately controlled"). Outcome language permits theater because the auditor verifies that an outcome statement exists, not that the underlying control disrupts the documented adversary TTP. NCSC's 2024 prompt-injection and AI-supply-chain guidance updates the threat narrative but the CAF outcome statements are unchanged — Patterns 3 / 5 / 6 recur cleanly inside a CAF Level-3 attestation. |
|
|
72
|
+
| UK FCA / PRA SS1/21 (Operational Resilience) | Important Business Service tolerance + scenario testing | Operational-resilience scenario testing is principle-based about severe-but-plausible disruptions. CBEST TIBER-EU scenario libraries lag adversary capability 12-18 months and rarely include AI-as-C2 / prompt-injection / MCP-class scenarios. An FCA-attested IBS resilience programme can be "compliant" with zero exercised coverage of Patterns 3 / 4 / 5 / 6 / 7. |
|
|
73
|
+
| AU APRA CPS 234 | Para 26 (notification) + Para 27 (information security capability proportional to vulnerabilities and threats) | "Proportional to vulnerabilities and threats" language. APRA quarterly returns and tripartite reviews verify documented capability exists; they do not verify the capability disrupts a current-vintage TTP. CPS 234 attestation can be clean while Patterns 1 / 3 / 5 / 6 / 7 are all present. CPS 230 operational-resilience overlay (effective 2025-07-01) is silent on AI-specific operational scenarios. |
|
|
74
|
+
| AU ASD Essential 8 | Patch Applications + Patch Operating Systems + Restrict Administrative Privileges (ML1-ML3) | ML3 48-hour patch window with public exploit is the closest national baseline to adequate for Pattern 1, but the other six strategies (User Application Hardening, Office Macros, Application Control, Daily Backups, MFA, Restrict Admin) do not address Patterns 3 / 5 / 6 / 7 at all. ACSC assessments score the eight strategies; they do not score AI-pipeline integrity or LLM-provider third-party risk. |
|
|
75
|
+
| AU Voluntary AI Safety Standard (10 guardrails, 2024) | Guardrails 5 (test and monitor), 7 (transparency), 8 (record-keeping), 10 (stakeholder engagement) | Voluntary, principles-language. Operationally identical to the EU AI Act / UK DSIT AI Cyber Code lag — names the right concerns at the principle layer without testable controls. Patterns 3 / 4 / 5 are unaddressed by current guardrail attestation. |
|
|
68
76
|
|
|
69
77
|
The pre-analyzed gaps for these controls live in the framework-gap-analysis skill's Built-In Gap Catalog. This skill consumes those gaps and produces a theater detection per gap.
|
|
70
78
|
|
|
@@ -22,11 +22,9 @@ triggers:
|
|
|
22
22
|
- vllm
|
|
23
23
|
data_deps:
|
|
24
24
|
- cve-catalog.json
|
|
25
|
-
- atlas-ttps.json
|
|
26
|
-
- framework-control-gaps.json
|
|
27
25
|
- cwe-catalog.json
|
|
28
26
|
- d3fend-catalog.json
|
|
29
|
-
-
|
|
27
|
+
- framework-control-gaps.json
|
|
30
28
|
atlas_refs:
|
|
31
29
|
- AML.T0010
|
|
32
30
|
attack_refs:
|
|
@@ -18,13 +18,12 @@ triggers:
|
|
|
18
18
|
- embedding store exfil
|
|
19
19
|
- clipboard ai paste
|
|
20
20
|
data_deps:
|
|
21
|
-
- dlp-controls.json
|
|
22
21
|
- cve-catalog.json
|
|
23
|
-
- atlas-ttps.json
|
|
24
|
-
- framework-control-gaps.json
|
|
25
|
-
- global-frameworks.json
|
|
26
22
|
- cwe-catalog.json
|
|
27
23
|
- d3fend-catalog.json
|
|
24
|
+
- dlp-controls.json
|
|
25
|
+
- framework-control-gaps.json
|
|
26
|
+
- global-frameworks.json
|
|
28
27
|
atlas_refs:
|
|
29
28
|
- AML.T0096
|
|
30
29
|
- AML.T0017
|
|
@@ -20,14 +20,7 @@ triggers:
|
|
|
20
20
|
- deepfake phishing
|
|
21
21
|
- ai phishing
|
|
22
22
|
- secure email gateway
|
|
23
|
-
data_deps:
|
|
24
|
-
- cve-catalog.json
|
|
25
|
-
- atlas-ttps.json
|
|
26
|
-
- framework-control-gaps.json
|
|
27
|
-
- cwe-catalog.json
|
|
28
|
-
- d3fend-catalog.json
|
|
29
|
-
- rfc-references.json
|
|
30
|
-
- dlp-controls.json
|
|
23
|
+
data_deps: []
|
|
31
24
|
atlas_refs: []
|
|
32
25
|
attack_refs:
|
|
33
26
|
- T1566
|
|
@@ -12,14 +12,16 @@ triggers:
|
|
|
12
12
|
- patch priority
|
|
13
13
|
- beyond cvss
|
|
14
14
|
data_deps:
|
|
15
|
+
- atlas-ttps.json
|
|
15
16
|
- cve-catalog.json
|
|
16
17
|
- exploit-availability.json
|
|
18
|
+
- zeroday-lessons.json
|
|
17
19
|
atlas_refs: []
|
|
18
20
|
attack_refs: []
|
|
19
21
|
framework_gaps:
|
|
20
22
|
- CWE-Top-25-2024-meta
|
|
21
23
|
- CIS-Controls-v8-Control7
|
|
22
|
-
last_threat_review: "2026-05-
|
|
24
|
+
last_threat_review: "2026-05-17"
|
|
23
25
|
---
|
|
24
26
|
|
|
25
27
|
# Real-World Exploit Priority (RWEP) Scoring
|
|
@@ -57,7 +59,10 @@ RWEP exists because the exploit development cycle has compressed. The factors th
|
|
|
57
59
|
| ISO 27001:2022 | A.8.8 (Management of technical vulnerabilities) | "Appropriate timescales" set by risk classification, typically CVSS-driven | Risk classification methodology is not specified; in practice orgs use CVSS bands. Standard offers no guidance distinguishing AI-discovered KEV-listed from theoretical High. |
|
|
58
60
|
| CIS Controls v8 | Control 7 (Continuous Vulnerability Management) | IG1/IG2/IG3 timelines indexed on CVSS Critical/High | Same CVSS-anchored SLA failure. No factor for KEV status as a re-prioritization trigger. |
|
|
59
61
|
| NIS2 Directive | Art. 21 (vulnerability handling) | "Appropriate measures" — methodology unspecified | In practice essential/important entities map this to CVSS-driven internal SLAs. Standard does not require any non-CVSS factor. |
|
|
60
|
-
|
|
|
62
|
+
| UK NCSC CAF | Principle B4 (System Security) — vulnerability and patch management contributing outcomes | Outcome-based: "Vulnerabilities are identified and addressed appropriately" | Outcome language permits CVSS-only prioritization. No requirement to factor KEV listing, public-PoC availability, or AI-discovery into the remediation cadence. NCSC Vulnerability Management Guidance (2024) recommends but does not require exploit-availability weighting. |
|
|
63
|
+
| UK Cyber Essentials Plus | Patch management criterion | Critical/High patches within 14 days | CVSS-anchored 14-day window. No factor for CISA KEV / public PoC. Tighter than NIST/PCI but still framework-lag-vulnerable for AI-accelerated 4-hour weaponization. |
|
|
64
|
+
| AU ASD Essential 8 | Patch Operating Systems ML1–ML3 | ML3: 48h for OS vulns "with working exploit" | Closest to adequate — at least incorporates exploit availability. Still does not model AI-discovery, KEV, blast radius, or live-patch availability. 48h window remains long for AI-accelerated weaponization. |
|
|
65
|
+
| AU ASD ISM | Control ISM-1493 (vulnerability management) + ISM-1144 (patching frequency) | Risk-based patching aligned to vendor severity / exploitability | "Exploitability" not operationalized as KEV / public-PoC / AI-discovery factors. Risk-based language permits CVSS-only ranking in practice. |
|
|
61
66
|
| FedRAMP Continuous Monitoring | Vuln scan cadence + CVSS-band remediation | Monthly scans, CVSS-banded SLAs | Cadence-based detection plus CVSS-banded remediation cannot respond inside the AI-accelerated exploit window. |
|
|
62
67
|
|
|
63
68
|
Across all of these, the framework lag is the same shape: **CVSS-as-risk-proxy.** RWEP is the operational corrective layer.
|