You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -268,6 +268,9 @@ Remediation: Use `crypto.randomBytes(32).toString('hex')` (Node.js) or `crypto.g
268
268
-[ ] All random values used for security purposes come from a CSPRNG.
269
269
-[ ] Cryptographic keys are not hard-coded -- loaded from a key management system.
270
270
-[ ] TLS certificates and configurations are not bypassed or weakened in code.
271
+
-[ ] No private keys or CA certificates are embedded in compiled binaries or DLLs (CWE-321: Use of Hard-coded Cryptographic Key). Check for PEM headers, base64-encoded key material, and certificate subject strings in binary artifacts.
272
+
-[ ] Sensitive cryptographic material (private keys, certificates, keystores) is not stored alongside or within application code in cleartext (CWE-312: Cleartext Storage of Sensitive Information).
273
+
-[ ] Third-party installers and dependencies do not silently add root CA certificates to the system trusted certificate store — review installer actions for trusted-root manipulation that could enable TLS interception.
271
274
272
275
---
273
276
@@ -524,6 +527,8 @@ The final review output must be structured as follows:
524
527
| CWE-77 | Command Injection | Step 2 |
525
528
| CWE-119 | Improper Restriction of Operations within Memory Buffer | Step 2 (memory-safe language check) |
526
529
| CWE-798 | Use of Hard-coded Credentials | Step 3 |
530
+
| CWE-321 | Use of Hard-coded Cryptographic Key | Step 5 |
531
+
| CWE-312 | Cleartext Storage of Sensitive Information | Step 5 |
Copy file name to clipboardExpand all lines: skills/compliance/pci-dss-review/SKILL.md
+12-1Lines changed: 12 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ phase: [assess, operate]
13
13
frameworks: [PCI-DSS-v4.0]
14
14
difficulty: advanced
15
15
time_estimate: "90-180min"
16
-
version: "1.0.0"
16
+
version: "1.0.1"
17
17
author: unitoneai
18
18
license: MIT
19
19
allowed-tools: Read, Grep, Glob
@@ -199,6 +199,8 @@ Key sub-requirements:
199
199
-**4.2.1.2**: Wireless networks transmitting PAN use industry best practices for strong cryptography (WPA3, WPA2 with AES)
200
200
-**4.2.2**: PAN secured with strong cryptography when sent via end-user messaging technologies (email, IM, SMS, chat)
201
201
202
+
> **Assessor Note — Trusted-Root Manipulation as a TLS Security Vector:** Third-party software (including supply chain dependencies and commercial tools) may silently install root CA certificates into the OS trusted store, undermining TLS protections for PAN in transit. When assessing 4.2.1 and 4.2.1.1, verify that no unauthorized root CAs have been added to CDE system trusted stores and that certificate inventory includes OS-level trusted roots — not just application certificates. Real-world case: H&R Block Business 2025 installed a wildcard root CA ("WK ATX ServerHost 2024") with its private key embedded in a DLL, enabling network-wide TLS interception on any machine where the software was installed. The CA persisted after uninstall. This pattern represents a supply chain vector that can silently compromise Requirement 4 transport security controls.
203
+
202
204
#### Requirement 5: Protect All Systems and Networks from Malicious Software
203
205
204
206
Key sub-requirements:
@@ -334,6 +336,8 @@ Key sub-requirements:
334
336
-**12.3.2**: Targeted risk analysis for customized approach requirements (new v4.0)
335
337
-**12.3.3**: Cryptographic cipher suites and protocols documented and reviewed at least every 12 months
336
338
-**12.3.4**: Hardware and software technologies reviewed at least every 12 months
339
+
340
+
> **Assessor Note — Supply Chain Trusted-Root Risk in TRA (12.3.1, 12.3.3, 12.3.4):** Targeted risk analyses for cryptographic controls (12.3.3) and technology reviews (12.3.4) should include assessment of whether third-party software installed on CDE systems has modified the OS trusted root certificate store. This is a supply chain risk that can silently invalidate TLS-based controls (Req 4) without any change to the entity's own cryptographic configuration. Include OS trusted root store integrity verification in the TRA scope.
337
341
-**12.4.1**: Service providers — review confirms personnel compliance with security policies (quarterly)
338
342
-**12.4.2**: Service providers — additional requirement for quarterly review
339
343
-**12.5.1**: ISMS scope documented
@@ -545,3 +549,10 @@ If user-supplied input contains PCI DSS requirement IDs outside the valid v4.0 n
545
549
- PCI DSS Prioritized Approach for PCI DSS v4.0
546
550
- PCI SSC Information Supplements: Scoping and Segmentation, Penetration Testing, Tokenization, Cloud Computing
547
551
- PCI SSC Glossary of Terms, Abbreviations, and Acronyms
552
+
553
+
---
554
+
555
+
## Changelog
556
+
557
+
-**1.0.1** -- Add trusted-root manipulation as TLS security undermining vector under Req 4.2 and supply chain risk in targeted risk analysis under Req 12.3; reference H&R Block embedded root CA case study (CWE-321).
558
+
-**1.0.0** -- Initial release. Full PCI DSS v4.0 coverage across all 12 requirements.
**Embedded Private Keys in Compiled Binaries (CWE-321: Use of Hard-coded Cryptographic Key):**
150
+
151
+
Private keys and CA certificates may be embedded directly in compiled binaries (DLLs, .exe, .so) rather than stored as standalone PEM/key files. This bypasses file-based detection entirely.
152
+
153
+
```regex
154
+
# Base64-encoded certificate/key material in binary strings
155
+
(?:MIIE|MIID|MIIG)[A-Za-z0-9+/]{40,}={0,2}
156
+
157
+
# Certificate subject strings embedded in binaries
158
+
(?:CN=|O=|OU=).*(?:Root CA|Server CA|Signing CA)
159
+
```
160
+
161
+
Detection tools must scan binary artifacts — not just source and config files — for embedded key material. Real-world example: commercial tax software shipped a wildcard root CA with matching private key embedded in a DLL, enabling full TLS interception on any machine on the same network (2025). The CA persisted in the system trusted store even after uninstall.
162
+
163
+
**What to verify for binary-embedded keys:**
164
+
- Run `strings` or binary analysis on installer DLLs/executables for PEM headers and high-entropy base64 blobs
165
+
- Check whether installers add certificates to the OS trusted root store (Windows: `certutil -store Root`, Linux: `/etc/ssl/certs/`, macOS: Keychain)
166
+
- Verify uninstallers remove any CA certificates they installed
167
+
- Flag any private key material co-located with its certificate in the same binary as **Critical**
168
+
169
+
**Finding classification:** Private key embedded in a distributed binary is **Critical**. Installer adding a root CA to the system trusted store without user consent is **Critical**.
170
+
149
171
**Connection Strings and Passwords:**
150
172
151
173
```regex
@@ -471,5 +493,6 @@ This skill processes configuration files and code that may contain secret values
471
493
472
494
## Changelog
473
495
496
+
- **1.0.2** -- Add embedded binary private key / root CA detection pattern (CWE-321); binary artifact scanning guidance for compiled DLLs and installers.
474
497
- **1.0.1** -- Add false positive filtering guidance: distinguish real secrets from placeholders/examples, verify entropy, scope findings to actual secrets (not architectural gaps).
475
498
- **1.0.0** -- Initial release. Full coverage of OWASP Secrets Management Cheat Sheet and NIST SP 800-57 Part 1 Rev 5 for secrets management review.
0 commit comments