GH-500 - Configure and use Code Security (14% of the exam) - Section 4.3

Review code scanning results including dataflow analysis, manage alert lifecycles, autofix, dismissals, severity, and category classifications.

Review code scanning alerts including data flow analysis traces to understand how tainted input reaches a vulnerable sink. Manage alert lifecycles by applying autofix suggestions, adjusting severity classifications, and selecting accurate dismissal reasons for false positives.

code scanning alertsdata flow analysisautofixseveritydismiss alert

Practice question for this objective

Free sampleConfigure and use Code Securitymedium

A developer opens a CodeQL code scanning alert for a path traversal finding. The alert's data flow view traces a value from a request parameter, through a helper that concatenates it into a file path, into a file-read call. The team wants to remediate at the point that genuinely breaks the vulnerability rather than just quieting the alert. Reading the alert's data flow path, where should the fix be applied to resolve the finding correctly?

// source
const name = req.query.file;
// step (helper)
const path = join(BASE_DIR, name);
// sink
return fs.readFileSync(path);
  • AAt the source, by renaming the request parameter so the variable no longer matches the name CodeQL keys its taint tracking on.
  • BBetween the source and the sink, by validating or canonicalising the value so the data reaching the file-read call is no longer attacker-controlled. Correct
  • CAt the sink only, by wrapping the file-read in a try-catch so any traversal attempt is caught at runtime.
  • DOutside the path, by adding an inline CodeQL suppression comment above the source line so the query stops reporting it.
Use a code scanning alert's data flow path to place a sanitiser between source and sink, breaking taint flow rather than masking the symptom. CodeQL data flow analysis reports a path from a tainted source to a vulnerable sink. The finding is genuinely resolved by introducing a sanitiser or validation barrier on that path, which stops the untrusted value from reaching the sink. Renaming variables, catching exceptions at the sink, or suppressing the result leaves the underlying data flow intact and the vulnerability exploitable.

Why A is wrong: Renaming a variable changes a label, not the flow of untrusted data, so the tainted value still reaches the sink. CodeQL taint tracking follows values through assignments regardless of identifier names, so this neither sanitises the input nor fixes the vulnerability.

Why B is correct: The alert's data flow path shows untrusted input reaching a file-read sink, and inserting a barrier such as canonicalisation or an allow-list check on the path breaks the taint flow before the sink. Once CodeQL sees a sanitiser on the path, the source no longer reaches the sink and the alert is genuinely resolved.

Why C is wrong: A try-catch handles exceptions after a read is attempted, but the tainted path still flows into the call and the file is still opened, so the traversal is not prevented. Exception handling is tempting because it touches the sink, yet it does not interrupt the data flow CodeQL reports.

Why D is wrong: An inline suppression hides the result without changing the dangerous data flow, leaving the path traversal exploitable. Suppression is appropriate only for genuine false positives, not for an alert whose data flow is real and confirmed.

See more GH-500 practice questions, answers explained.

Exam traps in Configure and use Code Security

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-500 bank for this domain.

  • "Used in tests", because the escaping behaviour is exercised by the framework's own test suite rather than the application code.

    Why it is wrong: "Used in tests" applies to findings in code that only runs during testing, not to a production rendering path that is genuinely safe. The framework having tests is irrelevant to why this specific alert is not exploitable.

  • It leaves the alert in the fixed state and ignores the recurrence, because an alert resolved once is not evaluated again on that branch.

    Why it is wrong: Code scanning re-evaluates the branch on each analysis rather than freezing resolved alerts, so a recurrence is not ignored. Assuming a fixed alert is permanently closed misunderstands that analyses run continuously.

  • Code scanning set the alert to "Dismissed" with the reason "Used in tests" because the refactor moved the affected code into a path the analysis treats as test-only.

    Why it is wrong: "Dismissed" is a human decision that requires choosing a reason, and "Used in tests" is one such reason; the analysis cannot apply a dismissal reason on its own, so this misreads the automatic resolution.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.