GH-500 Questions and Answers

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.

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.

For compiled languages, CodeQL performs extraction by monitoring the normal build process. This means it watches your usual build commands (like make, javac, or dotnet build) and extracts the relevant data from the actual build steps being executed. CodeQL uses this information to construct a semantic database of the application.

This approach ensures that CodeQL captures a precise, real-world representation of the code and its behavior as it is compiled, including platform-specific configurations or conditional logic used during build.

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.​

The first step when you receive a secret scanning alert is to revoke the secret if it is still valid. This ensures the secret can no longer be used maliciously. Only after revoking it should you proceed to remove it from the code history and apply other mitigation steps.

Simply deleting the secret from the code does not remove the risk if it hasn’t been revoked — especially since it may already be exposed in commit history.

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.

A Dependabot alert is only marked as resolved when the related vulnerability is no longer present in your code — specifically after you merge a pull request that updates the vulnerable dependency.

Simply viewing alerts or graphs does not affect their status. Ignoring the alert by leaving the repo unchanged keeps the vulnerability active and unresolved.

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:

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.​

When dealing with a data flow issue in a code scanning alert, clicking on "Show paths" provides a detailed view of the data's journey through the code. This includes the source of the data, the path it takes, and where it ends up (the sink). This information is crucial for understanding how untrusted data might reach sensitive parts of your application and helps in identifying where to implement proper validation or sanitization.​

The security-extended query suite includes additional CodeQL queries that detect lower severity issues than those in the default security-and-quality suite.

It’s often used when projects want broader visibility into code hygiene and potential weak spots beyond critical vulnerabilities.

The other options listed are paths to language packs, not query suites themselves.

A security policy is defined by a SECURITY.md file in the root of your repository or .github/ directory. This file informs contributors and security researchers about how to responsibly report vulnerabilities. It improves your project’s transparency and ensures timely communication and mitigation of any reported issues.

Adding this file also enables a “Report a vulnerability” button in the repository’s Security tab.

Comprehensive and Detailed Explanation:

Secret scanning push protection is a proactive feature that scans for secrets in your code during the push process. If a secret is detected, the push is blocked, preventing the secret from being added to the repository. This helps prevent accidental exposure of sensitive information.​

GitHub Docs

Dependabot alerts utilize standardized identifiers to describe vulnerabilities:​

CVE (Common Vulnerabilities and Exposures): A widely recognized identifier for publicly known cybersecurity vulnerabilities.​

CWE (Common Weakness Enumeration): A category system for software weaknesses and vulnerabilities.​

These identifiers help developers understand the nature of the vulnerabilities and facilitate the search for more information or remediation strategies.​

Dependency review runs as part of a pull request and shows which dependencies are being added, removed, or changed — and highlights vulnerabilities associated with any added packages.

It works in real-time and is specifically designed for use during pull request workflows.

The dependency graph is an overview, Dependabot alerts notify post-merge, and the Security tab shows the aggregated alert list.

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.​

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