gitlab

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The skill includes explicit examples that embed tokens/credentials into commands and URLs (e.g., Authorization headers, parameter-based auth, and git clone https://:<deploy_token>@...), and shows literal token values in example responses, which would encourage or require substituting real secret values verbatim into generated output, creating an exfiltration risk.

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

• Secret detected (high risk: 1.00). I scanned the skill prompt for literal credential values. Most items are placeholders or low-entropy examples and are ignored per the rules: environment variable names like $RUNNER_TOKEN and $DEPLOY_TOKEN (documentation placeholders), the YAML mysql password set to "secret" (low-entropy setup/example), and template placeholders like , <deploy_token>, <access_token>.

However, the OAuth PKCE example response contains two high-entropy, random-looking hex strings:

• access_token: "de6780bc506a0446309bd9362820ba8aed28aa506c71eedbe1c5c4f9dd350e54"
• refresh_token: "8257e65c97202ed1726cf9571600918f3bffb2544b26e00a61df9897668c33a1"

These are literal, high-entropy values that resemble real tokens and therefore meet the definition of secrets. Even though they appear in an example response, they are not obviously redacted or placeholders and thus should be flagged.