GH-500 GitHub Advanced Security Guide (2026)

Exam GH-500: GitHub Advanced Security is designed for practitioners who protect code, credentials, and software dependencies throughout the development lifecycle. The audience profile expects more than feature recognition. Candidates should be able to configure security capabilities, triage and remediate alerts, apply prevention-first practices through policies and workflows, collaborate across developer, security, and administrative roles, and automate operations at scale.

The terminology matters. Current GitHub documentation presents GitHub Code Security and GitHub Secret Protection as purchasable security suites for eligible organization repositories, alongside supply chain capabilities such as the dependency graph, Dependabot, dependency review, and SBOM export. Features and plan availability differ for public, private, internal, organization-owned, and enterprise repositories. Do not memorize an old licensing table. Learn to verify current eligibility and then solve the security problem described in a scenario.

The PrepKloud five-phase GH-500 roadmap provides a responsive checklist. This guide explains the reasoning behind it and connects the six domains into one operating model.

Current GH-500 domains and study allocation

Four domains carry a 15–20% range, so a balanced plan is essential. Code Security has a smaller percentage but still contains deep technical details: setup selection, CodeQL workflows, matrices, scan events, data-flow triage, SARIF interoperability, custom analysis, performance, and remediation. Administration also has a 10–15% range, yet configuration inheritance, roles, bypass boundaries, or automation failures can determine whether every other control is effective.

Domain 1: security-suite architecture and a secure SDLC

Begin by separating the risks. Secret Protection finds exposed credentials and prevents supported secrets from being pushed. Code Security uses CodeQL and integrated analysis to identify source-code weaknesses. Supply chain security inventories third-party components, alerts on known vulnerable dependencies, proposes updates, and evaluates dependency changes before merge. One suite does not substitute for the others.

Then place those controls in the lifecycle. Prevention-first security gives developers fast feedback before a risky change reaches a protected branch. Push protection can block a supported credential at push time. Code scanning can annotate a pull request. The dependency review action can fail when a pull request introduces a vulnerable package or violates a license policy. Rulesets or required checks convert those scanner results into an enforceable gate.

Detection and remediation remain necessary because organizations already have code and dependencies, scanners add new rules, advisories change, and prevention has limits. Dependabot alerts find vulnerable dependencies on the default branch. Secret scanning examines history and collaboration surfaces within its documented scope. Scheduled CodeQL analysis can discover risk outside a new pull request. Security campaigns organize a focused backlog across repositories.

Security overview ties these activities together. Coverage and Enablement reveal whether features are operating. Risk views aggregate active alerts. Overview dashboards show detection, remediation, and prevention trends. CodeQL pull-request metrics and secret push-protection metrics help teams evaluate shift-left behavior. Access is permission-scoped, and an empty alert page is not proof of safety: the feature may be disabled, the viewer may lack access, or the issue may fall outside detection.

Domain 2: Secret Protection and push protection

Secret scanning examines Git history and documented collaboration content for supported provider, generic, custom, and other enabled patterns. Alerts are not all identical. User alerts appear in repository security views for detected supported or configured patterns. Push-protection alerts are created when repository push protection is bypassed. Partner alerts are sent directly to participating providers and do not appear as ordinary repository alerts.

The highest-priority fact is operational: if a real credential is exposed, revoke or rotate it first. Removing a file from the latest commit does not invalidate a token that may already have been copied. Rewriting history can reduce future discovery but is slower, disruptive, and not containment. After rotation, investigate possible use, determine affected systems and data, replace hardcoded handling with an identity or secret-management pattern, clean source and history according to policy, and close the alert with accurate evidence.

Validity checks can help prioritize supported secrets by contacting the issuing service to determine whether a credential is active. This is distinct from the partner program, where GitHub sends detected partner secrets to the provider. Validity is valuable context, not the entire decision: an inactive credential may still show a serious development-process failure, and a secret without validity support can still be urgent.

Push protection moves the control earlier. Repository push protection requires Secret Protection and can block supported secrets in command-line pushes, GitHub UI commits, file uploads, REST requests, and other documented surfaces. User push protection is a separate personal protection for public repositories. Bypassing only user protection does not create a repository alert unless repository protection is also active.

For repository protection, the bypass reason matters. A test-use or false-positive reason creates a closed alert with that resolution. “I’ll fix it later” creates an open alert. The event is also available through audit and notification paths. Delegated bypass lets selected reviewers approve requests instead of allowing every contributor to self-bypass. Full exemptions are broader: exempt actors do not trigger the control, so exemption should be rare, attributable, and reviewed.

Domain 3: dependency graph, Dependabot, review, and SBOM

The dependency graph is the foundation. GitHub parses supported manifest and lock files and accepts dependency snapshots through the dependency submission API. It can show dependencies, versions, licenses, manifests, known vulnerabilities, and transitive paths for supported ecosystems. If a build system resolves components that are not statically visible, submit that information. Incomplete inventory weakens every dependent control.

An SBOM is a machine-readable inventory. GitHub exports the current dependency graph in SPDX format through the repository interface or REST API. The export can include versions, package identifiers, licenses, transitive paths, and copyright information. It does not list dependents—outside projects that use your project. An SBOM is valuable for transparency and analysis, but it does not automatically fix or approve components.

Dependabot alerts compare the default-branch dependency graph with GitHub-reviewed advisories. Alerts appear when a new advisory affects a dependency or the dependency graph changes. Each alert can include the affected file, severity, vulnerability details, and a fixed version where one is available. Dependabot cannot detect every issue, does not scan archived repositories, and depends on accurate manifests and the advisory database.

Prioritization should combine severity with exploitability and application context. EPSS can estimate exploitation likelihood when available. Dependency path, direct versus transitive status, actual usage, exposure, asset criticality, and fix availability matter. “Indirect” does not mean harmless, and “no fixed version” does not mean no action. A team may need to upgrade a parent, replace a package, disable a path, add compensating controls, or accept documented time-bound risk.

Dependabot security updates propose fixes for vulnerable dependencies. Version updates maintain packages on a schedule configured in dependabot.yml. The current version 2 configuration requires an ecosystem, directory or directories, and schedule for each update block. Groups reduce pull-request volume. Limits, labels, assignees, cooldown, allow and ignore rules, update strategies, and private registries adapt updates to the repository. Security updates have behavior differences from version updates, so read the option labels rather than assuming one setting applies to both.

Dependency review addresses pull requests. The review displays dependencies added, removed, or updated and can show vulnerable transitive changes. The dependency review action enforces a policy in GitHub Actions and fails by default when it discovers vulnerable packages. Configure severity and license rules, then require the workflow or status check through a ruleset. Without required enforcement, a failure may inform developers but not prevent merge.

Build-time dependency submission introduces sequencing. GitHub recommends running submission before dependency review in the same workflow. Separate execution can create a race where the review snapshot is incomplete. If separation is unavoidable, use the action’s documented retry behavior for snapshot warnings. Direct API integrations should inspect the snapshot-warning header and use bounded exponential backoff.

Domain 4: Code Security with CodeQL and SARIF

CodeQL treats code as data. Analysis creates a database representing a supported codebase, runs queries, and surfaces results as code scanning alerts. Current supported languages include C/C++, C#, Go, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, Rust, Swift, and GitHub Actions workflows. An unsupported language is not made safe by adding its name to a matrix.

There are three main setup paths. Default setup is the fastest low-maintenance route: GitHub selects languages, queries, and scan triggers, with supported customization. Advanced setup creates a workflow you control, which is appropriate for custom build commands, language matrices, events, runners, query suites or packs, paths, and schedules. External CI can run the CodeQL CLI and upload results when analysis must remain in an existing system.

A sound advanced workflow uses minimum permissions, intentional events, appropriate build mode, bounded matrices, and current approved action versions. Scan pull requests for early feedback, the default branch for authoritative state, and on a schedule when the risk model justifies periodic analysis. More scans are not always better if they overload runners or create redundant configurations. Monitor failed extraction, build, database, memory, timeout, and upload behavior.

Code scanning can also display third-party SARIF. GitHub Actions can upload a SARIF file with the CodeQL upload action; the REST API and CodeQL CLI support other paths. When two result sets for the same commit use the same tool and category, a later upload can replace an earlier one. Assign unique categories or runAutomationDetails.id values so monorepo slices, languages, tools, or rulesets remain independent. Partial fingerprints help prevent duplicate alerts as code moves.

During triage, inspect the rule, location, first introduction, affected branches, severity, security severity, and configuration. CodeQL data-flow alerts show how data travels from a source to a sink. Related paths may be grouped under one alert, which helps the reviewer see the full weakness. File categories such as generated, test, library, or documentation are derived from paths and cannot be manually changed to avoid remediation.

Copilot Autofix can propose a code change for supported alerts, but it does not transfer responsibility. Review the patch, confirm that it addresses the trust boundary, add regression and adversarial tests, check compatibility, and re-run analysis. A green alert status without a validated behavioral fix is weak evidence.

Organization-specific analysis can use custom CodeQL models, queries, suites, and query packs. Begin with positive and negative cases. Measure precision and scan cost. Version the pack, publish it through an approved registry, pin or control upgrades, and retain a rollback path. Custom queries should extend risk coverage, not silently replace the default suite with an untested gate.

Domain 5: prioritization, campaigns, and remediation

Security operations turns alerts into decisions. CVE identifies a disclosed vulnerability instance. CWE classifies a weakness type. A GitHub Security Advisory communicates affected software, severity, and remediation information. CVSS provides a severity framework; EPSS can provide exploitation probability context. None of these values knows your complete deployment exposure or business impact, so combine them with reachability, data sensitivity, asset criticality, active exploitation, compensating controls, and fix availability.

Define remediation service levels by priority and alert type. For code, inspect data flow, fix the trust boundary, test, review, merge, and re-scan. For secrets, revoke or rotate, investigate, replace handling, clean source, and document. For dependencies, update and test or establish a time-bound alternative. Assign ownership to a person, team, or supported agent while keeping human review and accountability.

Dismissal is a risk decision. Use an accurate reason, evidence, reviewer, date, and reassessment trigger. A code path believed unreachable can become reachable after a routing change. A “used in tests” secret can escape into a deployed fixture. A vulnerable dependency can become exploitable when a dormant feature activates. Audit decisions and review them when assumptions change.

Security campaigns group related code scanning or secret scanning alerts across repositories. They provide a named contact, notifications, assignments, and progress tracking. Closely related alerts let developers reuse remediation knowledge. Code campaigns can integrate Autofix and repository tracking behavior. Secret campaigns have different behavior and were documented as public preview when this guide was prepared; verify status before relying on them.

A good campaign has a coherent risk statement, bounded repository set, due date, service owners, completion definition, escalation path, and outcome measure. “Assigned” is not “fixed.” Count validated credential rotation, merged code fixes, updated dependencies, appropriate dismissals, and residual blocked work. Pair campaigns with preventive rules so the same risk is not reintroduced faster than the backlog is burned down.

Domain 6: configurations, roles, APIs, and governance

Large organizations need consistent feature baselines. Security configurations let administrators select capabilities and apply them across repositories. Design configurations by risk tier or repository class, pilot representative languages and build systems, observe actual feature activation, and document custom workflow exceptions. Understand current enforcement and inheritance behavior from official documentation rather than assuming every repository setting is independently editable.

Least privilege separates duties. Organization owners manage broad administration. Security managers can oversee security across an organization without every operator becoming an owner. Developers need enough access to understand and fix their repositories. Push-protection reviewers need delegated bypass authority, not permanent exemption. Alert dismissal and policy changes should be constrained to accountable roles. Automation should use a dedicated GitHub App or identity rather than a shared personal token.

APIs make rollout and alert operations scalable, but an HTTP success or process exit code is not proof of coverage. Implement dry runs, pagination, rate-limit handling, idempotent desired-state reconciliation, structured errors, bounded retries, and post-change queries. Record unsupported, ineligible, intentionally excepted, failed, and successful repositories separately. Verify observed state in security overview and sampled settings.

Metrics need context. Track coverage and enablement beside detection, backlog, remediation time, prevention, push-protection blocks and bypasses, dismissal reasons, exception age, and campaign progress. Keep repository scope, date range, filters, and viewer permissions stable. Security overview dashboard values can change as repositories are deleted, archived, or reclassified and advisories change. When compliance requires a stable historical record, use audit-log evidence.

Two projects that convert objectives into evidence

The first GH-500 portfolio project is an enterprise security rollout and campaign. Inventory synthetic repositories, define risk tiers and roles, pilot security configurations, add prevention-first rules, write triage standards, run a focused campaign, build coverage-aware metrics, automate safe reconciliation, test rollback, and clean up. The project demonstrates administration and collaboration without using production source or monitoring individual developers.

The second project is a secure supply chain lab. Build a disposable application, choose CodeQL setup, remediate one isolated toy weakness, demonstrate unique SARIF categories, block a nonfunctional custom secret marker, generate the dependency graph and SPDX SBOM, configure Dependabot, and require dependency review before merge. Every unsafe fixture must be removed, every credential must be synthetic, and the repository must never be deployed publicly.

These projects are intentionally synthetic. A portfolio should show architecture, policy, secure code, alert reasoning, tests, metrics, and cleanup—not employer source, customer records, real secrets, or hidden exam material.

An eight-to-ten-week GH-500 study plan

1. Week 1: read the entire current blueprint and map every objective to a feature, role, alert, workflow, or governance decision.
2. Week 2: navigate security overview, build a repository coverage inventory, and explain prevention, detection, remediation, and administration as one lifecycle.
3. Weeks 3–4: practice Secret Protection in a disposable repository using only an invalid custom marker. Test validity concepts, push blocking, bypass reasons, delegated review, alert response, and cleanup.
4. Weeks 5–6: build dependency graph inventory, export SPDX, configure Dependabot alerts and updates, run dependency review, require its check, and test dependency submission ordering.
5. Weeks 7–8: enable CodeQL, compare setup paths, interpret data flow, remediate a toy finding, upload categorized synthetic SARIF, and test custom analysis concepts.
6. Weeks 9–10: design security configurations and roles, run a campaign, build coverage-aware metrics, preserve audit evidence, test API reconciliation and rollback, then revisit weak objectives.

Use 25 original GH-500 practice questions to diagnose scenario reasoning. Use 25 GH-500 flashcards for active recall. Do not memorize answer positions. Explain why each distractor is incomplete, unsafe, too broad, or aimed at the wrong lifecycle stage.

Common GH-500 preparation and operations mistakes

• Studying only CodeQL. Four other major areas and administration determine end-to-end security.
• Using a live token as a fixture. That creates a real incident and possible provider action.
• Deleting a leaked secret before rotating it. Git cleanup does not invalidate copied credentials.
• Confusing Dependabot alerts with dependency review. One addresses existing default-branch risk; the other prevents risky pull-request changes.
• Running submission and review in parallel. Snapshot races can omit build-discovered dependencies.
• Choosing advanced CodeQL setup by default. Custom workflows add maintenance and failure modes; justify them.
• Reusing one SARIF category. Later results can replace earlier analysis for the same tool and commit.
• Closing alerts to improve a dashboard. Closure does not revoke credentials or remove vulnerabilities.
• Tracking alert count without coverage. Disabled security features can appear falsely safe.
• Granting broad owner, token, or bypass access. Use security managers, delegated review, GitHub Apps, and expiring exceptions.
• Running a campaign without prevention. Backlog can return as quickly as it is remediated.
• Keeping unsafe lab branches and artifacts. Cleanup is part of the security result.

Official references

• Microsoft Learn: Study guide for Exam GH-500
• GitHub Docs: Security overview
• GitHub Docs: Secret scanning
• GitHub Docs: Push protection
• GitHub Docs: Secret scanning alert types
• GitHub Docs: Dependency graph
• GitHub Docs: Dependabot alerts
• GitHub Docs: Dependency review
• GitHub Docs: Export an SPDX SBOM
• GitHub Docs: Dependabot options reference
• GitHub Docs: Code scanning with CodeQL
• GitHub Docs: Code scanning alerts
• GitHub Docs: Uploading SARIF
• GitHub Docs: Security campaigns

Continue across PrepKloud

• GH-500 five-phase roadmap
• GH-500 original practice questions
• GH-500 flashcards
• GH-500 portfolio projects
• Security, DevSecOps, and cloud jobs
• Technology career paths
• All certification roadmaps
• All PrepKloud guides
• PrepKloud editorial policy

Frequently asked questions