GH-500 Practice Questions

GitHub secret scanning is a native security feature that operates specifically on repositories hosted on the GitHub platform (GitHub.com and GitHub Enterprise). It automatically scans the entire Git history of all branches within a repository to find accidentally committed secrets, such as tokens and private keys. The scope of the scan is confined to the content of the GitHub repository itself, making it a repository-centric security tool.

A. Secret scanning is a GitHub feature that scans repository content, not the continuous integration system's infrastructure or configuration itself.

B. The feature is specific to repositories hosted on GitHub. It does not scan any arbitrary Git repository hosted on other platforms like GitLab or a private server.

D. Secret scanning finds credentials for external services that are located within a repository; it does not scan the external services themselves.

1. GitHub Docs

"About secret scanning." This document explicitly states

"Secret scanning scans your entire Git history on all branches present in your GitHub repository for secrets." This confirms the feature's scope is the GitHub repository.

Source: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning

Section: "About secret scanning."

2. Microsoft Learn

"Configure secret scanning

" GH-500 Learning Path. The official training material for the exam describes the feature's function: "GitHub scans repositories for known types of secrets to prevent fraudulent use of secrets that were committed by accident." The context is always a repository on GitHub.

Source: https://learn.microsoft.com/en-us/training/modules/configure-secret-scanning-in-your-repo/2-what-is-secret-scanning

Paragraph 1.

3. GitHub Docs

"Managing security and analysis settings for your repository." The configuration process for secret scanning is performed within the settings of a specific GitHub repository

reinforcing that its operational boundary is the repository.

Source: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-security-and-analysis-settings-for-your-repository

Section: "Allowing or disallowing features for your private repository."

You should dismiss a code scanning alert when you determine that the finding does not represent a security risk that needs to be fixed. A common and valid reason for dismissal is when the identified vulnerability exists in code that is exclusively used for testing purposes and is not part of the production application. Dismissing the alert in this context correctly triages the finding as a non-actionable item, allowing the team to focus on genuine threats in production code.

A. If you fix the code, the alert will be automatically closed on the next scan of the branch. Manual dismissal is not the correct procedure.

B. Dismissing an existing alert is a reactive measure for a specific finding; it does not proactively prevent developers from introducing new problems.

D. An alert corresponding to a production error signifies a real risk. This type of alert should be prioritized and fixed, not dismissed.

1. GitHub Docs

"Managing code scanning alerts for your repository." This official documentation states

"You can dismiss an alert if you don't think it's a problem... Common reasons for dismissing an alert are that the code is not used in production

or that the alert is a false positive result." This directly supports dismissing alerts for code used only in testing.

2. Microsoft Learn

"Configure and manage code scanning in your repository

" Unit: "Manage code scanning alerts." This module

relevant to GitHub administration

explains the process of triaging alerts. It notes that when dismissing an alert

you can select a reason

such as "Used in tests

" which confirms this is an intended use case for the dismissal feature.

3. GitHub Docs

"About code scanning alerts." This document clarifies the lifecycle of an alert

explaining that when code is fixed

"the alert is closed" automatically after the branch is rescanned. This confirms that manual dismissal is incorrect for fixed code.

The "used in tests" dismissal reason for a secret scanning alert is appropriate only when the detected string is a mock or example credential created exclusively for testing purposes. The defining characteristic is the secret's intended use and scope—it must have no value or access rights outside of a controlled test environment. The location of the secret (e.g., in a test file) is a contributing factor but not the sole determinant. The crucial point is that the secret itself is not a real, active credential for any environment, including development or staging.

A. A secret in a readme.md file is a severe documentation exposure and should be remediated, not dismissed as a test case.

B. A real, high-value secret can be accidentally committed to a test file; its location does not automatically make it safe or intended for tests.

D. A secret for a non-production environment (e.g., staging, QA) is still a valid credential that poses a security risk and should be remediated.

1. GitHub Docs. "Managing alerts from secret scanning." GitHub Enterprise Cloud Documentation. Accessed October 2023. In the section "Dismissing a secret scanning alert

" the documentation specifies the reasons for closing an alert. The "Used in tests" option is described for cases where "The secret is only used in tests

" confirming that the secret's purpose

not just its location

is the deciding factor.

Dependabot alerts are powered by the GitHub Advisory Database. When a vulnerability is identified, the resulting alert uses standardized formats to describe it. The Common Vulnerabilities and Exposures (CVE) system provides a unique identifier for each specific, publicly known cybersecurity vulnerability. Additionally, the Common Weakness Enumeration (CWE) is used to classify the type of software or hardware weakness that led to the vulnerability (e.g., CWE-79 for Cross-site Scripting). Both formats are integral to the information presented in a Dependabot alert, providing both a unique ID and a categorical description.

B. Exploit Prediction Scoring System (EPSS): This is a scoring system that estimates the probability of a vulnerability being exploited. It provides a metric for prioritization, not a format for describing the vulnerability itself.

D. Vulnerability Exploitability eXchange (VEX): VEX is a format used to communicate the status of a vulnerability within a specific product (e.g., "not affected"), rather than describing the initial vulnerability alert.

1. GitHub Docs

"About the GitHub Advisory Database": This document explicitly states

"Each security advisory includes information about the vulnerability

which may include... a CVE (Common Vulnerabilities and Exposures) identifier... and one or more Common Weakness Enumeration (CWE) identifiers." This directly confirms the use of both CVE and CWE.

Source: GitHub

Inc. (2024). About the GitHub Advisory Database. GitHub Docs. Retrieved from https://docs.github.com/en/code-security/security-advisories/global-security-advisories/about-the-github-advisory-database (See the section "About security advisories").

2. GitHub Docs

"About Dependabot alerts": This page clarifies that Dependabot alerts are based on vulnerabilities from the GitHub Advisory Database

which uses CVE identifiers.

Source: GitHub

Inc. (2024). About Dependabot alerts. GitHub Docs. Retrieved from https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts (See the section "Detection of insecure dependencies").

To prevent a GitHub Actions workflow from running on a pull request when only specific file types are changed, you use the paths-ignore filter. This key is nested under the event trigger, in this case, pullrequest. The paths-ignore key accepts a list of file path patterns. The workflow will not run if all changed files in the pull request match at least one of the patterns in this list. The options '/.md' and '/.txt' specify patterns to ignore markdown and text files in the root directory, respectively.

C. paths: This key is used to include paths. The workflow would only run if changes occurred in the specified paths, which is the opposite of the desired behavior.

E. - 'docs/.md': This pattern is too specific. It would only ignore markdown files within the docs directory, failing to meet the requirement to ignore any markdown file.

1. GitHub Docs

"Workflow syntax for GitHub Actions": Under the section on..paths-ignore

the documentation states: "When you use paths-ignore

the workflow will not run if the only changed files match at least one of the paths-ignore patterns." This confirms the use of paths-ignore to exclude file patterns from triggering a workflow. The examples provided show the list format using hyphens (-).

Reference Location: on > on.. > on..paths-ignore

2. GitHub Docs

"Events that trigger workflows": In the section for the pullrequest event

the documentation details the available filters

including branches

paths

and paths-ignore. It clarifies that paths and paths-ignore are mutually exclusive and cannot be used in the same trigger configuration.

Reference Location: Events that trigger workflows > pullrequest > Using filters

GitHub Advanced Security (GHAS) is a suite of security features. The question specifically asks about three of its core components:

1. Code scanning analyzes your code to find security vulnerabilities and coding errors.

2. Secret scanning detects secrets, such as API keys and tokens, that have been checked into the repository.

3. Dependency review allows you to visualize dependency changes and their security impact directly within a pull request, helping you understand the full effect before merging.

Option A accurately summarizes the primary function of each of these three distinct features.

B. This describes private vulnerability reporting, a feature that allows security researchers to disclose vulnerabilities to repository maintainers confidentially, which is separate from the listed GHAS tools.

C. This describes Dependabot alerts, which notify you about existing dependencies with known vulnerabilities in your repository, but it doesn't cover code scanning or secret scanning.

D. This describes Dependabot security and version updates, which automatically create pull requests to update dependencies, a different function from the three features mentioned in the question.

1. GitHub Docs

"About GitHub Advanced Security." This document provides an overview

stating

"GitHub Advanced Security features are available for enterprise accounts on GitHub Enterprise Cloud and GitHub Enterprise Server... [It] provides additional features... such as code scanning

secret scanning

and dependency review."

Source: https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security

2. GitHub Docs

"About code scanning." Section: "About code scanning." It states

"Code scanning is a feature that you use to analyze the code in a GitHub repository to find security vulnerabilities and coding errors."

Source: https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning

3. GitHub Docs

"About secret scanning." Section: "About secret scanning." It explains

"Secret scanning helps protect you by searching repositories for known types of secrets... GitHub scans the content for secrets."

Source: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning

4. GitHub Docs

"About dependency review." Section: "What is dependency review?" It details

"Dependency review helps you understand dependency changes and the security impact of these changes at every pull request... You can clearly see what's changed in a pull request."

Source: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review

Dependency review is a security feature specifically designed to operate within the pull request workflow. It automatically scans for changes in dependency manifest files and lock files. When a pull request introduces a new or updated dependency, dependency review checks it against the GitHub Advisory Database. If a vulnerability is found, it is flagged directly in the "Files changed" tab of the pull request, allowing reviewers to identify and address potential security risks before the code is merged into the main branch.

A. Dependency graph provides a repository-level summary of all dependencies; it does not function as a review tool within a specific pull request's changes.

C. Dependabot alerts notify you of existing vulnerabilities in your repository's default branch, rather than proactively showing vulnerabilities introduced in a pending pull request.

D. The repository's Security tab is a centralized dashboard for viewing security alerts and configurations, not the specific feature that reviews dependency changes in a pull request.

1. GitHub Docs

"About dependency review." This document states

"Dependency review helps you understand dependency changes and the security impact of these changes at every pull request. It provides an easily understandable visualization of dependency changes with a rich diff on the 'Files Changed' tab of a pull request." (Source: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review

Section: "What is dependency review?")

2. GitHub Docs

"Reviewing dependency changes in a pull request." This guide details the process: "The dependency review for a pull request shows... which dependencies have known vulnerabilities... You can find the dependency review on the Files changed tab of a pull request." (Source: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/reviewing-dependency-changes-in-a-pull-request

Section: "About the dependency review")

Code scanning is a static analysis security testing (SAST) feature within GitHub that analyzes the code in a repository to find security vulnerabilities and coding errors. It uses engines, most notably CodeQL, to run queries against a database representation of the code. The results are displayed as alerts in the repository's "Security" tab, allowing developers to triage and fix potential issues before they reach production. This process is typically automated to run on events like pushes or pull requests.

A. Code scanning finds and reports vulnerabilities; it does not automatically contact maintainers to request the creation of security advisories. This is a separate, manual action taken by repository maintainers.

B. Code scanning runs as a check on pull requests or after a push, it does not function as a pre-receive hook to block the push itself. It can prevent a merge, but not the initial push.

D. This describes secret scanning, a distinct GitHub Advanced Security feature that searches a repository's history for exposed credentials like tokens and private keys, not code vulnerabilities.

1. GitHub Docs

"About code scanning." This document states

"Code scanning is a feature that you use to analyze the code in a GitHub repository to find security vulnerabilities and coding errors... The results are shown as code scanning alerts in your repository." This directly supports option C as the primary function.

2. GitHub Docs

"About secret scanning." This source clarifies the function described in option D: "GitHub scans repositories for known types of secrets

to prevent fraudulent use of secrets that were committed accidentally." This distinguishes it from code scanning.

3. GitHub Docs

"About GitHub Security Advisories for repositories." This page details the manual process for creating security advisories

stating

"Repository maintainers can create a security advisory to privately discuss and fix a vulnerability in their repository." This confirms that the action in option A is a separate

non-automated process.

4. GitHub Docs

"Configuring code scanning." The documentation on triggering code scanning shows it is configured to run on events like on: push or on: pullrequest within a GitHub Actions workflow

which is a post-commit/post-push mechanism

invalidating the pre-receive hook claim in option B.

A Dependabot alert is automatically closed when the vulnerability that triggered it is resolved. The standard resolution process involves updating the insecure dependency to a secure version. This is typically accomplished by creating a pull request with the necessary changes to the manifest or lock file. Once this pull request is reviewed, approved, and merged into the default branch, GitHub automatically rescans the repository's dependencies. Upon confirming that the vulnerable dependency has been updated, GitHub closes the alert.

B. Viewing an alert is a passive, informational action. It does not change the repository's code or dependencies, and therefore does not resolve the vulnerability.

C. The dependency graph is a tool for visualizing dependencies. Simply viewing it does not alter the repository's state or fix any security issues.

D. Leaving the repository in its current state means the vulnerability persists. The Dependabot alert will remain open until the issue is addressed or manually dismissed.

1. GitHub Docs

"Viewing and updating Dependabot alerts." Under the section "Fixing a Dependabot alert

" the documentation states: "When you merge a pull request that updates the manifest or lock file to a secure version of the dependency

the alert is resolved for your repository. Dependabot automatically closes the alert when it detects that the vulnerable dependency has been removed or updated." This directly supports that merging a pull request to fix the vulnerability closes the alert.

When defining a custom pattern for GitHub secret scanning, two fields are mandatory for its creation. You must provide a unique Name to identify and manage the pattern. You must also define the Secret format using a regular expression (regex). This regex is the core of the pattern, specifying the structure of the secret that the scanning engine will search for. These two components are the minimum required details to save a new custom pattern at the organization or enterprise level.

C. A list of repositories to scan

Specifying repositories is part of enabling or configuring a scan, not defining the pattern itself.

D. Additional match requirements for the secret format

These are optional settings, such as "surrounding content," used to refine the main pattern and reduce false positives, not a mandatory creation detail.

1. GitHub Docs

"Defining custom patterns for secret scanning." This official documentation outlines the steps for creating a custom pattern. In the section "Creating a custom pattern

" it explicitly lists "Name" and "Secret format (regex)" as required fields. It also describes "Additional match requirements" as an optional step to refine results. The process described does not include selecting repositories during pattern creation.

Reference Location: Navigate to the "Creating a custom pattern" section. The input fields in the UI steps clearly distinguish between required and optional information.

2. GitHub Docs

"About secret scanning." This document provides an overview of the feature and distinguishes between defining patterns and enabling them for repositories. It clarifies that patterns are defined at the organization/enterprise level before being applied to specific repositories or all repositories.

Reference Location: See the section on "Defining custom patterns for secret scanning."