GH-500 — GitHub Advanced Security Quick Review
Quick Review for GitHub Advanced Security (GH-500): code scanning, secret scanning, dependency security, administration, and exam traps.
Quick Review purpose
This Quick Review is for candidates preparing for the real GitHub Advanced Security (GH-500) exam from GitHub. Use it to refresh high-yield concepts before moving into IT Mastery practice, original practice questions, topic drills, mock exams, and detailed explanations.
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?
High-yield capability map
| Need | GitHub capability to think of first | What it helps detect or control | Common exam trap |
|---|---|---|---|
| Find vulnerable code patterns | Code scanning with CodeQL or SARIF upload | Security and quality issues in source code | Confusing CodeQL analysis with dependency vulnerability detection |
| Customize static analysis | Advanced CodeQL setup, query suites, custom queries, CodeQL packs | Language-specific analysis, custom policies, organization standards | Assuming default setup supports every custom build or query requirement |
| Block exposed credentials before they land | Secret scanning push protection | Supported secrets detected during push or web commit flows | Thinking secret scanning and push protection are the same thing |
| Find committed secrets already present | Secret scanning alerts | Tokens, keys, credentials, custom patterns | Treating a resolved alert as proof the secret was rotated |
| Review vulnerable dependencies | Dependabot alerts and dependency graph | Known vulnerable package versions | Confusing dependency graph inventory with remediation |
| Automatically propose dependency fixes | Dependabot security updates | Pull requests for vulnerable dependencies when possible | Assuming every alert can be automatically fixed |
| Stop risky dependencies in PRs | Dependency review | Newly introduced vulnerable or disallowed dependencies | Using it for historical repository-wide remediation |
| Centralize security visibility | Security overview and organization or enterprise views | Alert posture across repositories | Looking only at one repository when the scenario says organization-wide |
| Harden CI/CD | GitHub Actions permissions, reusable workflows, trusted actions, OIDC, environments | Workflow supply-chain and secret exposure risk | Using pull_request_target carelessly with untrusted code |
Core decision rules
Pick the feature by timing
| Timing of the problem | Best feature family | Example scenario |
|---|---|---|
| Before code is merged | Code scanning PR checks, dependency review, branch protection or rulesets, push protection | A pull request introduces SQL injection or a vulnerable package |
| During development workflow | GitHub Actions security controls, CodeQL workflow, Dependabot PRs | CI should run CodeQL and fail if severe issues appear |
| After code already exists | Code scanning alerts, secret scanning alerts, Dependabot alerts, security overview | A repository has accumulated unresolved alerts |
| Across many repositories | Organization or enterprise security settings, security configurations, security overview | Standardize scanning for all production repos |
Pick default setup or advanced setup
| Situation | Prefer default setup | Prefer advanced setup |
|---|---|---|
| Standard repository with supported languages | Yes | Maybe not needed |
| Need custom CodeQL query suites or packs | No | Yes |
| Need custom build steps | No | Yes |
| Need custom workflow triggers | No | Yes |
| Need matrix strategy or multi-language tuning | Limited | Yes |
| Need quick baseline enablement across repositories | Yes | Sometimes, after standardization |
The exam commonly tests whether you know that default setup is fast and opinionated, while advanced setup gives control through a GitHub Actions workflow.
Code scanning and CodeQL
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
| Step | What happens | Exam-relevant point |
|---|---|---|
| Initialize | CodeQL prepares analysis for selected languages | Language detection and configuration matter |
| Build or extract | CodeQL creates a database representation of the code | Compiled languages may need accurate build information |
| Analyze | Queries run against the CodeQL database | Query suite choice affects alert coverage |
| Upload results | Results appear as code scanning alerts | SARIF category and branch context can affect display |
| Triage | Developers fix, dismiss, or investigate alerts | Dismissal should be justified, not used as cleanup |
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:
- Custom build commands.
- Custom query suites.
- Custom CodeQL packs or organization-authored queries.
- Specific workflow triggers.
- Matrix builds for multiple languages.
- Integration with a more complex CI process.
CodeQL query suites
| Query suite idea | What to remember |
|---|---|
| Default security coverage | Baseline security analysis suitable for many repositories |
| Extended security coverage | Broader security detection, often more alerts |
| Security and quality coverage | Includes quality-oriented findings in addition to security-oriented findings |
| Custom queries | Useful for organization-specific rules, frameworks, or internal secure-coding requirements |
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.
| Concept | Meaning |
|---|---|
| Database | CodeQL’s structured representation of the source code |
| Query | Logic that searches the database for patterns |
| Source | Where untrusted or sensitive data originates |
| Sink | Dangerous operation where that data may cause harm |
| Sanitizer | Validation or transformation that makes data safer |
| Path problem | Alert type that can show a flow path from source to sink |
| Query pack | Packaged CodeQL queries that can be reused and versioned |
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
| Status or action | Meaning | Good candidate behavior |
|---|---|---|
| Open | Alert is currently detected | Prioritize by severity, exploitability, and affected code |
| Fixed | The issue is no longer detected | Confirm the fix is merged into the relevant branch |
| Dismissed | The alert is intentionally closed without code change | Use only with a valid reason and documentation |
| Reopened | The issue appears again or was not truly resolved | Investigate regression or incomplete remediation |
Decision rule: Fix when the finding is valid and reachable. Dismiss only when you can justify why the alert is not actionable.
Secret scanning and push protection
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.
| Feature | Main purpose | Timing |
|---|---|---|
| Secret scanning alerts | Detect exposed secrets already present | After detection in repository content |
| Push protection | Prevent supported secrets from being pushed | Before or during push |
| Custom patterns | Detect organization-specific secret formats | Depends on configuration and rollout |
| Bypass review or audit | Manage exceptions | After a user attempts to bypass |
Common exam trap: Push protection is preventive; secret scanning alerts are detective. They complement each other.
Secret scanning response process
| Step | What to do | Why it matters |
|---|---|---|
| Validate context | Check where the secret appeared and what it can access | Not all secrets have equal blast radius |
| Revoke or rotate | Disable the exposed credential and issue a replacement if needed | Removing code history alone is not enough |
| Remove exposure | Delete or rewrite the secret from code, config, or docs as appropriate | Prevents repeated exposure |
| Investigate use | Review logs or provider activity | Detects possible compromise |
| Close alert with reason | Document the outcome | Maintains auditability |
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.
| Design point | Good practice | Trap |
|---|---|---|
| Regex specificity | Match the actual token structure | Overly broad regex creates noisy alerts |
| Context requirements | Use surrounding text or format rules where helpful | Matching random strings as secrets |
| Dry run or test mode | Evaluate alert volume before broad rollout | Enabling noisy patterns everywhere immediately |
| Ownership | Define who triages alerts | Creating alerts with no response process |
| Exclusions | Keep narrow and documented | Excluding large paths to hide noise |
Dependency security and supply chain review
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.
| Concept | Meaning |
|---|---|
| Affected package | Package with a known vulnerability |
| Affected range | Vulnerable version range |
| Patched version | Version that addresses the vulnerability, if available |
| Severity | Risk indicator, often based on vulnerability scoring and context |
| Manifest location | Where the dependency is declared |
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.
| Scenario | Best answer |
|---|---|
| PR adds a package with a known critical vulnerability | Dependency review |
| Existing default branch has vulnerable package versions | Dependabot alerts |
| Need automated PR to upgrade a vulnerable dependency | Dependabot security updates |
| Need inventory of repository dependencies | Dependency graph |
| Need organization-wide visibility into vulnerable repos | Security overview |
Common trap: Dependency review is PR-centered. It is not primarily a historical scanner for all existing dependency debt.
Administration, permissions, and rollout
Repository, organization, and enterprise thinking
GH-500 scenarios often describe the scope of the problem. Match the solution to that scope.
| Scope in scenario | What to consider |
|---|---|
| Single repository | Repository security settings, workflow configuration, branch protection, alert triage |
| Team-owned set of repositories | Organization security settings, security manager access, standard workflows |
| Many repositories | Security configurations, organization policies, security overview, rollout strategy |
| Enterprise-wide governance | Enterprise-level policies, visibility, standardized enablement approach |
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:
- Identify repository scope and ownership.
- Decide required security features.
- Apply standard settings or configurations.
- Validate that alerts are flowing.
- Assign triage owners.
- Monitor adoption and exceptions.
- Improve based on false positives and remediation time.
GitHub Actions security concepts
GitHub Advanced Security questions may connect scanning with CI/CD. Know the security implications of workflow design.
Workflow permission basics
| Control | Why it matters |
|---|---|
| Least-privilege GITHUB_TOKEN permissions | Reduces damage if a workflow is compromised |
| Explicit permissions at workflow or job level | Avoids overly broad defaults |
| Environment protection rules | Adds control for sensitive deployments |
| Secrets scoped to repositories, environments, or organizations | Limits who and what can access secrets |
| OIDC federation | Can reduce long-lived cloud credentials in GitHub secrets |
| Pinning actions | Reduces risk from unexpected third-party action changes |
Pull request event traps
| Event pattern | Risk |
|---|---|
| Running untrusted fork code with write credentials | Can expose secrets or modify repository state |
| Using pull_request_target without care | Runs in the target repository context and can be dangerous with untrusted code |
| Checking out attacker-controlled code in privileged workflows | May allow workflow compromise |
| Broad token permissions in PR workflows | Increases blast radius |
Exam rule: If untrusted code is involved, be cautious with secrets, write tokens, privileged events, and checkout behavior.
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.
| Factor | Why it matters |
|---|---|
| Severity | Indicates potential technical impact |
| Exposure | Public-facing code or internal-only code changes priority |
| Reachability | Vulnerable code that is actually invoked is more urgent |
| Secret validity | Active credentials require immediate action |
| Asset criticality | Production authentication service matters more than a demo repo |
| Fix availability | Available patches or clear code fixes accelerate remediation |
| Age and recurrence | Long-lived or repeated alerts suggest process issues |
Quick rule: Active leaked secret in a production system is usually urgent even if a static severity label is not present.
Common GH-500 candidate mistakes
| Mistake | Correct thinking |
|---|---|
| Treating all GitHub security features as interchangeable | Identify whether the issue is code, secret, dependency, workflow, or governance |
| Choosing advanced setup for every CodeQL scenario | Default setup is often correct for fast standard enablement |
| Choosing default setup when custom builds or custom queries are required | Advanced setup is needed for control |
| Assuming a Dependabot alert automatically means a PR exists | Security updates may need to be enabled and may not always generate a clean fix |
| Using dependency review for historical vulnerable dependencies | Use Dependabot alerts for existing dependency vulnerabilities |
| Ignoring lock files | Resolved versions often matter for accurate dependency analysis |
| Dismissing code scanning alerts to reduce noise | Dismiss only with defensible rationale |
| Removing a committed secret but not rotating it | Rotation or revocation is the security-critical action |
| Giving broad admin access to security staff | Prefer delegated security roles and least privilege |
| Overlooking organization-wide visibility | Use security overview for cross-repository posture |
| Allowing powerful workflow tokens in untrusted PRs | Restrict permissions and avoid privileged execution of untrusted code |
| Forgetting SARIF upload | Third-party analysis can be centralized in code scanning |
Scenario shortcuts
If the scenario says “custom build”
Think: advanced CodeQL setup.
Why: CodeQL may need the project to be built in a specific way to analyze accurately.
If the scenario says “custom internal token format”
Think: secret scanning custom pattern.
Why: Built-in patterns may not know the organization’s private credential format.
If the scenario says “block secrets before commit or push”
Think: push protection.
Why: The goal is prevention before the secret is introduced.
If the scenario says “PR adds vulnerable library”
Think: dependency review.
Why: The problem is introduced in a pull request.
If the scenario says “repository already has vulnerable library”
Think: Dependabot alerts and possibly Dependabot security updates.
Why: The vulnerability already exists in the dependency inventory.
If the scenario says “single view across repositories”
Think: security overview.
Why: Repository-by-repository review does not scale.
If the scenario says “third-party static analysis results”
Think: SARIF upload to code scanning.
Why: SARIF is the interoperability format for code scanning results.
Rapid final checklist
Before your next GH-500 practice session, confirm you can answer these without notes:
- When should you choose CodeQL default setup instead of advanced setup?
- What CodeQL scenario requires custom workflow configuration?
- What is the difference between code scanning, secret scanning, and dependency scanning?
- What is the difference between secret scanning alerts and push protection?
- Why is secret rotation more important than simply deleting a committed key?
- When should you use custom secret patterns?
- What is the dependency graph used for?
- How do Dependabot alerts differ from Dependabot security updates?
- How does dependency review protect pull requests?
- When is SARIF upload the right answer?
- What does security overview provide that a repository alert page does not?
- Why is pull_request_target risky with untrusted code?
- How should GITHUB_TOKEN permissions be configured?
- What is the principle behind delegated security administration?
- When is dismissing an alert appropriate?
How to use this with practice questions
Use this Quick Review as a compressed map, then move into IT Mastery practice:
- Start with topic drills for code scanning, secret scanning, dependency security, and administration.
- For every missed original practice question, identify the decision point you missed.
- Read the detailed explanations, especially for similar-sounding features.
- Build a short error log with traps such as “used Dependabot alert when dependency review was needed.”
- 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.
Continue in IT Mastery
Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official GitHub questions, copied live-exam content, or exam dumps.