No explicit permissions block
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
The workflow sets no permissions block, so the job token inherits the repository default. On many repositories that default is read/write across all scopes, far more than a build needs. This is a heuristic hardening flag; set least-privilege permissions explicitly.
Why it matters
With no permissions block, the job token falls back to the repository or organization default. On repositories created before GitHub tightened the default, that is read/write across all scopes, so a build job runs with far more power than it needs. Setting permissions explicitly makes the token least-privilege regardless of the repo default. This is a heuristic hardening flag.
How to fix it
Add a top-level permissions block set to the minimum, commonly permissions: contents: read, and grant extra scopes only on the specific jobs that need them. This also documents, in the workflow itself, exactly what the token is allowed to do.
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