Let's cut through the marketing fluff for a moment. Everyone parrots the GitHub Advanced Security (GHAS) talking points about shifting left and integrated security, but the moment you actually try to use it at scale, you hit the brick wall of performance and cost. The default, push-triggered secret scanning and dependency review are fine for tiny repos, but they're essentially toy scanners. The real question isn't about a "speed difference"—it's about whether you're getting any meaningful security coverage at all with the default setup.
I've been running a comparative analysis on a mid-sized monorepo with about 500k lines of mixed Java and TypeScript. The default scans, which GitHub runs automatically on pushes, are fast because they're superficial. They miss entire classes of context-aware vulnerabilities. When I integrated a dedicated CodeQL step into our CI pipeline (GitHub Actions, in this case), the initial analysis time ballooned from under a minute to over 25 minutes for a full build. That's the headline number everyone freaks out about. But that's not the full story.
The critical detail is what you're buying with that time. The default secret scanning will catch a raw AWS key in a comment. CodeQL, built into CI with a proper query suite, identified a hardcoded credential being assembled via string concatenation across three different methods, which would never be caught by a regex. The default dependency review flags a known CVE. CodeQL can trace that tainted data from a user input through a vulnerable version of that library to a sink, proving exploitability. You're not comparing apples to apples; you're comparing a security guard who glances at a building to a full structural engineering survey.
So, the speed "difference" is a red herring. The real discussion should be about total cost of ownership. You're trading CI minutes (which cost real money on any platform, including GitHub) for actual security insight. But then you have to ask: is CodeQL the right tool for that deep analysis, or are you just buying into the GitHub ecosystem lock-in? Could a scheduled, offline Semgrep or a self-hosted SonarQube setup give you 80% of the coverage for 50% of the runtime and zero vendor-tied analysis minutes? Has anyone done a rigorous TCO breakdown including engineer hours to triage, tune queries, and maintain these pipelines, versus using the defaults as a basic safety net and investing elsewhere?
Just my two cents
Skeptic by default
I'm a platform engineer at a fintech, we run ~200 microservices on k8s with GitHub Actions for CI. I've set up both default GHAS scans and dedicated CodeQL pipelines for our Java/Go repos, and we run both in prod because they're doing completely different jobs.
The speed difference is real, but it's the wrong metric. You need to compare what they're actually scanning.
* **Analysis Depth**: Default secret scanning does regex matches on your diff. It'll catch `AKIAIOSFODNN7EXAMPLE` but miss a secret assembled via string concatenation. CodeQL builds a full database of your code's data flow, so it can find that `String apiKey = "AKIA" + "IOSFODNN7" + "EXAMPLE";` leads to an HTTP call. That's why it takes 25+ minutes.
* **Coverage Scope**: Dependency scanning only looks at manifest files (pom.xml, package.json). CodeQL can find vulnerabilities in your *actual code* that uses those dependencies, like identifying a path where user input reaches a `clone` method from a library known to be vulnerable. It's the difference between "you have a bad library" and "here's how an attacker can reach the bad function."
* **Cost Model**: GHAS is ~$4-8 per user/month, but that's just the license. The real cost is in Actions minutes for CodeQL. A 25-minute scan per commit adds up. For a team of 50 doing 30 commits/day, you're looking at ~375 hours of Actions runtime monthly. On GitHub's larger runners, that can push you into the next tier of spending. The default scans are "free" within your existing Actions allowance.
* **Configuration Overhead**: Default scans are zero-config. CodeQL requires a `codeql.yml` to define build steps and queries. For a mixed monorepo, you'll spend a day getting the autobuild to work right or writing custom build commands. The config looks like this for a Java/TS monorepo:
```yaml
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v2
with:
languages: java, javascript
build-mode: manual
build-command: |
cd ${{ github.workspace }}/backend && mvn clean compile -DskipTests
cd ${{ github.workspace }}/frontend && npm ci && npm run build
```
I push teams to run both, but prioritize CodeQL on PRs for services that handle user data or payments. For your 500k-line monorepo, I'd run a scheduled weekly CodeQL scan on the main branch (to catch deep issues without blocking every PR) and keep the default scans on push for fast feedback on secrets and new dependencies. If you had to pick one, tell me your compliance requirements and whether your biggest threat is credential leaks or logic flaws.
Automate everything. Twice.
Yeah, the "toy scanners" line really resonates. So if default GHAS is mostly checking diffs and manifest files, is the move just to run CodeQL nightly on a schedule and let the fast-but-weak scans handle PRs? That 25-minute hit on every push would kill our dev flow.