check-sensitive-data

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The prompt instructs the agent to produce vulnerability reports including code blocks of "vulnerable code" (and already contains literal example secrets), which requires reproducing secret values verbatim if present in the analyzed files.

HIGH W008: Secret detected in skill content (API keys, tokens, passwords).

• Secret detected (high risk: 1.00). I scanned the full prompt for literal, high-entropy credentials and applied the provided rules (ignore placeholders, simple setup passwords, and obvious examples).

Flagged:

• 'sk_live_abc123xyz789' — This matches a live-style API key prefix (sk_live_) and is presented as an API key literal rather than a named placeholder. Even though parts are readable, it follows the real key pattern and is not an obvious placeholder like "YOUR_API_KEY" or "sk-xxxx", so it should be treated as a real, exposed credential.

Ignored (with reasons):

• 'SuperSecret123!' (PDO password) — low-entropy/example-style password; presented as an illustrative hardcoded password in docs, not a clearly unique, high-entropy secret.
• 'my-secret-key-123' (JWT_SECRET) — obvious placeholder/weak secret; documentation example.
• 'aes256-encryption-key' (ENCRYPTION_KEY) — placeholder/descriptive string.
• 'production_password_here' — explicit placeholder.
• 'admin', 'admin123' in comments — simple example/setup credentials.
• 'sk_test_abc123' in comments — labeled test key / example and clearly non-production.
• All other mentions (e.g., grep patterns, AKIA pattern) are patterns/examples, not literal secrets in the prompt.

Based on the protocol, only the sk_live_abc123xyz789 literal meets the threshold for a real, usable credential in this content.