GH-500 GitHub Advanced Security Exam Question and Answers

GitHub Advanced Security features can be managed at both the organization and repository levels. Organization owners can control security configurations and Advanced Security access across repositories from the organization's Settings area. At the repository level, administrators can manage eligible security and analysis features through the repository's Settings, subject to any policies or security configurations enforced by the organization or enterprise. Current GitHub terminology separates Advanced Security into products such as GitHub Secret Protection and GitHub Code Security, but the same management hierarchy applies. The organization's Repository permissions area manages general repository access permissions rather than feature licensing or enablement, while enterprise settings primarily establish higher-level policies rather than directly serving as the normal per-repository control described here.

Comprehensive and Detailed Explanation:

When configuring Dependabot via the dependabot.yml file, the following fields are mandatory for each update configuration:

directory: Specifies the location of the package manifest within the repository. This tells Dependabot where to look for dependency files.​

package-ecosystem: Indicates the type of package manager (e.g., npm, pip, maven) used in the specified directory.​

schedule.interval: Defines how frequently Dependabot checks for updates (e.g., daily, weekly). This ensures regular scanning for outdated or vulnerable dependencies.​

The milestone field is optional and used for associating pull requests with milestones. The allow field is also optional and used to specify which dependencies to update.​

GitLab

To detect and block vulnerable dependencies before merge , developers should use the Dependency Review GitHub Action in their pull request workflows. It scans all proposed dependency changes and flags any packages with known vulnerabilities.

This is a preventative measure during development, unlike Dependabot, which reacts after the fact .

GitHub Actions supports path filters for events such as push and pull_request. The paths: key allows a workflow to run only when changed files match one or more specified path patterns. For example, a workflow could use paths: - 'src/**' so that a code scanning job runs when files under the src directory are changed. The related paths-ignore: key performs the opposite function by excluding matching paths. Characters such as ** are glob-pattern components placed beneath paths:; they are not replacements for the paths keyword itself. Therefore, because the workflow must conditionally run when files in a particular directory change, line 3 should contain paths: followed by the applicable directory pattern.

Validity checks — where GitHub verifies if a secret is still active — are available for partner patterns only. These are secrets issued by GitHub's trusted partners (like AWS, Slack, etc.) and have APIs for GitHub to validate token activity status.

Custom patterns and high entropy patterns do not support automated validity checks.

Enabling the dependency graph allows GitHub to analyze supported manifest and lock files and build a representation of the repository's direct and transitive dependencies. GitHub receives read-only access to the dependency files, parses supported manifests when the feature is first enabled, and then updates the graph as repository content changes. Dependabot alerts and Dependabot security updates are separate capabilities: enabling the dependency graph alone does not automatically mean that security-update pull requests will be generated. Likewise, the dependency graph setting for one repository does not require administrators to manually enable dependency information for every newly created repository unless their organization's configuration requires that behavior. Therefore, the applicable result among the supplied options is that repository administrators can view the dependency information exposed by the dependency graph.

When a CodeQL workflow uses a language matrix, the matrix explicitly defines which programming languages the workflow analyzes. GitHub states that CodeQL will analyze only the languages included in that matrix; adding or removing matrix entries therefore directly changes the languages scanned. The matrix also allows separate language-analysis jobs to run in parallel, so it does not inherently make analysis sequential. The languages input of the CodeQL init action commonly receives the current matrix.language value, but that describes how the matrix value is passed into CodeQL rather than the principal impact asked for here. The matrix also does not represent dependency exclusions. Consequently, the operational effect being tested is that CodeQL analysis is restricted to the languages explicitly included in the workflow's matrix.

Before CodeQL can execute security queries, the source code must first be represented in a CodeQL database. Database creation extracts structured, relational information from the source code and, where applicable, observes or performs the build process required for the language being analyzed. Once the database exists, CodeQL can execute queries against it. The resulting query output is then interpreted using query metadata and can ultimately be converted to a format such as SARIF for presentation as code scanning alerts. Therefore, running queries, interpreting results, and converting results are later phases of analysis. GitHub's CodeQL documentation explicitly identifies creation of the CodeQL database as a prerequisite for analyzing source code with CodeQL queries, making preparation/database creation the correct first step.

Comprehensive and Detailed Explanation:

Push protection for secret scanning custom patterns is an opt-in feature. This means that for each custom pattern defined in a repository, maintainers can choose to enable or disable push protection individually. This provides flexibility, allowing teams to enforce push protection on sensitive patterns while leaving it disabled for others.​

You should dismiss a code scanning alert if the flagged code is not a true security concern , such as:

Code in test files

Code paths that are unreachable or safe by design

False positives from the scanner

Fixing the code would automatically resolve the alert — not dismiss it. Dismissing is for valid exceptions or noise reduction.

When a person's access to a private repository is removed, GitHub deletes that person's private forks belonging to the repository's network. This prevents the GitHub-hosted fork from remaining available after the user loses authorization to the upstream private repository. GitHub cannot, however, automatically erase local clones that the person previously downloaded to their own computers; the documentation explicitly states that local clones are retained. Removing one individual's access also does not necessarily revoke an entire team's access, because team permissions are managed separately. Nor does GitHub automatically delete confidential information that may have been copied outside the repository. GitHub therefore advises organizations to ensure that former collaborators appropriately dispose of confidential or proprietary information. The direct platform behavior described in the question is deletion of the user's private forks.

To proactively address secret scanning:

Webhooks can be configured to listen for secret scanning events. This allows automation, logging, or alerting in real-time when secrets are detected.

Documenting secure development practices (like using environment variables or secret managers) helps reduce the likelihood of developers committing secrets in the first place.

Dismissal based on age is not a best practice without triage. SCIM deals with user provisioning, not scanning alerts.

A Dependabot alert is marked as resolved only after the related pull request is merged into the repository. This indicates that the vulnerable dependency has been officially replaced with a secure version in the active codebase.

Simply generating a PR or passing checks does not change the alert status; merging is the key step.

Ignoring an unresolved code scanning alert leaves the underlying security issue present in the application. GitHub identifies several risks through CodeQL data-flow analysis, including data being used insecurely, dangerous arguments reaching sensitive functions, and sensitive information being leaked. These are precisely the kinds of vulnerabilities for which code scanning traces data from a source to a potentially unsafe sink. GitHub does not automatically remove an unresolved alert merely because sixty days have elapsed. Likewise, webhooks and the code scanning API can expose alert events and enable integrations, but they do not automatically eliminate the vulnerability. Proper remediation requires fixing the affected code or intentionally dismissing an alert with an appropriate reason after security review. Therefore, A, B, and E describe the relevant security implications.

Validity checks , also called secret validation , allow GitHub to check if a detected secret is still active . If verified as live, the alert is marked as "valid" , allowing security teams to prioritize the most critical leaks.

Push protection blocks secrets but does not check their validity. Custom patterns are user-defined and do not include live checks.

A GitHub personal access token (PAT) is a credential and is therefore a type of value that secret scanning is designed to detect. GitHub supports patterns for GitHub-issued tokens and can generate secret scanning alerts when supported PAT formats are committed to repositories. GitHub also performs validity checks for certain GitHub tokens and can distinguish active from inactive credentials. SQL injection, cross-site scripting, and server-side request forgery are application vulnerabilities rather than exposed credentials; those issues are detected through code scanning tools such as CodeQL. The distinction is important: secret scanning looks for credentials, API keys, passwords, tokens, and similar sensitive values, whereas code scanning analyzes source code for insecure programming patterns. Therefore, only the GitHub PAT belongs to secret scanning.

Dependabot security updates are automated pull requests triggered when GitHub detects a vulnerability in a dependency listed in your manifest or lockfile. These PRs upgrade the dependency to the minimum safe version that fixes the vulnerability.

This is separate from regular updates (which keep versions current even if not vulnerable).

The best proactive control is push protection . It scans for secrets during a git push and blocks the commit before it enters the repository.

Other options (like CODEOWNERS or security managers) help with oversight but do not prevent secret leaks.

Making a repo public would increase the risk, not reduce it.

Secrets committed and then deleted are still accessible in the repository’s Git history . To locate them, navigate to the Commits tab. GitHub's secret scanning can detect secrets in both current and historical commits, which is why remediation should also include revoking the secret , not just removing it from the latest code.

The best way to prioritize secret scanning alerts is to filter by active secrets — these are secrets GitHub has confirmed are still valid and could be exploited. This allows security teams to focus on high-risk exposures that require immediate attention.

Sorting by time or filtering by custom patterns won’t help with risk prioritization directly.

Comprehensive and Detailed Explanation:

For code scanning to be triggered on a specific branch, the branch must contain the appropriate workflow file, typically located in the .github/workflows directory. This YAML file defines the code scanning configuration and specifies the events that trigger the scan (e.g., push, pull_request).​

Without the workflow file in the branch, GitHub Actions will not execute the code scanning process for that branch. The repository's visibility (private or public), the status of secret scanning, or the activity level of developers do not directly influence the triggering of code scanning.​

If autobuild fails (which attempts to automatically detect how to build your project), you should disable it in your workflow and replace it with explicit build commands , using steps like run: make or run: ./gradlew build.

This ensures CodeQL can still extract and analyze the code correctly.

The correct selection is No policy. At the enterprise level, GitHub uses policy states to determine whether a setting is imposed on organizations or left under organization-level control. GitHub's enterprise administration schema defines NO_POLICY as meaning that no enterprise policy has been set for organizations. Consequently, the enterprise does not force the feature to be enabled or disabled, allowing organization owners to make the applicable decision within their own organization. By contrast, an Enabled or Disabled enterprise policy explicitly determines the state for organizations and therefore removes that discretion. “Enable all” is not the relevant policy state represented by this setting. This distinction is important in hierarchical GitHub governance because enterprise policies can either enforce behavior globally or deliberately delegate configuration to individual organizations.

By default , no repositories receive Dependabot alerts unless configuration is explicitly enabled. GitHub does not enable Dependabot alerts automatically for any repositories unless:

The feature is turned on manually

It's configured at the organization or enterprise level via security policies

This includes public, private, and enterprise-owned repositories — manual activation is required .

If a secret is intentionally used in a test environment and poses no real-world security risk , you may close the alert with the reason "used in tests" . This helps reduce noise and clarify that the alert was reviewed and accepted as non-critical.

Just being in a test file isn't enough unless its purpose is purely for testing .

In a query suite (a .qls file), the **query** key is used to specify the paths to one or more .ql files that should be included in the suite.

Example:

- query: path/to/query.ql

qls is the file format.

qlpack is used for packaging queries, not in suite syntax.

To create or modify a code scanning workflow file (typically under .github/workflows/codeql-analysis.yml), you must have Write access to the repository.

Write permission allows you to commit the workflow file, which is required to run or configure code scanning using GitHub Actions.

Known vulnerable dependencies detected in a repository are presented as Dependabot alerts. GitHub uses the dependency graph to determine which packages and versions the repository depends on and compares that information with vulnerability data from the GitHub Advisory Database. When a match is found, an alert appears in the repository's Security and quality area under Dependabot vulnerabilities. Each alert can provide the affected dependency, vulnerability details, severity, the affected manifest or lockfile, and a secure version when one is available. Secret scanning alerts relate to exposed credentials, while code scanning alerts represent vulnerabilities or coding errors in source code. Security advisories are vulnerability records and disclosure mechanisms rather than the repository-specific list of vulnerable dependencies.

The correct place to look is the SECURITY.md file. This file provides contributors and security researchers with instructions on how to responsibly report vulnerabilities. It may include contact methods, preferred communication channels (e.g., security team email), and disclosure guidelines.

This file is considered a GitHub best practice and, when present, activates a “Report a vulnerability” button in the repository’s Security tab.

All results from CodeQL analysis appear under the repository’s code scanning alerts tab. This section is part of the Security tab and provides a list of all current, fixed, and dismissed alerts found by CodeQL.

A CodeQL database is used internally during scanning but does not display results. Query packs contain rules, not results. Security advisories are for published vulnerabilities, not per-repo findings.

Comprehensive and Detailed Explanation:

Dependabot alerts are generated based on data from various sources:​

National Vulnerability Database (NVD): A comprehensive repository of known vulnerabilities, which GitHub integrates into its advisory database.​

GitHub Docs

Security Advisories Reported on GitHub: GitHub allows maintainers and security researchers to report and discuss vulnerabilities, which are then included in the advisory database.​

The dependency graph and manifest/lock files are tools used by GitHub to determine which dependencies are present in a repository but are not sources of vulnerability disclosures themselves.​

In a CodeQL query suite, the query filename constraint matches the final path component—that is, the filename of the query file itself. GitHub distinguishes this from query path, which matches the path to the query relative to the enclosing CodeQL pack. The tags contain and tags contain all constraints operate on values from the query's @tags metadata rather than its filesystem path. tags contain requires one of the specified strings to match a tag component, while tags contain all requires all specified strings to be represented. Therefore, when the objective is specifically to filter queries according to the last component of their file path, query filename is the appropriate CodeQL query-suite constraint.

Secret validation checks whether a secret found in your repository is still valid and active with the issuing provider (e.g., AWS, GitHub, Stripe). If a secret is confirmed to be active, the alert is marked as verified , which means it's considered a high-priority issue because it presents an immediate security risk.

This helps teams respond faster to valid, exploitable secrets rather than wasting time on expired or fake tokens.

Comprehensive and Detailed Explanation:

Dependency review is triggered by specific events in GitHub workflows:​

pull_request: When a pull request is opened, synchronized, or reopened, GitHub can analyze the changes in dependencies and provide a dependency review.​

workflow_dispatch: This manual trigger allows users to initiate workflows, including those that perform dependency reviews.​

The trigger and commit options are not recognized GitHub Actions events and would not initiate a dependency review.​