Security operations: best practices, prioritization, and remediation — GH-500 Practice Quiz

Question 1

Your security team wants to automatically dismiss Dependabot alerts for a category of vulnerabilities that leadership has formally accepted as low-risk in your environment. Regulators later require proof that each dismissal was intentional, attributable, and reviewable. Which combination of practices BEST satisfies both the operational goal and the auditability requirement?

Accepted Answer

Configure Dependabot auto-triage rules to dismiss the matching alerts, and rely on the rule definition plus the auto-generated audit log entries as the documented, attributable record of each dismissal.

Answer

Manually dismiss each alert one at a time with a free-text comment, because only human action produces a defensible audit trail.

Answer

Delete the affected dependencies from the dependency graph so the alerts no longer appear, eliminating the need for dismissal records.

Answer

Disable Dependabot alerts entirely for the repositories in scope so the low-risk category is never reported.

Question 2

A security manager at a fintech company is closing out a large backlog of Code Scanning alerts across 40 repositories. Several hundred alerts share the same CWE and originate from a deprecated internal library that is being fully removed next sprint. Leadership requires that any mass dismissal leave a clear, auditable record explaining the business justification, and that the alerts do NOT silently reappear if the deprecated code is temporarily reintroduced during the migration. Which approach best satisfies both the scale and the governance requirements?

Accepted Answer

Use bulk alert management to dismiss the matching alerts with the reason 'Won't fix' and include a documented dismissal comment describing the deprecation and migration plan.

Answer

Delete the affected repositories' CodeQL workflow files so the analysis stops running and the alerts disappear from Security Overview.

Answer

Add the deprecated library's file paths to a paths-ignore filter in each workflow so the alerts are excluded from future scans without any dismissal record.

Answer

Bulk dismiss the alerts with the reason 'False positive' since the code is scheduled for removal and therefore no longer represents a real risk.

Question 3

A security lead at a large organization wants to launch a security campaign to drive down the most impactful code scanning alerts across dozens of repositories. Leadership has directed the team to focus first on alerts that are both easiest to attribute to a responsible engineer and most likely to be actively dangerous in production. Which approach best aligns campaign scope with these priorities?

Accepted Answer

Create a campaign filtered to critical- and high-severity alerts that appear on the default branch and reside in code with recent commit activity, so ownership can be traced and exposure is real

Answer

Create a campaign that includes every open alert regardless of severity or branch, so no potential issue is missed during the remediation push

Answer

Create a campaign filtered only to alerts on feature branches, since those represent in-progress work that developers are already focused on

Answer

Create a campaign scoped to low- and medium-severity alerts first, because they are more numerous and clearing them shows faster backlog reduction

Question 4

A security manager at a large organization launches a security campaign targeting 340 high-severity SQL injection alerts spread across 60 repositories. She wants to hold each development team accountable by giving them a shared context, a due date, and direct visibility into which alerts they own, so progress can be tracked centrally in Security Overview. Which combination of campaign configuration steps best achieves this goal?

Accepted Answer

Create the campaign with a due date and a description providing remediation guidance, then assign alerts to specific team members or teams so ownership and progress are tracked in Security Overview.

Answer

Bulk-dismiss all 340 alerts with the reason 'won't fix' and open a tracking issue in each of the 60 repositories to coordinate the work manually.

Answer

Create a cross-repository ruleset that blocks all merges to default branches until every SQL injection alert is resolved, without setting a due date.

Answer

Export the alerts to a SARIF file, distribute it to team leads over email, and ask each team to self-report completion percentages weekly.

Question 5

A security engineer fixed a CodeQL SQL-injection alert three months ago; the alert moved to 'Fixed' after the default branch was rescanned. This week a developer reverted part of that refactor in a new commit, reintroducing the vulnerable data-flow pattern on the default branch. Assuming CodeQL analysis runs on pushes to the default branch, what happens to the alert tracking, and what is the recommended remediation practice?

Accepted Answer

CodeQL reopens the original alert (returning it to 'Open') when the vulnerable pattern reappears on the analyzed branch, so the team should treat the reopened alert as active work rather than filing a brand-new issue.

Answer

The alert stays permanently 'Fixed' once resolved; CodeQL only creates a separate new alert with no link to the prior one, so the engineer must manually cross-reference the history.

Answer

The alert can only be reopened manually by a security manager, because CodeQL never automatically transitions an alert out of the 'Fixed' state.

Answer

Because the code was previously fixed, CodeQL suppresses detection of the reintroduced pattern for 90 days and will not alert until the suppression window expires.

Question 6

A developer receives a CodeQL code scanning alert for a SQL injection vulnerability on the default branch. They create a feature branch, refactor the code to use parameterized queries, and open a pull request. After the PR's CodeQL analysis completes with no findings on the changed code, the developer wants to confirm the original alert will be properly closed. Which statement correctly describes what happens to the alert as it moves through the remediation workflow?

Accepted Answer

The alert on the default branch is automatically resolved as 'Fixed' only after the PR is merged and CodeQL runs on the default branch without detecting the vulnerability

Answer

The alert is automatically resolved as 'Fixed' the moment the PR's CodeQL analysis completes without findings, before the merge occurs

Answer

The developer must manually dismiss the alert with the reason 'Used in tests' once the PR is merged, since CodeQL cannot auto-close alerts

Answer

The alert remains open indefinitely until a security manager manually marks it as remediated in the security overview dashboard

Question 7

A security engineer at a fintech company is building a remediation runbook. She needs to document the correct end-to-end handling for two different alert types. For a Dependabot alert flagging a vulnerable transitive dependency (with a fix version available), the runbook must specify the primary remediation action that GitHub can automate. For a CodeQL alert flagging a SQL injection in first-party code, the runbook must specify who owns the fix. Which pairing correctly reflects how each remediation workflow operates?

Accepted Answer

The Dependabot alert is remediated by an auto-generated security update pull request bumping the dependency to the fixed version; the CodeQL alert requires a developer to change the application source code, as no dependency bump can resolve it.

Answer

Both alerts can be resolved automatically by Dependabot security update pull requests, since Dependabot patches both dependency and source-code vulnerabilities.

Answer

The Dependabot alert must be fixed by manually editing source code, while the CodeQL alert is remediated by an auto-generated pull request that upgrades the affected package.

Answer

Both alerts must be dismissed with a documented reason because GitHub does not provide any automated remediation for either alert type.

Question 8

A platform security team wants to enforce a consistent remediation SLA across 40 repositories: any open code scanning alert with a security severity of 'critical' or 'high' must block deployment to production, while medium and low alerts should only generate warnings. They also need the enforcement to survive when individual repository admins try to loosen their local branch protection settings. Which approach best meets these requirements at scale?

Accepted Answer

Create an organization-level code scanning ruleset that requires resolution of alerts at the critical and high security-severity levels and apply it to all 40 repositories, since org rulesets take precedence over repository-level configuration.

Answer

Ask each repository admin to add a branch protection rule requiring the CodeQL status check to pass, and document the SLA in a shared wiki for accountability.

Answer

Configure a Dependabot auto-triage rule set to snooze medium and low alerts and open pull requests for critical and high alerts across the organization.

Answer

Enable push protection at the organization level so that any commit introducing a critical or high alert is blocked before it reaches the default branch.

Question 9

A security engineer is triaging the code scanning alert backlog for a critical payment service. Two open CodeQL alerts compete for immediate attention: Alert 1 is tagged with a security-severity score of 9.1 (Critical) but has a low occurrence count, while Alert 2 shows a code-scanning severity of 'error' but carries no security-severity metadata because it comes from a code-quality query. The team's remediation ruleset gates merges based on security-severity thresholds. Which alert should the engineer prioritize for remediation first, and why?

Accepted Answer

Alert 1, because its security-severity score of 9.1 reflects exploitable vulnerability risk that the ruleset uses to gate merges, making it the higher security priority.

Answer

Alert 2, because a code-scanning severity of 'error' always outranks any security-severity score when both are present.

Answer

Alert 2, because alerts without security-severity metadata are treated as the most dangerous and are auto-escalated by the ruleset.

Answer

Alert 1, but only after manually assigning it a code-scanning severity of 'error' since security-severity alone cannot be used for prioritization.

Question 10

A large platform team shares a monorepo across three feature squads. A CodeQL scan surfaces a high-severity SQL injection alert in a module that all three squads modify. The security manager wants a single accountable owner to drive remediation while still allowing other engineers to comment, share findings, and track the discussion directly on the alert. Which approach best supports this collaboration model using native GitHub code scanning capabilities?

Accepted Answer

Assign the alert to a specific engineer and use the alert's comment thread so collaborators can discuss the finding while ownership stays clear.

Answer

Dismiss the alert as "used in tests" so it stops appearing, then coordinate the fix over email until the module is patched.

Answer

Create three separate issues, one per squad, and delete the code scanning alert to avoid duplicate tracking.

Answer

Convert the alert into a security advisory draft so the squads can collaborate privately before any fix is written.

Question 11

A security team runs a remediation campaign and wants accurate metrics on how many code scanning alerts were genuinely resolved through code changes versus those that were triaged away without a fix. During the campaign, engineers merge PRs that remove the vulnerable code paths, and reviewers also dismiss several alerts they judge to be false positives. When the security lead reviews the code scanning results after the next default-branch scan, how will these two categories of alerts be distinguished in the alert list?

Accepted Answer

Alerts whose underlying code was remediated automatically transition to a 'Fixed' state after a scan no longer detects them, while manually triaged alerts appear in a 'Closed' state with a 'Dismissed' reason.

Answer

Both remediated and dismissed alerts appear identically as 'Closed', so the team must rely on PR links to tell them apart.

Answer

Remediated alerts must be manually marked as 'Fixed' by a reviewer, since GitHub cannot detect that vulnerable code was removed.

Answer

Dismissed alerts are permanently deleted from the alert list, so only 'Fixed' alerts remain visible for reporting.

Question 12

Your security team has enabled push protection and pre-merge CodeQL analysis on a critical microservice repository. A developer opens a pull request from a feature branch, and CodeQL flags a new SQL injection alert in the PR check. The developer argues the alert should not block the merge because 'the code isn't on the default branch yet, so it's not a real exposure.' As the security lead defining the org's shift-left enforcement strategy, which response best reflects correct preventive security practice?

Accepted Answer

The pre-merge PR analysis is intentionally designed to catch vulnerabilities before they reach the default branch; the alert should be remediated on the feature branch before merge to prevent the flaw from ever entering protected code.

Answer

Since the code is not yet on the default branch, the alert can be safely dismissed as 'won't fix' and revisited only if it later appears in a default-branch scan.

Answer

Push protection already inspects source code for injection patterns, so the CodeQL PR alert is redundant and can be ignored.

Answer

PR-based CodeQL alerts are informational only and cannot be configured to block a merge, so remediation must wait until after the merge completes.

Question 13

A security architect at a fintech company wants CodeQL analysis to reflect the organization's elevated risk tolerance for injection and cryptographic weaknesses, while suppressing noisy maintainability-related alerts that developers routinely ignore. The team already runs default setup across 200 repositories but finds the standard query set produces too many low-value results and misses some deeper security patterns. Which approach best tailors detection to the organization's risk profile without abandoning centralized management?

Accepted Answer

Switch the affected repositories to advanced setup and configure a code scanning configuration file that runs the security-extended query suite, then use query filters to exclude the specific low-severity queries the team considers noise

Answer

Keep default setup but dismiss every low-value alert individually with the 'won't fix' reason so future scans stop reporting them

Answer

Disable CodeQL entirely on the 200 repositories and rely solely on Dependabot and secret scanning to reduce alert volume

Answer

Lower the severity threshold in branch protection so that only critical alerts block merges, leaving all other detection unchanged

Question 14

You are a security manager for an organization with 40 repositories. Leadership wants a consistent, enforced policy: any pull request that introduces a new code scanning alert of 'critical' or 'high' security severity must be blocked from merging across all repositories, without requiring each repository admin to configure branch protection individually. You also want the enforcement to apply automatically to newly created repositories. Which approach best satisfies these requirements?

Accepted Answer

Create an organization-level code scanning merge protection ruleset that blocks merges on critical and high severity alerts, and target it to all repositories including future ones

Answer

Ask each repository admin to add a required status check for CodeQL in their branch protection rules and set the failure threshold manually

Answer

Configure a custom CodeQL query suite that only emits critical and high alerts, then rely on the default setup to fail the workflow

Answer

Enable Dependabot security updates at the organization level so that high and critical findings are auto-remediated before merge

Question 15

A platform team maintains an internal npm package consumed by twelve product repositories across your organization. A newly published GHSA reveals a high-severity prototype-pollution flaw in a third-party dependency that the platform package pulls in transitively. Leadership wants a single, coordinated remediation effort that gives each product team visibility into their own affected repositories, tracks progress against a shared deadline, and avoids twelve independent, uncoordinated fixes. Which approach best meets these requirements using GitHub Advanced Security capabilities?

Accepted Answer

Create a security campaign at the organization level that groups the related Dependabot alerts across the affected repositories, assigns each repository's alerts to its owning team, and sets a shared remediation deadline.

Answer

Open a draft security advisory in each of the twelve product repositories and use the private fork to coordinate a fix independently in each one.

Answer

Configure a cross-suite ruleset that blocks all pull requests in the twelve repositories until the vulnerable dependency version is no longer present.

Answer

Enable Dependabot security updates on the platform package only and rely on transitive resolution to silently patch all twelve consumers without notifying the product teams.

Question 16

A platform security lead wants to enforce a single organization-wide policy that (1) blocks pull requests introducing code scanning alerts of 'high' security severity or above, and (2) prevents merges when Dependabot detects a 'critical' vulnerability in a new dependency. They want this enforced consistently across dozens of repositories without configuring each repo individually. Which GitHub capability best achieves this cross-suite enforcement from a single point of control?

Accepted Answer

Define organization rulesets (including code scanning merge protection rules) combined with an enterprise/org security configuration and the dependency review action gated on severity, applied across the targeted repositories

Answer

Configure branch protection rules manually in each repository, adding required status checks for CodeQL and dependency review

Answer

Create an organization-level security configuration and apply it to repositories, but rely on each developer to self-enforce severity thresholds

Answer

Add a single CodeQL workflow with a security-severity filter and rely on it to also block vulnerable dependency merges

Question 17

A security engineer is documenting the remediation workflow for a Dependabot alert. The alert references GHSA-abcd-1234-wxyz, which in turn maps to CVE-2024-99999 and is categorized under CWE-89. A junior teammate asks how these three identifiers relate to each other so the team can write accurate remediation notes. Which explanation correctly describes the relationship among GHSA, CVE, and CWE in this context?

Accepted Answer

The CWE identifies the class of weakness (SQL injection), the CVE identifies the specific publicly disclosed vulnerability instance, and the GHSA is GitHub's advisory record that curates the vulnerability with affected package/version data used to trigger the alert.

Answer

The GHSA is a numeric severity score, the CVE defines the patched version range, and the CWE is GitHub's internal ticket for tracking the fix across repositories.

Answer

The CVE is the broad weakness category, the CWE is the specific disclosed vulnerability, and the GHSA is the CVSS vector string attached to the alert.

Answer

All three are interchangeable identifiers issued by MITRE, and GitHub randomly selects one to display depending on the ecosystem of the affected package.

Question 18

You maintain a popular open-source library on GitHub. A security researcher privately reports a remote code execution vulnerability affecting your project. As the maintainer, you want to develop and test a fix collaboratively with a few trusted contributors before any details become public, then publish coordinated disclosure with a proper identifier. Which GitHub Security Advisory workflow best supports this goal?

Accepted Answer

Create a draft repository security advisory, use its temporary private fork to collaborate on the fix with selected collaborators, request a CVE identifier through GitHub, and publish the advisory when the patch is released.

Answer

Open a public issue describing the vulnerability so contributors can immediately begin working on a fix in the open, then file for a CVE after merging.

Answer

Push the fix directly to the default branch in a private commit and let Dependabot automatically generate and publish the advisory to the GitHub Advisory Database.

Answer

Create a custom secret scanning pattern to detect the vulnerable code path, then rely on push protection to block downstream consumers from using the affected version.

Question 19

Your organization's dependency scanning has raised several Dependabot alerts across multiple repositories, all linked to a single GitHub Security Advisory (GHSA). Three days later, a security engineer notices that the upstream advisory has been marked as 'Withdrawn' in the GitHub Advisory Database, with a note that the vulnerability report was determined to be invalid. Some teams have already started upgrading the dependency. What is the most appropriate remediation-workflow response?

Accepted Answer

Because the advisory was withdrawn, the associated Dependabot alerts will no longer be actionable; verify that GitHub auto-closes the alerts and communicate to teams that pending upgrades for this GHSA can be deprioritized.

Answer

Immediately dismiss every alert with the reason 'This alert is inaccurate or incorrect' and permanently disable Dependabot alerts for those repositories to prevent recurrence.

Answer

Continue forcing all teams to complete the dependency upgrade, since a withdrawn advisory still indicates a confirmed exploitable vulnerability that must be patched.

Answer

Open a new GitHub Security Advisory in each affected repository to override the withdrawn upstream advisory and re-trigger the alerts for tracking.

Question 20

A platform security engineer wants to strengthen preventive security so that newly introduced vulnerabilities in application code are caught before they reach the default branch. Developers currently rely on a nightly scheduled CodeQL scan that reports findings a day after merge. The team complains that vulnerabilities are only discovered once they are already in main, forcing costly follow-up remediation. Which change best shifts detection left for code-level vulnerabilities?

Accepted Answer

Configure CodeQL to run on pull_request events so analysis executes on the PR's merge commit and surfaces new alerts as required status checks before merge

Answer

Enable secret scanning push protection on the repository to block the PR when vulnerable code patterns are pushed

Answer

Increase the nightly scheduled scan to run every six hours so findings appear sooner after merge

Answer

Create a Dependabot security update rule so vulnerable code is patched automatically after it lands on main

More GH-500 practice