Adopting a code scanning template is usually a good idea, since it puts analysis in front of every pull request. Check what it runs, which permissions it requests, who authored it, and whether it blocks merges or only reports. A scanner you do not read is still code running in your pipeline.
What GitHub says about it
The secure use guide notes that code scanning finds security vulnerabilities before they reach production, and that GitHub provides workflow templates for it. GitHub's own template is the CodeQL analysis workflow. The guide also says there are third party workflow templates available, which you can use instead of starting from scratch.
That last point matters. A template in the same list is not the same as a template from the same author. Each one is a workflow file with its own steps, actions and permissions.
Five checks before you adopt one
- Author. Who maintains it? A GitHub authored template and a vendor authored one carry different trust and different support routes.
- Actions it calls. List them. Scanners often call a setup action, an analysis action and an upload step. Review each like any other dependency.
- Permissions. A scan that uploads results usually needs one extra scope for that, and the template's own documentation should say which. It rarely needs write access to contents. Put the narrowest set in a job level block.
- Triggers. Pull request and push on the default branch are normal. A scheduled run is a useful addition for catching new rules on old code.
- Secrets. Some third party templates need an API token. Store it as an environment or repository secret, and confirm fork pull requests cannot reach it.
Report only or block?
Start in report only mode. Run the scan for a few weeks, triage the findings, and fix or suppress the noisy ones. Then make selected severities block the merge. A gate that fails on day one for forty old issues teaches developers to ignore it.
| Phase | What happens | Goal |
|---|---|---|
| Week 1 to 2 | Report only, results visible | Learn the baseline |
| Week 3 to 4 | Fix or accept existing findings | Reduce noise |
| After that | Block new high severity findings | Stop regressions |
Scan the workflow files too
GitHub says CodeQL can scan and detect potentially vulnerable GitHub Actions workflows, and recommends making sure Actions scanning is enabled in default setup. It also mentions OpenSSF Scorecards for spotting risky workflow patterns. So the same tool you adopt for application code can help check the pipeline file you just copied.
Where Safeguard fits
Safeguard offers dependency scanning with reachability analysis and pull request gates and policies, which cover the library side that a code scanning template does not. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are described and how you would decide which ones should block a merge.
Quick check
Does a code scanning workflow replace dependency scanning?
No. Code scanning looks at the code you wrote. Dependency scanning looks at the libraries you use. Most teams want both.
Is a third party template riskier than GitHub's own?
Not automatically, but it adds a different author and different actions to your trust list. Review it the same way.
Sources
Last reviewed: 19 October 2026.
