GH-500 — GitHub Advanced Security Cheat Sheet

The exam is likely to test whether you can choose the right GitHub Advanced Security capability for a scenario, configure it correctly, interpret alerts, and avoid unsafe defaults in real repositories and organizations. Focus less on memorizing product slogans and more on decision-making: Which feature solves the problem? Who can configure it? What happens in a pull request? What alert should be triaged first?

Use this Cheat Sheet as a compressed map, then move into IT Mastery practice:

1. Start with topic drills for code scanning, secret scanning, dependency security, and administration.
2. For every missed original practice question, identify the decision point you missed.
3. Read the detailed explanations, especially for similar-sounding features.
4. Build a short error log with traps such as “used Dependabot alert when dependency review was needed.”
5. Finish with mixed mock exams so you practice switching contexts quickly.

Practical next step: take a focused GH-500 question bank drill on one weak area, review every explanation, then return to this checklist and confirm you can explain the correct feature choice in your own words.

Security configurations vs workflow files

Code scanning event selection

Minimal advanced CodeQL workflow pattern

Use advanced setup when you need workflow control. Keep permissions least-privilege and add build steps only when required by the language/build system.

name: CodeQL

on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: "30 2 * * 1"

jobs:
  analyze:
    name: Analyze
    runs-on: ubuntu-latest

    permissions:
      actions: read
      contents: read
      security-events: write

    strategy:
      fail-fast: false
      matrix:
        language: [javascript-typescript]

    steps:
      - uses: actions/checkout@v4

      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: +security-extended,security-and-quality

      # Add manual build steps here when autobuild is insufficient.

      - uses: github/codeql-action/analyze@v3

CodeQL build decision table

CodeQL configuration file reference

A CodeQL config file is useful when you want reusable path/query configuration separate from the workflow.

name: codeql-config

queries:
  - uses: security-extended
  - uses: security-and-quality

paths:
  - src

paths-ignore:
  - test
  - docs
  - "**/*.generated.*"

CodeQL query and pack distinctions

CodeQL CLI pattern

Use the CLI when analysis is performed outside GitHub Actions or when building custom automation.

codeql database create codeql-db \
  --language=javascript-typescript \
  --source-root=.

codeql database analyze codeql-db \
  --format=sarif-latest \
  --output=codeql-results.sarif \
  codeql/javascript-queries

Then upload the SARIF through a GitHub Actions workflow or API-supported process with appropriate permissions.

SARIF upload reference

- uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: results.sarif
    category: third-party-sast

Code scanning triage

What code scanning does

Code scanning helps identify vulnerabilities and coding errors in a repository. With GitHub Advanced Security, the most commonly tested engine is CodeQL, but code scanning can also ingest compatible third-party static analysis results through SARIF upload.

Think of code scanning as answering:

• Does this code contain a known insecure pattern?
• Did this pull request introduce a new alert?
• Is a vulnerability still present on the default branch?
• Should an alert be fixed, dismissed, or investigated further?

CodeQL analysis flow

Default setup

Default setup is appropriate when the repository fits GitHub’s supported automatic configuration model. It is valuable for broad rollout because it reduces workflow maintenance.

High-yield points:

• It is designed for fast enablement.
• It uses GitHub-managed configuration choices.
• It may not be enough for custom build requirements.
• It is usually not the right answer when the scenario demands custom queries, custom schedules, special build commands, or complex language handling.

Advanced setup

Advanced setup uses a GitHub Actions workflow for CodeQL. Choose it when you need control.

Common reasons to use advanced setup:

1. Custom build commands.
2. Custom query suites.
3. Custom CodeQL packs or organization-authored queries.
4. Specific workflow triggers.
5. Matrix builds for multiple languages.
6. Integration with a more complex CI process.

CodeQL query suites

Exam trap: More queries is not always better. Broader query suites can increase coverage but may also increase triage effort. In a scenario about reducing noise, do not blindly select the broadest suite.

CodeQL custom queries

You do not need to become a full CodeQL developer for a quick review, but you should understand the concepts.

Common exam pattern: a scenario describes tainted user input reaching a dangerous API. The right mental model is source → flow steps → sanitizer check → sink.

SARIF upload

SARIF upload allows compatible third-party static analysis results to appear in GitHub code scanning.

Use SARIF when:

• The organization already uses another scanner.
• The language or framework is better covered by a specialized tool.
• Results should be centralized in GitHub code scanning.
• A CI workflow generates analysis results outside CodeQL.

Common traps:

• SARIF upload does not mean the tool is CodeQL.
• Multiple tools or categories should be distinguished clearly so alerts do not overwrite or confuse each other.
• Uploading results is not the same as fixing alerts.

Code scanning alert lifecycle

Decision rule: Fix when the finding is valid and reachable. Dismiss only when you can justify why the alert is not actionable.

Secret scanning vs push protection

Push protection response choices

Custom secret pattern checklist

• Define the secret format precisely enough to avoid broad matches.
• Add surrounding context when possible, such as a prefix, key name, or delimiter.
• Test against representative repositories before broad enablement.
• Publish/apply at the narrowest level that meets the need.
• Monitor false positives and tune the pattern.
• Pair detection with an incident response process: revoke, rotate, remove, document.

Secret alert triage

Secret scanning basics

Secret scanning detects credentials such as tokens, keys, and other secrets in repository content. It may detect provider-specific patterns and, where configured, custom patterns created by the organization.

Secret scanning helps answer:

• Has a secret already been committed?
• Which repository, commit, file, or surface exposed it?
• Is the detected secret likely active or valid?
• Who needs to rotate or revoke it?
• Should a custom pattern be added for internal secrets?

Push protection

Push protection acts earlier than ordinary alerting. It can block a push or commit flow when a supported secret is detected before the secret lands in the repository.

Common exam trap: Push protection is preventive; secret scanning alerts are detective. They complement each other.

Secret scanning response process

Critical trap: Deleting the secret from the repository does not automatically make the secret safe. Rotation or revocation is usually the key security action.

Custom secret patterns

Custom patterns are useful when your organization has internal token formats that GitHub’s built-in partner patterns may not recognize.

Alert triage priorities

Use severity, exploitability, reachability, and business context together. The highest numeric severity is important, but exam scenarios may include additional context that changes priority.

Quick rule: Active leaked secret in a production system is usually urgent even if a static severity label is not present.

Dependency feature decision matrix

Dependabot alerts vs updates

Dependabot configuration pattern

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Dependency review action pattern

name: Dependency Review

on:
  pull_request:

permissions:
  contents: read
  pull-requests: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high

Dependency triage

Dependency graph

The dependency graph identifies dependencies declared in supported manifest and lock files. It is foundational because other features use dependency information.

Think of the dependency graph as an inventory layer:

• What packages does the repository depend on?
• Which versions are declared or resolved?
• Which ecosystems are involved?
• Are manifests and lock files accurate?

Trap: The dependency graph itself is not the same as a fix. It provides dependency visibility.

Dependabot alerts

Dependabot alerts identify dependencies with known vulnerabilities based on advisory data and version ranges.

Common exam decision: If a repository already contains a vulnerable dependency, think Dependabot alert. If a pull request introduces a vulnerable dependency, think dependency review.

Dependabot security updates

Dependabot security updates can open pull requests to update vulnerable dependencies when an upgrade path is available.

Remember:

• Security updates are remediation-oriented.
• They are not the same as version updates for routine freshness.
• They may not work automatically if the ecosystem, version constraints, private registry authentication, or compatibility issues prevent a clean update.
• Generated pull requests still need review and testing.

Dependency review

Dependency review evaluates dependency changes in pull requests. It can help prevent new vulnerable or disallowed dependencies before merge.

Common trap: Dependency review is PR-centered. It is not primarily a historical scanner for all existing dependency debt.

Prioritization reference

Next step: practice applying these distinctions to GH-500 scenario questions, especially cases that mix CodeQL setup, secret scanning prevention, Dependabot remediation, and organization-level governance.

Pick default setup or advanced setup

The exam commonly tests whether you know that default setup is fast and opinionated, while advanced setup gives control through a GitHub Actions workflow.

Security manager role and least privilege

Security work often requires alert visibility and configuration access without full administrative ownership of every repository. GitHub supports delegated security administration patterns, such as security-focused roles at the organization level.

Exam principle: Grant the minimum access needed to manage security alerts and settings. Do not make everyone an organization owner just to view or triage alerts.

Security overview

Security overview helps security teams monitor posture across repositories and organizations.

Use it to answer questions like:

• Which repositories have code scanning disabled?
• Which repositories have unresolved critical alerts?
• Which teams own the riskiest repositories?
• Are security features consistently enabled?
• Where should remediation work be prioritized?

Trap: If the scenario asks for broad visibility, a repository-level alert page is too narrow.

Standardizing enablement

For large environments, manual per-repository setup is error-prone. Look for centralized approaches when the scenario mentions scale, consistency, governance, or onboarding many repositories.

Good rollout sequence:

1. Identify repository scope and ownership.
2. Decide required security features.
3. Apply standard settings or configurations.
4. Validate that alerts are flowing.
5. Assign triage owners.
6. Monitor adoption and exceptions.
7. Improve based on false positives and remediation time.

Pull request event traps

Exam rule: If untrusted code is involved, be cautious with secrets, write tokens, privileged events, and checkout behavior.