To scan a GitHub repository for vulnerabilities, run four checks: dependency scanning for known CVEs in packages, static analysis for flaws in your own code, secret scanning for committed credentials, and configuration scanning for Dockerfiles and infrastructure files. One tool rarely does all four equally well.
The four checks
| Check | Finds | Reads |
|---|---|---|
| Dependency scan (SCA) | Known vulnerable packages | Lockfiles and manifests |
| Static analysis (SAST) | Flaws in code you wrote | Source files |
| Secret scan | Committed credentials | Files and full git history |
| Config scan | Misconfigured Dockerfile, Terraform, Kubernetes | IaC and build files |
Steps
- Start with dependencies, because that is where most known CVEs live. Make sure your lockfile is committed, so the scan sees exact versions. See which file to scan.
- Add secret scanning across all branches and history.
- Add SAST for your own code in pull requests.
- Scan Dockerfiles and infrastructure files in the same pull request.
- Gate merges on new high severity findings, not on the whole backlog.
- Schedule a weekly full scan, since advisories change after you merge.
Where results should land
Put findings where developers already look: the pull request check, the repository security tab or a ticket queue. Scanners that produce SARIF 2.1.0 can upload to GitHub code scanning, which accepts only that SARIF version and caps a file at 10 MB compressed.
Public and private repositories
Public repositories can be scanned by anyone who can read them. For private repositories, give the scanner the narrowest access it needs, read only if possible, and review that access when the pilot ends.
Reading the first results
A first scan often returns a long list. Sort by severity, whether a fix exists and whether the vulnerable code is reachable. Fix the top handful, record the rest with owners, and set a rule that prevents new ones. See your first hour with scan results.
How Safeguard helps
Safeguard provides SBOM and dependency scanning with reachability analysis, and policies, gates and guardrails you can apply before merge. You can try the free scan on a repository.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the dependency inventory and find direct versus transitive packages.
Quick check
Is one scanner enough for a repository?
Usually not. Dependencies, code, secrets and configuration are different problems, and coverage varies by tool.
Do I need to commit my lockfile?
Yes, for accurate results. Without it the scanner has to guess versions.
Sources
- GitHub Docs, SARIF support for code scanning (fetched 19 October 2026).
- GitHub Docs, About secret scanning (fetched 19 October 2026).
Last reviewed: 19 October 2026.
