Explanation:
Dependabot alerts are a feature of GitHub Advanced Security (GHAS), which requires an active GHAS license and explicit enablement for private repositories. For public repositories, Dependabot alerts are free. However, the key phrase here is "default code security settings have not been changed." The default setting for all repositories is that Dependabot alerts are disabled unless an administrator proactively enables them.

Correct Option:

C. None:
By default, Dependabot alerts are not automatically enabled for any repositories. For private/internal repos, an organization or enterprise admin must explicitly enable GitHub Advanced Security. For public repos, while the feature is free, it is still opt-in and must be enabled in the repository's security settings by someone with admin access. The default state is "off."

Incorrect Options:

A. Repositories owned by an enterprise account & D. Repositories owned by an organization:
These are scopes where features can be managed, but ownership alone does not enable Dependabot alerts. An administrator must explicitly enable the feature at the enterprise, organization, or repository level. The default setting is disabled.

B. Private repositories:
Dependabot alerts for private repositories are a paid feature (part of GHAS). They are never enabled by default. An organization owner must first purchase GHAS, then explicitly enable it for the organization or specific private repositories.

Reference:
GitHub documentation, "Enabling Dependabot alerts for vulnerable dependencies," states: "Dependabot alerts are disabled by default. Repository administrators and organization owners can enable Dependabot alerts." It further clarifies that for private repositories, the feature is available with GitHub Advanced Security, which must be enabled.

Explanation:
Dependabot's workflow involves both detection and remediation. After sending an alert about a vulnerable dependency, its next automated action is to attempt to fix the issue. If a secure version of the dependency is available, Dependabot will propose a direct update to resolve the vulnerability, minimizing the effort required from the development team.

Correct Option:

A. Creates a pull request to upgrade the vulnerable dependency to the minimum possible secure version.
This is Dependabot's standard, automated remediation behavior. When configured for security updates, it automatically opens a pull request that updates the vulnerable dependency to the lowest available non-vulnerable version (a security fix). This happens after the alert is generated.

Incorrect Options:

B. Scans repositories for vulnerable dependencies on a schedule and adds those files to a manifest:
Scanning is the initial detection step that triggers the alert, not a subsequent action. Dependabot does not "add files to a manifest"; it reads existing manifest files.

C. Constructs a graph of all the repository's dependencies and public dependents for the default branch:
While dependency graph creation is a related foundational service, it is a continuous background process, not a specific sequential action taken after an alert is sent.

D. Scans any push to all branches and generates an alert for each vulnerable repository:
This describes real-time scanning behavior, not a follow-up action. The phrase "for each vulnerable repository" is also incorrect; alerts are generated per vulnerable dependency within a repository.

Reference:
GitHub documentation, "About Dependabot security updates," explains the sequence: "When Dependabot identifies a vulnerable dependency... Dependabot creates a pull request to update the dependency to the minimum version that resolves the vulnerability."

Explanation:
Integrating CodeQL into a third-party CI system involves using the standalone CodeQL CLI tool. The core process requires installing the CLI, using it to analyze the code by creating a database and running queries, and then uploading the results back to GitHub so they appear as code scanning alerts in the repository's Security tab.

Correct Options:

B. Analyze code:
This is the primary function. Using the CLI, you run codeql database analyze on a previously created CodeQL database. This executes the queries against your code to find potential security issues, generating a SARIF results file.

C. Upload scan results:
After analysis, you must upload the resulting SARIF file to GitHub. This is done using the github/codeql-action/upload-sarif action (even within external CI) or via the Code Scanning REST API to make the results visible in the repository's Security tab.

D. Install the CLI:
This is the foundational first step. You must download and install the CodeQL CLI bundle on your third-party CI runner to have the codeql command available for database creation and analysis.

Incorrect Options:

A. Process alerts:
This is a step performed by GitHub after results are uploaded. The third-party CI system's job ends with uploading the SARIF file. GitHub then processes that file to create, deduplicate, and display the code scanning alerts. The CI system does not process alerts itself.

E. Write queries:
While advanced users can write custom queries, this is not a required step for basic integration. The integration uses the standard, pre-written security queries provided in the CodeQL query packs (codeql/-queries). Writing new queries is an optional, advanced activity.

Reference:
GitHub documentation, "Using CodeQL code scanning with your existing CI system," outlines the three-step process: 1. Install the CodeQL CLI on your runner, 2. Use the CLI to analyze the code, 3. Upload the results to GitHub using the upload action.

Explanation:
Custom patterns are a feature of GitHub's secret scanning service that allows you to detect secrets specific to your organization. Like all secret scanning features, the underlying service must be active and running on the repository for you to configure any of its extended capabilities, including custom patterns.

Correct Option:

D. Enable secret scanning:
This is the absolute prerequisite. Secret scanning (for push protection or scanning existing repositories) must be enabled for the repository, either at the repository, organization, or enterprise level. Without the base feature being active, the option to define custom patterns is unavailable.

Incorrect Options:

A. Change the repository visibility to Internal:
Repository visibility does not determine feature availability for secret scanning. Secret scanning is available for public repositories for free and for private/internal repositories with GitHub Advanced Security. Changing visibility is not a prerequisite for configuration.

B. Close other secret scanning alerts:
There is no requirement to resolve existing alerts before defining new custom patterns. These are independent functions; you can configure detection rules while having open alerts.

C. Specify additional match criteria:
This describes part of defining the custom pattern itself (e.g., specifying a confidence level or required prefix). It is a step you take after the prerequisite of enabling secret scanning has been met, not a prerequisite for enabling the feature.

Reference:
GitHub documentation, "Defining custom patterns for secret scanning," begins by stating: "To define custom patterns for a repository, you must be a repository administrator and secret scanning must be enabled for the repository." It lists enabling the feature as the first requirement.

Explanation:
The repository's Security tab is the centralized dashboard for GitHub Advanced Security (GHAS) findings and insights. It is designed to aggregate and display security-related data generated by automated analysis tools, providing a summary view of the repository's security posture based on active scans.

Correct Option:

A. Number of alerts per GHAS feature:
The Security tab provides an overview that shows counts of open alerts for each GHAS feature: Code scanning (from CodeQL), Dependabot alerts (for vulnerabilities), and Secret scanning. This allows maintainers to quickly see the volume and types of security issues.

Incorrect Options:

B. Two-factor authentication (2FA) options:
2FA is a user or organization account security setting, managed in user Settings or organization Settings. It is not a repository-level security finding and is not located in the repository's Security tab.

C. Access management:
This refers to configuring collaborator permissions and team access, which is managed via the repository's Settings > Collaborators and teams or at the organization level. It is an administrative control, not a security analysis result.

D. GHAS settings:
The settings to enable or configure GHAS features (like code scanning or secret scanning) are found in the repository's Settings > Security & analysis (or at the org/enterprise level). The Security tab is for viewing the output (alerts) of those features, not for changing their settings.

Reference:
GitHub documentation, "About the Security overview," states: "The security overview is a consolidated view of GitHub Advanced Security features... For each feature, the security overview shows how many alerts of each severity level are currently open." This confirms the tab displays alert counts per feature.

Explanation:
Secret scanning push protection is a preventive security feature. It acts as a real-time gatekeeper during the git push operation. Its primary function is to intercept commits containing detected secrets before they are written to the repository's history, thereby preventing the secret from being exposed in the first place.

Correct Option:

A. Commits that contain secrets are blocked before code is added to the repository.
This is the exact purpose of push protection. When a user attempts to push code containing a pattern that matches a supported secret (e.g., an API token), the push is blocked on the server side, and the user receives an error message with instructions on how to remove the secret.

Incorrect Options:

B. Secret scanning alerts must be closed before a branch can be merged into the repository.
This describes a potential branch protection rule or status check requirement based on existing secret scanning alerts, not the real-time blocking of the push event itself. Push protection happens earlier in the workflow.

C. Buttons for sensitive actions in the GitHub UI are disabled.
This is not a defined feature of secret scanning. It might loosely relate to administrative controls or sensitive action verification but is not "push protection."

D. Users need to reply to a 2FA challenge before any push events.
This describes two-factor authentication (2FA), which is a general account security measure to verify a user's identity. It is not specific to secret scanning and does not scan or block the content of the push for secrets.

Reference:
GitHub documentation, "About secret scanning push protection," states: "Push protection for secret scanning checks pushes for supported secrets... If a supported secret is found in any commit, we'll block the entire push."

Explanation:
Code scanning is a GitHub Advanced Security feature designed to perform static application security testing (SAST). It works by automatically analyzing the source code in a repository to identify patterns that represent potential security vulnerabilities or coding errors, providing developers with actionable alerts within their workflow.

Correct Option:

C. It analyzes a GitHub repository to find security vulnerabilities.
This is the core function. Code scanning (typically using CodeQL or third-party tools) statically analyzes code to identify security flaws such as injection vulnerabilities, exposure of sensitive data, and insecure dependencies based on predefined query suites.

Incorrect Options:

A. It contacts maintainers to ask them to create security advisories if a vulnerability is found:
This describes a potential manual follow-up process for a critical finding, not the automated function of code scanning itself. Code scanning generates alerts; it does not automatically contact maintainers to create advisories.

B. It prevents code pushes with vulnerabilities as a pre-receive hook:
This describes push protection, which is a feature of secret scanning, not code scanning. Code scanning analysis typically runs after code is pushed, often in a CI workflow, and can be configured to fail status checks on pull requests, but it does not act as a pre-receive hook blocking pushes.

D. It scans your entire Git history on branches present in your GitHub repository for any secrets:
This describes the function of secret scanning for historical repositories, which specifically looks for secret patterns. Code scanning analyzes code for security vulnerabilities, not for hardcoded secrets.

Reference:
GitHub documentation, "About code scanning," states: "Code scanning is a feature that you use to analyze the code in a GitHub repository to find security vulnerabilities and coding errors."

Explanation:
When reviewing a pull request, it's critical to understand if the proposed changes introduce new dependencies with known security vulnerabilities. GitHub provides a specific feature that integrates directly into the pull request interface to display this information, offering a proactive review mechanism before code is merged.

Correct Option:

B. Dependency review:
This is a feature that checks dependency changes in pull requests. It displays a diff view showing any added or updated dependencies and highlights if any of the new versions have known vulnerabilities, helping reviewers block risky introductions.

Incorrect Options:

A. Dependency graph:
This is a navigable, visual representation of a repository's dependencies found on the repository's Insights tab. It is a monitoring and exploration tool, not a feature that shows vulnerability information within a pull request interface.

C. Dependabot alert:
This is a notification of a vulnerable dependency already present in the default branch of the repository, viewable in the Security tab. It is a reactive alert for existing code, not a proactive check within a pull request.

D. The repository's Security tab:
This is the central dashboard for viewing all security alerts (code scanning, Dependabot, secret scanning) for the repository's default branch. It does not provide a focused view of vulnerabilities introduced by a specific, unmerged pull request.

Reference:
GitHub documentation, "About dependency review," states: "Dependency review lets you understand dependency changes and the security impact of these changes at every pull request." It explicitly describes it as a feature that shows vulnerable dependencies in pull requests.