@blamejs/exceptd-skills 0.16.14 → 0.16.16
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 +3 -1
- package/CHANGELOG.md +8 -0
- package/README.md +5 -5
- package/bin/exceptd.js +3 -1
- package/data/_indexes/_meta.json +17 -15
- package/data/_indexes/activity-feed.json +16 -2
- package/data/_indexes/chains.json +7429 -451
- package/data/_indexes/currency.json +19 -1
- package/data/_indexes/frequency.json +135 -64
- package/data/_indexes/handoff-dag.json +9 -1
- package/data/_indexes/jurisdiction-map.json +11 -4
- package/data/_indexes/section-offsets.json +170 -0
- package/data/_indexes/stale-content.json +1 -1
- package/data/_indexes/summary-cards.json +77 -0
- package/data/_indexes/token-budget.json +103 -3
- package/data/_indexes/trigger-table.json +98 -1
- package/data/_indexes/xref.json +45 -4
- package/data/cwe-catalog.json +21 -5
- package/data/playbooks/cloud-iam-incident.json +26 -5
- package/data/playbooks/framework.json +2 -0
- package/data/playbooks/multitenancy-isolation.json +660 -0
- package/data/playbooks/sbom.json +21 -6
- package/data/playbooks/self-update-integrity.json +636 -0
- package/manifest-snapshot.json +106 -2
- package/manifest-snapshot.sha256 +1 -1
- package/manifest.json +160 -48
- package/package.json +2 -2
- package/sbom.cdx.json +92 -32
- package/skills/multitenancy-isolation/skill.md +83 -0
- package/skills/self-update-integrity/skill.md +79 -0
package/sbom.cdx.json
CHANGED
|
@@ -1,23 +1,23 @@
|
|
|
1
1
|
{
|
|
2
2
|
"bomFormat": "CycloneDX",
|
|
3
3
|
"specVersion": "1.6",
|
|
4
|
-
"serialNumber": "urn:uuid:
|
|
4
|
+
"serialNumber": "urn:uuid:04e89773-5ab6-4db8-9c18-bb4abb56fd87",
|
|
5
5
|
"version": 1,
|
|
6
6
|
"metadata": {
|
|
7
|
-
"timestamp": "
|
|
7
|
+
"timestamp": "2028-08-11T03:33:07.000Z",
|
|
8
8
|
"tools": [
|
|
9
9
|
{
|
|
10
10
|
"vendor": "blamejs",
|
|
11
11
|
"name": "scripts/refresh-sbom.js",
|
|
12
|
-
"version": "0.16.
|
|
12
|
+
"version": "0.16.16"
|
|
13
13
|
}
|
|
14
14
|
],
|
|
15
15
|
"component": {
|
|
16
|
-
"bom-ref": "pkg:npm/@blamejs/exceptd-skills@0.16.
|
|
16
|
+
"bom-ref": "pkg:npm/@blamejs/exceptd-skills@0.16.16",
|
|
17
17
|
"type": "application",
|
|
18
18
|
"name": "@blamejs/exceptd-skills",
|
|
19
|
-
"version": "0.16.
|
|
20
|
-
"description": "AI security skills grounded in mid-2026 threat reality, not stale framework documentation.
|
|
19
|
+
"version": "0.16.16",
|
|
20
|
+
"description": "AI security skills grounded in mid-2026 threat reality, not stale framework documentation. 48 skills, 11 catalogs (439 CVEs / 174 CWEs / 805 ATT&CK + ICS / 170 ATLAS / 468 D3FEND / 8888 RFCs), 35 jurisdictions, 10-class catalog gap detector + budget gate, real XML parser + canonical-form diff + content-pattern regression detection, Ed25519-signed.",
|
|
21
21
|
"licenses": [
|
|
22
22
|
{
|
|
23
23
|
"license": {
|
|
@@ -25,17 +25,17 @@
|
|
|
25
25
|
}
|
|
26
26
|
}
|
|
27
27
|
],
|
|
28
|
-
"purl": "pkg:npm/%40blamejs/exceptd-skills@0.16.
|
|
28
|
+
"purl": "pkg:npm/%40blamejs/exceptd-skills@0.16.16",
|
|
29
29
|
"hashes": [
|
|
30
30
|
{
|
|
31
31
|
"alg": "SHA-256",
|
|
32
|
-
"content": "
|
|
32
|
+
"content": "19fd1d02fb02bcc9ce834018a04cb4499913fc116b9c3d1afe8e0553161e9b91"
|
|
33
33
|
}
|
|
34
34
|
],
|
|
35
35
|
"externalReferences": [
|
|
36
36
|
{
|
|
37
37
|
"type": "distribution",
|
|
38
|
-
"url": "https://www.npmjs.com/package/@blamejs/exceptd-skills/v/0.16.
|
|
38
|
+
"url": "https://www.npmjs.com/package/@blamejs/exceptd-skills/v/0.16.16"
|
|
39
39
|
},
|
|
40
40
|
{
|
|
41
41
|
"type": "vcs",
|
|
@@ -54,7 +54,7 @@
|
|
|
54
54
|
},
|
|
55
55
|
{
|
|
56
56
|
"name": "exceptd:skill:count",
|
|
57
|
-
"value": "
|
|
57
|
+
"value": "48"
|
|
58
58
|
},
|
|
59
59
|
{
|
|
60
60
|
"name": "exceptd:integrity:method",
|
|
@@ -86,11 +86,11 @@
|
|
|
86
86
|
"hashes": [
|
|
87
87
|
{
|
|
88
88
|
"alg": "SHA-256",
|
|
89
|
-
"content": "
|
|
89
|
+
"content": "c33b531131baa65065c83571c6b8e24509ebf8c996f3d4201c1455748a38504a"
|
|
90
90
|
},
|
|
91
91
|
{
|
|
92
92
|
"alg": "SHA3-512",
|
|
93
|
-
"content": "
|
|
93
|
+
"content": "654f61a4cd4a95467903a2f2c5b1d1d5d14c16d4b098993fce89d35b51c0f9f3192e8789a5ad887eac75cd90044096b6c3a9341665f663306186bad4edfbe0fc"
|
|
94
94
|
}
|
|
95
95
|
]
|
|
96
96
|
},
|
|
@@ -116,11 +116,11 @@
|
|
|
116
116
|
"hashes": [
|
|
117
117
|
{
|
|
118
118
|
"alg": "SHA-256",
|
|
119
|
-
"content": "
|
|
119
|
+
"content": "3049953c76658c14f8e4b6f6cfc4eaa717d1ea872b90b46e0d32a0b7b6fab3b5"
|
|
120
120
|
},
|
|
121
121
|
{
|
|
122
122
|
"alg": "SHA3-512",
|
|
123
|
-
"content": "
|
|
123
|
+
"content": "3e0978a7d16170cf31e425b9e945b48a8c8146aad38f246847a2d2deeff41013cc38193ff09afe849eda8b4cfb3bf889522f68b0115d5a5e2676f75d21912aac"
|
|
124
124
|
}
|
|
125
125
|
]
|
|
126
126
|
},
|
|
@@ -176,11 +176,11 @@
|
|
|
176
176
|
"hashes": [
|
|
177
177
|
{
|
|
178
178
|
"alg": "SHA-256",
|
|
179
|
-
"content": "
|
|
179
|
+
"content": "d60ea592639a1c721162bdb8f72b5b12d624cefc90f36b606b7f116353e36b08"
|
|
180
180
|
},
|
|
181
181
|
{
|
|
182
182
|
"alg": "SHA3-512",
|
|
183
|
-
"content": "
|
|
183
|
+
"content": "18a5b34d22cc5b4e43da00c891f30ecb1cc535876dc9de3983b5886bbd9492c3731c3f41688e0d2f6a5d1017331fef97fcfd780f7ef6d5b2a04ce8d61029970c"
|
|
184
184
|
}
|
|
185
185
|
]
|
|
186
186
|
},
|
|
@@ -281,11 +281,11 @@
|
|
|
281
281
|
"hashes": [
|
|
282
282
|
{
|
|
283
283
|
"alg": "SHA-256",
|
|
284
|
-
"content": "
|
|
284
|
+
"content": "d3715b8a3a5fa54d7b5b0176bc6adac8f2ee0113f40b6b9ea96ca63d673b202f"
|
|
285
285
|
},
|
|
286
286
|
{
|
|
287
287
|
"alg": "SHA3-512",
|
|
288
|
-
"content": "
|
|
288
|
+
"content": "bf130a643490db459df0adb4cca9b03e116c1524f2940746b13a916ba1d22b90342b5963b0650627669dd07ed12518a149c758afa02ffb7f7fe7962ce87fdb12"
|
|
289
289
|
}
|
|
290
290
|
]
|
|
291
291
|
},
|
|
@@ -341,11 +341,11 @@
|
|
|
341
341
|
"hashes": [
|
|
342
342
|
{
|
|
343
343
|
"alg": "SHA-256",
|
|
344
|
-
"content": "
|
|
344
|
+
"content": "11e035b62bf760eb7ea5e408b7364f737f3b3510612d6a65948c8d8ab1085587"
|
|
345
345
|
},
|
|
346
346
|
{
|
|
347
347
|
"alg": "SHA3-512",
|
|
348
|
-
"content": "
|
|
348
|
+
"content": "ecf8f495282ad4302cf058f4a8846afeddfc2cc04ea879b883e995a3b5c9555e292b59dbc8e0679e40678c5212bf9b4c3737c0d8b1c5528fc7fa08c12d63a7b8"
|
|
349
349
|
}
|
|
350
350
|
]
|
|
351
351
|
},
|
|
@@ -506,11 +506,11 @@
|
|
|
506
506
|
"hashes": [
|
|
507
507
|
{
|
|
508
508
|
"alg": "SHA-256",
|
|
509
|
-
"content": "
|
|
509
|
+
"content": "8d5945f5aff2d349b852572c84ff76ab8b14fab7b38aaa0b968ca56c5496b2fe"
|
|
510
510
|
},
|
|
511
511
|
{
|
|
512
512
|
"alg": "SHA3-512",
|
|
513
|
-
"content": "
|
|
513
|
+
"content": "78c1767f798485e2143283c00edf50bf3402d8bdd3fe085533d6beb004d870a226159bc6ba45e2adb18bde241d30d0ebc5bc87f1ba4820fe6dd05da567d6e265"
|
|
514
514
|
}
|
|
515
515
|
]
|
|
516
516
|
},
|
|
@@ -581,11 +581,11 @@
|
|
|
581
581
|
"hashes": [
|
|
582
582
|
{
|
|
583
583
|
"alg": "SHA-256",
|
|
584
|
-
"content": "
|
|
584
|
+
"content": "81dcd98aca801cccdeb81063af985cc2e87015cc750a42f3f557b35968d7730d"
|
|
585
585
|
},
|
|
586
586
|
{
|
|
587
587
|
"alg": "SHA3-512",
|
|
588
|
-
"content": "
|
|
588
|
+
"content": "c27c06699191eb8b08d39a6a2fe02b547f7bb95dca79d07d9e5b02b8a5ccfc5396f20c0d89cc45be3404829baceb505794dc20efda2a3787e52d3a51f036fe30"
|
|
589
589
|
}
|
|
590
590
|
]
|
|
591
591
|
},
|
|
@@ -709,6 +709,21 @@
|
|
|
709
709
|
}
|
|
710
710
|
]
|
|
711
711
|
},
|
|
712
|
+
{
|
|
713
|
+
"bom-ref": "file:data/playbooks/multitenancy-isolation.json",
|
|
714
|
+
"type": "file",
|
|
715
|
+
"name": "data/playbooks/multitenancy-isolation.json",
|
|
716
|
+
"hashes": [
|
|
717
|
+
{
|
|
718
|
+
"alg": "SHA-256",
|
|
719
|
+
"content": "3ca080c89326dc369736dadb12431379bd039cf3776ee9633992b0fef42130fc"
|
|
720
|
+
},
|
|
721
|
+
{
|
|
722
|
+
"alg": "SHA3-512",
|
|
723
|
+
"content": "9e085d55f4ae506cde7d06285a0efe9f13df12b9b0042a84b6d48bddc4e7dff628dc7e8a6ae92aa35a0047521428338c822b2252775da1d32817634d482d65fd"
|
|
724
|
+
}
|
|
725
|
+
]
|
|
726
|
+
},
|
|
712
727
|
{
|
|
713
728
|
"bom-ref": "file:data/playbooks/network-trust.json",
|
|
714
729
|
"type": "file",
|
|
@@ -776,11 +791,11 @@
|
|
|
776
791
|
"hashes": [
|
|
777
792
|
{
|
|
778
793
|
"alg": "SHA-256",
|
|
779
|
-
"content": "
|
|
794
|
+
"content": "30b2bcf9d032d29e4da0d2fbb372441f9a510b325818485e9135c668748ecbd9"
|
|
780
795
|
},
|
|
781
796
|
{
|
|
782
797
|
"alg": "SHA3-512",
|
|
783
|
-
"content": "
|
|
798
|
+
"content": "42f28be0b807304e39f86d3ddf75129dacf68b6dc0d341e6119c09692f4e0ede17c7d025351337deb900657ee36ced0e951981f4b81d4ea793ff79d19d2b0594"
|
|
784
799
|
}
|
|
785
800
|
]
|
|
786
801
|
},
|
|
@@ -799,6 +814,21 @@
|
|
|
799
814
|
}
|
|
800
815
|
]
|
|
801
816
|
},
|
|
817
|
+
{
|
|
818
|
+
"bom-ref": "file:data/playbooks/self-update-integrity.json",
|
|
819
|
+
"type": "file",
|
|
820
|
+
"name": "data/playbooks/self-update-integrity.json",
|
|
821
|
+
"hashes": [
|
|
822
|
+
{
|
|
823
|
+
"alg": "SHA-256",
|
|
824
|
+
"content": "f069f73dfcfa8148d585ad5976829518c1f0ca37b3a95a7011b7494f78825731"
|
|
825
|
+
},
|
|
826
|
+
{
|
|
827
|
+
"alg": "SHA3-512",
|
|
828
|
+
"content": "70ff865b8e93cad5424a0c50bf487e717c2fdeb469de7775e8f203913b32fec8c3f8ad95d07e30d27989c94db1e328d1271167531fd898e2a84c66b8ca585df2"
|
|
829
|
+
}
|
|
830
|
+
]
|
|
831
|
+
},
|
|
802
832
|
{
|
|
803
833
|
"bom-ref": "file:data/playbooks/supply-chain-recovery.json",
|
|
804
834
|
"type": "file",
|
|
@@ -1781,11 +1811,11 @@
|
|
|
1781
1811
|
"hashes": [
|
|
1782
1812
|
{
|
|
1783
1813
|
"alg": "SHA-256",
|
|
1784
|
-
"content": "
|
|
1814
|
+
"content": "58d5adcb2f75841236338793c49b71adbd5662743fbd444b16c349dd26edbd21"
|
|
1785
1815
|
},
|
|
1786
1816
|
{
|
|
1787
1817
|
"alg": "SHA3-512",
|
|
1788
|
-
"content": "
|
|
1818
|
+
"content": "bfbca81d382983435fd8994cb4bed554d56d01008dd5ae6f581c61d00d88a2791087e56cd405ad1e9e7e0255a1ee454562ba6c6276446077a53f97df606e52c8"
|
|
1789
1819
|
}
|
|
1790
1820
|
]
|
|
1791
1821
|
},
|
|
@@ -1796,11 +1826,11 @@
|
|
|
1796
1826
|
"hashes": [
|
|
1797
1827
|
{
|
|
1798
1828
|
"alg": "SHA-256",
|
|
1799
|
-
"content": "
|
|
1829
|
+
"content": "643d612268e8a98f27a0d53e2f749bc81d217ae3c37b47d90075c81d676db09f"
|
|
1800
1830
|
},
|
|
1801
1831
|
{
|
|
1802
1832
|
"alg": "SHA3-512",
|
|
1803
|
-
"content": "
|
|
1833
|
+
"content": "273e5881d3832a17c574cf1f933219f7f1209593cd5c6cf9e821899594af3f55bf6f4168f1217b8beca2f11483516cfbba46d8d292d10df19761fa512a14201f"
|
|
1804
1834
|
}
|
|
1805
1835
|
]
|
|
1806
1836
|
},
|
|
@@ -1811,11 +1841,11 @@
|
|
|
1811
1841
|
"hashes": [
|
|
1812
1842
|
{
|
|
1813
1843
|
"alg": "SHA-256",
|
|
1814
|
-
"content": "
|
|
1844
|
+
"content": "9156c60052b185a8d265bbb53d586ed6be9b1387b2aa2cdb77186bed997d5fbd"
|
|
1815
1845
|
},
|
|
1816
1846
|
{
|
|
1817
1847
|
"alg": "SHA3-512",
|
|
1818
|
-
"content": "
|
|
1848
|
+
"content": "3f1fefe1ff7236635e00a4e92886980f747fe546827fa134ac122cf276cf09420778d051b6f736ced0c5d9592300a41c7aeced7ddf584ec6f1f47c662307cff5"
|
|
1819
1849
|
}
|
|
1820
1850
|
]
|
|
1821
1851
|
},
|
|
@@ -3004,6 +3034,21 @@
|
|
|
3004
3034
|
}
|
|
3005
3035
|
]
|
|
3006
3036
|
},
|
|
3037
|
+
{
|
|
3038
|
+
"bom-ref": "file:skills/multitenancy-isolation/skill.md",
|
|
3039
|
+
"type": "file",
|
|
3040
|
+
"name": "skills/multitenancy-isolation/skill.md",
|
|
3041
|
+
"hashes": [
|
|
3042
|
+
{
|
|
3043
|
+
"alg": "SHA-256",
|
|
3044
|
+
"content": "60d7db9cbac49b307c7062a3b27a3cef8aab8cc774176c428075981fbc18758f"
|
|
3045
|
+
},
|
|
3046
|
+
{
|
|
3047
|
+
"alg": "SHA3-512",
|
|
3048
|
+
"content": "702591a3b7a299e2d204dc48c24cc4123379de1aa9912597149b9c1be3f42cd490c0c4cb7afba9dba310283237a4d4f01a2f2842650daa6820f3af4e0eeaa0cf"
|
|
3049
|
+
}
|
|
3050
|
+
]
|
|
3051
|
+
},
|
|
3007
3052
|
{
|
|
3008
3053
|
"bom-ref": "file:skills/network-trust/skill.md",
|
|
3009
3054
|
"type": "file",
|
|
@@ -3199,6 +3244,21 @@
|
|
|
3199
3244
|
}
|
|
3200
3245
|
]
|
|
3201
3246
|
},
|
|
3247
|
+
{
|
|
3248
|
+
"bom-ref": "file:skills/self-update-integrity/skill.md",
|
|
3249
|
+
"type": "file",
|
|
3250
|
+
"name": "skills/self-update-integrity/skill.md",
|
|
3251
|
+
"hashes": [
|
|
3252
|
+
{
|
|
3253
|
+
"alg": "SHA-256",
|
|
3254
|
+
"content": "305d4841d7434e18812be4b8646eb7a4f7f4416e3646aad3b6e7152d16f0c8af"
|
|
3255
|
+
},
|
|
3256
|
+
{
|
|
3257
|
+
"alg": "SHA3-512",
|
|
3258
|
+
"content": "59dfe4b515245a41fb56d4420e42999ebdf53c7e5f80d491637e0ef71c23bbc1c3eda25d0e6a4e44785940446473a3784e909196d7575d636594ecd9c554e213"
|
|
3259
|
+
}
|
|
3260
|
+
]
|
|
3261
|
+
},
|
|
3202
3262
|
{
|
|
3203
3263
|
"bom-ref": "file:skills/skill-update-loop/skill.md",
|
|
3204
3264
|
"type": "file",
|
|
@@ -0,0 +1,83 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: multitenancy-isolation
|
|
3
|
+
version: "1.0.0"
|
|
4
|
+
description: Application multitenancy isolation and availability/DoS resilience for mid-2026 — principal-bound tenant identity, data-layer row-level-security under a non-bypass role, cross-tenant cache/queue namespacing, per-tenant rate/byte quotas, HTTP/2 Rapid Reset caps, bounded allocation, distributed-lock fencing, and circuit breakers
|
|
5
|
+
triggers:
|
|
6
|
+
- multitenancy isolation
|
|
7
|
+
- multi tenant
|
|
8
|
+
- cross tenant
|
|
9
|
+
- tenant isolation
|
|
10
|
+
- row level security
|
|
11
|
+
- rls
|
|
12
|
+
- bola
|
|
13
|
+
- broken object level authorization
|
|
14
|
+
- idor
|
|
15
|
+
- noisy neighbour
|
|
16
|
+
- rapid reset
|
|
17
|
+
- rate limit
|
|
18
|
+
- per tenant quota
|
|
19
|
+
- circuit breaker
|
|
20
|
+
- distributed lock fencing
|
|
21
|
+
- resource exhaustion
|
|
22
|
+
- denial of service
|
|
23
|
+
discovery_mode: standalone
|
|
24
|
+
data_deps:
|
|
25
|
+
- cve-catalog.json
|
|
26
|
+
- atlas-ttps.json
|
|
27
|
+
- attack-techniques.json
|
|
28
|
+
- framework-control-gaps.json
|
|
29
|
+
- cwe-catalog.json
|
|
30
|
+
- rfc-references.json
|
|
31
|
+
atlas_refs: []
|
|
32
|
+
attack_refs:
|
|
33
|
+
- T1078
|
|
34
|
+
- T1499
|
|
35
|
+
- T1499.001
|
|
36
|
+
- T1530
|
|
37
|
+
framework_gaps:
|
|
38
|
+
- NIST-800-53-AC-3
|
|
39
|
+
- NIS2-Art21-network-security
|
|
40
|
+
- UK-CAF-B4
|
|
41
|
+
- AU-ISM-1556
|
|
42
|
+
cwe_refs:
|
|
43
|
+
- CWE-639
|
|
44
|
+
- CWE-770
|
|
45
|
+
- CWE-863
|
|
46
|
+
- CWE-668
|
|
47
|
+
- CWE-400
|
|
48
|
+
last_threat_review: "2026-06-02"
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
# Application Multitenancy Isolation + Availability/DoS Resilience
|
|
52
|
+
|
|
53
|
+
## Threat Context (mid-2026)
|
|
54
|
+
|
|
55
|
+
Shared multitenant infrastructure has two linked failure classes. Isolation: if the tenant identifier is trusted from a client-controlled header/parameter/claim, or the tenant filter lives in per-query application discipline rather than the data layer, a single authenticated user of one tenant reads or writes another tenant's data — broken object-level authorization (CWE-639), the most common and highest-impact SaaS vulnerability class. Cache, pub/sub, and queue keys leak the same way when not tenant-namespaced. Availability: asymmetric denial of service — HTTP/2 Rapid Reset (CVE-2023-44487), unbounded per-request allocation — and the noisy-neighbour pattern (no per-tenant quota) deny service to all tenants; autoscaling pays the attacker's bill without stopping the attack.
|
|
56
|
+
|
|
57
|
+
## Framework Lag Declaration
|
|
58
|
+
|
|
59
|
+
Organisational controls treat "we have an authorization layer" as tenant isolation and "the cloud autoscales" as DoS resilience. NIST 800-53 AC-3 (access enforcement) is satisfied by an authorization layer existing and does not require tenant scoping be structurally enforced at the data layer rather than per-query discipline. SC-6 (resource availability) is named but rarely operationalised as per-tenant quotas, Rapid Reset caps, or circuit breakers. SOC 2 CC6 logical access is met with an auth layer. A clean "we have authorization and the cloud autoscales" audit is therefore NON-EVIDENCE for multitenancy isolation or DoS resilience; it confirms an auth layer and elastic infra, not data-layer RLS under a non-bypass role, cross-tenant namespacing, per-tenant quotas, or breakers.
|
|
60
|
+
|
|
61
|
+
## TTP Mapping
|
|
62
|
+
|
|
63
|
+
The multitenancy failures map to MITRE ATT&CK: **T1078 (Valid Accounts)** for cross-tenant access from a legitimate account via a client-trusted tenant id, an unscoped query, or an RLS-bypassing request role; **T1530 (Data from Cloud Storage / shared store)** for cross-tenant leakage through un-namespaced cache/queue keys; **T1499 (Endpoint DoS)** for the noisy-neighbour, distributed-lock, and circuit-breaker gaps; and **T1499.001 (OS Exhaustion Flood)** for HTTP/2 Rapid Reset and unbounded per-request allocation. The weakness classes are CWE-639 (authorization bypass through user-controlled key), CWE-863 (incorrect authorization), CWE-668 (exposure to wrong control sphere — shared keys), CWE-770 (allocation without limits), and CWE-400 (uncontrolled resource consumption).
|
|
64
|
+
|
|
65
|
+
## Exploit Availability Matrix
|
|
66
|
+
|
|
67
|
+
These are application-posture gaps exploited from a single authenticated account or client, so the exploit is the absent control. Cross-tenant access via a client-trusted tenant id requires only changing a header — trivially scriptable and the staple of SaaS bug-bounty reports. HTTP/2 Rapid Reset has public tooling and the CVE-2023-44487 catalog entry; it produced record-breaking DDoS. Unbounded allocation and the noisy-neighbour DoS require only a crafted or high-volume request. The real-world priority is set by whether one authenticated user can reach all tenants' data, or one client can deny service to all tenants — both maximum-blast-radius outcomes on shared infrastructure.
|
|
68
|
+
|
|
69
|
+
## Analysis Procedure
|
|
70
|
+
|
|
71
|
+
1. Determine the effective tenant id derivation and confirm it binds to the authenticated principal, not a client-supplied field. 2. Confirm tenant scoping is enforced at the data layer (row-level security) and that the request connection runs under a role SUBJECT to RLS (not a BYPASSRLS/owner role). 3. Confirm cache/pub-sub/queue keys include the tenant id. 4. Confirm HTTP/2 client-initiated stream resets are capped per connection (Rapid Reset). 5. Confirm per-tenant/per-IP rate + byte quotas and bounded per-request allocation (result-set, body, connections, fan-out). 6. Confirm distributed locks carry a TTL + fencing token and critical dependencies have circuit breakers. Run the `multitenancy-isolation` playbook to execute these as detect indicators with false-positive checks, then score by whether one account reaches all data or one client denies all service.
|
|
72
|
+
|
|
73
|
+
## Output Format
|
|
74
|
+
|
|
75
|
+
Report per surface, marking each isolation and availability control enforced / missing / inconclusive (visibility gap). For every missing control, state whether a single authenticated user could read another tenant's data or a single client could deny service to all tenants. Distinguish a control enforced at a lower layer (data-layer RLS, CDN/WAF quotas) from an absent one, and a dedicated single-tenant deployment (cross-tenant indicators not applicable) from a shared one. Provide the prioritised remediation (bind tenant to principal + data-layer RLS under a non-bypass role, namespace shared keys, cap Rapid Reset + per-tenant quotas, bound allocation, fence locks + circuit-break) and the negative validation tests (cross-tenant read blocked, unscoped query blocked, Rapid Reset capped) plus a functional test that two tenants get fair, isolated service.
|
|
76
|
+
|
|
77
|
+
## Compliance Theater Check
|
|
78
|
+
|
|
79
|
+
The recurring theater is "we have an authorization layer, so tenants are isolated," "row-level security is enabled," and "the cloud autoscales, so we are DoS-resilient." An auth layer is not data-layer isolation; RLS is bypassed by a superuser/owner/BYPASSRLS request connection; autoscaling pays the attacker's bill without stopping an asymmetric DoS. The distinguishing test: probe whether a query can run without a tenant predicate, whether the request connection bypasses RLS, whether the tenant id is client-trusted, and whether Rapid Reset / unbounded allocation is capped. If a cross-tenant read or an asymmetric DoS succeeds, the auth layer and autoscaling did not isolate or protect, and the assurance is paper.
|
|
80
|
+
|
|
81
|
+
## Defensive Countermeasure Mapping
|
|
82
|
+
|
|
83
|
+
Map findings to MITRE D3FEND: principal-bound tenant id + data-layer RLS under a non-bypass role realise Authorization Event Thresholding and Mandatory Access Control (countering T1078 cross-tenant access); tenant-namespaced shared keys realise Resource Access Pattern isolation (countering T1530 leakage); per-tenant quotas + HTTP/2 Rapid Reset caps + bounded allocation realise Resource Consumption Limiting (countering T1499/T1499.001); distributed-lock fencing and circuit breakers realise System Availability and Failure-Domain isolation. Pair data-layer RLS with an automated test asserting no query runs without a tenant filter. The residual risk after these controls is compromise of a legitimately-scoped tenant account, an identity-control concern, accepted at the CISO level.
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: self-update-integrity
|
|
3
|
+
version: "1.0.0"
|
|
4
|
+
description: Consumer-side self-update and artifact integrity for mid-2026 — signature-verification-before-apply, out-of-band key pinning, anti-rollback/downgrade protection, channel pinning, Subresource Integrity on browser modules, and C2PA / SCITT-TSA transparency verification on received artifacts
|
|
5
|
+
triggers:
|
|
6
|
+
- self update
|
|
7
|
+
- auto update
|
|
8
|
+
- update integrity
|
|
9
|
+
- anti rollback
|
|
10
|
+
- downgrade attack
|
|
11
|
+
- code signing verification
|
|
12
|
+
- key pinning
|
|
13
|
+
- subresource integrity
|
|
14
|
+
- sri
|
|
15
|
+
- import map integrity
|
|
16
|
+
- c2pa
|
|
17
|
+
- content credentials
|
|
18
|
+
- scitt
|
|
19
|
+
- transparency log
|
|
20
|
+
- software supply chain consumer
|
|
21
|
+
- update channel
|
|
22
|
+
discovery_mode: standalone
|
|
23
|
+
data_deps:
|
|
24
|
+
- cve-catalog.json
|
|
25
|
+
- atlas-ttps.json
|
|
26
|
+
- attack-techniques.json
|
|
27
|
+
- framework-control-gaps.json
|
|
28
|
+
- cwe-catalog.json
|
|
29
|
+
- rfc-references.json
|
|
30
|
+
atlas_refs: []
|
|
31
|
+
attack_refs:
|
|
32
|
+
- T1195.002
|
|
33
|
+
- T1574
|
|
34
|
+
framework_gaps:
|
|
35
|
+
- NIST-800-53-SR-11
|
|
36
|
+
- NIS2-Art21-network-security
|
|
37
|
+
- UK-CAF-B4
|
|
38
|
+
- AU-ISM-1556
|
|
39
|
+
cwe_refs:
|
|
40
|
+
- CWE-494
|
|
41
|
+
- CWE-829
|
|
42
|
+
- CWE-353
|
|
43
|
+
- CWE-347
|
|
44
|
+
last_threat_review: "2026-06-02"
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
# Consumer-Side Self-Update & Artifact Integrity
|
|
48
|
+
|
|
49
|
+
## Threat Context (mid-2026)
|
|
50
|
+
|
|
51
|
+
The self-update loop is the highest-privilege code path most products ship: it fetches code and runs it as the application. Publisher-side posture — code signing, SBOM, SLSA attestations — is necessary but useless if the receiving client does not enforce it. The consumer-side failures are an update applied without verifying a signature, a signature verified against a key the update channel itself supplied, a signed-but-older version accepted (downgrade / no anti-rollback) that re-opens a patched CVE, an update fetched over an unauthenticated channel as the sole control, browser modules served without Subresource Integrity, and an apply step that does not gate on the verifier result. A channel compromise (poisoned CDN, mirror, MITM) then yields arbitrary code execution across the installed base.
|
|
52
|
+
|
|
53
|
+
## Framework Lag Declaration
|
|
54
|
+
|
|
55
|
+
Organisational supply-chain controls focus on the publisher: signing, SBOM generation, SLSA build levels. NIST 800-53 SR-11 (component authenticity) covers the supplier side and does not require the consumer's update path to verify signatures against a pinned key before applying or to refuse downgrades. The EU Cyber Resilience Act mandates secure updates for products with digital elements, but conformance is commonly attested by "we ship signed updates" without verifying the receiving client enforces signature + anti-rollback + key-pin. A clean "updates are signed / SLSA-attested / SBOM-published" audit is therefore NON-EVIDENCE for consumer-side update integrity; it confirms publisher posture, not signature-before-apply, key pinning, anti-rollback, or verifier-gating on the receiving client.
|
|
56
|
+
|
|
57
|
+
## TTP Mapping
|
|
58
|
+
|
|
59
|
+
The consumer-side update failures map to MITRE ATT&CK: **T1195.002 (Supply Chain Compromise: Software Supply Chain)** for an update applied without signature verification, against an in-band key, over an unauthenticated channel, or as an unverified browser module / artifact; and **T1574 (Hijack Execution Flow)** for an apply step that swaps the new code into the execution path without gating on the verifier. The weakness classes are CWE-494 (Download of Code Without Integrity Check), CWE-829 (Inclusion of Functionality from an Untrusted Control Sphere), CWE-353 (Missing Support for Integrity Check — e.g. absent SRI), and CWE-347 (Improper Verification of Cryptographic Signature — in-band or unpinned key).
|
|
60
|
+
|
|
61
|
+
## Exploit Availability Matrix
|
|
62
|
+
|
|
63
|
+
These are consumer-side validation gaps exploited from a channel-influencing position, so the exploit is the absent check, not a published CVE. Serving a tampered update to a client that applies without signature verification requires only control of a mirror or an on-path position. A downgrade requires merely a genuinely-signed older release. Substituting a key when trust is in-band requires control of the same endpoint as the update. The real-world priority is driven by the breadth of the installed base reachable through the update channel and whether a single channel compromise yields mass arbitrary-code execution — historically the highest-impact supply-chain outcome.
|
|
64
|
+
|
|
65
|
+
## Analysis Procedure
|
|
66
|
+
|
|
67
|
+
1. Identify every self-updating client/agent and every consumer of externally-sourced executable artifacts (modules, models, signed bundles). 2. Confirm the update path verifies a signature over the artifact BEFORE applying (not a server-provided hash) and fails closed. 3. Confirm the verifying root key is pinned out-of-band (in the binary / OS trust store), not fetched alongside the update. 4. Confirm anti-rollback: the updater refuses a version lower than installed. 5. Confirm the channel is TLS-pinned (defence-in-depth behind the signature). 6. Confirm browser-served modules carry SRI and the import map is integrity-protected. 7. Confirm C2PA content credentials and SCITT/TSA receipts on received artifacts are verified where relied upon, and that the apply gates on the verifier. Run the `self-update-integrity` playbook to execute these as detect indicators with false-positive checks, then score by installed-base breadth.
|
|
68
|
+
|
|
69
|
+
## Output Format
|
|
70
|
+
|
|
71
|
+
Report per update path, marking each consumer-side control enforced / missing / inconclusive (visibility gap). For every missing control, state whether a channel compromise would yield arbitrary-code execution and across how much of the installed base. Distinguish a control delegated to a verifying mechanism (OS package manager, gated verifier) from an absent one. Provide the prioritised remediation (verify signature against a pinned key before apply, enforce anti-rollback, pin the channel, enforce SRI on modules, verify provenance/transparency) and the negative validation tests that prove each fix (tampered update rejected, downgrade rejected, verifier-failure blocks apply) plus a functional test that a legitimate newer update still verifies and applies.
|
|
72
|
+
|
|
73
|
+
## Compliance Theater Check
|
|
74
|
+
|
|
75
|
+
The recurring theater is "our updates are signed, so the channel is secure," "updates come over HTTPS, so they cannot be tampered," and "we have an update verifier." Signing is the publisher side; HTTPS authenticates a CA bundle and falls to a mis-issued cert; a verifier whose output does not gate the apply is decorative. The distinguishing test: verify the client checks the signature against an out-of-band-pinned key before applying, refuses older versions, and blocks the apply on verifier failure. If a swapped artifact, an attacker-supplied key, or an older signed version would be applied, the signing did not protect the consumer and the assurance is paper.
|
|
76
|
+
|
|
77
|
+
## Defensive Countermeasure Mapping
|
|
78
|
+
|
|
79
|
+
Map findings to MITRE D3FEND: signature-before-apply with an out-of-band-pinned key realises Executable Allowlisting and Cryptographic Verification (countering T1195.002); anti-rollback realises Software Version Pinning (countering downgrade reintroduction); channel pinning realises Certificate Pinning; Subresource Integrity realises Resource Integrity Checking on browser modules; verifier-gating realises Execution Flow Integrity (countering T1574). Pair the signature check with provenance (C2PA) and transparency (SCITT/TSA) verification for non-repudiation. The residual risk after consumer-side enforcement is compromise of the publisher's signing key or build pipeline itself, which yields a validly-signed malicious update — addressed publisher-side (supply-chain-integrity) and accepted at the CISO level with key-management oversight.
|