Security teams rarely get to pick one source control platform and stick with it forever. Mergers bring GitLab instances into GitHub shops. Regulated business units run self-hosted Bitbucket or Gitea behind the firewall while product teams live on GitHub Cloud. Contractors and acquired startups show up with their own git servers. Yet GitHub Advanced Security (GHAS) — GitHub's bundled code scanning, secret scanning, and dependency review suite — only scans code that lives inside GitHub. If a repository sits in GitLab, Bitbucket, Azure DevOps, or an internally hosted Git server, GHAS has nothing to say about it.
That gap isn't a bug; it's the product's design center. GHAS is built to sell more GitHub Enterprise seats, not to be a neutral security layer across whatever version control your engineering org actually uses. This post breaks down what "GitHub-only" really means in practice, where it bites multi-SCM organizations hardest, and how Safeguard approaches the same problem set without requiring you to consolidate your source control first.
What Does "GitHub-Only" Actually Mean for GHAS?
GHAS ships as a set of features layered on top of GitHub's own platform: code scanning powered by CodeQL, secret scanning with optional push protection, and dependency review/Dependabot alerts. All three are implemented as GitHub-native constructs — they run through GitHub Actions or GitHub's own scanning infrastructure, surface results in the GitHub Security tab, and annotate pull requests using GitHub's PR API. None of that machinery has an equivalent hook into GitLab merge requests, Bitbucket pull requests, or a self-hosted Gitea/Gogs instance.
There's a nuance worth being precise about: CodeQL, the analysis engine underneath code scanning, is open source and can be run standalone via the CodeQL CLI against any codebase, regardless of where it's hosted. But that's CodeQL the engine, not GHAS the product. The parts organizations actually pay for and rely on operationally — the unified alerts dashboard, inline PR annotations, secret scanning with push protection, and dependency review gating — are only available where the repository lives in GitHub Enterprise Cloud or GitHub Enterprise Server. Running CodeQL by hand on a GitLab repo gets you scan results in a file; it doesn't get you the GHAS workflow.
Licensing reinforces the same boundary. GHAS is billed per active committer and requires a GitHub Enterprise plan to enable — it's an add-on to GitHub, not a standalone security product you can point at arbitrary repositories.
Why Do Multi-SCM Organizations Get Left Out?
Most engineering orgs above a certain size aren't single-platform by choice — they're single-platform by accident of history, acquisition, or team autonomy. Common patterns we see:
- Post-acquisition sprawl. An acquired company's engineering team keeps its GitLab or Bitbucket instance for months or years after close, because migrating hundreds of repositories, CI pipelines, and permission models isn't a weekend project.
- Regulatory or air-gapped requirements. Government, defense, and some financial services workloads run on self-hosted Git servers that never touch a SaaS platform, for reasons that predate any tooling decision.
- Platform-team autonomy. Some business units standardized on GitLab for its built-in CI/CD years before a company-wide GitHub rollout, and re-platforming thousands of pipelines isn't a security team's call to make.
In every one of these cases, the security team's job is to get consistent scanning coverage across all of it — not to wait for a multi-year SCM consolidation project to finish first. A tool that only covers the GitHub slice of the estate leaves the rest of the org flying blind, with no secret scanning, no dependency review, and no centralized vulnerability visibility on repositories that may carry just as much production risk as anything on GitHub.
GHAS vs. Safeguard: Platform Coverage Compared
Here's where the two approaches diverge on concrete, checkable dimensions:
SCM platform support. GHAS scans repositories hosted on GitHub.com or GitHub Enterprise Server only — that's a documented product boundary, not a configuration limitation you can work around. Safeguard is built as an SCM-agnostic layer: it connects to GitHub, GitLab, Bitbucket, and self-hosted Git servers through the same underlying scanning and policy engine, so a security team can enforce one set of rules regardless of where a given repo happens to live.
Deployment coupling. GHAS requires a GitHub Enterprise Cloud or Server license to activate — you cannot license GHAS independent of GitHub itself. Safeguard is deployed as its own service that integrates with whatever SCM you already run, which means adopting it doesn't force a parallel decision about which git host to standardize on.
Unified reporting across a mixed estate. Because GHAS results live inside GitHub's own Security tab, an org with repos split across GitHub and GitLab ends up with security findings split across two (or more) separate dashboards with no common view. Safeguard's design goal is the opposite: a single pane of findings, policies, and risk scoring that spans every connected SCM, so "what's our overall exposure" is one query, not a manual reconciliation across tools.
These are structural, verifiable differences in how each product is built and licensed — not claims about which engine finds more vulnerabilities. If your organization is single-platform on GitHub today and has no plans to change, that distinction may not matter to you. If it isn't, it's worth weighing before you standardize your security tooling around a platform-bundled feature.
What Happens When You Migrate or Run Mixed SCMs Long-Term?
Two realistic scenarios expose the cost of a GitHub-only security layer:
During migration. If you're consolidating onto GitHub from GitLab or Bitbucket, there's inevitably a transition window — sometimes measured in quarters — where repositories exist on both platforms simultaneously. A GitHub-only tool gives you zero coverage on the source platform during exactly the period when repos are being touched, re-permissioned, and re-wired the most, which is often when secrets and misconfigurations get introduced.
When mixed SCM is the permanent state. Some organizations will never fully consolidate — a self-hosted instance tied to a compliance boundary, or a subsidiary that keeps its own tooling by contractual agreement. For these, "eventually migrate everything to GitHub" isn't a real plan, and a security program built entirely on a GitHub-native tool leaves a permanent, unaddressed gap.
In both cases, the practical question isn't "which scanner is better" — it's "which security layer still works after the org's SCM footprint doesn't match the vendor's assumptions."
Is Self-Hosted Git Support Really Off the Table for GHAS?
For GitHub Enterprise Server (GitHub's self-hosted product), yes — GHAS features are available if you're running that specific self-hosted GitHub distribution. But that's self-hosted GitHub, not self-hosted git in the general sense. Organizations running Gitea, Gogs, plain git over SSH with a custom review tool, or any non-GitHub self-hosted server are outside GHAS's supported surface entirely, regardless of GitHub Enterprise licensing. If your self-hosted requirement means "our own Git server, not necessarily GitHub's own product," GHAS doesn't extend to that case, and there's no supported path to make it do so.
How Safeguard Helps
Safeguard was built on the premise that source-control choice and security tooling choice shouldn't be the same decision. Concretely, that means:
- One connector model, multiple SCMs. Safeguard integrates with GitHub, GitLab, Bitbucket, and self-hosted Git servers through a consistent connection and policy framework, so onboarding a new platform doesn't mean standing up a parallel security stack.
- Consistent policy enforcement regardless of host. Secret detection, dependency risk, and code-level policy checks apply the same rules whether a repository sits in GitHub Cloud or an internal Git server — teams don't inherit weaker coverage just because of where a repo happens to live.
- A single view across your actual estate. Rather than reconciling findings across GitHub's Security tab and separate tooling for everything else, Safeguard centralizes scan results and risk signals across every connected SCM, so leadership and security teams can answer "what's our real exposure" without cross-referencing multiple dashboards.
- No forced re-platforming. Adopting Safeguard doesn't require migrating repositories to a specific host first. Coverage starts where your code already lives today, including during multi-year migrations or permanently mixed environments.
If your organization's source control footprint spans more than one platform — now or as a matter of long-term architecture — it's worth evaluating whether a platform-bundled security feature can actually keep pace with that reality, or whether you need a security layer that was designed for it from the start.