Credential interpolated into a URL in a run step
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A run step builds a URL with a secret embedded in the userinfo part (https://${{ secrets.TOKEN }}@host). The credential then appears in the process argument list, in error output, and in any shell trace, none of which GitHub reliably masks.
Why it matters
Building a URL like https://${{ secrets.TOKEN }}@host puts the credential into the command line, where it shows up in the process list, in shell traces (set -x), and in many error messages. GitHub does not reliably mask a secret embedded in a longer string, so the token can end up in logs even though you never echoed it directly.
How to fix it
Keep the credential out of the URL. For git, use a credential helper or the http.extraheader authorization header instead of userinfo, and pass the token through an environment variable. For other tools, prefer an Authorization header or a config file with restricted permissions over an inline URL.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo