Built-in scanning is enough when your code lives on one host, your languages and ecosystems are on the supported lists, your tier includes the features you need, and your team triages the output. When any of those fail, a dedicated scanner can fill the gap. This checklist helps you decide.
What built-in features usually cover
GitHub and GitLab both offer dependency alerts or scanning, static analysis, secret detection and some form of policy or ruleset. Per their documentation, both run inside the platform you already use, so setup is light. That is a real advantage for small teams. No comparison between vendors is implied here: the test is your own coverage.
Seven questions
- Is all your code on one host? Built-in views cover that host. Repositories elsewhere need another view.
- Are your languages supported? CodeQL does not cover PHP or Scala, and GitLab SAST lists some languages as standard analyzer only or beta.
- Does your tier or plan include the features? Several GitHub features need Code Security or Secret Protection on private repositories, and many GitLab features need Ultimate.
- Do you need reachability? The Dependabot alerts page does not describe reachability, and the GitLab dependency scanning page does not mention it. If you want to know whether vulnerable code is called, confirm how you will get that.
- Do gates fail safe? GitLab approval policies treat missing reports as needing approval. Check that your gates behave the same when a scan is skipped.
- Who triages? A dashboard with no owner becomes noise.
- What do auditors want? Evidence over time, exportable, with owners and dates.
A scoring table
| Question | Yes | Partly | No |
|---|---|---|---|
| One source host | Built-in fits | Add a cross-host view | Add a cross-host view |
| Languages supported | Built-in fits | Cover the rest separately | Add a scanner |
| Tier includes features | Built-in fits | Upgrade or add | Add |
| Reachability needed | Add if not available | Test it | Built-in fits |
What to measure in a pilot
Pick three real repositories. Record findings from the built-in tools, then compare them with an independent scan. Look for items found by only one tool, and ask why. Do not decide from a feature list. Decide from the overlap and the gaps on your own code.
Common mistakes
- Treating a green check as proof of safety.
- Enabling a feature on some repositories and assuming the rest are the same.
- Letting alerts pile up without a service level for triage.
- Mixing up scanning (what is in it) with provenance (where it came from).
Where a dedicated scanner fits
Safeguard offers SBOM and dependency scanning, reachability analysis, zero-day discovery, policies and gates, and asset discovery, with a free scan at gold.safeguard.sh/scan. You can run it next to your built-in tools and compare.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how one queue with owners and statuses differs from several separate dashboards.
Quick check
Is a dedicated scanner a replacement for built-in features?
Not necessarily. Many teams run both, using built-in checks for convenience and another tool for coverage gaps.
What is the quickest test?
Scan three real repositories with both approaches and review the differences.
Sources
- GitHub Docs: GitHub security features
- GitHub Docs: About Dependabot alerts
- GitHub Docs: About code scanning with CodeQL
- GitLab Docs: Dependency scanning
- GitLab Docs: Merge request approval policies
- GitLab Docs: SAST
Last reviewed: 19 October 2026.
