Security teams rolling out CodeQL on GitHub face a decision that looks small but shapes how much visibility and control they'll have for years: default setup or advanced setup. Default setup lets GitHub auto-configure code scanning with a couple of clicks — no workflow file, no query tuning, minimal upkeep. Advanced setup hands you a CodeQL workflow YAML file you own, with full control over languages, query suites, build steps, and runners.
Both live inside GitHub Advanced Security (GHAS), and both only analyze the code sitting in the repository they're attached to. Neither one tells you what's happening in the open-source dependencies that make up most of a modern application, or gives you one view across the dozens (or hundreds) of repositories a real engineering org actually runs.
This post breaks down the concrete differences between CodeQL's default and advanced setup, where each one hits a wall at scale, and how Safeguard fits around GHAS rather than trying to replace what CodeQL already does well.
What's the Difference Between CodeQL Default Setup and Advanced Setup?
Default setup is GitHub's zero-config path. You enable it from the repository's Security tab, GitHub detects the languages present, and it schedules CodeQL scans automatically — typically on pushes to the default branch and on a periodic cadence. There's no workflow file to write or maintain, and query suite choice is limited to a simple toggle between the default query pack and the security-extended pack.
Advanced setup requires committing a codeql-analysis.yml workflow to the repository yourself. In exchange, you get:
- Full control over trigger events (pull requests, specific branches, cron schedules, manual dispatch)
- The ability to select or combine query packs, including
security-and-quality,security-extended, or custom query suites - Explicit build steps for compiled languages instead of relying on CodeQL's autobuild
- The option to run on self-hosted runners instead of GitHub-hosted ones
- Matrix strategies to scan multiple languages or components with different configurations in one workflow
The trade-off is ownership. Default setup is maintained by GitHub; advanced setup is maintained by whoever owns that YAML file, repo by repo.
Which Languages and Build Systems Does Each Setup Actually Handle?
Default setup works well for languages and projects GitHub's autobuild can compile or analyze without custom instructions — this generally covers interpreted languages cleanly and a growing set of compiled ones for straightforward build layouts. It struggles with anything that needs a nonstandard build: monorepos with multiple build tools, custom compiler flags, generated code that must be produced before analysis, or multi-module projects where autobuild can't infer the right sequence.
Advanced setup exists specifically to solve that problem. Because you write the build steps directly into the workflow, you can point CodeQL at exactly the compilation process your project actually uses — a Bazel build, a multi-stage Gradle build, a Makefile with environment-specific flags. If your repository doesn't build cleanly under GitHub's autobuild, advanced setup isn't an optional upgrade, it's the only setup that will produce a working scan.
This is a real, verifiable operational fact teams run into fast: default setup's simplicity is bounded by what GitHub can build for you automatically, and complex codebases routinely exceed that boundary.
Is Code Scanning the Same Thing as Supply Chain Security?
No, and this is worth being precise about. CodeQL — under either setup — is a static analysis (SAST) engine. It looks for vulnerability patterns in the code you wrote: injection flaws, unsafe deserialization, path traversal, and similar classes of bugs discoverable through data-flow analysis. GHAS bundles CodeQL alongside separate engines — secret scanning and Dependabot for dependency alerts — but each is a distinct tool with its own coverage and its own dashboard.
None of them are designed to answer supply-chain-scale questions on their own: What's the aggregate risk across every repo when a widely-used dependency version turns out to be compromised? Which services are actually reachable from a vulnerable function versus which just happen to import a library that contains one? What's the build provenance of the artifact that got deployed?
That's a different problem from "does this code contain a known vulnerable pattern," and it's the problem Safeguard is built around: correlating findings across code, dependencies, and build pipelines into a single risk picture, rather than treating each GitHub security feature as its own island.
How Does Setup Complexity Scale Across an Organization With Hundreds of Repositories?
At the scale of a single repository, either CodeQL setup is manageable. At the scale of an engineering organization, the math changes.
Default setup scales administratively fine — you can enable it repo by repo, or via organization-wide policy — but its lack of per-repo customization means teams with nonstandard build requirements will silently get incomplete or failing scans unless someone is watching. Advanced setup scales in capability but not for free: every repository that needs advanced setup needs its own workflow file, and those files drift. Query suites go stale, build steps break when dependencies change, and nobody notices until a scan quietly stops running. Auditing "which repos are on advanced setup, which are on default, and which have working scans versus silently broken ones" becomes its own manual project once you're past a few dozen repositories.
Safeguard's approach is to give security and platform teams a single place to see scan health and coverage status across every repository, regardless of which setup a given repo uses or which SCM it lives in, so gaps show up as a finding rather than as a surprise during an incident or audit.
Where Does CodeQL Fit Into a Broader AppSec Program?
CodeQL, run well, is a strong SAST engine — that's not in question. The practical gap most teams hit isn't the quality of CodeQL's analysis, it's everything around it: normalizing findings across repos that use different setups, correlating a code-level finding with the dependency or component it touches, tracking remediation across teams that don't all use GitHub the same way, and producing the artifacts — SBOMs, policy compliance evidence, audit trails — that supply chain security programs and frameworks increasingly require.
GHAS is scoped to the GitHub platform and to the specific engines it bundles. That's a reasonable scope for a source-control-native security product. It does mean that organizations with mixed SCM environments, or with supply chain requirements that go beyond source code (build provenance, artifact signing, dependency risk scoring, license and policy compliance), need something layered on top to unify that picture.
How Safeguard Helps
Safeguard is built to sit around tools like CodeQL rather than compete with them for the same job. Concretely, that means:
- Unified findings across engines and repos. Safeguard ingests results from code scanning, dependency analysis, and other security tooling and normalizes them into a single risk view, so a team doesn't have to check GHAS dashboards repo by repo to know their actual exposure.
- Coverage and configuration visibility. Because default and advanced CodeQL setups behave differently and can silently diverge (a broken build step, a stale query suite, a repo that was never onboarded), Safeguard tracks scan coverage and health as a first-class signal, not an assumption.
- Software supply chain context beyond source code. SAST findings from CodeQL tell you about a code pattern; Safeguard adds the dependency, build, and provenance context needed to judge whether that pattern is actually reachable and exploitable in a shipped artifact.
- Policy consistency across a heterogeneous environment. Organizations rarely run one SCM or one CI system exclusively. Safeguard applies consistent security policy and reporting regardless of whether a given repository is on GitHub with advanced setup, default setup, or a different platform entirely.
- Audit-ready evidence. For teams that need to demonstrate scan coverage and remediation history to auditors or customers, Safeguard consolidates that evidence instead of requiring it to be reconstructed from multiple tools after the fact.
The choice between CodeQL's default and advanced setup is a real, worthwhile decision to get right — advanced setup earns its extra maintenance burden the moment a build doesn't fit GitHub's autobuild assumptions. But that decision only governs how well one part of the code gets scanned. Safeguard is designed to answer the wider question that comes right after: across every repository, every dependency, and every build, where is the organization's actual supply chain risk — and can you prove it's under control.