How do you handle false positives and finding fatigue with GitLeaks?
Quick Answer
Triage by exploitability rather than raw severity, use the tool's native suppression mechanism with a reason and an expiry, baseline existing findings so new code is held to a higher bar, and review suppressions periodically.
Detailed Answer
Every scanner produces findings that are not real risks in context — an unreachable code path, a vulnerable function the app never calls, a test fixture that looks like a credential. Answer this by describing a triage flow rather than claiming the tool is accurate.
First, separate "is this a true finding" from "is it exploitable here". Reachability, network exposure, and whether the affected component handles untrusted input all matter more than the CVSS number alone. Second, use the tool's own suppression path for GitLeaks rather than deleting the check — detect vs protect modes is usually where this is configured. Every suppression should carry an owner, a justification and an expiry date, and should be reviewed like code.
Third, baseline. Adopting a scanner on a mature codebase produces a wall of findings; freezing that backlog and blocking only on newly introduced issues is what makes adoption survivable. Then burn the backlog down deliberately.
Code Example
# Triage flow for GitLeaks findings # 1. is it a true positive? (does the pattern really match this code path) # 2. is it exploitable here? (reachable, untrusted input, network exposed) # 3. suppress with reason + owner + expiry, never a blanket ignore # 4. baseline existing findings; block only on newly introduced ones # 5. re-review suppressions on a schedule so they do not become permanent
Interview Tip
Saying "we suppress false positives with an expiry and review them" signals real operational experience.