SQLCipher Encrypted Database Expert

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The prompt contains hardcoded-looking encryption keys in tests and examples and uses direct insertion of key values into PRAGMA/SQL statements (e.g., f"PRAGMA key = {key}"), which requires handling and can lead the model to output secret values verbatim.

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

• Secret detected (high risk: 1.00). I found hardcoded encryption keys in the test and example code. Specifically, the Python tests and Rust examples embed literal SQLCipher keys of the form:
• "x'0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'"
• "x'fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'"
• "x'ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'"

These are 64-hex-character key literals (wrapped as x'...') used directly to open/rekey databases in tests and examples — i.e., usable encryption keys, not placeholders. Even though the all-f value is low-entropy, it is still a literal key used in code and should be treated as a hardcoded credential.

Ignored items (not flagged):

• "user-password" in a unit test — a simple example password (low entropy), treated as a test/example value.
• Commented example values like "my-secret" or other placeholder-style strings — documentation/examples to be ignored per the rules.
• Environment names, PRAGMA placeholders, and dependency/version strings — not secrets.

Therefore the skill prompt does include real, hardcoded encryption keys that constitute exposed secrets.