GH-500 — GitHub Advanced Security Quick Reference

Last revised: June 18, 2026

Compact quick reference for GitHub Advanced Security (GH-500): code scanning, CodeQL, secret scanning, Dependabot, dependency review, governance, and exam decision points.

This Quick Reference is independent review support for candidates preparing for the GitHub Advanced Security (GH-500) exam from GitHub. Use it to connect exam scenarios to the right GitHub Advanced Security feature, configuration pattern, and troubleshooting path.

Core GitHub Advanced Security feature map

Area	Primary purpose	Typical signal	Best used for	Common exam trap
Code scanning	Find code vulnerabilities and coding errors	Code scanning alerts, PR annotations, SARIF results	Secure coding issues, data-flow flaws, custom static analysis	It is not dependency/SCA scanning and not runtime detection
CodeQL	GitHub’s semantic code analysis engine	CodeQL-generated code scanning alerts	Deep source analysis, custom queries, variant analysis	Default setup is easier; advanced setup is needed for custom builds/queries
Third-party SARIF upload	Bring external static analysis results into GitHub	SARIF code scanning alerts	Centralizing external tool findings in GitHub	SARIF upload needs correct workflow permissions and commit/branch context
Secret scanning	Detect secrets committed to repositories	Secret scanning alerts	Leaked tokens, keys, credentials	It detects known/custom patterns; it does not prove no secret exists
Push protection	Block supported secrets before they enter the repository	Blocked push or bypass request	Preventing new secret leaks	It does not clean historical secrets already committed
Dependency graph	Inventory dependencies from manifests/lockfiles/submissions	Dependency inventory	Foundation for Dependabot alerts and dependency review	If dependencies are not represented/submitted, alerts may be missing
Dependabot alerts	Identify vulnerable dependencies	Security alert	Known vulnerable package versions	Alerting requires dependency visibility and advisory data
Dependabot security updates	Open PRs to fix vulnerable dependencies	Security update PR	Remediating Dependabot alerts	Not the same as scheduled version updates
Dependabot version updates	Keep dependencies current on a schedule	Maintenance PR	Reducing lag and future upgrade risk	Not vulnerability-driven by itself
Dependency review	Evaluate dependency changes in PRs	PR check/failure/comment	Blocking risky new dependencies before merge	It reviews PR deltas; it is not a full repository scan
Security overview	Organization/enterprise security posture view	Aggregated coverage and alerts	Governance, prioritization, reporting	It summarizes; it does not replace feature-level triage
Repository security advisories	Coordinate disclosure and fixes for a project vulnerability	Advisory draft/published advisory	Maintainer-managed vulnerability disclosure	Different from Dependabot alerts raised against consumers
SECURITY.md	Publish security policy/contact process	Security policy file	Directing reporters and contributors	A policy does not enable scanning by itself
Audit log	Record security-relevant admin/user activity	Audit events	Investigating changes, bypasses, settings	Use for “who changed/bypassed” questions, not code vulnerability discovery

Fast scenario-to-feature selection

Scenario keyword	Choose	Why
“Find SQL injection, XSS, path traversal, unsafe deserialization in source”	Code scanning with CodeQL	Semantic/code-flow analysis
“Use organization-specific insecure API pattern”	Custom CodeQL query or query pack	Encodes custom rules beyond default queries
“Existing SAST tool already produces results”	Upload SARIF to code scanning	Centralizes findings in GitHub UI
“Block a personal access token before it is pushed”	Secret scanning push protection	Preventive control at push time
“Detect internal token format not known to GitHub”	Secret scanning custom pattern	Adds organization-specific regex detection
“Find vulnerable npm/Maven/Python package version already in repo”	Dependency graph + Dependabot alerts	Matches dependency inventory to advisories
“Open PR automatically to fix a vulnerable dependency”	Dependabot security updates	Remediation PRs for alerts
“Keep GitHub Actions or package versions current weekly/monthly”	Dependabot version updates	Scheduled maintenance updates
“Fail a PR that introduces a critical dependency vulnerability”	Dependency review action / dependency review policy	PR-time dependency risk gate
“See which repositories have GHAS features enabled”	Security overview / security configurations	Governance and coverage
“Standardize security settings for new repositories”	Organization security configurations	Apply consistent feature enablement
“Need who bypassed push protection or disabled scanning”	Audit log	Administrative/event investigation
“Project maintainer needs private vulnerability coordination”	Repository security advisory + private fork	Coordinated disclosure and patch workflow

Enablement, permissions, and governance reference

Level	What is commonly managed there	Exam-oriented notes
Enterprise	GHAS availability, enterprise-wide policies, audit visibility, security posture	Enterprise settings can constrain organization and repository choices. Do not assume a repository admin can override enterprise policy.
Organization	Security configurations, default feature enablement, security managers, custom secret patterns, overview views	Use organization-level controls for consistency across many repositories.
Repository	Feature toggles when permitted, workflow files, CodeQL config, Dependabot config, alert triage	Repository settings are best for repo-specific tuning, but may be governed from above.
Branch/ruleset controls	Required checks, review requirements, merge restrictions	Use with CodeQL/dependency review checks to prevent insecure changes from merging.
Security manager role	Manage security alerts and settings across an organization without full owner privileges	High-yield least-privilege answer when broad security administration is needed.
Repository admin/maintainer/developer roles	Configure workflows, triage alerts, fix findings depending on permission model	Exact visibility/action depends on repository permissions and organization policy.

Security configurations vs workflow files

Need	Better fit
Enable GHAS features consistently across many repositories	Organization security configuration
Customize CodeQL build commands, query suites, paths, languages	CodeQL workflow/config file
Enforce that new repositories start with selected security settings	Default security configuration
Standardize scanner behavior for many repositories with similar build	Reusable workflow plus organization policy
Tune a single monorepo with special generated-code exclusions	Repository-specific CodeQL config

High-yield workflow: detect, prevent, triage, govern

    flowchart LR
	    A[Repository code and dependencies] --> B[Prevent]
	    B --> B1[Push protection]
	    B --> B2[Dependency review]
	    B --> B3[Required checks/rulesets]
	
	    A --> C[Detect]
	    C --> C1[Code scanning/CodeQL]
	    C --> C2[Secret scanning]
	    C --> C3[Dependabot alerts]
	
	    C1 --> D[Triage alerts]
	    C2 --> D
	    C3 --> D
	
	    D --> E[Fix, dismiss with reason, or document risk]
	    E --> F[Govern]
	    F --> F1[Security overview]
	    F --> F2[Security configurations]
	    F --> F3[Audit log]

Code scanning and CodeQL

Code scanning setup choices

Setup path	Use when	Strengths	Watch for
Default setup	Repository has supported languages and standard build needs	Fast enablement, low maintenance, GitHub-managed workflow behavior	Limited customization; may not fit complex monorepos or special build steps
Advanced setup	Need custom queries, paths, build commands, workflow triggers, matrices, or permissions	Full workflow control	Misconfigured builds lead to incomplete analysis
CodeQL CLI	Analysis occurs outside GitHub Actions or in custom CI	Portable, scriptable, useful for advanced pipelines	Must create/analyze databases and upload SARIF correctly
Third-party SARIF	Existing scanner is preferred or required	Unified alerts in GitHub code scanning	SARIF quality and mapping affect alert usefulness
Variant analysis	Need to search for variants of a known issue pattern across codebases	Powerful for security research and organization-wide patterns	Not a replacement for continuous scanning

Code scanning event selection

Trigger	Use for	Notes
`pull_request`	Preventing new issues before merge	High-value for PR annotations and required checks
`push` to default/protected branches	Updating baseline alerts after merge	Common baseline scan trigger
`schedule`	Re-scan without code changes, pick up query improvements	Useful even when code is stable
`workflow_dispatch`	Manual/ad hoc scans	Good for troubleshooting and one-off validation
External CI + SARIF upload	Non-GitHub Actions pipelines	Requires correct commit SHA/ref and upload permissions

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

Repository/build characteristic	Prefer	Why
JavaScript/TypeScript, Python, Ruby with normal layout	Default setup or advanced setup with no custom build	Many interpreted ecosystems do not need a compile step for useful analysis
Compiled language with standard project	Default setup or `autobuild`	Lower maintenance if GitHub can infer build
Compiled language with custom build, private dependencies, generated sources, monorepo	Advanced setup with manual build commands	Ensures CodeQL observes the correct compilation/database
Multiple languages	Matrix or multiple language entries	Keeps analysis organized and avoids missing languages
Multiple independent projects in one repo	Path filters, custom build, or separate jobs/categories	Avoids scanning noise and result overwrites
External scanner	SARIF upload	Code scanning UI can ingest compatible results

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.*"

Configuration item	Use for	Trap
`queries`	Add standard suites or custom packs	More queries can mean more findings and longer analysis
`paths`	Limit analysis to relevant source	Overly narrow paths can hide vulnerable code
`paths-ignore`	Exclude generated/test/vendor code	Do not exclude code that ships to production
Manual build steps	Make database accurate for compiled languages	A successful workflow can still produce poor results if the wrong build ran
Matrix languages	Analyze multiple languages cleanly	A language not listed may not be analyzed in advanced setup
`security-events: write`	Upload code scanning results	Missing permission is a common SARIF/analyze failure

CodeQL query and pack distinctions

Term	Meaning	Exam use
Query	A CodeQL rule that finds a pattern	Add custom detection for a vulnerability class
Query suite	A curated set of queries	Select `security-extended` or `security-and-quality` based on signal goals
Query pack / QL pack	Packaged queries and dependencies	Share custom queries across repositories
CodeQL database	Extracted representation of code for analysis	Created during CodeQL analysis or with CodeQL CLI
Modeling	Teaching CodeQL about frameworks/libraries	Improves data-flow results for custom APIs
Variant analysis	Running a query to find related issue variants	Useful after discovering a specific bug pattern

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

SARIF issue	Likely cause	Fix
Upload denied	Missing `security-events: write` or policy restriction	Set workflow permissions or adjust policy
Alerts attached to wrong branch/commit	SARIF uploaded from wrong ref/SHA	Upload in workflow context matching analyzed commit
Results overwrite each other	Same tool/category for multiple analyses	Use distinct categories for different tools/languages
Alerts lack useful locations	Poor SARIF mapping	Ensure results include file paths, regions, rule IDs
PR annotations missing	Scan not triggered on PR or paths not changed/mapped	Add PR trigger and confirm SARIF locations map to diff

Code scanning triage

Action	Use when	Notes
Fix	Alert represents a real issue	Preferred for exploitable or reachable code
Dismiss as false positive	Tool finding is incorrect	Include rationale; avoid hiding similar real issues
Dismiss as used in tests	Intentional vulnerable pattern in test-only code	Better long-term fix may be excluding test paths or using safe fixtures
Dismiss as won’t fix / accepted risk	Business decision accepts risk	Should be documented and reviewable
Reopen	Dismissed issue becomes relevant or reintroduced	Alerts may reappear when code changes or analysis improves

Secret scanning and push protection

Secret scanning decision table

Need	Use	Why
Detect known provider tokens already committed	Secret scanning alerts	Scans repository content for supported secret patterns
Prevent supported secrets from being pushed	Push protection	Blocks at push time before secret lands
Detect internal credential format	Custom secret scanning pattern	Adds organization/repository-specific regex
Reduce false positives before rollout	Test/dry-run custom pattern where available	Validates pattern against real repositories
Investigate whether a bypass occurred	Audit log and alert metadata	Tracks user/admin security-relevant actions
Remove exposed credential risk	Revoke/rotate secret, then remediate code/history as needed	Deleting code alone may not invalidate the secret

Secret scanning vs push protection

Capability	Secret scanning	Push protection
Detects historical committed secrets	Yes	No
Blocks new pushes containing supported secrets	No	Yes
Creates alerts for triage	Yes	Yes, when bypassed or detected depending on flow
Supports custom patterns	Yes	May apply depending on configuration and support
Requires developer action before push succeeds	No	Yes
Best control type	Detective	Preventive

Push protection response choices

Developer sees blocked push	Best response	Exam reasoning
Real secret accidentally committed	Remove secret from commit and rotate/revoke it	Secret may already be exposed locally or in attempted workflow
False positive test value	Replace with clearly fake value that does not match real pattern	Avoid repeated bypasses
Business-critical urgent push	Bypass only if policy allows and reason is valid	Bypass creates governance/audit concern
Secret needed by app	Store in GitHub Actions secrets, environment secrets, or external secret manager	Do not hard-code secrets in source

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

Status/action	Use when	Important distinction
Open	Needs investigation or remediation	Do not leave real credentials open after rotation
Resolved as revoked/rotated	Credential is invalidated	Preferred for real secrets
Resolved as false positive	Match is not actually a secret	Tune custom pattern if repeated
Resolved as used in tests	Non-production test credential is intentional	Safer to use fake values that cannot authenticate
Accepted risk / will not fix	Organization explicitly accepts exposure risk	Should be rare and documented
Reopen	Credential is still valid or reintroduced	Reassess scope and rotation

Dependency security and supply chain

Dependency feature relationships

    flowchart LR
	    A[Manifest, lockfile, or submitted dependencies] --> B[Dependency graph]
	    B --> C[Dependabot alerts]
	    C --> D[Dependabot security updates]
	    B --> E[Dependency review on PRs]
	    F[dependabot.yml schedule] --> G[Dependabot version updates]

Dependency feature decision matrix

Feature	Detects/does	Trigger	Output	Use when
Dependency graph	Identifies dependencies	Repository files or dependency submission	Dependency inventory	You need visibility into what packages are used
Dependency submission API	Adds build-resolved dependencies not visible in manifests	CI/build submission	Enriched dependency graph	Ecosystem/build system is not fully represented by checked-in files
Dependabot alerts	Matches dependencies to advisories	Dependency graph + advisory data	Security alert	You need vulnerability awareness
Dependabot security updates	Opens PRs to remediate vulnerable dependencies	Dependabot alert with available fix path	Security PR	You want automated vulnerability remediation
Dependabot version updates	Opens PRs for newer versions on a schedule	`dependabot.yml` schedule	Maintenance PR	You want regular dependency freshness
Dependency review	Reviews dependency changes in PRs	Pull request	PR check/comment/failure	You want to block newly introduced vulnerable dependencies

Dependabot alerts vs updates

Item	Dependabot alerts	Dependabot security updates	Dependabot version updates
Primary goal	Notify about vulnerable dependency	Fix vulnerability	Keep dependency current
Vulnerability-driven	Yes	Yes	No
Opens PR	No	Yes	Yes
Requires `dependabot.yml`	Not always for alerting	Not always for security updates, but config may tune behavior	Yes
Best exam phrase	“Identify vulnerable dependency”	“Automatically create remediation PR”	“Scheduled update PRs”

Dependabot configuration pattern

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

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

Config choice	Use for	Trap
`package-ecosystem`	Select npm, Maven, pip, GitHub Actions, etc.	Wrong ecosystem means no updates
`directory`	Location of manifest	Monorepos often need multiple entries
`schedule`	Cadence for version update checks	Version updates are maintenance, not vulnerability alerting
Groups	Combine related updates	Over-grouping can make PRs harder to review
Private registry config	Allow Dependabot to access private packages	Dependabot secrets are separate from GitHub Actions secrets
Ignore rules	Suppress specific versions/dependencies	Can hide needed security fixes if too broad

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 review question	Answer
“When does it run?”	On pull requests
“What does it evaluate?”	Dependency changes introduced by the PR
“How can it block merges?”	Fail the PR check and require the check through rulesets/branch protection
“What does it depend on?”	Dependency graph and recognizable dependency manifests/lockfiles
“Is it the same as Dependabot alerts?”	No. Alerts report known vulnerabilities; review gates PR changes

Dependency triage

Finding	Best first action	Notes
Vulnerable direct dependency with patch available	Accept Dependabot security update PR or manually upgrade	Direct upgrades are usually straightforward
Vulnerable transitive dependency	Upgrade parent dependency or override if ecosystem supports it	Understand dependency chain before dismissing
No fixed version available	Mitigate usage, monitor advisory, document risk	Do not invent a fix
Package unused in runtime	Remove dependency or dismiss with clear rationale	“Not used” should be verified
Private package not detected	Use dependency submission or registry configuration	Visibility problem, not necessarily no risk

GitHub Actions security for GHAS workflows

Situation	Secure pattern	Trap
CodeQL or SARIF upload	Grant `security-events: write` only where needed	Overly broad workflow permissions
Analyze private dependencies	Use least-privilege credentials/secrets	Hard-coding tokens to make build work
PRs from forks	Be careful with secrets and privileged triggers	`pull_request_target` can be dangerous with untrusted code
Dependabot PR runs workflow	Use Dependabot-aware permissions/secrets	Dependabot does not automatically get normal Actions secrets
Required security gates	Require CodeQL/dependency review status checks	A scanner that only reports after merge is not a preventive gate
Reusable workflows	Standardize GHAS scanning across repos	Still need repo-specific language/build tuning

Repository security and disclosure

Capability	Use when	Key distinction
SECURITY.md	You want to tell users how to report vulnerabilities	Documentation/policy only
Private vulnerability reporting	You want external reporters to privately report issues	Intake mechanism
Repository security advisory	Maintainer coordinates fix and disclosure	Advisory workflow for the affected project
Temporary private fork	Patch collaboration without public exposure	Used during advisory remediation
CVE request/publishing support	Public vulnerability disclosure needs standardized identifier	Do not confuse with scanner-generated alerts
Dependabot alert	Your repository consumes a vulnerable dependency	Consumer-side notification

Security overview, campaigns, and prioritization

View/control	Use for	Practical exam angle
Security overview	See alert counts, feature coverage, risk across repositories	Best answer for organization/enterprise posture questions
Security coverage	Identify repos missing code scanning, secret scanning, Dependabot, etc.	Helps roll out GHAS consistently
Repository risk views	Prioritize repositories with more severe/open alerts	Supports remediation planning
Security configurations	Apply standard security settings	Governance at scale
Security campaigns / remediation tracking where available	Coordinate fixing selected alert groups	Useful for focused remediation, not initial detection
Audit log	Investigate settings changes, bypasses, admin actions	Governance and accountability

Prioritization reference

Highest priority	Why
Exposed valid production secret	Immediate credential compromise risk; rotate/revoke first
Critical reachable dependency vulnerability with exploit path	Known vulnerable component in use
Code scanning alert in internet-facing/auth-sensitive path	Application exploit risk
PR introducing new high/critical vulnerable dependency	Prevent before merge
Repeated push protection bypasses	Indicates training or policy enforcement gap
Repositories with no security coverage	Blind spot; enable baseline controls

Alert lifecycle quick reference

Step	Code scanning	Secret scanning	Dependabot
Detect	CodeQL/third-party SARIF scan	Pattern match in repository or push	Advisory match against dependency graph
Notify	Alert, PR annotation, check	Alert/block/bypass event	Alert and optional PR
Triage	Confirm exploitability/reachability	Determine whether credential is real/valid	Determine affected package path and fix availability
Remediate	Code fix, safe API, validation, sanitization	Revoke/rotate, remove secret, purge if needed	Upgrade, remove, override, or mitigate
Close	Fixed by scan result or dismissed	Resolved with reason	Fixed, dismissed, or no longer detected
Govern	Required checks, security overview	Push protection, audit log	Dependency review, rulesets, security overview

Common GH-500 traps

Trap	Correct exam reasoning
“Enable secret scanning to block secrets from being pushed.”	Secret scanning detects; push protection blocks supported secrets at push time.
“Dependabot version updates fix vulnerabilities.”	They update versions on a schedule. Security updates are vulnerability-driven.
“Dependency review scans the whole repository.”	It evaluates dependency changes in a pull request.
“Code scanning finds vulnerable open-source packages.”	That is dependency security. Code scanning analyzes source code.
“Default CodeQL setup is always best.”	Use advanced setup for custom builds, queries, paths, triggers, or monorepos.
“Autobuild success means perfect analysis.”	The build may be incomplete or not representative. Manual build may be needed.
“Dismissed alerts are gone forever.”	They can reappear if code changes, analysis changes, or issue is reintroduced.
“Deleting a leaked secret from code fixes the incident.”	Rotate/revoke the credential; assume exposure.
“Actions secrets are available to Dependabot.”	Dependabot uses its own secret handling; configure accordingly.
“Security overview remediates issues.”	It provides posture and prioritization; fixes happen in repos/workflows/dependencies.
“SARIF upload just needs a file.”	It also needs correct permissions, commit/ref context, and useful locations/rules.
“A SECURITY.md enables vulnerability scanning.”	It documents reporting policy only.

Quick troubleshooting table

Symptom	Likely cause	Check/fix
CodeQL workflow passes but no alerts/results	Language not detected, wrong paths, no analyzable code, upload issue	Confirm language matrix, config paths, Security tab, workflow logs
CodeQL fails during build	Missing dependencies, wrong build command, private registry credentials	Add setup steps, credentials, or manual build
SARIF upload fails	Missing permission or invalid SARIF	Add `security-events: write`; validate SARIF
PR has no code scanning annotation	Scan not running on PR or finding not in changed lines	Add PR trigger; verify branch/ruleset behavior
Secret push not blocked	Push protection not enabled or pattern not covered	Enable push protection and/or custom pattern
Too many custom secret false positives	Regex too broad	Add prefix/context and test pattern
Dependabot opens no PR	No supported manifest, no update path, config directory wrong, access issue	Check dependency graph, `dependabot.yml`, private registry config
Dependency review does not fail PR	Action not installed, severity threshold too low, check not required	Configure action and require status check
Security overview shows missing coverage	Features not enabled or policies not applied	Apply security configuration or repo setting
Developers bypass push protection often	Training/policy issue or false-positive pattern	Review audit events and tune controls

Final exam-day selection guide

If the scenario asks for…	Answer with…
“Prevent new leaked secrets”	Secret scanning push protection
“Find existing leaked secrets”	Secret scanning
“Custom internal credential detection”	Custom secret scanning pattern
“Find source code vulnerabilities”	Code scanning with CodeQL
“Use custom static analysis results in GitHub”	SARIF upload
“Analyze complex compiled monorepo”	Advanced CodeQL setup with manual build
“Add organization-specific vulnerability pattern”	Custom CodeQL query/query pack
“Find vulnerable dependencies”	Dependency graph + Dependabot alerts
“Automatically create dependency fix PR”	Dependabot security updates
“Keep dependencies current”	Dependabot version updates
“Block PRs adding risky dependencies”	Dependency review with required check
“Standardize GHAS enablement across repos”	Security configurations
“View posture across organization/enterprise”	Security overview
“Investigate setting changes or bypasses”	Audit log
“Document how to report vulnerabilities”	SECURITY.md
“Coordinate disclosure for a project vulnerability”	Repository security advisory

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.

Scenario Guide

GHAS Features