Choose Your Scanners
The four detection engines Shield runs on pull requests, when to leave one off, and how to change them later.
Turn each scanner on or off during setup, or later under Shield → Settings.
What Each Scanner Covers
| Scanner | Turn it on to catch |
|---|---|
| Secret Scanning | Committed credentials - API keys, access tokens, private keys, connection strings. Findings name the secret type so you know what to rotate. |
| Code Scanning | Code-level vulnerabilities - injection flaws, unsafe deserialization, weak cryptography. Findings include the offending snippet. |
| Dependency Scanning | Known CVEs in your dependencies and container images. Findings name the package, the advisory, and the version that fixes it. |
| Infrastructure Scanning | Misconfigured infrastructure-as-code - public buckets, permissive security groups, privileged containers - across Terraform, Kubernetes, and Docker. |
Decide What to Enable
Shield pre-selects scanners based on the tooling it finds already running in your organization. Adjust the selection using these rules:
- Leave a scanner off where an existing tool already covers it. If you run Dependabot, accept the suggestion to leave Dependency Scanning off - unless you also need container and OS scanning.
- Turn a scanner on to add Shield's coverage on top of an existing tool. A warning icon marks the overlap so you know to expect duplicate findings.
- Keep at least one scanner on. Shield blocks disabling the last one, because new pull requests would then go unscanned.
Findings from GitHub's own tooling still appear on your Findings page, so a mixed setup stays reviewable in one place.
When Scans Run
Shield scans a pull request when it is opened, updated, or reopened against the default branch of an in-scope repository. Only the scanners you enabled run.
Scanning is change-driven. Enabling a new scanner covers pull requests opened after the change; runs already in progress are unaffected.
What Happens When a Scan Fails
In Monitoring mode, nothing is blocked.
Shield reports findings on the pull request and in your dashboard, and the merge goes ahead. Only in Active mode does a failing scan block the merge - and organization admins can still bypass it.
Change mode under Shield → Settings → Enforcement mode. It applies to every repository in scope, on pull requests evaluated after the change.
Act on Severities
Every finding is graded on the same scale, whichever scanner produced it.
| Severity | What to do |
|---|---|
| Critical | Fix immediately. |
| High | Schedule promptly. |
| Medium | Fix when convenient; usually needs other conditions to be exploitable. |
| Low | Minor hygiene or hardening opportunity. |
| Info | No action strictly required. |
Work top-down from Fix these first on your Overview, which is already ordered by severity.