GitHub Advanced Security — CodeQL-powered SAST, secret scanning with push protection, and Dependabot-fed SCA — is the default suggestion when a platform team standardizes AppSec tooling in 2024, particularly for organizations already on GitHub Enterprise. The list-price economics are blunt: GHAS runs roughly $49 per committer per month, which at a few hundred engineers adds up fast enough to justify an RFP against Snyk, Semgrep, Endor Labs, Checkmarx, and Veracode. The choice is no longer a matter of "best SAST" because most tools now converge on similar finding sets; it is a matter of which tool fits your developer workflow, which integrates into your SCM and CI, and which reduces noise enough that engineers actually fix findings. This post compares the major options on the dimensions that matter for a 2024 buying decision, using public pricing, public feature docs, and the operational experience we see across customer programs.
What does GitHub Advanced Security actually include?
GitHub Advanced Security bundles CodeQL-based SAST, secret scanning with push protection, and Dependabot-powered software composition analysis, with pull request annotations and a dashboard integrated into GitHub Enterprise. CodeQL supports C/C++, C#, Go, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, and Swift, with a queryable semantic graph that lets security teams write custom rules. Secret scanning covers hundreds of token providers and, with push protection on, blocks commits containing new high-confidence secrets before they reach the repo. Dependabot opens PRs for vulnerable dependencies and rebases them. In January 2024 GitHub split GHAS into GHAS Code Security and GHAS Secret Protection, letting customers buy just the secret-scanning piece for a lower price — a significant change that narrowed the list-price gap against competitors.
Where does Snyk win or lose against GHAS?
Snyk wins on developer experience and multi-SCM support; it loses on deep SAST coverage and on the cost at scale. Snyk's IDE integrations — especially for VS Code and IntelliJ — surface findings inline during editing rather than at PR time, which is meaningfully faster feedback than CodeQL's PR-bound model. Snyk Open Source maintains its own vulnerability database with vetted advisories that often lead GHAS by days on fresh CVEs. Where Snyk loses is on the SAST side: Snyk Code is competitive but does not match CodeQL's semantic depth for custom rules, and customers running Snyk SAST at scale commonly pair it with Semgrep or GHAS for coverage on languages where Snyk's engine is thinner. Pricing lands in a similar range per developer, with Snyk's enterprise contracts often softer on mid-market volumes.
How does Semgrep fit into the picture?
Semgrep competes on speed, rule transparency, and open source, and it slots in alongside GHAS as often as it replaces it. Semgrep's rule language is pattern-based and readable, which makes writing and reviewing custom rules dramatically faster than authoring CodeQL queries. Semgrep's open-source engine runs in any CI, and the Semgrep Pro engine adds interprocedural analysis, supply chain (SCA), and secrets. Teams that want a fast PR check with tight triage workflow often run Semgrep at the PR boundary and reserve CodeQL for deeper nightly analysis, or they go Semgrep-only and save GHAS spend. Pricing is typically lower than GHAS on a per-developer basis, particularly for organizations that can live without push protection for secrets.
What does Endor Labs do differently?
Endor Labs focuses on reachability analysis for open-source dependencies, a dimension that GHAS and most competitors treat thinly. The pitch: Dependabot tells you a vulnerable version of log4j is in your tree; Endor tells you whether your application actually calls the vulnerable sink. For programs buried under dependency alerts, that delta is real — the typical Java monorepo has more than half its transitive CVEs in code paths that are never loaded. Endor's approach combines call-graph analysis with SBOM generation and license analytics, and it integrates with GitHub Actions, GitLab CI, and Jenkins. Where Endor does not compete is on SAST or secrets; customers typically pair it with GHAS or Semgrep for those functions.
How do Checkmarx and Veracode stack up in 2024?
Checkmarx and Veracode remain the legacy SAST heavyweights, strong in regulated industries and weaker in developer workflow, and they are losing ground to the lighter-weight alternatives outside of those niches. Both tools still dominate in organizations with long-standing FedRAMP, PCI, or regulated-industry audit postures because their reporting and compliance integrations are mature and their rule sets are accepted by auditors without much argument. But for a 2024 greenfield buying decision, both struggle against Snyk and Semgrep on developer experience, and against GHAS on SCM-native integration. Checkmarx One has closed some of that gap with a cloud-native product, and Veracode's Scan IDE plugin is better than it was, but the trajectory favors newer entrants.
What is a reasonable 2024 buying posture?
A reasonable 2024 posture is to centralize on one primary vendor for SAST and SCA, layer push-protection secret scanning wherever it is native, and add a reachability tool if your OSS dependency depth warrants it. For GitHub-native organizations, start with GHAS and add Endor if reachability is a genuine pain. For multi-SCM organizations, Snyk or Semgrep across SCMs will usually beat GHAS-only and a second tool for the non-GitHub repos. Do not buy five tools for overlapping coverage; the bottleneck is engineering time to triage findings, and adding another scanner without a triage budget increases noise, not security.
# Minimal CI that runs Semgrep as a PR gate with a SARIF upload
- uses: returntocorp/semgrep-action@v1
with:
config: p/ci
publishDeployment: ${{ secrets.SEMGREP_DEPLOYMENT }}
How Safeguard Helps
Safeguard sits above your SAST and SCA tooling as the policy and reachability layer, ingesting findings from GHAS, Snyk, Semgrep, and Endor into a single graph so you can apply consistent policy regardless of which scanner produced a finding. Reachability analysis reduces alert volume by distinguishing truly exploitable paths from library-only exposure, which is the single biggest win over running any of these tools standalone. Griffin AI routes findings through a triage workflow tuned for your codebase and owner map, and SBOM generation complements whichever scanner you use with cryptographic provenance. Policy gates enforce your chosen baseline on every PR, and TPRM assessments extend the same policy to vendor-delivered components so your AppSec posture is uniform across first-party and third-party code.