GitHub Advanced Security (GHAS) puts code analysis, secret detection and dependency checks directly inside the repository and the pull request. Vulnerabilities and leaked credentials surface at the moment the code is written, in the same place the developer already works.
Start here
GHAS is a set of security capabilities built into GitHub itself. Instead of sending code to an external scanner and waiting for a report, the analysis runs on GitHub's own infrastructure, against the repository, and writes results back into the developer's normal workflow.
Code Scanning analyses the source you write and flags issues such as SQL injection, cross-site scripting or unsafe deserialisation before they ever reach production.
In plain words: a very thorough reviewer that reads every line, every time, and never gets tired.Secret Scanning looks for API keys, tokens, passwords and certificates in code, commits, issues and history, and can block a push that contains one.
In plain words: a bouncer at the door that checks nobody is carrying the office keys out of the building.Copilot Autofix proposes a concrete code change for most alerts. The developer reviews a suggested diff rather than reading a PDF finding and researching a remedy.
In plain words: the tool does not only say "this is broken", it offers the patch.Capabilities
Code Scanning and Secret Scanning solve two different problems. One looks for mistakes in the logic you wrote. The other looks for credentials that should never have been committed at all.
Static analysis powered by CodeQL. Your code is turned into a queryable database, then hundreds of security queries run against it to trace how untrusted input flows through the application into a dangerous operation.
Pattern matching for credentials, built with more than 200 partner providers. It checks new commits, the full git history, plus issues, pull request bodies and descriptions.
Shows the security impact of a dependency change inside the pull request, and opens automated update PRs for vulnerable packages.
Why it matters: most application code today is other people's code.One org-level dashboard showing risk and coverage across every repository: which repos are enabled, where the open alerts sit, and how fast they are being closed.
Why it matters: security leads need the aggregate view, not 400 repo tabs.Bundle a set of existing alerts into a tracked remediation effort, assign them to the right teams, and drive the backlog down with Autofix suggestions attached.
Why it matters: turns a long alert list into finite, assignable work.Software Development Lifecycle
GHAS is not one gate at the end. It attaches to five points in the lifecycle, each with a different owner and a different cost of failure. The earlier a problem is caught, the cheaper it is to fix.
Secret scanning and code scanning results surface in the IDE, so problems are visible before a commit exists.
Owner: DeveloperPush protection blocks commits containing live credentials. The secret never enters git history.
Owner: DeveloperCodeQL analysis and dependency review run as checks. Findings appear as inline comments with suggested fixes.
Owner: ReviewerMerge protection can require the security checks to pass. Third-party scanner results feed into the same alert model via SARIF.
Owner: Platform teamScheduled scans and new advisories re-evaluate code already shipped. Dependabot opens update PRs when a CVE lands.
Owner: Security teamContinuous, and in parallel with development. This is the single biggest difference from a classic scanning tool.
A separate team runs a tool at the end of a release cycle, or once a quarter. Results arrive as a report, days or weeks after the code was written. The developer has moved on to other work and has to reload the whole context to fix anything. Findings compete with feature deadlines and often lose.
Result: a backlog of stale findings and a late, expensive fix.Analysis is triggered by the developer's own actions: every push, every pull request, plus a schedule on the default branch. The result lands within minutes, on the exact diff, while the code is still fresh in the author's head. Security work becomes part of the review, not a separate project.
Result: issues are fixed in the same pull request that created them.Developer workflow
Nothing here asks a developer to open a new tool, log into a separate console, or learn a new vocabulary. The security signal arrives inside the pull request they already had open.
No agent to install per machine, no local scan to remember to run. Configuration lives with the repository.
Push protection rejects the push and names the credential type and file. The developer removes it, or requests a bypass that is logged for the security team.
CodeQL analysis and dependency review run as GitHub Actions checks, in parallel with the unit tests. Typical feedback within minutes.
Each alert is an inline comment on the offending line, with the data-flow path and severity. Copilot Autofix attaches a proposed code change the developer can commit directly.
Branch protection can require the security checks to pass before merge. Clean code goes in. Accepted risk is documented as a dismissal with a reason.
Scheduled scans and new security advisories re-evaluate the default branch. If a dependency you shipped last year becomes vulnerable, Dependabot opens the update PR.
The case for it
These two features cover the two most common and most damaging root causes of application breaches: a flaw in the code, and a credential that got out.
A vulnerability needs an attacker to find and weaponise it. A live API key needs nothing. Public repositories are continuously scraped by automated tooling, and a committed cloud credential can be used within minutes of the push.
And: deleting the line does not help. The secret stays in git history until it is revoked. Push protection is the only reliable answer, because it stops the commit from happening.A vulnerability caught in a pull request is a small edit by the person who wrote the code. The same vulnerability found in production is an incident: triage, a hotfix, a release, possibly a disclosure and a customer conversation.
And: code review by humans does not scale to every line of every PR. Automated analysis does, and it never skips a file because the sprint is ending.Time from writing insecure code to being told about it, instead of weeks.
Most findings are resolved in the pull request that introduced them.
Push protection prevents new secrets entering history, rather than reporting them afterwards.
One security overview across all repositories, replacing scattered tool reports.
Feedback on their own diff, in their own language, with a suggested fix. Less context switching, fewer surprise security tickets months later.
Coverage across every repository instead of sampling. Alerts with data-flow evidence, and campaigns to drive the backlog down with named owners.
Fewer late-stage blockers before a release, auditable evidence of controls, and a consistent policy applied across the whole estate.
Commercials
GHAS is licensed per active committer, billed monthly. An active committer is a developer who pushed at least one commit to a repository where the product is enabled, during that billing month. Someone who did not commit that month is not billed for that month.
| Product | List price | Metric | What you get |
|---|---|---|---|
| GitHub Secret Protection | $19 | per active committer / month | Secret scanning, push protection, validity checks, custom patterns, partner alerts, historic scan. |
| GitHub Code Security | $30 | per active committer / month | CodeQL code scanning, Copilot Autofix, dependency review, security campaigns, SARIF ingest. |
| Both together | $49 | per active committer / month | The full GHAS scope. Matches the price of the legacy bundled GHAS licence. |
| Public repositories | $0 | free | Code scanning, secret scanning and dependency features are free on public repos. |
The count is derived from commits in the billing period, not from a static seat list. Contractors who finish an engagement drop out of the count automatically.
A developer working across ten enabled repositories is counted once, not ten times. The billing unit is the person in the enterprise, per month.
Turn it on per repository or per organisation. Start with the repositories that carry real risk, watch the committer count, then widen the scope.
Common questions
The questions that come up most often in the first conversation about GHAS.
Scans run as checks in parallel with your existing tests, so they overlap with work that was happening anyway. Analysis time depends on repository size and language, and typically lands in minutes. You decide whether a failing security check blocks merge or is advisory.
CodeQL traces actual data flow rather than matching keywords, which keeps noise well below a naive pattern scanner. Alerts can be dismissed with a documented reason, queries can be tuned per repository, and Copilot Autofix reduces the effort for the alerts that are real.
Not necessarily. Third-party scanners can upload SARIF results into the same alert list, so GitHub becomes the single place developers look. Many teams keep a specialist tool and use GHAS as the always-on layer in the developer workflow.
A historic scan flags them. The important step is revoking and rotating the credential, because it stays retrievable in git history even after the line is deleted. Push protection then prevents the next one from getting in.
Yes. Enablement is per repository, and can be applied at organisation level with security configurations so new repositories inherit the policy automatically. Billing follows the committers in the repositories you enabled.