Let's get this out of the way upfront: if you're expecting GitHub Advanced Security (GHAS) to be a magic wand you wave over your repos to make security problems vanish, you will be profoundly disappointed. We've been running it across our entire estate—about 300 microservices, a mix of Java, Go, Python, and TypeScript—for a full year. The rollout was mandated, the budget was approved, and the expectation from leadership was a shiny "security solved" dashboard. Reality, as always, is a grittier, more expensive, and more operational affair.
The core components—Code Scanning (with CodeQL), Secret Scanning, and Dependency Review—are technically competent. The integration is, unsurprisingly, seamless within GitHub workflows. The pain isn't in the tools themselves; it's in the operational burden and the cold, hard truth that these tools expose your development team's priorities, or lack thereof. You are buying a very efficient system for generating work, alerts, and tough conversations.
Here is a breakdown of our lived experience, the good, the bad, and the financially painful:
* **CodeQL is powerful but becomes a velocity tax.**
You will spend significant time tuning it to reduce false positives. Out of the box, it's noisy. We had to create a dedicated workflow for managing custom queries and suppressing specific alert patterns that didn't apply to our context. The learning curve for writing your own CodeQL queries is non-trivial. This isn't a "set and forget" system; it's an engine that requires a dedicated mechanic (or a team of them).
```yaml
# Example: A suppression in a code-scanning configuration to ignore a specific Java query pattern in test directories
# This is the kind of toil you'll be adding
- name: CodeQL Advanced Setup
uses: github/codeql-action/init@v2
with:
queries: +security-and-quality, ./.github/codeql/custom-queries.qls
config-file: ./.github/codeql/codeql-config.yml
```
* **Secret Scanning is the most immediate ROI, and the most humbling.**
It will find credentials you didn't know were there, in branches you thought were dead. The first month is a firefight. You must have a clear, non-negotiable remediation protocol in place *before* you turn this on. We integrated it with our internal credential vault and a dedicated Slack channel for immediate alerts. This component alone justified the initial spend, but it also created a backlog of hundreds of historical secrets that needed rotation.
* **Dependency Review is a compliance checkbox, not a fix.**
It cleanly blocks PRs with new critical vulnerabilities. That's good. However, it does nothing for your existing 10,000 dependencies. You get a clear "no" on new problems, but the mountain of old problems in your main branch is still your problem. This shifted our work from "preventing new vulns" to "the endless backlog of renovate and Dependabot PRs," which consumes CI minutes and reviewer time.
* **The cost model will bite you.**
You pay per committer. Not per active user, not per repo, per *committer*. If you have a large organization with many developers who touch many repos, the bill scales linearly and predictably, but it feels heavy. You are paying for the *potential* of an alert, not the volume of findings. The value is not linear with the cost; you get the most critical findings in the first few months, and then you're paying a large annual fee for maintenance and incremental new findings. The push towards Enterprise for features like push protection for secrets feels like a necessary upsell.
The biggest lesson is cultural, not technical. GHAS shines a blinding light on your development practices. If your team views security as a last-minute gate, GHAS will cause rebellion. You must embed security findings into the normal development workflow, or the alerts will just be ignored and the tool becomes a very expensive report generator. We had to restructure our Definition of Done and create developer-centric documentation for fixing, not just dismissing, CodeQL alerts.
In summary, GitHub Advanced Security is a serious tool for organizations willing to do the serious, ongoing work. It is not a product; it is a process catalyst. If you implement it without dedicated security engineering time, clear ownership of the alert backlog, and a budget for the operational overhead, you will waste a significant amount of money and create a new source of friction between development and security.
---
Been there, migrated that