27 min read6 domains coveredFree practice, no sign-up
The GitHub Advanced Security (GH-500) certification tests one practical skill above feature trivia: knowing which GitHub security capability to enable, at which scope, to meet a stated security requirement. GitHub hands you a scenario about a repository, organisation, or enterprise with a credential, dependency, or code-quality risk, then asks which feature and configuration addresses it. The hard part is rarely knowing that code scanning exists. It is knowing that code scanning with CodeQL belongs to Code Security, that secret scanning and push protection belong to Secret Protection, that the dependency graph powers Dependabot and dependency review, and which of those you turn on, where, and in what order to prevent a problem rather than clean it up afterwards.
It suits security engineers, platform and DevOps engineers, and application developers who already work in GitHub and need to prove they can configure GitHub Advanced Security across the software development lifecycle. The exam draws across six weighted areas: describing the security suites and ecosystem, configuring Secret Protection, configuring supply chain security, configuring Code Security, running security operations and remediation, and administering the suites at enterprise, organisation, and repository scope. Several areas overlap, so the same feature (push protection, for example) shows up as a Secret Protection control, a prevention-first operations practice, and an administration toggle inside a security configuration.
The exam rewards decision rules over memorised menus. Most questions are short situations where two or three options sound plausible and only one matches the documented default behaviour, the correct enablement scope, and a prevention-first posture. The skill being tested is choosing correctly under that pressure, which is why working through scenario questions with a worked explanation, and a reason every wrong option is wrong, beats reading product overviews. Know what each feature is licensed under, what it does by default, and at which level you switch it on.
GH-500 is a configure-the-right-control exam: nearly every question is a scenario where the answer is the documented GitHub Advanced Security feature, enabled at the correct repository, organisation, or enterprise scope, that prevents the problem early rather than remediating it late.
Difficulty
Intermediate
Best for
Working GitHub practitioners: security engineers, platform and DevOps engineers, and application developers who use GitHub day to day and need to prove they can enable and configure GitHub Advanced Security (code scanning with CodeQL, secret scanning, push protection, Dependabot, dependency review, and security overview) across the development lifecycle and across enterprise, organisation, and repository scopes.
Prerequisites
None enforced. You should be comfortable with everyday GitHub: repositories, pull requests, branches, GitHub Actions workflows, and organisation and repository settings. Hands-on time enabling secret scanning, reviewing a code scanning alert, and editing a dependabot.yml file is what actually carries you through the scenarios.
Approximately 75
Questions
90 min
Time allowed
700 / 1000
Pass mark
$99
Exam cost (USD)
292
Practice questions
How this exam thinks
One habit decides this exam: read the scenario for the requirement, then pick the documented GitHub feature at the correct scope that prevents the problem earliest. GH-500 consistently favours the supported, built-in mechanism over a hand-rolled workaround, the prevention-first control over after-the-fact cleanup, and the right enablement tier (repository versus organisation versus enterprise) over the wrong one. When two options both seem to work, the one that matches GitHub's default behaviour and shifts the control left in the lifecycle usually wins.
The rest is a set of discriminations the exam leans on. For licensing, map every feature to its product: code scanning with CodeQL is Code Security; secret scanning and push protection are Secret Protection; the dependency graph, Dependabot, and dependency review are supply chain features, with secret scanning free on public repositories but paid on private and internal ones. For prevention, push protection stops a secret at push time, dependency review blocks a vulnerable or wrongly licensed dependency before merge, and a CodeQL pull request scan catches a flaw before it lands, while security campaigns and bulk remediation address what is already live. For scope, an enterprise security configuration is authored once and offered down to organisations, a default configuration only governs repositories created after it is set, and existing repositories must be attached in bulk. For rulesets, evaluate is the non-blocking dry run, active enforces, and bypass modes differ between Always and Pull request. Name the requirement, then choose the supported feature at the correct scope built for it.
What each domain tests and how to study it
The GH-500 blueprint is split across 6 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.
What you must be able to do. Given a scenario about which security capability addresses a risk, place each feature under the correct product (Code Security, Secret Protection, or Supply Chain Security), judge its availability for public versus private and enterprise repositories, and order controls along the secure development lifecycle from prevention to remediation.
In one sentenceThe orientation domain: knowing what each GitHub Advanced Security feature is, which licensable product it belongs to, where it is available, and where it sits in a prevention-first lifecycle.
Recall check: answer these from memory first
Name the licensable product for each feature: code scanning with CodeQL, secret scanning, push protection, and dependency review.
Which security features run free on a public repository on GitHub.com, and what changes for a private or internal repository?
Order these controls from earliest prevention to latest remediation: a CodeQL pull request scan, push protection at push time, dependency review on a pull request, and a security campaign in production.
What it tests. Mapping the GitHub security ecosystem before configuring any of it. Understanding the structure of the security suites and the security overview, and contrasting Code Security (code scanning with CodeQL), Secret Protection (secret scanning and push protection), and Supply Chain Security (dependency graph, Dependabot, dependency review). Differentiating feature availability across public repositories, private and internal repositories, and enterprise environments, including which features are free and which require a paid licence and seat. Applying a secure software development lifecycle with these features, comparing a prevention-first approach with gate-based strategies and security campaigns. Identifying vulnerability and secret detection mechanisms and choosing how to act on, dismiss, or ignore alerts across roles, and explaining alert access management, roles, delegated bypass, and enforcement.
How to study it. Build the product map first, because every other domain rests on it. Draw three columns (Code Security, Secret Protection, Supply Chain Security) and place each feature: code scanning with CodeQL under Code Security; secret scanning and push protection under Secret Protection; dependency graph, Dependabot alerts, Dependabot security updates, and dependency review under supply chain. Learn the public-versus-private split cold: secret scanning and the dependency graph are free on public repositories, while extending detection to private and internal repositories needs a paid product and seat. Practise ordering controls along the lifecycle using the shift-left principle: push protection at push time, then dependency review and a CodeQL pull request scan as pre-merge gates, then security campaigns and bulk remediation for what is already in production. Use the security overview to see where alerts surface across an organisation, and learn which roles can act on, dismiss, or bypass each kind of alert.
Easy to confuse
GitHub Secret Protection versus GitHub Code Security as separately purchasable products. Secret Protection contains secret scanning and push protection; Code Security contains code scanning with CodeQL. They are now sold as standalone products, so buying one does not grant the other, which means buying only Secret Protection gives credential detection and prevention but not static analysis.
Security overview versus the product that detects the alert. Security overview is the reporting and triage surface that aggregates alerts across repositories and organisations; it does not perform detection. The detection itself belongs to code scanning, secret scanning, or Dependabot, so an alert is owned by its product even though it is viewed in security overview.
Worked example from the GH-500 bank
lock_openFree sampleDescribe GitHub Security suites, features, and ecosystemmedium
A finance lead is told that "GitHub Advanced Security" is now sold as two standalone products and wants to buy only the capability that detects and blocks exposed credentials, holding off on static analysis to control cost. They ask which features they would and would not gain by purchasing only "GitHub Secret Protection" on a private repository in GitHub Enterprise Cloud. Which statement is accurate?
ABuying Secret Protection enables secret scanning, push protection, and code scanning with CodeQL, because both belong to the same Advanced Security licence and cannot be purchased apart.
BBuying Secret Protection enables secret scanning and Dependabot alerts but not push protection, because push protection requires the separate GitHub Code Security product.
CBuying Secret Protection enables nothing on a private repository until GitHub Code Security is also purchased, because the two products are licensed only as a bundle.
DBuying Secret Protection enables secret scanning and push protection but not code scanning with CodeQL, which is licensed separately under GitHub Code Security.check_circle Correct
Map secret scanning and push protection to GitHub Secret Protection and code scanning with CodeQL to GitHub Code Security as separately purchasable products. Advanced Security is now offered as two standalone products. GitHub Secret Protection contains secret scanning and push protection, and GitHub Code Security contains code scanning with CodeQL. Buying one does not grant the other, so purchasing only Secret Protection delivers credential detection and prevention but not static analysis.
Why A is wrong: This reflects the older single-licence model where the two arrived together, which makes it tempting. Since the split into two standalone products, code scanning sits under GitHub Code Security and is not included when only Secret Protection is purchased, so this is no longer correct.
Why B is wrong: Push protection is a core part of Secret Protection rather than Code Security, so the pairing here is wrong. Dependabot alerts are a Supply Chain Security feature that is free on all repositories and is not gated behind Secret Protection, so two parts of this statement are mistaken.
Why C is wrong: The two products are sold independently and each enables its own features on private repositories, so Secret Protection works without Code Security. The claim that they are licensed only as a bundle contradicts the standalone product model and is incorrect.
Why D is correct: Secret Protection bundles secret scanning and push protection, the credential detection and prevention controls, while code scanning with CodeQL is the static analysis capability sold under the separate GitHub Code Security product. Purchasing only Secret Protection therefore leaves code scanning unlicensed, which matches the finance lead's stated intent.
What you must be able to do. Given a scenario about leaked or about-to-be-leaked credentials, enable secret scanning and push protection at the correct scope, predict alert lifecycle behaviour (reopening, history scanning, validity checks), and apply the right remediation and access controls including delegated bypass and custom patterns.
In one sentenceThe credential-protection domain: enabling secret scanning and push protection, knowing what they scan and when alerts reopen, and remediating exposed secrets by rotating rather than just dismissing.
Recall check: answer these from memory first
When secret scanning is first enabled on a repository with years of history, what does it examine, and why do teams see a burst of alerts?
A previously dismissed or resolved secret is committed again on the default branch. Does secret scanning create a new alert, stay closed, or reopen the original, and why?
A real cloud key has leaked and the alert is closed. What is the correct remediation, and why is closing the alert not enough?
What it tests. Configuring and operating Secret Protection end to end. Enabling and configuring secret scanning and push protection at repository and organisation level and contrasting behaviour for public versus private and enterprise repositories. Explaining how push protection prevents secrets at the source, and describing validity checks and prioritised alerting for high-confidence secrets. Managing the secret alert lifecycle from creation through status changes to dismissal, and applying the correct remediation when a secret is exposed, which is rotation of the live credential rather than only closing the alert. Controlling access with role-based and delegated bypass policies, configuring alert recipients and exclusions, and creating and managing custom secret scanning patterns including dry runs and pattern scope.
How to study it. Anchor on three behaviours the exam tests repeatedly. First, what gets scanned: enabling secret scanning backfills against the entire Git history of a repository and then scans new pushes incrementally, so expect a burst of alerts for old, never-rotated tokens. Second, the alert lifecycle: secret scanning tracks an alert by the secret value, so re-committing a previously dismissed or resolved secret reopens the original alert and adds the new location rather than spawning a duplicate or staying closed. Third, remediation: the correct fix for an exposed secret is to rotate or revoke the live credential, because the secret is already out; closing the alert alone does not. Learn push protection as the prevention control that blocks a secret at push time before it ever reaches history, and how delegated bypass lets a developer request an exception that a reviewer approves. Practise authoring a custom pattern and running a dry run to estimate matches before enabling it.
Easy to confuse
Secret scanning versus push protection. Secret scanning detects credentials that are already in the repository or its history and raises alerts after the fact; push protection blocks a supported secret at push time before it is ever committed. One is detection of what exists, the other is prevention at the source.
Dismissing a secret scanning alert versus rotating the leaked credential. Dismissing only changes the alert status and does not make the exposed secret safe, and if the value reappears the alert reopens; rotating or revoking the live credential is what actually removes the risk because the secret is already exposed.
Worked example from the GH-500 bank
lock_openFree sampleConfigure and use Secret Protectionmedium
A security engineer enables secret scanning on a private repository that has years of existing commit history. Several hard-coded tokens were committed long ago and have never been rotated. The engineer wants to know what secret scanning will examine once the feature is switched on, so they can plan triage of any historical exposures rather than assuming only future commits are covered. What does enabling secret scanning do with respect to the repository's history?
AIt scans only commits pushed after the feature is enabled, so historical tokens must be surfaced by manually re-pushing the affected files to trigger a scan.
BIt scans only the current tip of each branch, so a token that was overwritten in a later commit will not be reported even though it remains in history.
CIt scans history only if push protection is also enabled, because push protection is what unlocks retrospective analysis of earlier commits.
DIt scans the entire Git history of the repository as well as new commits, so tokens committed before the feature was enabled are also detected and alerted.check_circle Correct
Enabling secret scanning triggers a full scan of existing Git history, so secrets committed before enablement are detected, not only future commits. Secret scanning backfills against the repository's whole commit history when first enabled and then runs incrementally on new pushes. That historical pass is why teams often see a burst of alerts for old, never-rotated credentials immediately after switching the feature on.
Why A is wrong: This understates coverage; secret scanning performs a full historical scan on enablement, so re-pushing files is unnecessary and would not be the mechanism for surfacing old secrets.
Why B is wrong: Secret scanning examines historical commits, not just branch tips, so a secret that survives only in older commits is still detected; this answer wrongly limits scope to current file contents.
Why C is wrong: Historical scanning is a property of secret scanning itself and does not depend on push protection, which governs blocking at push time rather than retrospective coverage.
Why D is correct: When secret scanning is enabled it backfills by scanning the full existing history of the default and other branches, then continues on new pushes, so previously committed secrets are surfaced as alerts.
What you must be able to do. Given a scenario about vulnerable or wrongly licensed dependencies, interpret the dependency graph and SBOM exports, distinguish Dependabot alerts from security updates and version updates, and configure dependency review and dependabot.yml to gate or automate updates.
In one sentenceThe supply chain domain: reading the dependency graph and SBOMs, acting on Dependabot, and configuring dependency review and dependabot.yml to block risky dependencies before merge.
Recall check: answer these from memory first
Distinguish Dependabot alerts, Dependabot security updates, and Dependabot version updates in one sentence each.
Which dependency review action input blocks a pull request that introduces a GPL-licensed dependency while still allowing MIT and Apache-2.0, and why?
The dependency graph lists direct dependencies but not the full transitive tree. What is missing from the repository, and why does that limit the graph?
What it tests. Configuring and using supply chain security across the lifecycle. Generating and interpreting the dependency graph, including why a manifest without a committed lock file shows direct dependencies but not the fully resolved transitive tree, and using SBOM export options and formats such as SPDX, where the relationships array expresses dependency associations. Detecting, prioritising, and responding to Dependabot alerts and security updates using EPSS scoring, auto-dismiss behaviour, and security campaigns. Configuring dependency review for pre-merge checks, including the dependency review action, fail-on-severity gating, and licence compliance with allow-licenses and deny-licenses. Configuring advanced update rules with dependabot.yml, including grouping, scheduling, and update strategies, and managing permissions, role-based alert assignment, notifications, webhooks, and integrations.
How to study it. Fix the three Dependabot behaviours that the exam conflates. Dependabot alerts notify you of a vulnerable dependency; Dependabot security updates open pull requests to fix vulnerable dependencies; Dependabot version updates keep dependencies current on a schedule you define in dependabot.yml regardless of vulnerabilities. Then learn dependency review as the pre-merge gate: the dependency review action fails a pull request based on fail-on-severity (the threshold is inclusive upwards, so high also catches critical), enforces licence policy with allow-licenses or deny-licenses (mutually exclusive), and warn-only mode reports findings without failing the check during a transition. Understand the dependency graph: it parses manifests for direct dependencies but needs a committed lock file to resolve the full transitive tree and pinned versions. For SBOMs, learn that SPDX records components as packages and dependency associations as DEPENDS_ON entries in the relationships array. Practise editing dependabot.yml for grouping and scheduling.
Easy to confuse
Dependabot alerts versus Dependabot security updates versus Dependabot version updates. Alerts notify you of a known vulnerability in a dependency; security updates automatically open pull requests to remediate those vulnerable dependencies; version updates open pull requests on a configured schedule to keep dependencies current regardless of any vulnerability. Notify, fix-the-vulnerable, and routinely-update are three different jobs.
Dependency review action versus Dependabot alerts for pre-merge gating. The dependency review action inspects the dependency diff on a pull request and can fail the check to block merge before changes land; Dependabot alerts surface vulnerabilities in dependencies already present and do not act as a required pull request gate. Use dependency review to gate the merge, Dependabot to track what is already there.
Worked example from the GH-500 bank
lock_openFree sampleConfigure and use supply chain securitymedium
An organisation must enforce licence compliance on incoming dependencies. Their counsel has approved permissive licences but forbids any code under the GNU General Public License. The team configures the "dependency-review-action" and asks how to make a pull request that introduces a GPL-licensed dependency fail the pre-merge check while continuing to permit MIT and Apache-2.0 dependencies. Which configuration meets this requirement most directly?
- uses: actions/dependency-review-action@v4
with:
# licence policy goes here
ASet "deny-licenses" to the GPL SPDX identifiers, because the action then fails the check when an introduced dependency declares a licence on that deny list while permitting others.check_circle Correct
BSet "fail-on-severity: low" so that the action treats a disallowed licence as a low-severity vulnerability and fails the check accordingly.
CAdd "allow-dependencies-licenses" listing only the SPDX identifiers your security team has audited, leaving GPL absent so it is implicitly skipped without failing the run.
DEnable both "deny-licenses" with the GPL identifiers and "allow-licenses" with MIT and Apache-2.0, because the action requires both lists to be present for licence enforcement to activate.
Use the "deny-licenses" input of the dependency review action to block specific SPDX licences while leaving approved licences permitted. Dependency Review can enforce licence policy by either allowing a closed set of licences with "allow-licenses" or blocking specific ones with "deny-licenses", and these two inputs are mutually exclusive. Listing the GPL SPDX identifiers under "deny-licenses" causes the pre-merge check to fail only when an introduced dependency declares one of those licences, leaving permissive licences such as MIT and Apache-2.0 unaffected.
Why A is correct: The "deny-licenses" input takes a list of SPDX licence identifiers, and the action fails the pull request check when an introduced dependency declares any listed licence. Listing the GPL identifiers blocks GPL dependencies while MIT and Apache-2.0 are unaffected, which matches the policy exactly. An "allow-licenses" input is the inverse approach for an allowlist.
Why B is wrong: The "fail-on-severity" input governs vulnerability advisories, not licences, so lowering it does not make a GPL dependency fail on licence grounds. Licence findings are handled by separate allow or deny inputs rather than by the severity threshold.
Why C is wrong: The "allow-dependencies-licenses" input names individual dependencies to exempt from scanning, not an allowed-licence list, so it does not express a licence allowlist. The wording is tempting because it contains "allow" and "licenses", but it solves a different problem and would not fail the GPL dependency.
Why D is wrong: The "allow-licenses" and "deny-licenses" inputs are mutually exclusive and you configure one or the other, not both; supplying both is an invalid configuration. The claim that both are mandatory for enforcement is incorrect, which makes this option fail rather than satisfy the requirement.
What you must be able to do. Given a scenario about static analysis, choose between CodeQL and third-party tools, enable code scanning via default or advanced setup, ingest SARIF correctly, and use a data flow path to remediate an alert at the point that breaks the vulnerability.
In one sentenceThe static-analysis domain: enabling code scanning with CodeQL or third-party SARIF, reading data flow paths, and fixing the source-to-sink flow rather than masking the alert.
Recall check: answer these from memory first
How do third-party static analysis findings become native code scanning alerts, and what alone does not achieve it?
A CodeQL alert traces a value from a request parameter through a helper into a file read. Where on the data flow path do you apply the fix to genuinely break the vulnerability?
Third-party SARIF alerts all show low or unspecified severity and cannot be gated. What addition to the SARIF makes code scanning rank them by security severity?
What it tests. Configuring and using Code Security. Choosing between CodeQL and third-party analysis tools and using SARIF file ingestion, management, and interoperability, including that third-party findings become native code scanning alerts only by uploading SARIF through the upload-sarif action or the SARIF upload API, and that a rule's security-severity property, not the SARIF level, drives prioritisation and severity-threshold gating. Enabling code scanning with GitHub Actions or external continuous integration, configuring workflow templates, matrix builds, and scan frequency, and choosing between default setup and advanced setup. Reviewing results including data flow analysis, managing alert lifecycles, autofix, dismissals, severity, and category classifications. Applying advanced configuration and customisation, including model packs that teach a custom sanitiser through data extensions, and troubleshooting scan failures and performance issues.
How to study it. Learn the two ways to run code scanning: default setup turns on CodeQL automatically with little configuration, and advanced setup uses an editable workflow file for matrix builds, custom queries, and compiled-language build steps. Fix the SARIF rules: any tool that can emit SARIF becomes native code scanning alerts via the upload-sarif action or the SARIF API, and to make third-party alerts rankable and gateable the rule needs a numeric security-severity property because the SARIF level (error, warning, note) is separate from security severity. For remediation, practise reading a CodeQL data flow path from source to sink: the genuine fix is a sanitiser or validation barrier between source and sink, not renaming a variable, catching an exception at the sink, or suppressing the result. For a sound custom sanitiser CodeQL does not recognise, the supported low-effort fix is a model pack with data extensions that classify it, applied across repositories, rather than forking the query.
Easy to confuse
Default setup versus advanced setup for code scanning. Default setup enables CodeQL automatically with minimal configuration and no workflow file to maintain; advanced setup generates an editable Actions workflow for matrix builds, custom query suites, and explicit build steps for compiled languages. Reach for advanced setup only when the scenario needs that customisation.
SARIF level versus a rule's security-severity property. The SARIF level (error, warning, note) controls how a result is displayed, while the numeric security-severity property on the rule is what code scanning buckets into critical, high, medium, or low for prioritisation and severity-threshold gating. Raising the level does not set the security severity.
Worked example from the GH-500 bank
lock_openFree sampleConfigure and use Code Securitymedium
A team uploads SARIF from a third-party linter into code scanning. The findings appear as alerts, but every one is displayed with a low or unspecified severity even though the team considers several of the rules high risk, and they cannot make any of them block a pull request on their severity-threshold rule. The SARIF carries each result's level and a physical location correctly. Which addition to the SARIF makes code scanning rank these alerts by a meaningful security severity?
ARaise each result's level from warning to error so code scanning maps the higher level onto a high security severity.
BAdd a security-severity property to each rule, giving a numeric score that code scanning maps onto critical, high, medium, or low.check_circle Correct
CAdd a precision tag of high to each rule's tags array so code scanning promotes the alert to high severity.
DSet a defaultConfiguration level of error on the run so all of that tool's results inherit a high security severity.
Recognise that code scanning derives an alert's security severity for third-party SARIF from the rule's security-severity property, not from the SARIF level. Code scanning shows two related but distinct attributes for an alert: the SARIF level (error, warning, note) and a security severity used for prioritisation and severity-threshold gating. The security severity comes from a numeric security-severity value in the rule's properties, which code scanning buckets into critical, high, medium, or low. A third-party tool that emits only level values leaves the security severity unset, so adding security-severity to each rule is the change that makes the alerts rankable and gateable.
Why A is wrong: The SARIF level distinguishes error, warning, and note for display, but code scanning does not translate level into a numeric security severity that drives severity-threshold gating. Promoting the level changes the alert's visual level only, so the severity used for blocking pull requests stays unset.
Why B is correct: Code scanning reads the security-severity value in a rule's properties as a numeric CVSS-style score and buckets it into critical, high, medium, or low. Without it, security findings default to an unspecified or low severity, so adding security-severity is what gives the alerts a meaningful severity that a threshold rule can act on.
Why C is wrong: Precision metadata describes how likely a rule is to be correct and influences query-suite filtering, not the displayed severity of an alert. Tagging precision as high does not assign a security severity, so the alerts remain unranked for gating purposes.
Why D is wrong: A run-level default configuration only sets a fallback SARIF level for results that omit their own level; it still produces a level, not a security severity. It is tempting as a bulk fix, but code scanning derives the severity that drives thresholds from security-severity, not from the default level.
What you must be able to do. Given a scenario about triaging and remediating across alerts, apply CVE, CWE, and GitHub Security Advisory concepts, distinguish GitHub-reviewed from unreviewed advisories, customise CodeQL query suites and threat models, and run campaign-based and bulk remediation.
In one sentenceThe operations domain: prioritising and remediating at scale with advisories and rulesets, tuning CodeQL by precision and threat model, and strengthening prevention across the lifecycle.
Recall check: answer these from memory first
Of CVE, CWE, and CVSS, which classifies the type of software weakness so you can search your own code for the same mistake, and what do the other two do?
Why do some GitHub Advisory Database entries raise Dependabot alerts while others never do, even when the affected package is in use?
You want CodeQL injection queries to also treat command-line arguments and environment variables as untrusted, with a workflow-level setting and no new queries. What do you add?
What it tests. Running security operations across suites. Applying CVE, CWE, and GitHub Security Advisory concepts within end-to-end remediation, where CWE classifies the weakness type, CVE identifies a specific vulnerability, and CVSS rates severity, and distinguishing GitHub-reviewed advisories (which power Dependabot alerts through verified affected ecosystems and version ranges) from unreviewed advisories (catalogued but not alerted on). Defining, prioritising, and enforcing severity and remediation rulesets, and running campaign-based remediation and bulk alert management. Customising CodeQL query suites and language-specific analysis, including filtering a suite by the precision metadata field and extending the threat model with threat-models: local so built-in queries treat command-line arguments, environment variables, and file inputs as untrusted. Managing security roles, delegated exceptions, and alert ownership, enforcing cross-suite rulesets and policies, and strengthening preventive security through push protection, dependency scanning, and pre-merge analysis.
How to study it. Separate the three identifiers cleanly: CWE is the weakness category (such as improper input neutralisation) that you search your own code for, CVE is one specific disclosed vulnerability, and CVSS is the severity score; do not conflate them. Learn why some advisories alert and others do not: GitHub-reviewed advisories carry verified affected ecosystem, package, and version ranges that Dependabot can match against the dependency graph, while unreviewed advisories lack that mapping, so review status, not severity or the presence of a CVE, decides alerting. For CodeQL tuning, learn to filter a query suite by precision (include high and very-high to cut false positives) rather than severity or tags, and to extend coverage to local inputs with the threat-models: local workflow setting for supported languages instead of switching suites or build modes. For scale, practise security campaigns and bulk alert management to drive remediation of alerts already live, and keep prevention (push protection, dependency review, pre-merge CodeQL) as the goal that reduces future operational load.
Easy to confuse
CWE versus CVE versus CVSS. CWE names the general class of weakness (the kind of mistake), CVE identifies one specific publicly disclosed vulnerability in a product, and CVSS is a numeric severity score derived from exploitability and impact. Only CWE generalises the weakness type for finding recurrences in first-party code.
GitHub-reviewed advisories versus unreviewed advisories. GitHub-reviewed advisories are curated with verified affected ecosystems and precise version ranges, which is the matchable data Dependabot needs to raise alerts; unreviewed advisories are imported for reference and lack that mapping, so they do not generate alerts regardless of severity or whether they carry a CVE.
Worked example from the GH-500 bank
lock_openFree sampleSecurity operations: best practices, prioritization, and remediationmedium
A platform team is auditing why some advisories in the GitHub Advisory Database generate Dependabot alerts in their repositories while others, found by browsing the database directly, never produce an alert even though the affected package is in use. They notice the alerting entries are labelled differently from the silent ones. Which distinction best explains which Advisory Database entries Dependabot uses to raise alerts?
AGitHub-reviewed advisories, which are curated with verified affected ecosystems and version ranges, drive Dependabot alerts, whereas unreviewed advisories are catalogued for reference but do not generate alerts.check_circle Correct
BOnly advisories whose CVSS base score is high or critical raise Dependabot alerts; moderate and low advisories are stored in the database for reference but are never alerted on in any repository.
CAdvisories that carry a CVE identifier from an external CVE Numbering Authority raise alerts, while GHSA-only advisories without a CVE are reference entries that Dependabot ignores.
DOnly advisories published directly by the package's own maintainer raise alerts; third-party and community submissions are stored but cannot trigger Dependabot.
Distinguish GitHub-reviewed advisories, which power Dependabot alerts, from unreviewed advisories that are catalogued but do not generate alerts. The GitHub Advisory Database contains two classes of entry. GitHub-reviewed advisories are curated to include the affected ecosystem, package name, and precise version ranges, which is the structured data Dependabot needs to match against a repository's dependency graph and raise an alert. Unreviewed advisories are imported for reference and lack that verified mapping, so Dependabot does not alert on them. Neither severity nor the presence of a CVE determines whether an alert is created; review status and matchable affected ranges do.
Why A is correct: The Advisory Database holds both GitHub-reviewed entries, which carry the curated package and version data Dependabot needs to match the dependency graph, and unreviewed entries that lack that mapping and therefore do not produce alerts.
Why B is wrong: Severity controls notification filtering and prioritisation, not whether an alert is created at all; reviewed advisories of any severity can raise Dependabot alerts when the package and version match.
Why C is wrong: This is tempting because a CVE feels authoritative, but alerting depends on whether the advisory is reviewed with affected ranges, not on the presence of a CVE; reviewed GHSA-only advisories still raise alerts.
Why D is wrong: Reviewed advisories enter the database from several sources including GitHub's curation team and community contributions, and any reviewed entry with affected ranges can drive alerts regardless of who originally submitted it.
What you must be able to do. Given a scenario about enabling security at scale, choose the right tier (enterprise, organisation, or repository), use security configurations and inheritance correctly, and set ruleset enforcement and bypass modes to govern repositories with the documented behaviour.
In one sentenceThe administration domain: enabling the suites at the correct enterprise, organisation, or repository scope, knowing that defaults only cover future repositories, and setting ruleset enforcement and bypass precisely.
Recall check: answer these from memory first
An enterprise owner wants one baseline of features authored once and offered to every organisation without recreating it. Which mechanism does this, and at which tier?
A default security configuration was set, but hundreds of pre-existing repositories are still unprotected. What must the administrator do, and why does the default not cover them?
Which ruleset enforcement status road-tests a rule against live pull request activity and reports in rule insights without blocking any merge?
What it tests. Administering the security suites at scale. Enabling the suites at enterprise, organisation, and repository levels and understanding feature differences across GitHub Enterprise Cloud and GitHub Enterprise Server. Defining default security configurations and inheritance to enable Code Security, Secret Protection, and Supply Chain Security across repositories, knowing that an enterprise-level security configuration is authored once and offered to organisations, that a default configuration governs only repositories created after it is set, and that existing repositories must be attached in bulk. Defining enterprise and organisation policies and rulesets, configuring enforcement boundaries, bypass permissions, exceptions, and security roles, including the evaluate enforcement status as a non-blocking dry run and the difference between Always and Pull request bypass modes. Enabling default or approved custom CodeQL workflows and using APIs and automation for large-scale configuration and governance.
How to study it. Drill scope, because the exam tests it directly. An enterprise security configuration is authored once at the enterprise tier and becomes available for organisation owners to apply, so the enterprise owner does not log in to each organisation. A security configuration set as the default applies automatically only to repositories created after it is set; existing repositories are unaffected until an administrator attaches the configuration to them in bulk from the organisation code security settings. Learn the three ruleset enforcement statuses: disabled (saved but not evaluated), evaluate (assessed and reported in rule insights but non-blocking, the dry-run option), and active (enforced). Learn bypass modes precisely: Always exempts an actor from the rules entirely across direct pushes and merges, while Pull request still forces the pull request flow but lets the actor merge without meeting the requirements, preserving the audit trail. Know that the security manager role grants alert and configuration access without making someone an organisation owner.
Easy to confuse
Evaluate enforcement status versus active enforcement status. Evaluate assesses a ruleset against live activity and records pass or fail in rule insights without blocking anything, making it the dry run; active enforces the requirement and blocks non-compliant actions. Evaluate measures impact, active enforces it.
Always bypass mode versus Pull request bypass mode. Always exempts the actor from the ruleset entirely, allowing direct pushes and merges as if the rules did not apply; Pull request still requires the actor to open a pull request but lets them merge it without satisfying the requirements, which keeps a reviewable audit trail.
Security manager role versus organisation owner. The security manager role grants read access across the organisation plus the ability to manage security alerts and configurations without the full administrative power of an organisation owner; an owner has complete control over the organisation. Assign security manager for security governance without handing over ownership.
An organisation owner on GitHub Enterprise Cloud sets a custom security configuration as the default for newly created repositories. The configuration enables secret scanning and code scanning. The owner also wants the same protections switched on across the hundreds of repositories that already existed before the configuration was created. Setting the configuration as the default has not changed those older repositories. What does the owner need to do to bring the existing repositories under the same configuration?
ANothing further is required, because setting a security configuration as the default retroactively attaches it to every repository in the organisation, including ones created before the configuration existed.
BRecreate each older repository so that it inherits the default configuration at creation time, because a security configuration can only ever attach to a repository as it is being created.
CConvert the custom configuration into the 'GitHub recommended' configuration, which is the only configuration that can attach to repositories that already existed.
DApply the security configuration to the existing repositories, selecting them in bulk from the organisation's code security settings, since the default only governs repositories created after it was set.check_circle Correct
Recognise that setting a security configuration as the default only covers future repositories, so existing repositories must be explicitly attached in bulk. A default security configuration is applied automatically only to repositories created after it is designated as default; repositories that already exist are unaffected until an administrator attaches the configuration to them, which can be done in bulk from the organisation's code security settings.
Why A is wrong: This is the tempting assumption that 'default' means 'all', but the default only governs repositories created from that point onward; pre-existing repositories are left untouched until the configuration is explicitly applied to them.
Why B is wrong: Recreating repositories is destructive and unnecessary; configurations can be applied to existing repositories at any time, so the premise that attachment only happens at creation is false.
Why C is wrong: Both custom and GitHub-provided configurations can be applied to existing repositories; there is no rule restricting retroactive attachment to the recommended configuration, so this conflates 'default for new repos' with configuration type.
Why D is correct: Setting a configuration as the default affects only future repositories; bulk-applying (attaching) the configuration to the chosen existing repositories is the action that brings already-created repositories under the same baseline.
A study plan that works
Map the blueprint and book a date
Day 1
Read the official GitHub exam objectives and the six areas with their weights. Book a provisional date now: a fixed date turns open-ended study into a plan and is the strongest predictor of actually sitting. Note that describing the suites, Secret Protection, supply chain security, and security operations each carry the heaviest weight, so plan the most study across those four.
Build the product and scope maps
Week 1
Before drilling any area, build the two maps the whole exam rests on. First the product map: code scanning with CodeQL under Code Security, secret scanning and push protection under Secret Protection, and the dependency graph, Dependabot, and dependency review as supply chain features, with which are free on public repositories. Second the scope map: repository versus organisation versus enterprise, security configurations and their defaults, and what only covers future repositories. Use the recall prompts here: cover the answer, choose from the requirement, then reveal.
Go deep on Secret Protection and supply chain security
Weeks 1 to 2
These are heavy and full of trap distinctions. For Secret Protection, lock the lifecycle behaviour (history backfill on enablement, alerts reopening on re-commit) and that remediation means rotating the live credential. For supply chain, fix the Dependabot alerts versus security updates versus version updates split, dependency review with fail-on-severity and licence lists, and the dependency graph and SBOM behaviour. Practise on scenario questions and read the worked explanation on every one, including the ones you got right.
Lock Code Security and the CodeQL model
Weeks 2 to 3
Code Security rewards precision. Fix default setup versus advanced setup, how third-party SARIF becomes native alerts via upload-sarif, and the SARIF level versus security-severity distinction. Practise reading a CodeQL data flow path and placing a sanitiser between source and sink, and learn model packs with data extensions for a custom sanitiser. Do the SARIF-ingestion and data-flow calls by hand until the requirement alone decides them.
Cover security operations and remediation at scale
Weeks 3 to 4
Drill the CVE versus CWE versus CVSS distinction, GitHub-reviewed versus unreviewed advisories and why only the former alert, CodeQL suite filtering by precision, and the threat-models: local setting. Then practise campaign-based and bulk remediation and how prevention controls reduce future operational load. Tie every choice back to the requirement named and to a prevention-first posture.
Master administration scope and rulesets
Week 4
Administration is dependable marks once scope is automatic. Drill enterprise versus organisation versus repository configuration, that a default only governs future repositories so existing ones need bulk attachment, the three ruleset enforcement statuses with evaluate as the dry run, the Always versus Pull request bypass modes, and the security manager role versus organisation owner. Practise the calls until the correct tier and status are reflexive.
Drill weak areas, then sit a timed mock
Weeks 4 to 5
Use your per-domain accuracy to attack the two areas dragging you down rather than re-reading what you know, then space the review of each area's recall prompts after a few days and again a week later. Finish with at least one full timed mock under exam conditions to rehearse pacing and the flag-and-return habit, and review every missed question by naming the requirement and scope you misread before you book or sit.
Know when you're ready
Readiness for GitHub Advanced Security is a measured score on scenario questions you have not seen before, not a feeling that the features are familiar. Those are different things, and the gap between them is where people fail. Re-reading the documentation builds fluency, and fluency feels like knowledge, so confidence rises while real recall does not. The fix is to test yourself: if you can read a fresh scenario, name the requirement, and pick the right feature at the right scope while explaining why each other option is wrong, you know it; if you can only nod along to an explanation, you do not yet.
Be especially wary of early confidence on the product map. Knowing what secret scanning, code scanning, and Dependabot each do is the easy half; choosing between them under a licensing, scope, or lifecycle constraint, when two of them sound plausible, is the half the exam actually tests. Trust your measured per-domain accuracy over your gut, and set the bar at clearing every domain comfortably on unseen questions across more than one session, not scraping a single pass on the marked pass score. The practice bank, with a worked explanation and a reason every distractor is wrong on every question, is where you find out whether you can navigate the map this guide gives you.
Ready to put this into practice?
Free GH-500 questions with worked explanations. No sign-up.
Read the scenario for its requirement first. The security need named in the question, paired with the scope it concerns, is what picks the answer, so find both before you judge the options.
Prefer the documented, built-in mechanism. When an option describes a supported GitHub feature and another describes a hand-rolled workaround such as re-pushing files or parsing artifacts, the supported feature is almost always the answer.
Choose prevention over cleanup. Push protection at push time, dependency review before merge, and a CodeQL pull request scan beat after-the-fact remediation when the scenario allows catching the problem early.
Match the enablement scope exactly. Decide whether the action belongs at repository, organisation, or enterprise level, and remember a default security configuration only covers repositories created after it is set, so existing ones need bulk attachment.
Map every feature to its product. Code scanning with CodeQL is Code Security, secret scanning and push protection are Secret Protection, and dependency review and Dependabot are supply chain features; licensing questions hinge on this split.
Remediate a leaked secret by rotating it. Dismissing or resolving a secret scanning alert does not make an exposed credential safe, and re-committing the value reopens the original alert, so rotate or revoke the live credential.
Distinguish the three Dependabot jobs. Alerts notify, security updates open fixes for vulnerable dependencies, and version updates keep dependencies current on a schedule; pick the one whose job matches the requirement.
Flag and move on. Cover every question once before you spend time on a hard one; collecting the clear marks first protects the ones you actually know within the time limit.
Frequently asked questions
Is the GitHub Advanced Security (GH-500) exam hard?
It is an intermediate exam, and the difficulty is judgement rather than recall. Most questions are scenarios where several GitHub features sound plausible and only one matches the documented behaviour, the correct enablement scope, and a prevention-first posture. Scenario practice with worked explanations matters far more than memorising what each feature does.
How long should I study for GH-500?
Most candidates who already use GitHub day to day are ready in four to six weeks of steady study. Less hands-on exposure means more time building the product map (which feature belongs to which licensable product) and the scope map (repository versus organisation versus enterprise) that the whole exam rests on.
Do I need to write CodeQL queries or know a specific language?
No. The exam tests configuring and using code scanning, not authoring queries from scratch. You should be able to read a CodeQL data flow path and know how to tune detection with query suite filters, the local threat model, and model packs, but you are not asked to write a query during the exam.
What is the difference between secret scanning and push protection?
Secret scanning detects credentials that are already committed, including across the full Git history when first enabled, and raises alerts. Push protection prevents a supported secret from being committed at all by blocking the push at the source. One detects what exists, the other prevents the exposure happening.
How do Dependabot alerts, security updates, and version updates differ?
Dependabot alerts notify you of a known vulnerability in a dependency. Dependabot security updates automatically open pull requests to remediate those vulnerable dependencies. Dependabot version updates open pull requests on a schedule you define in dependabot.yml to keep dependencies current regardless of any vulnerability. They are three separate jobs.
Which features are free, and which need a paid licence?
Secret scanning and the dependency graph are free on public repositories on GitHub.com. Extending detection such as secret scanning, push protection, and code scanning with CodeQL to private and internal repositories requires a paid product (GitHub Secret Protection or GitHub Code Security) with a seat assigned. The product split decides what a given purchase enables.
What is a security configuration, and does setting it as the default protect existing repositories?
A security configuration is a named baseline of features such as secret scanning, push protection, and code scanning that you apply to repositories. Setting it as the default applies it automatically only to repositories created afterwards; existing repositories are unaffected until an administrator attaches the configuration to them in bulk from the organisation code security settings.
When should I use the evaluate enforcement status on a ruleset?
Use evaluate to road-test a ruleset against live pull request activity and collect pass or fail results in rule insights without blocking any merge. It is the non-blocking dry run, distinct from active (which enforces and blocks) and disabled (which is saved but not evaluated), so you can measure impact before switching to active.
Is the GitHub Advanced Security (GH-500) certification worth it?
It is a strong credential for security engineers and platform engineers who are responsible for securing code and supply chains on GitHub at scale, because it validates the ability to configure the right control at the right scope rather than general security awareness. The preparation is genuinely useful for practitioners: working through the product boundaries between Secret Protection, Code Security, and supply chain features clarifies distinctions that are easy to use imprecisely in day-to-day work. A common next step is a broader security specialisation or application security certification that covers threat modelling and secure design beyond the GitHub toolset.
Examworthy is not affiliated with or endorsed by GitHub. This guide is original study material based on the public exam blueprint. We never reproduce live exam items. GH-500 and related marks belong to their respective owners.
