The ignore file is where security programs go to die
Open the ignore file of any security tool that has been in a codebase for two years.
You will find entries nobody can explain. A rule id with no comment. A path that no longer exists.
A wildcard somebody added during an incident. Possibly a whole control switched off, dated by
git blame to a Friday.
None of that happened because the team was careless. It happened because the tool offered exactly one way to deal with a finding it could not fix today, and that way was to make it disappear.
Accepting risk is not the problem#
Every security program accepts risk. A vulnerability with no patch, a rule that is wrong about your code, a finding in a test fixture that is supposed to look like a secret. Refusing to accept any risk means never shipping, so the question was never whether. Only whether it is written down.
The problem is the shape of the mechanism. An ignore entry deletes the finding, and a deleted finding produces a report that is indistinguishable from three very different situations:
- the scan found nothing,
- the scan found something and somebody decided it was fine,
- the scan did not run.
One output, three realities. The reader cannot tell, and neither can you, six months later.
The question you will be asked#
The question is not "do you have vulnerabilities?", since everyone does. It is:
This was in the March report and not in June's. What happened to it?
Three possible answers. It was fixed is fine; the diff proves it. Somebody accepted it, here is who and why is fine, and is a functioning process. We don't know is the one that costs, and it is what an ignore file produces by default.
What a decision needs to survive#
Four things. The absence of any one turns a decision into a hole:
Narrow scope. An exception tied to a rule and a path is a decision. One tied to a whole control is a switch somebody flipped, and it will silently cover findings nobody has ever seen.
A reason a stranger can evaluate. Not "false positive", why. The reader in two years has no context, cannot ask you, and will either re-derive it badly or leave it alone forever.
A named owner. Accountability that belongs to everybody belongs to nobody. A name also tells the next person who to ask, which is often all they need.
An expiry. This is the one nearly every tool omits and nearly every program needs. Risk accepted today because no patch exists stops being acceptable the week one ships. Without a date, a temporary decision becomes permanent by inaction, and the entry will still be there when the person who wrote it has left.
Suppress rather than delete#
The alternative to an ignore file is not "fix everything" but keeping the finding in the report, marked, with the decision attached.
The report gets longer. That is the entire cost, and it buys something specific: a passing verdict that does not pretend, and a list of accepted risks that somebody can review. Because that is the other half. An exceptions list is a document to be read on a schedule, not a configuration file that grows.
If nobody has ever removed an entry from yours, it is sediment rather than a list of decisions.
What to check in your own tooling#
Three questions, and you can answer them this afternoon:
- Does a suppressed finding still appear anywhere? If not, your reports cannot distinguish clean from quiet.
- Can an exception carry a reason and an owner in a structured way, not a comment somebody might have written?
- Can it expire? And when it does, does anything say so, or does it just start failing?
Draugr's answer is config.exclude: an excluded finding stays in the report marked suppressed,
carrying its reason and the person who accepted it. The scan says how many were suppressed and by
whom, an exclusion past its expires date stops suppressing and reports that it lapsed, and one
that matched nothing is reported too, because a rule doing nothing is usually a typo, a rule id that
moved, or a finding somebody already fixed and forgot to stop excusing.
None of that decides anything for you. It makes the decision legible, which is the part anyone asking is after.
The risk acceptance guide covers the discipline, and your CI logs are not evidence covers what the resulting report has to carry.