GH-500 — GitHub Advanced Security Exam Blueprint

How to Use This Exam Blueprint

Use this page as a practical readiness map for the GitHub Advanced Security (GH-500) exam from GitHub. It is organized around the skills a candidate should be able to apply in real scenarios: enabling GitHub Advanced Security capabilities, interpreting alerts, configuring workflows, reducing risk, and explaining tradeoffs.

For each area, ask:

• Can I explain the feature and when to use it?
• Can I configure it at the repository, organization, or enterprise level when applicable?
• Can I interpret the alert or result produced by the feature?
• Can I choose the right remediation path?
• Can I recognize common misconfigurations and security gaps?

This is not a substitute for official exam materials. It is an independent exam blueprint for final review and practice planning.

GH-500 Readiness Areas at a Glance

Core GitHub Advanced Security Concepts

Checklist: Feature Purpose and Fit

You should be able to match each feature to the problem it solves.

Can You Explain These Relationships?

Check each item only when you can explain it without notes.

• How GitHub Advanced Security features support a secure software development lifecycle.
• The difference between detecting a problem after code is pushed and preventing it before merge.
• The difference between repository-level configuration and organization-level governance.
• How alerts move from detection to triage to remediation to closure.
• Why security tools need tuning to reduce noise without hiding real risk.
• How developer workflow impact changes depending on whether a feature comments, alerts, blocks, or opens pull requests.
• How GHAS capabilities complement, but do not replace, secure design, code review, and runtime monitoring.

Code Scanning Readiness

What to Know

Code scanning is a major GH-500 readiness area. Be prepared to reason about setup, analysis scope, result interpretation, and remediation workflow.

Code Scanning Configuration Checklist

• Know where code scanning is enabled for a repository.
• Know the difference between default setup and advanced setup.
• Know when GitHub Actions is used to run CodeQL analysis.
• Know when a repository may require a custom build step.
• Know how workflow permissions can affect analysis and result upload.
• Know how to configure languages for analysis.
• Know how pull request alerts differ from existing default-branch alerts.
• Know how to upload SARIF from a third-party tool.
• Know how to filter alerts by severity, tool, rule, branch, state, and other useful dimensions.
• Know how to assign responsibility for remediation.

Recognize a Typical CodeQL Workflow

You do not need to memorize every workflow line, but you should recognize the purpose of the main stages.

name: "CodeQL"

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  security-events: write
  contents: read

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: javascript-typescript

      - name: Autobuild
        uses: github/codeql-action/autobuild@v3

      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v3

Be ready to identify:

• What triggers the workflow.
• Why repository contents must be checked out.
• Why permissions matter.
• What the initialization step does.
• Why some languages may need a build.
• What the analysis step uploads.
• When you would customize languages, queries, build steps, or paths.

Code Scanning Alert Triage

Code Scanning “Can You Do This?” Prompts

• Given a repository with no custom build needs, choose a simple code scanning setup.
• Given a compiled project that fails autobuild, identify the need for explicit build steps.
• Given a third-party SAST tool, explain how SARIF upload fits into code scanning.
• Given noisy alerts, recommend query tuning or alert triage instead of disabling scanning entirely.
• Given a pull request introducing a vulnerability, explain how code scanning can surface it before merge.
• Given an alert marked as a false positive, explain what information should support dismissal.
• Given an organization with many repositories, explain how security overview helps find unscanned repositories.

CodeQL Readiness

CodeQL Concepts to Review

CodeQL Reasoning Checklist

• Understand that CodeQL treats code as data that can be queried.
• Know why different languages may require different setup behavior.
• Understand the idea of a vulnerable flow from source to sink.
• Know the difference between a real false positive and an alert that is merely inconvenient.
• Know when custom queries help enforce organization-specific security expectations.
• Know why query expansion can increase useful coverage and also increase triage volume.
• Know why a failed build or incomplete extraction can reduce analysis quality.
• Know how CodeQL results are surfaced as code scanning alerts.

Scenario Cues for CodeQL

Secret Scanning Readiness

What to Know

Secret scanning is about detecting and preventing exposed credentials. For GH-500, be ready to handle both default provider patterns and organization-specific secret formats.

Secret Remediation Checklist

When a secret is found, you should know that deleting it from the latest file version is usually not enough.

• Confirm what secret type was exposed.
• Determine whether the secret is active.
• Revoke or rotate the credential.
• Identify affected systems, repositories, branches, forks, logs, or artifacts where applicable.
• Remove the secret from code and configuration.
• Avoid committing replacement secrets.
• Use a secure secret store or GitHub Actions secrets where appropriate.
• Investigate potential misuse when the exposure risk is meaningful.
• Close or resolve the alert with an accurate reason.
• Educate the contributor on prevention.

Secret Scanning Decision Points

Custom Pattern Readiness

Be able to explain the purpose of custom patterns without overfitting to a regex syntax question.

• Identify examples of organization-specific secrets.
• Know why overly broad patterns create alert noise.
• Know why overly narrow patterns miss real secrets.
• Understand testing a pattern before broad rollout.
• Understand the need for ownership of alert response.
• Know that custom patterns should be reviewed as systems and token formats change.

Dependency Security Readiness

Dependency Security Feature Map

Dependency Triage Checklist

For a dependency alert, can you determine:

• Which package is affected?
• Which manifest or lockfile introduced it?
• Whether it is a direct or transitive dependency?
• Which version is currently used?
• Which versions are affected?
• Whether a patched version is available?
• Whether an automated pull request exists?
• Whether the dependency is used in production, development, tests, or build tooling?
• Whether upgrading could introduce breaking changes?
• Who owns the affected application or package?
• Whether compensating controls are temporary or acceptable?

Dependabot Configuration Recognition

You should recognize the shape and purpose of a Dependabot configuration file.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5

Be ready to explain:

• package-ecosystem identifies the package manager or ecosystem.
• directory points to where manifest files are located.
• schedule controls update cadence.
• Version updates and security updates serve different goals.
• Excessive update noise can reduce developer responsiveness.
• Grouping, scheduling, or ownership strategies may improve adoption where supported.

Dependency Review Scenario Cues

GitHub Actions Security Readiness

Why Actions Security Matters for GH-500

GitHub Advanced Security is closely tied to secure development workflows. Be prepared to reason about how CI/CD workflows can expose secrets, run untrusted code, or grant excessive permissions.

Workflow Hardening Checklist

• Set minimal required permissions for workflows and jobs.
• Avoid granting broad write permissions by default.
• Treat pull requests from forks or unknown contributors as untrusted.
• Avoid running untrusted code with access to sensitive secrets.
• Pin third-party actions according to organizational policy.
• Prefer trusted and maintained actions.
• Review action source and permissions before adoption.
• Avoid printing secrets, tokens, or sensitive environment variables.
• Use environments and required reviewers where appropriate.
• Use OIDC-based federation where suitable instead of long-lived cloud credentials.
• Separate build, test, release, and deployment responsibilities.
• Monitor workflow changes in sensitive repositories.

Risky Workflow Pattern Recognition

Governance, Settings, and Security Posture

Repository, Organization, and Enterprise Thinking

The exam may test whether you can choose the right level for a setting or control.

Governance Checklist

• Know how to identify repositories without required security features enabled.
• Know how to use security overview to find risk across repositories.
• Know how security managers or equivalent delegated roles help scale remediation.
• Know why repository ownership metadata matters for alert routing.
• Know how security policies communicate vulnerability reporting expectations.
• Know how branch protection or repository rules can support secure merge behavior.
• Know why exceptions should be documented and reviewed.
• Know how audit logs or activity records can support investigation and accountability.
• Know how to phase GHAS rollout across critical repositories first.
• Know how to measure whether teams are fixing alerts, not just enabling tools.

Security Overview Readiness

Be able to use security overview conceptually to answer questions such as:

• Which repositories have code scanning disabled?
• Which repositories have the most critical open alerts?
• Which alerts are stale or unassigned?
• Which teams are missing dependency security coverage?
• Which repositories have unresolved secret scanning alerts?
• Which repositories require onboarding, ownership, or policy cleanup?
• Which trends indicate improving or worsening security posture?

Alert Triage and Remediation Workflow

Practical Triage Flow

    flowchart TD
	    A[New security alert] --> B{Is it a real exposure or weakness?}
	    B -->|Clearly false positive| C[Dismiss with accurate reason]
	    B -->|Needs investigation| D[Identify owner and affected code]
	    D --> E{Is there active secret or exploitable vulnerability?}
	    E -->|Yes| F[Prioritize urgent remediation]
	    E -->|No or lower risk| G[Prioritize by severity and context]
	    F --> H[Fix, rotate, update, or remove]
	    G --> H
	    H --> I[Validate with tests and scanning]
	    I --> J[Close alert or confirm auto-closure]
	    J --> K[Document lessons and prevent recurrence]

Alert Handling Checklist

• Confirm the alert type: code, secret, dependency, or workflow-related.
• Identify severity and potential impact.
• Identify affected branch, repository, package, file, or workflow.
• Identify code owner or service owner.
• Determine whether the issue is exploitable or exposed.
• Prioritize based on severity, exposure, asset criticality, and fix availability.
• Choose the right remediation action.
• Validate the fix with tests and rescanning.
• Avoid dismissing alerts only because they are hard to fix.
• Record accurate dismissal reasons when dismissal is appropriate.
• Look for repeated patterns that require training, policy, or automation changes.

Remediation Action Map

Scenario and Decision-Point Practice

Code Scanning Scenarios

Secret Scanning Scenarios

Dependency Scenarios

Governance Scenarios

Common Weak Areas and Traps

Feature Confusion

Configuration Traps

• CodeQL workflow lacks required permissions to upload security results.
• Workflow runs but does not include the language or path expected.
• Compiled project analysis misses code because the build step is incomplete.
• Third-party scanner creates results but does not upload valid SARIF.
• Dependabot configuration points to the wrong directory.
• Dependency graph lacks required manifest or lockfile visibility.
• Custom secret pattern is too broad and creates excessive false positives.
• Push protection bypasses are allowed but not reviewed.
• Workflow exposes secrets to untrusted pull request code.
• Organization-level policy exists but repository exceptions are unmanaged.

Triage Traps

Artifact and Configuration Review Checklist

Files and Artifacts You Should Recognize

Configuration Questions to Practice

• Where is this feature enabled?
• Is the setting repository-specific, organization-wide, or enterprise-wide?
• Who can change it?
• Who receives alerts?
• What branch or workflow does it affect?
• Does it block, warn, comment, alert, or open a pull request?
• Does it require GitHub Actions?
• Does it depend on manifests, lockfiles, build steps, or language support?
• What happens when the configuration is missing or incorrect?
• How would you validate that it is working?

High-Value “Can You Do This?” Checklist

Use this section as a final readiness gate.

Code Scanning and CodeQL

• Explain the purpose of code scanning in GitHub.
• Compare default setup and advanced setup.
• Identify when a CodeQL workflow needs custom build commands.
• Explain what CodeQL queries do.
• Explain what a CodeQL database represents.
• Interpret a data-flow-based alert at a high level.
• Identify when custom CodeQL queries are useful.
• Explain SARIF upload for third-party tools.
• Troubleshoot missing or failed code scanning results conceptually.
• Recommend an alert triage approach for noisy findings.

Secret Scanning

• Explain secret scanning versus push protection.
• Respond correctly to a committed secret.
• Explain why rotation or revocation is required.
• Identify when a custom secret pattern is needed.
• Explain the risk of bypassing push protection.
• Recommend secure handling of secrets in GitHub Actions.
• Distinguish alert closure from actual credential remediation.
• Prioritize active, privileged, or externally exposed secrets.

Dependency Security

• Explain the dependency graph.
• Interpret a Dependabot alert.
• Explain Dependabot security updates.
• Explain Dependabot version updates.
• Use dependency review to assess pull request risk.
• Distinguish direct and transitive dependencies.
• Identify manifests and lockfiles.
• Recommend remediation when an automated update fails.
• Prioritize dependency alerts based on context.

GitHub Actions and Supply Chain

• Explain why workflow permissions matter.
• Reduce token permissions using least privilege.
• Identify risky use of secrets in workflows.
• Recognize risks from untrusted pull request code.
• Explain why third-party actions require review.
• Explain the value of reusable workflows for governance.
• Explain OIDC at a conceptual level.
• Identify artifact, log, and environment variable exposure risks.

Governance and Operations

• Use security overview conceptually to find gaps.
• Explain repository versus organization-level controls.
• Describe how delegated security responsibility can scale.
• Recommend rollout sequencing for many repositories.
• Explain why alert ownership is essential.
• Connect branch protection or rules to secure development.
• Define a practical exception process.
• Explain how to measure remediation progress.

Final-Week Review Checklist

7 to 5 Days Before

• Revisit each GHAS feature and write one sentence explaining its purpose.
• Review code scanning setup paths: default setup, advanced setup, SARIF upload.
• Review CodeQL concepts: database, query, query suite, query pack, custom query, data flow.
• Review secret scanning response steps, especially rotation and revocation.
• Review Dependabot alerts, security updates, version updates, and dependency review.
• Review workflow security basics: permissions, secrets, triggers, third-party actions.
• Make a short list of features you confuse and drill the differences.

4 to 2 Days Before

• Practice scenario questions that ask “what should you do next?”
• Practice identifying the right feature from a short problem statement.
• Review common misconfigurations in workflows and scanning setup.
• Review how alerts are triaged, assigned, fixed, dismissed, and validated.
• Practice explaining tradeoffs: coverage versus noise, automation versus review, prevention versus detection.
• Review repository, organization, and enterprise-level governance concepts.
• Avoid memorizing unsupported exact limits or dates; focus on decisions and workflows.

Final 24 Hours

• Review the feature map table.
• Review the remediation action map.
• Review secret exposure response steps.
• Review dependency alert triage steps.
• Review CodeQL workflow stages.
• Review Actions security traps.
• Sleep and avoid last-minute deep dives into unrelated tooling.

Practical Next Step

Turn this checklist into practice tasks: for each unchecked item, create one scenario question and answer it in your own words. Prioritize areas where you cannot explain the decision path, not just areas where you forgot a term. For GH-500 readiness, the goal is to choose and justify the right GitHub Advanced Security action in realistic repository, organization, and workflow situations.