GH-500 GitHub Advanced Security Exam Questions and Answers

A code scanning alert provides information that helps a developer identify and understand the security problem detected by the analysis tool. GitHub specifically displays the line of code that triggered the alert, together with properties such as severity, security severity, the nature of the problem, and when the issue was introduced. CodeQL-generated alerts may additionally contain remediation guidance and data-flow information. Secret values are handled through secret scanning rather than being shown as the defining detail of a code scanning alert. GitHub also does not list all users with repository Read access within an individual alert, and a CWE submission date is not the primary alert-location information. The source-code location is therefore the correct answer.

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.

GitHub code scanning integrates with third-party static analysis tools through SARIF, the Static Analysis Results Interchange Format. A compatible analysis tool generates its findings as a SARIF file, which GitHub can process and display as code scanning alerts within the repository. GitHub supports SARIF output generated outside GitHub, including results from external CI/CD systems or security-analysis products. The results can then be uploaded to GitHub using an appropriate workflow action, API, or supported integration. YAML is commonly used for GitHub Actions workflow configuration but is not the interchange format for code scanning findings. ESLint is an analysis tool rather than a results-exchange specification, and ECMAScript defines JavaScript language standards. Therefore, SARIF is the required output format.

In a repository's Security tab, you can view:

Secret scanning alerts : Exposed credentials or tokens

Dependabot alerts : Vulnerable dependencies from the advisory database

Code scanning alerts : Vulnerabilities in code detected via static analysis (e.g., CodeQL)

You won’t see general "security status alerts" (not a formal category) or permission-related alerts here.

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:

To generate a dependency graph for a private repository, GitHub requires:​

Dependency graph enabled: The repository must have the dependency graph feature enabled. This can be configured at the organization level to apply to all new private repositories.​

Access to manifest and lock files: GitHub needs read-only access to the repository's dependency manifest and lock files (e.g., package.json, requirements.txt) to identify and map dependencies.​

Secret scanning is a feature provided by GitHub that scans the contents of your GitHub repositories for known types of secrets, such as API keys and tokens. It operates within the GitHub environment and does not scan external systems, services, or repositories outside of GitHub. Its primary function is to prevent the accidental exposure of sensitive information within your GitHub-hosted code.​

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

When secret scanning is enabled on a private repository, GitHub performs a read-only analysis of the repository's contents. This includes the entire Git history and files to identify strings that match known secret patterns or custom-defined patterns.

GitHub does not alter the repository, and enabling secret scanning does not automatically enable code scanning or dependency review — each must be configured separately.

By default, secret scanning is enabled automatically for all public repositories . For private or internal repositories, secret scanning must be enabled manually unless configured at the organization or enterprise level.

This default behavior helps protect open-source projects without requiring additional configuration.

GitHub identifies repository administrators as users who can enable Dependabot alerts for an individual repository. Organization owners can also enable the feature at organization scope, but they are not one of the options presented. Once enabled, Dependabot compares dependency information against vulnerability data from the GitHub Advisory Database and generates alerts when affected dependencies are found. Users with Maintain or Write access can view and work with alerts when permissions allow, but enabling or disabling repository security features requires repository administration privileges under the configuration model tested here. Outside collaborators do not automatically receive that level of administrative control, and “security analyst” is not a standard repository role granting feature-enablement authority. Therefore, repository administrator is the correct selection.

Comprehensive and Detailed Explanation:

In private repositories, users with write access can fix code scanning alerts. They can do this by committing changes that address the issues identified by the code scanning tools. This level of access ensures that only trusted contributors can modify the code to resolve potential security vulnerabilities.​

GitHub Docs

Users with read or triage roles do not have the necessary permissions to make code changes, and the security manager role is primarily focused on managing security settings rather than directly modifying code.​

Code scanning merge requirements and severity thresholds are repository configuration controls and are therefore managed from the repository's Settings area. In GitHub's current interface, administrators can create a branch ruleset under Settings and configure Require code scanning results. They can then select the code scanning tool and specify alert thresholds, including which normal alerts or security-severity levels should prevent merging. The Security and quality tab is primarily where security findings are reviewed and triaged, while the Actions tab displays workflow execution information. The Pull Requests tab is used to review and merge proposed changes rather than configure repository-wide code scanning policy. Thus, although GitHub's implementation has evolved toward ruleset-based merge protection, the appropriate top-level location remains the repository's Settings tab.

GitHub states that its repository security advisory form is a standardized form that matches the Common Vulnerabilities and Exposures (CVE) description format. GitHub Security Advisories build on the CVE ecosystem, and GitHub itself is a CVE Numbering Authority capable of assigning CVE identification numbers for eligible vulnerabilities. The advisory form captures structured information such as the vulnerability description, affected products, vulnerable and patched versions, severity, CWEs, references, and CVE information. A CNA is an organization authorized to assign CVEs rather than a separate advisory-description format. Dependabot alerts are generated for vulnerable dependencies and are unrelated to the structure of the security advisory form. Therefore, the CVE description format is the correct choice.

The config-file input is used with the github/codeql-action/init action to specify the path to a custom CodeQL configuration file. This configuration can define additional query packs, custom queries, directories to include or exclude, and other CodeQL analysis settings. GitHub's official workflow documentation shows config-file under the with: section of the CodeQL initialization step. The queries input is used to specify additional query suites or query packs directly, rather than referencing a configuration file. source-root and db-location are not the appropriate init inputs for supplying the configuration-file path. Therefore, when the CodeQL workflow must load settings from a separate YAML configuration file, config-file is the correct parameter.

To systematically analyze newly introduced source code for security weaknesses, you should configure code scanning. GitHub code scanning can use CodeQL or supported third-party analysis tools and can run automatically when developers push changes or create pull requests. This places vulnerability detection directly into the development workflow rather than depending on manual review. The extended CodeQL query suite broadens the set of queries executed, but it only has an effect after code scanning itself is configured. CODEOWNERS determines who reviews specific paths and does not perform vulnerability analysis. A security policy explains how vulnerabilities should be reported but does not scan source code. Therefore, enabling and properly configuring code scanning is the foundational mechanism for ensuring new code is automatically analyzed.

To change the threshold that defines whether a pull request fails due to code scanning alerts (such as blocking merges based on severity), the user must have Admin access on the repository. This is because modifying these settings falls under repository configuration privileges.

Users with Write, Maintain, or Triage roles do not have the required access to modify rulesets or status check policies.

GitHub requires you to perform a dry run before publishing a new secret scanning custom pattern. After defining the pattern and providing a sample test string, you select Save and dry run. GitHub searches the relevant repository data without creating secret scanning alerts and returns a sample of matching results. You should review these results for false positives, adjust the regular expression or additional match requirements if necessary, and repeat the dry run until the pattern behaves as intended. Only after a successful dry run and review should you publish the custom pattern. Push protection is optional and is enabled after the pattern has been published; GitHub explicitly notes that the option is not available until the dry run succeeds and the pattern is published.

When a vulnerability is detected, GitHub shows a warning that includes a brief description of the vulnerability . This typically covers the name of the CVE (if available), a short summary of the issue, severity level, and potential impact. The message also links to additional advisory data from the GitHub Advisory Database.

This helps developers understand the context and urgency of the vulnerability before applying the fix.

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 .

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.

Dependabot alerts are generated as soon as GitHub detects a known vulnerability in one of your dependencies. GitHub does this by analyzing your repository’s dependency graph and matching it against vulnerabilities listed in the GitHub Advisory Database. Once a match is found, the system raises an alert automatically without waiting for a PR or manual action.

This allows organizations to proactively mitigate vulnerabilities as early as possible, based on real-time detection.

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.

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.

Dependabot builds a dependency graph by analyzing package manifests and lockfiles in your repository. This graph includes both direct and transitive dependencies. It then compares this graph against the GitHub Advisory Database, which includes curated, security-reviewed advisories.

This method provides a comprehensive and automated way to discover all known vulnerabilities across your dependency tree.

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.

If an alert is raised on a pull request dependency , best practice is to update the dependency to a secure version before merging the PR. This prevents the vulnerable version from entering the main codebase.

Merging or deploying the PR without fixing the issue exposes your production environment to known risks.

When integrating CodeQL outside of GitHub Actions (e.g., in Jenkins, CircleCI):

Install the CLI : Needed to run CodeQL commands.

Analyze code : Perform the CodeQL analysis on your project with the CLI.

Upload scan results : Export the results in SARIF format and use GitHub’s API to upload them to your repo’s security tab.

You don’t need to write custom queries unless extending functionality. “Processing alerts” happens after GitHub receives the results.

To exclude .txt and .md files from triggering workflows on pull requests to the main branch:

on: defines the event (e.g., pull_request)

pull_request: is the trigger

paths-ignore: is the key used to ignore file patterns

Example YAML:

yaml

CopyEdit

on:

pull_request:

branches:

- main

paths-ignore:

- '*.md'

- '*.txt'

Using paths: would include only specific files instead — not exclude. paths-ignore: is correct here.

When a CodeQL workflow uses a language matrix, the autobuild step attempts to build each compiled language listed in that matrix. This differs from a workflow without a language matrix, where autobuild attempts to build the supported compiled language with the greatest number of source files in the repository. A matrix is therefore useful when a repository contains multiple languages that require separate CodeQL analysis jobs. GitHub's current CodeQL build documentation explicitly describes this matrix behavior. The analysis may use newer build modes such as none for some compiled languages, depending on language and configuration, but when the workflow specifically uses autobuild with a language matrix, each compiled language represented by that matrix is processed independently. Therefore, option D correctly describes the behavior.

Code scanning is a static analysis feature that examines your source code to identify security vulnerabilities and coding errors . It runs either on every push, pull request, or a scheduled time depending on the workflow configuration.

It does not automatically contact maintainers, scan full Git history, or block pushes unless explicitly configured to do so.

A custom CodeQL configuration file can be stored in an external repository and referenced by multiple repositories. This allows an organization to centralize query packs, additional queries, query filters, path exclusions, threat-model configuration, and other CodeQL settings rather than duplicating the same settings across many workflow files. GitHub explicitly documents centralized configuration as a benefit of external configuration files. A token may be required when an advanced-setup workflow retrieves a configuration file from a private external repository, but providing the token is not the purpose of the configuration file itself. Likewise, a configuration file does not automatically choose a package, and query packs do not inherently disable the default query suite. Default queries are disabled only when the appropriate configuration option is deliberately specified. Therefore, C is correct.

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.

Secret scanning for a private repository is enabled through the repository's security configuration/settings, currently located under Settings → Security and quality → Advanced Security. In current GitHub terminology, enabling Secret Protection enables secret scanning alerts for an eligible private or internal repository. Repository rulesets control policies such as branch protection, required checks, and merge conditions; they are not the primary mechanism for enabling secret scanning. GitHub also does not use a secret.yml file to activate the feature. Code scanning default setup configures CodeQL analysis and is separate from secret detection. Organization owners can additionally enable Secret Protection and secret-scanning capabilities at scale by applying security configurations to repositories. Consequently, the code security or Advanced Security settings area is the correct location, making A the correct answer.