GH-500 GitHub Advanced Security: Protecting Code, Secrets, and Dependencies

GH-500, GitHub Advanced Security, is a current security-focused exam in the GitHub certifications ecosystem. The July 2026 blueprint measures whether candidates can use GitHub security capabilities across the software development lifecycle, not simply identify vulnerabilities after code is merged. Its major areas include the GitHub Security suite, Secret Protection, software-supply-chain security, Code Security with CodeQL and compatible tools, security operations, and administration.

The exam is designed for professionals who already understand GitHub fundamentals, CI/CD, and secure-development concepts. Learners who still need repository and collaboration foundations should first be comfortable with GH-900 GitHub Foundations. GH-500 assumes that baseline and asks how security controls can be integrated into the daily developer workflow so risks are prevented, detected, prioritized, and remediated with as little friction as possible.

A useful mental model is that GitHub Advanced Security protects three different attack surfaces: source code, secrets, and dependencies. Each has different detection methods and remediation workflows. The exam rewards candidates who can decide which control applies to a scenario, how to configure it at repository or organization scale, and how to move from an alert to a defensible response.

Security suites turn scattered findings into an operating model

GitHub's security capabilities are most effective when treated as a connected system. Secret Protection detects credentials and can block them before they enter repository history. Supply-chain features expose vulnerable or risky dependencies. Code Security analyzes source code for patterns that can create exploitable behavior. Security Overview and campaign features help organizations aggregate risk across repositories rather than forcing security teams to inspect each project independently.

Prevention-first security is a recurring theme. Blocking an exposed credential at push time is cheaper than rotating it after it reaches a remote repository. Flagging a vulnerable dependency during a pull request is better than discovering it after a production release. The same principle applies to code scanning: feedback close to the developer reduces the cost of remediation and keeps security work inside normal engineering flow.

Enterprise administration of these capabilities overlaps with GH-100 GitHub Enterprise Administrator. GH-500 focuses on security operation and configuration; GH-100 broadens the view to identity, platform governance, Actions, licensing, and enterprise policy.

Secret Protection is about prevention as much as detection

Secret scanning identifies tokens, keys, passwords, and other credentials that match known or custom patterns. Public repositories receive some protections broadly, while enterprise features extend scanning and governance across private organizational code. Candidates should understand how scanning is enabled, which repositories are covered, who receives alerts, and how custom patterns expand detection beyond predefined provider formats.

Push Protection moves the control earlier by intercepting supported secrets before they are committed to remote history. A developer may be able to bypass protection in defined circumstances, but bypass should be governed and auditable. Delegated bypass policies can separate the person writing code from the person authorizing an exception, reducing the risk that convenience silently becomes policy.

When a secret is exposed, removing it from the current file is not enough. The credential may exist in history, forks, logs, or caches. The correct response usually starts with revoking or rotating the secret, assessing exposure, updating dependent systems, and then cleaning repository history only when necessary. Alert dismissal should record a defensible reason rather than hide unresolved risk.

Supply-chain security depends on knowing what software depends on

Modern applications incorporate open-source libraries, package-manager dependencies, container layers, generated components, and transitive dependencies. The dependency graph gives GitHub a model of that software supply chain. Dependabot and related security features use vulnerability intelligence to identify packages that need attention, while dependency review can show risk introduced by a pull request before it merges.

Severity alone is not always enough for prioritization. Exploitability, reachability, business criticality, and environmental exposure affect real risk. Signals such as EPSS can help security teams distinguish vulnerabilities that are more likely to be exploited. Security campaigns can group related remediation work so developers see a coherent objective rather than a long undifferentiated alert queue.

Software bills of materials provide another view of dependency exposure by producing an inventory of components and versions. SBOMs are useful for incident response, customer assurance, compliance, and supply-chain analysis because they answer a simple but difficult question quickly: where is this component used?

Code Security brings static analysis into development

Code scanning examines source code for security weaknesses. GitHub supports CodeQL as a native analysis engine and can also ingest SARIF results from compatible third-party tools. Candidates should understand when default setup is sufficient and when advanced configuration is required for custom build steps, language matrices, specialized query suites, or nonstandard repository structures.

CodeQL's strength is data-flow analysis. It can trace how untrusted input travels through a program to dangerous operations, revealing vulnerabilities that simple pattern matching may miss. The practical challenge is turning that analysis into actionable findings without overwhelming developers. Triage therefore includes severity, precision, category, ownership, and whether an alert represents a real exploitable path.

Scan frequency and workflow design matter. Pull-request scans provide early feedback, while scheduled or default-branch scans provide broader coverage. A code-scanning workflow that frequently fails or takes too long will be bypassed socially even if policy says it is required. Security engineering therefore includes reliability and performance.

Security operations convert alerts into measurable risk reduction

An organization can enable every scanner and still remain insecure if findings are not managed. GH-500 expects candidates to understand alert lifecycles, assignment, prioritization, dismissal, remediation, and campaign-based work. The goal is not a permanently empty dashboard; it is evidence that important findings are recognized and handled within an agreed process.

Developers, security teams, and administrators have different responsibilities. Developers understand code context and can implement fixes. Security teams define policy, investigate patterns, and help prioritize risk. Administrators enable features and ensure visibility across repositories. Healthy programs make those handoffs explicit so alerts do not sit unowned.

Broader application-security thinking, such as the secure-development concerns discussed in software development security, helps explain why scanning should be integrated across requirements, coding, testing, release, and maintenance rather than treated as a final gate.

Security automation should reinforce developer workflows

Security features often integrate with pull requests, branch policies, Actions, APIs, webhooks, and external ticketing systems. Automation can route alerts, enforce checks, open remediation pull requests, or export findings to a broader security platform. The best automation reduces repetitive work without hiding important context from the developer responsible for the change.

GH-500 therefore overlaps with GH-200 GitHub Actions. Actions may run code scans, dependency checks, or policy workflows, but automation itself must be secured. A build pipeline with excessive token permissions or untrusted third-party actions can undermine the security controls it executes.

API and webhook integrations should use scoped identities and preserve traceability. If an external system changes alert state or opens pull requests automatically, teams should still be able to determine what happened, why it happened, and which system initiated the action.

Administration determines whether controls are consistent across repositories

Repository-by-repository configuration does not scale well. Organizations can apply security configurations, policies, and defaults so new repositories begin with appropriate protections. Administrators also need to manage who can view alerts, who can bypass protections, which notifications are sent, and how custom patterns or analysis configurations are maintained.

Centralization should not remove necessary repository context. A monorepo, mobile application, infrastructure repository, and data-science project may require different analysis settings. Enterprise policy should define minimum controls while allowing justified variation where the technology demands it.

Metrics help identify gaps. Coverage, alert age, remediation time, recurring secret types, vulnerable dependency patterns, and repositories with disabled features can guide improvement. The most valuable metric is not the total number of alerts; it is whether the organization is reducing meaningful exposure over time.

GH-500 preparation should follow the life of a finding

Hands-on preparation is strongest when candidates trace an issue from creation through remediation. Add a test secret and observe scanning and Push Protection behavior. Introduce a vulnerable dependency and inspect dependency review and alerts. Configure code scanning, review a result, understand the path, and decide whether to fix or dismiss it. Then examine how the same control would be governed across many repositories.

Practice also should include failure modes. What happens when a CodeQL workflow cannot build? How should a leaked token be handled after it has entered history? When is a custom secret pattern appropriate? How do delegated bypass and repository roles affect who can override protection? These scenarios develop the judgment the exam measures.

GH-500 validates a security engineering mindset inside GitHub. Candidates who can connect detection with prevention, governance, remediation, and developer experience are prepared not only to pass the exam but to make GitHub security controls operationally useful.

Security configurations should also account for repository lifecycle. New repositories can inherit a standard configuration, but acquired codebases, archived projects, forks, and repositories with unusual build systems may need a staged rollout. An organization can use coverage reporting to identify where controls are missing and then prioritize the repositories whose exposure and business criticality justify immediate action.

Incident response is another cross-cutting skill. A leaked production credential may require secret rotation, repository investigation, audit-log review, deployment changes, and communication with an external provider. A vulnerable dependency may require identifying every affected repository before fixing versions. GH-500 preparation should therefore connect individual alerts to the wider response process rather than treating each feature as an isolated dashboard.

Teams should also rehearse how alerts move between tools and owners. A security finding may begin in GitHub, create a ticket, trigger a pull request, require validation in CI, and close only after the deployed fix is confirmed. Clear status mapping prevents automation from marking risk resolved before the remediation is actually complete.