GH-500 GitHub Advanced Security Exam Questions and Answers

After generating an alert for a vulnerable dependency, Dependabot automatically attempts to create a pull request to upgrade that dependency to the minimum required secure version—if a fix is available and compatible with your project.

This automated PR helps teams fix vulnerabilities quickly with minimal manual intervention. You can also configure update behaviors using dependabot.yml, but in the default state, PR creation is automatic.

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.

Comprehensive and Detailed Explanation:

When GitHub identifies a vulnerable dependency in a repository with Dependabot alerts enabled, it performs the following actions:​

Generates a Dependabot alert: The alert is displayed on the repository's Security tab, providing details about the vulnerability and affected dependency.​

Notifies repository maintainers: By default, GitHub notifies users with write, maintain, or admin permissions about new Dependabot alerts.​

GitHub Docs

These actions ensure that responsible parties are informed promptly to address the vulnerability.​

Comprehensive and Detailed Explanation:

In the advanced setup for CodeQL code scanning, GitHub generates a workflow file named codeql-analysis.yml. This file is located in the .github/workflows directory of your repository. It defines the configuration for the CodeQL analysis, including the languages to analyze, the events that trigger the analysis, and the steps to perform during the workflow.​

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.

When you identify that a code scanning alert is a false positive—such as when your code uses a custom sanitization method not recognized by the analysis—you should dismiss the alert with the reason "false positive." This action helps improve the accuracy of future analyses and maintains the relevance of your security alerts.​

As per GitHub's documentation:​

"If you dismiss a CodeQL alert as a false positive result, for example because the code uses a sanitization library that isn't supported, consider contributing to the CodeQL repository and improving the analysis."​

By dismissing the alert appropriately, you ensure that your codebase's security alerts remain actionable and relevant.

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.

When multiple instances of the same secret value appear in a repository, only one alert is generated. Secret scanning works by identifying exposed credentials and token patterns, and it groups identical matches into a single alert to reduce noise and avoid duplication.

This makes triaging easier and helps teams focus on remediating the actual exposed credential rather than reviewing multiple redundant alerts.

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.

You must enable secret scanning before defining custom patterns. Secret scanning provides the foundational capability for detecting exposed credentials, and custom patterns build upon that by allowing organizations to specify their own regex-based patterns for secrets unique to their environment.

Without enabling secret scanning, GitHub will not process or apply custom patterns.

GitHub automatically closes a code scanning alert when the vulnerable code is fixed in the same branch where the alert was generated, usually via a commit inside a pull request. Simply clicking or triaging an alert does not resolve it. The alert is re-evaluated after each push to the branch, and if the issue no longer exists, it is marked as resolved.

When using a SARIF-compatible tool within GitHub Actions, it's necessary to explicitly add a step in your workflow to upload the analysis results. This is typically done using the upload-sarif action, which takes the SARIF file generated by your tool and uploads it to GitHub for processing and display in the Security tab. Without this step, the results won't be available in GitHub's code scanning interface.​

Requesting a CVE ID for a security advisory in a GitHub repository requires Admin permissions. This level of access is necessary because it involves managing sensitive security information and coordinating with external entities to assign a CVE, which is a formal process that can impact the public perception and security posture of the project.​

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.

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

In a workflow: GitHub Actions workflows are the most common place for CodeQL code scanning. The codeql-analysis.yml defines how the analysis runs and when it triggers.

In an external CI system: GitHub allows you to run CodeQL analysis outside of GitHub Actions. Once complete, the results can be uploaded using the upload-sarif action to make alerts visible in the repository.

You cannot run or trigger analysis from third-party repositories directly, and the Files changed tab in pull requests only shows diff — not analysis results.

By default, users with Write, Maintain, or Admin permissions will receive notifications for new Dependabot alerts. However, Write permission is the minimum level needed to be automatically notified. Users with only Read access do not receive alerts unless added explicitly.

Comprehensive and Detailed Explanation:

To receive Dependabot alert notifications for a repository, you can utilize the following Watch settings:

Custom setting: Allows you to tailor your notifications, enabling you to subscribe specifically to security alerts, including those from Dependabot.​

All Activity setting: Subscribes you to all notifications for the repository, encompassing issues, pull requests, and security alerts like those from Dependabot.​

The Participating and @mentions setting limits notifications to conversations you're directly involved in or mentioned, which may not include security alerts. The Ignore setting unsubscribes you from all notifications, including critical security alerts.​

GitHub Docs

+1

GitHub Docs

+1

Comprehensive and Detailed Explanation:

Before defining a custom pattern for secret scanning in a repository, you must enable secret scanning for that repository. Secret scanning must be active to utilize custom patterns, which allow you to define specific formats (using regular expressions) for secrets unique to your organization.​

Once secret scanning is enabled, you can add custom patterns to detect and prevent the exposure of sensitive information tailored to your needs.​