How to Pass GitHub Advanced Security (GHAS) Certification in 2026: Complete Study Guide

GitHub Advanced Security (GHAS) is GitHub's suite of application security tools built directly into the development workflow — code scanning with CodeQL, secret scanning, and supply chain security through Dependabot and dependency review. The GitHub Advanced Security Certification validates that you can configure, use, and administer these tools effectively across an organization. This guide covers every domain, the exam format, key concepts that show up on test day, and a 4-week study plan to get you exam-ready.

Exam Format and Registration

The GHAS certification is the most security-focused of the GitHub certifications. Candidates are expected to understand not just how to enable features, but how to interpret alerts, remediate findings, and configure security policies across an organization. Software developers, DevSecOps engineers, and security engineers are the primary audience.

Domain Breakdown and Weights

Domain 1: Code Scanning and CodeQL

Code scanning analyzes source code for security vulnerabilities and coding errors. GitHub's primary code scanning engine is CodeQL — a semantic code analysis tool that models code as data and queries it to find patterns that indicate vulnerabilities.

Key concepts to master:

• CodeQL database: When CodeQL analyzes a codebase, it first builds a database — a representation of the code's structure, data flow, and control flow. The database is then queried to find vulnerabilities. For compiled languages, this requires a build step; for interpreted languages, the extractor runs without building.
• Query suites: GitHub provides built-in query suites. The default suite contains high-precision, high-severity queries used in code scanning by default. The extended suite adds more queries with some additional false positives. The security-and-quality suite is the most comprehensive.
• QL language: CodeQL uses its own declarative query language (QL) to express vulnerability patterns. Basic syntax: from (declare variables), where (filter conditions), select (output). You do not need to be a QL expert, but understand the structure.
• SARIF format: Static Analysis Results Interchange Format — the standard JSON format for code scanning results. You can upload SARIF results from third-party scanners to GitHub using the code scanning API or the github/codeql-action/upload-sarif action.
• Default setup vs advanced setup: Default setup enables CodeQL with recommended settings automatically (no workflow file needed). Advanced setup gives you full control via a workflow file — required for custom queries, non-default languages, or special build requirements.
• Alert lifecycle: Code scanning alerts can be open, fixed (code changed so the pattern no longer matches), dismissed (manually closed with a reason: false positive, won't fix, used in tests). Dismissed alerts are not re-opened automatically.
• Supported languages: CodeQL supports C/C++, C#, Go, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, Swift. Know which languages require a build step (compiled) vs not (interpreted).

Domain 2: Secret Scanning

Secret scanning detects credentials, API keys, and other secrets that have been accidentally committed to repositories.

Key concepts to master:

• Partner patterns: GitHub maintains partnerships with 100+ service providers (AWS, GitHub, Stripe, Slack, etc.). When a partner pattern is detected, GitHub notifies both the repository owner AND the service provider, who can revoke the credential automatically.
• Non-partner patterns: GitHub also detects patterns not covered by partners — these generate alerts but do not notify an external service provider.
• Custom patterns: Organizations can define custom regex-based patterns to detect internal secrets. Custom patterns can be created at the repository, organization, or enterprise level.
• Push protection: A proactive control that blocks pushes containing detected secrets before they reach the repository. Users can request a bypass with a justification. Bypasses are logged.
• Validity checks: For supported partners, GitHub can check whether a detected secret is still active (valid) using the provider's API. Alerts can be marked as "active", "inactive", or "unknown validity".
• Alert resolution states: Open, resolved (secret revoked, false positive, used in tests, or won't fix). Unlike code scanning, secret scanning alerts do not automatically close when the secret is removed from the code — they must be manually resolved.

Domain 3: Dependency Review and Supply Chain Security

Supply chain attacks target dependencies rather than first-party code. This domain covers how GitHub helps you understand and secure your software supply chain.

Key concepts to master:

• Dependency graph: GitHub automatically builds a graph of your repository's dependencies by parsing package manifests (package.json, requirements.txt, pom.xml, etc.). The dependency graph powers Dependabot and vulnerability detection.
• Dependabot alerts: Notifications when a dependency in your repository has a known vulnerability (based on the GitHub Advisory Database). These are read-only alerts — they do not change your code.
• Dependabot security updates: Automatically open PRs to upgrade vulnerable dependencies to a patched version. Requires Dependabot alerts to be enabled.
• Dependabot version updates: A separate feature that opens PRs to keep dependencies up to date with the latest releases — regardless of whether they are vulnerable. Configured via dependabot.yml.
• Dependency review action: A GitHub Action (actions/dependency-review-action) that runs on PRs and blocks merging if the PR introduces dependencies with known vulnerabilities. Configurable with fail-on-severity threshold.
• SBOM (Software Bill of Materials): GitHub can export a dependency graph as an SBOM in SPDX or CycloneDX format via the API or repository insights.
• SLSA (Supply chain Levels for Software Artifacts): A framework for supply chain integrity. GitHub Actions can generate SLSA provenance attestations for build artifacts.

Domain 4: Security Policies and Administration

Security policies define the rules and expectations for security in a repository or organization. This domain covers both the technical settings and the human-readable policy documents.

Key concepts to master:

• SECURITY.md: A file in the repository root (or .github/) that documents the security policy for the project — how to report vulnerabilities, disclosure timelines, and contact information. GitHub surfaces this file in the Security tab.
• Private vulnerability reporting: Enables security researchers to report vulnerabilities directly to maintainers via GitHub, without creating a public issue. The report is private until the maintainer acknowledges and addresses it.
• Required security features: Organization admins can require specific GHAS features to be enabled in all repositories. Enterprise owners can enforce these requirements across all organizations.
• Security manager role: An organization-level role that grants read access to all security alerts across all repositories in the organization, without granting admin or write access. Ideal for security team members.
• Code scanning required workflow: Organizations can set a required workflow for code scanning that runs on all repositories — ensuring consistent security scanning across every project.
• GitHub Advisory Database: GitHub's database of known vulnerabilities (CVEs and GitHub-reviewed advisories). Dependabot alerts are based on this database. Organizations can also create private security advisories for their own packages.

Domain 5: Security Overview and Reporting

The security overview provides a centralized dashboard showing the security posture of all repositories in an organization or enterprise.

Key concepts to master:

• Organization security overview: Shows which repositories have GHAS features enabled, alert counts by type, and which repositories have unresolved alerts. Accessible to organization owners and security managers.
• Enterprise security overview: Aggregates security data across all organizations in the enterprise. Shows adoption metrics and cross-organization alert trends.
• Alert metrics: Mean time to remediate (MTTR), alert counts by severity, alert age distribution. These help organizations measure the effectiveness of their security program.
• Filtering and export: Security overview supports filtering by repository, alert type, severity, and state. Data can be exported via the REST API for integration with external dashboards.
• Coverage views: Show what percentage of repositories have each GHAS feature enabled — useful for tracking adoption progress.

4-Week Study Plan

Passing Tips

• Enable vs enforce. Many exam scenarios test whether you know that GHAS features must be explicitly enabled at the repository level, and whether org settings force them on. Know the difference between enabling, requiring, and enforcing each feature.
• Understand alert states. Code scanning alerts auto-close when the vulnerability is fixed; secret scanning alerts do not. Dismissed alerts vs resolved alerts have different implications. These nuances appear on the exam.
• SARIF is not CodeQL. CodeQL generates SARIF output, but SARIF is a format — any scanner can produce SARIF. GitHub can ingest SARIF from any tool via the upload-sarif action or API.
• Dependency review vs Dependabot alerts. Dependabot alerts work on the default branch; dependency review action works on PRs. They serve different purposes at different points in the development lifecycle.
• Security manager role. This role comes up frequently in scenario questions. Know exactly what it grants (read access to security alerts across all repos) and what it does not grant (write access, admin access, ability to change security settings).