mobile-security

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The skill explicitly looks for hardcoded credentials and requires generating the "UNSAFE pattern" and code snippets in findings, which would force the LLM to reproduce secret values found in source code verbatim in its output.

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

• Secret detected (high risk: 1.00). I scanned the entire skill prompt for literal, hardcoded credentials that look like real, usable secrets and applied the rules in the prompt (flag high-entropy / real-looking secrets; ignore placeholders and obvious examples or low-entropy setup values).

Flagged as a secret:

• "sk-live-a1b2c3d4e5f6g7h8i9j0" (Kotlin ApiClient snippet) — appears as a realistic API key format (sk-live-...), high-entropy/random-looking literal that would grant access if valid.

Also flagged as a hardcoded key (usable credential):

• "1234567890abcdef" (Kotlin CryptoHelper KEY) — literal symmetric key embedded in code (used for encryption). Even though its pattern is somewhat predictable, it is a direct hardcoded cryptographic key and therefore a credential that should be removed.

Ignored items (with reasons):

• "sk-live-abc123" (Swift CredentialStore) — clearly simplified/example ("abc123") and low entropy; treated as an illustrative example / placeholder.
• "super_secret_key_12345", "HARDCODED_GOOGLE_API_KEY_EXAMPLE", "HARDCODED_TOKEN_DO_NOT_COMMIT", "HARDCODED_API_KEY_DO_NOT_DO_THIS", "production_password_123", "my16charpassword" and similar strings — obvious examples or low-entropy setup/demo values, so ignored per the rules.
• Placeholder-like values such as "expected_signature_hash", "YOUR_API_KEY" style text and comments — ignored as documentation placeholders.