Trackr.Live The landing site for Trackr Services
§ Trackr.Live

GitHub Advanced Security & Copilot Autofix

Most appsec tools are something you bolt onto your SDLC. GitHub Advanced Security is the opposite case: it is the security layer already living inside the platform your developers commit to, and that single fact drives almost everything good and bad about it. The scanning runs in GitHub Actions on pull requests and pushes. Findings show up in the PR conversation and the security overview tab, next to the code, where the person who wrote the bug actually looks. Adoption tends to follow, because nobody has to open a second tool.

That also means GHAS is not portable. None of this follows you to GitLab or Bitbucket. If you already live in GitHub, it is excellent. If you don’t, it is not a reason to migrate, and I’ll come back to that.

An abstract code pipeline with security gates positioned at the pull-request stage, alerts surfacing inline before a merge.

Three things people conflate

Before anything else, untangle the names, because the marketing has made a mess of them and half the confusion in an ATO conversation traces back to it.

GitHub Copilot is the AI pair-programmer. It writes code for you in the editor. It is a separate paid product, and it has nothing to do with security scanning.

Copilot Autofix is a security feature. When CodeQL flags a code-scanning alert, Autofix uses an LLM plus the surrounding code and the analysis context to draft a suggested fix you can review and apply from the PR. Same “Copilot” brand, completely different job.

GHAS, now “GitHub Advanced Security products” is the appsec suite itself: CodeQL code scanning, secret scanning with push protection, Dependabot and dependency review, security campaigns, and the overview dashboards. Autofix is one feature inside that suite.

Get this distinction stated early in your SSP narrative or your security overview walkthrough. An assessor who hears “Copilot” and pictures an autocomplete toy will discount the whole thing.

The 2025 unbundling

Here is the fact most likely to be stale in whatever doc you inherited. As of April 1, 2025, GitHub broke the old all-or-nothing GHAS bundle apart. There are now two standalone, separately purchasable products, and you can buy one without the other.

GitHub Secret Protection carries secret scanning, push protection, AI-assisted secret detection, and the secret risk assessment. GitHub Code Security carries CodeQL code scanning, Copilot Autofix, Dependabot and dependency review, and security campaigns. Both moved to metered, consumption-based billing per active committer rather than a fixed seat count, and both became available to GitHub Team plan customers for the first time. You no longer need a full Enterprise subscription to turn on secret scanning.

The umbrella phrase “GitHub Advanced Security products” survived as the family label, so people still say “GHAS” and that’s fine. The single bundle it used to name is gone.

Product What’s in it Approx unit price Where it’s authorized
Legacy GHAS bundle (pre-2025) Everything below, sold as one Enterprise add-on Per-committer, Enterprise only Retired April 2025
GitHub Secret Protection Secret scanning, push protection, AI secret detection, risk assessment ~$19 / active committer / mo GHEC (Gov: FedRAMP Mod / IL2) or GHES self-hosted
GitHub Code Security CodeQL, Copilot Autofix, Dependabot, dependency review, security campaigns ~$30 / active committer / mo GHEC (Gov: FedRAMP Mod / IL2) or GHES self-hosted

Treat those prices as directional and check the current pricing page before you put a number in a budget. Metered billing also means cost is a function of how many people touched a repo this month, which on a large monorepo or a sprawling org scales in a way that surprises people. Run the active-committer estimate before you commit; GitHub exposes a calculator for it.

Copilot Autofix, honestly

Autofix went generally available for Advanced Security customers on August 14, 2024, then free for all public repositories on September 18, 2024. It generates suggested fixes for CodeQL code-scanning alerts using an LLM with the codebase and analysis as context. Current builds run on a Codex-class model; the model behind it has rotated more than once and will again, so don’t pin your mental model to a specific version.

GitHub’s own beta numbers (these are GitHub’s, not independent measurement): vulnerabilities with a suggested fix close roughly 3x faster overall, with claimed 7x on cross-site scripting and 12x on SQL injection. Their 2025 operational figures put median resolution around 0.66 hours with Autofix against 1.29 without. Useful directionally. I would not carry those multipliers into a control narrative as if they were your numbers.

Coverage is a subset of the default and security-extended CodeQL queries, across C#, C/C++, Go, Java and Kotlin, Swift, JavaScript and TypeScript, Python, Ruby, and Rust. Not every alert gets a suggestion. The query you most want fixed may be one of the ones it doesn’t cover yet.

The 2026 story to track: GitHub is extending AI-powered scanning beyond CodeQL into ecosystems CodeQL never handled well, namely Shell and Bash, Dockerfiles, Terraform/HCL, and PHP. As of this writing that is in public preview (announced March 2026, rolling out across Q2). It is not the stable, GA, lean-on-it-for-your-ATO path yet. Write it as preview in any doc that matters, and re-check status before you cite it, because preview-to-GA on GitHub features moves fast and the docs sometimes lag the changelog.

Where I’ll plant a flag: Autofix is a triage accelerator, not an auto-merge. It lowers the friction of remediation, which is real value. The failure is wiring it into a workflow that applies suggestions without a human reading them. An LLM-drafted patch to a taint-flow bug can be right, plausible-but-wrong, or right in a way that breaks an adjacent assumption. Someone reviews it. If your process treats Autofix as a robot that closes alerts, you have built a machine for shipping confident mistakes.

Where it sits in a federal flow

This is developer-embedded appsec, so the owner is usually the dev, AppSec, or DevSecOps team, not the ISSO. The ISSO consumes the evidence; the engineers run the tool. Cadence is continuous: per-PR and per-push, plus scheduled full scans. That maps cleanly onto SA-11 developer security testing done as an ongoing activity rather than a one-time gate, which is exactly how RMF wants it framed.

The deployment shape splits hard on impact level, and getting this wrong in an SSP is a fast way to lose credibility.

Deeper: the authorization boundary is the whole question for DoD.
GitHub Enterprise Cloud for Government runs on Azure Government and holds FedRAMP Moderate authorization, which carries it to DoD SRG IL2 through that ATO. (Commercial GHEC was pursuing FedRAMP Moderate as of late 2024; confirm which offering and level your tenant actually sits under, because the marketplace listing distinguishes them.) For IL4 or IL5 the answer is not cloud GHAS at all. It is GitHub Enterprise Server, self-hosted, deployed inside your own IL4/IL5 boundary in GovCloud or Azure Gov, where the GHAS features run within the org’s accreditation envelope. The authorization attaches to the hosting platform, never to the scanning feature. CodeQL is not “FedRAMP authorized” as a thing. GHEC is, and CodeQL happens to run on it. With GHES you inherit far more of the control burden yourself, which is the trade you make to reach the higher impact levels.

GHAS is also not a DoD APL item in the network-appliance sense. Don’t assert an APL listing; the platform’s authorization story is FedRAMP and the SRG, not the APL.

Integration and the parts that bite

Findings export as SARIF, which is the lingua franca for pushing alerts into other dashboards or a SIEM. The dependency graph feeds Dependabot. Push protection hooks the secret-scanning partner program so a leaked credential gets caught at git push before it lands.

What there is no button for: eMASS. Getting GHAS findings into eMASS or a POA&M is a custom-glue exercise over SARIF and the REST API. There is no built-in eMASS connector and you should not expect one. Budget the engineering.

The pitfall that catches people: secret scanning detects, it does not remediate. Push protection stops a new secret from landing. A credential already committed to history months ago still sits in the git objects, and detection of it does nothing until someone rotates the key and purges the history. Detection is not rotation. Plan the rotation runbook, because the alert is the easy part.

Compiled languages add their own friction. CodeQL’s build-mode setup for C/C++, Java, and the like is where teams burn the first week, and the false-positive rate on a fresh CodeQL config will flood the security tab before anyone has tuned the queries. The dataflow engine is genuinely strong for taint-style and injection bugs, which is the reason to put up with the setup, but “strong engine” and “quiet out of the box” are not the same thing.

Control ties

GHAS generates evidence for these families. It does not “satisfy” them; an assessor still grades your implementation, not the vendor’s feature list.

  • SA-11 developer testing and evaluation is the strongest fit. CodeQL is static analysis under SA-11(1); secret, dependency, and code scanning together feed continuous developer testing rather than a one-shot gate.
  • SA-15 development process, tools, and standards. GHAS is the toolchain enforcing the secure-development practice, and SA-15(7) automated vulnerability analysis maps directly to it.
  • SR-3 / SR-4 supply chain. Dependabot, dependency review, and the dependency graph address third-party component risk and feed SBOM and provenance work.
  • RA-5 vulnerability monitoring. Continuous code and dependency scanning is ongoing vulnerability identification, which is what RA-5 wants.

CM-6 only brushes it, through branch-protection required-checks and the config of the scanning itself. I wouldn’t force CM-6 into the narrative; it reads as padding.

What it comes down to

If your code already lives in GitHub, Code Security and Secret Protection are a strong, well-integrated way to get SAST, SCA, secret detection, and AI-assisted remediation into the place developers already work, with a clean SA-11 and SA-15 evidence story. The honest limits are real too: per-active-committer cost scales painfully on big orgs, CodeQL needs tuning and build-mode patience, Autofix covers a subset of queries and must never auto-merge, the AI-beyond-CodeQL coverage is still in preview, and the eMASS path is yours to build. For a polyglot shop that isn’t on GitHub, a dedicated SAST like Fortify or Checkmarx is still the better-fit answer, and GHAS is not the reason to switch platforms.

Sources

Adjacent material on this site