Task 4.3: Analyze, triage, and remediate code scanning results

• AThe repository administrator chooses it for each alert when it is triaged

  Incorrect

  Security severity is computed per query, not chosen per alert.

• BIt is copied from the EPSS score of the most similar CVE in the Advisory Database

  Incorrect

  EPSS isn't used; security severity comes from CVSS.

• CIt is derived from how many times the query has fired across public repositories

  Incorrect

  Alert volume isn't part of the calculation.

• DIt is the 75th percentile CVSS score of the CVEs that share the query's CWE tags

  Correct

  That score is translated to Critical, High, Medium or Low.

When a security query is added to the default or extended suite, the CodeQL team finds the CVEs tagged with the query's CWEs, takes the 75th percentile of their CVSS scores and defines that as the query's security severity, shown as Critical, High, Medium or Low.

• AChange the check failure severities in the repository's code scanning settings

  Correct

  The severities that fail the check can be set for the repository.

• BSwitch the default setup query suite from Default to Extended so more findings count as high

  Incorrect

  A larger suite adds queries; it doesn't change which severities fail the check.

• CAdd medium to the dismissal reasons so medium alerts are treated as blocking

  Incorrect

  Dismissal reasons close alerts; they don't affect the check.

• DTurn on Copilot Autofix so that medium findings get fixes before merge

  Incorrect

  Autofix suggests changes; it doesn't decide whether the check fails.

If the code scanning results check finds problems with a severity of error, critical or high, it fails; lower severities are treated as warnings or notes and the check passes. You can override this in the repository settings by specifying the severities and security severities that cause a pull request check failure.

• ACritical, High, Medium, Low

  Incorrect

  Those are security severity levels for security alerts.

• BError, Warning, Note

  Correct

  All alerts have one of these severities.

• COpen, Closed

  Incorrect

  Those are states.

• DFixed, Dismissed

  Incorrect

  Those are resolutions.

All code scanning alerts have a severity of Error, Warning or Note. Security alerts from CodeQL also have a security severity of Critical, High, Medium or Low, which code scanning shows in preference.

• AAccepted risk, duplicate alert, out of scope

  Incorrect

  None of these is in the fixed list of code scanning dismissal reasons.

• BDeferred, low impact, needs triage

  Incorrect

  None of these is a code scanning dismissal reason either.

• CFalse positive, used in tests, won't fix

  Correct

  These are code scanning dismissal reasons.

• DFixed, reopened, closed

  Incorrect

  Those are alert states, not dismissal reasons.

When you dismiss a code scanning alert you choose a reason such as false positive, used in tests or won't fix, and can add a comment. The reason is recorded with the closed alert.

• AIt categorizes files by their paths

  Correct

  Labels such as Test are assigned from file paths.

• BA developer marks the file as test code

  Incorrect

  You can't categorize source files manually.

• CIt runs the tests to find out

  Incorrect

  Code scanning doesn't run tests.

• DIt reads labels from dependabot.yml

  Incorrect

  That file is for Dependabot.

GitHub assigns a category label (Generated, Test, Library or Documentation) to alerts that aren't found in application code, based on the file path. You can't manually categorize source files.

• AAs three separate alerts, one for each path

  Incorrect

  Related paths to the same vulnerability aren't split into separate alerts.

• BAs one alert for each function that handles the input

  Incorrect

  Alerts aren't created per function in the flow.

• CAs a single alert that groups the related paths

  Correct

  Code scanning groups related paths to one vulnerability under a single alert, so you see its full scope in one place.

• DAs one alert that keeps only the shortest path

  Incorrect

  The alert keeps the related paths together rather than dropping them.

When code scanning reports data-flow alerts, GitHub shows how data moves through the code. If the same vulnerability can be reached through several code paths, for example when several functions pass user input to the same unsafe operation, code scanning groups these related paths under a single alert rather than creating one alert per path.