GH-500 - Configure and use Code Security - 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.

More in this domain

Back to all Configure and use Code Security objectives, or the GH-500 cert hub.

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