DEV Community: Wilson Santos

The ignore file is where security programs go to die

Wilson Santos — Tue, 10 Nov 2026 04:05:22 +0000

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:

A deleted finding does not leave a gap shaped like itself. It leaves a report that reads exactly like one with nothing to report.

Every tool means something different by it

There is no shared idea of what an exclusion is. Three tools a normal pipeline runs suppress three
different kinds of thing, in three files, with three syntaxes:

	What an entry actually names	Expiry	Reason	Owner
`.trivyignore`	a vulnerability id, everywhere it appears	`exp:2026-01-01`	a comment	no
`.trivyignore.yaml`	an id, narrowed by path or package	`expired_at:`	`statement:`	no
`.semgrepignore`	files and paths, gitignore-style. Not findings at all	none	a comment	no
`.gitleaksignore`	a fingerprint, `commit:path:rule:line`	none	a comment	no

Trivy's YAML form is the closest any of them gets, with somewhere to write the reason and a date it
lapses. It is also one tool's file, experimental enough that it is not read unless you name it on
the command line, and it has nowhere to record who decided. The other two cannot express the
decision at all: a Semgrep exclusion is a path glob, so "we accepted this finding" and "do not look
in this directory" are written identically, and a Gitleaks entry is a hash of a finding at a commit,
which stops matching when the file moves.

So a team running four scanners is not maintaining an exceptions policy so much as four lists, in
four formats, that mean four different things and cannot be read together.

And the worst of it is not in a file at all. # nosemgrep and #trivy:ignore put the decision in
the source, on the line it excuses, where no review of accepted risk will ever find it. At best the
scanner notes the excluded finding in a machine format nobody reads, and a #trivy:ignore in an
IaC file leaves no record anywhere. You would have to grep the codebase to know your own policy.

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:

What it carries	What its absence leaves behind
Narrow scope, a rule and a path	an exception tied to a whole control is a switch somebody flipped, and it silently covers findings nobody has ever seen
A reason a stranger can evaluate, not "false positive"	a reader in two years has no context and cannot ask you, so they 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	risk accepted because no patch exists stops being acceptable the week one ships. Without a date a temporary decision becomes permanent by inaction

The last is the one nearly every tool omits and nearly every program needs, and it is why an entry
outlives the person who wrote it.

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:

Ask	If the answer is no
Does a suppressed finding still appear anywhere?	your reports cannot distinguish clean from quiet
Can an exception carry a reason and an owner in a structured way?	you have a comment somebody might have written, which nothing can read or check
Can it expire, and does anything say so when it does?	every acceptance is permanent, and you will find out which ones mattered from somebody else

One decision, the throwaway key in test/fixtures, in each format that can express it and as one config.exclude entry, the only one whose scan says who accepted it.

Draugr's answer is config.exclude: one syntax for every scanner, written in the file that
already describes your scope, so excusing a Trivy finding and a Gitleaks one are the same edit. It
writes down three of the four things above, and the git history of its line records the fourth:

config:
  exclude:
    - paths: ["test/fixtures/"]        # narrow scope, not a whole control
      rules: ["private-key"]
      reason: >-
        The integration test writes a throwaway key so the secrets control has
        something real to find. The material is fake and was never valid anywhere.
      expires: 2026-12-31

An excluded finding stays in the report marked suppressed, carrying its reason and the file and
line of the exclusion. --evidence prints the git history of that line, the last commit to change
it with its author and date, and report.json carries the same for every exclusion. That record is
stronger than a name typed into the entry, which nothing checks and anyone editing the file can
write. It holds to whatever the repository enforces before a change merges, signed commits and
required review included.

The scan says how many findings were suppressed, 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.

There is also nothing to learn per tool. A new scanner arrives with its own ignore format and its
own semantics, and none of that reaches you, because the exclusion was never expressed in the
scanner's terms. It was expressed in yours, against a rule id and a path, in the descriptor that
already says what your software is.

The exclusions somebody already wrote in a scanner's own terms are kept as well. A # nosemgrep, a
#nosec or a gitleaks:allow beside the line, a .trivyignore or .gitleaksignore line and a
Grype ignore: rule each leave the finding in the report, suppressed and still ranked
into a priority band, P1 to P4, from its severity and the
component's declared exposure and criticality. They are counted under scanner exclusions,
separately from config.exclude, because neither kind is a decision recorded in the descriptor.
Each one says where it was written: origin: tool for a directive in the scanned file, which sends
you to whoever committed the line,
and origin: scanner for the scanner's own configuration, named by file, which sends you to
whoever owns it. An exclusion the scanner records nowhere, such as a #trivy:ignore comment
in an IaC file, cannot be reported by anything, while one written in config.exclude
keeps the finding and its reason in every case.

Every exclusion in one repository, grouped by where it was written, which decides who to ask about it. Only the one in the descriptor says who decided and until when.

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.

This article was created with the help of AI.

What to fix first when everything is critical

Wilson Santos — Thu, 01 Oct 2026 20:31:45 +0000

Run any scanner across a real system and you will get the same shape of result, a wall of
findings, most of them stamped "high" or "critical." Those labels come from
CVSS, the Common Vulnerability Scoring System, a 0 to 10 scale
published with most vulnerabilities. The word is a band on that scale, and the bands are defined by
FIRST in the CVSS v3.1 specification:

The label	The score	What it took to earn it
Critical	9.0 to 10.0	reachable over a network, by somebody with no account, needing nothing from a user, and it takes confidentiality, integrity and availability together
High	7.0 to 8.9	most of the above, with one condition attached. An account is needed, or the attack is not straightforward, or one of the three impacts is spared
Medium	4.0 to 6.9	several conditions at once, or a partial impact. The bulk of what a scanner returns
Low	0.1 to 3.9	local access, or heavy prerequisites, or an impact that is real and narrow

That is a useful thing to know and it is not a statement about you. The specification is explicit
about it: a base score reflects severity "assuming the reasonable worst case impact across
deployed environments". So AV:N/PR:N, the pair that makes a 9.8, is a claim that somebody's
deployment exposes this to the internet without authentication. It is not a claim that yours does.

So the score did its job: it told you how severe each issue is in the abstract. What it did not tell
you is the only thing you need on Monday morning: which one do I fix first?

Severity is not priority. And the gap between them is where security programs quietly fail.

Why severity can't rank your work

CVSS scores a vulnerability in isolation, as if every place it appears were identical. But
the same CVE is not the same risk everywhere:

The same CVE, sitting on	What it actually is
an internet-facing service with no auth	a live attack path
an internal tool three network hops away, behind a policy	a someday-maybe
the component that takes the platform with it when it falls over	an emergency, whatever the score says

Feed all of that into one severity number and you get the two failure modes every team knows:
either you chase everything marked critical and burn out, or you stop believing the labels
and route around the gate. Both end in the same place, with the urgent thing sitting in a
backlog next to a hundred things that look exactly as scary.

The two questions a scanner can't answer

To rank findings you need two pieces of context that no scanner can compute, because they
aren't properties of the code:

How exposed is it? Reachable from the internet, or namespace-scoped behind a network policy? This is likelihood, meaning how reachable the weakness is at all.

How much would it cost? A platform-wide outage, or a dev tool nobody would notice for a week? This is impact, meaning what it costs when it goes wrong.

Real risk is the product of the two, layered on top of raw severity. A scanner sees none of it.

But your app description does

You already know this context. You know which services face the world and
which are buried. You know which ones are load-bearing. That knowledge is stable, small, and
exactly the kind of thing Draugr already captures
in the app descriptor.

So it becomes two more attributes on a component you already describe, its exposure and its
business criticality, and prioritization falls out of the description you wrote once.

components:
  - name: ingress-gateway
    exposure: public          # reachable from the internet
    criticality: critical     # failure = platform-wide outage
  - name: dev-dashboard
    exposure: restricted      # internal, network-scoped
    criticality: supporting   # nobody pages at 3am for this

Same finding, same severity, two answers, because the components differ.

Now the same CVE resolves two different ways, so on the gateway it is fix-now and top of the list.
On the dashboard it is track-and-move-on. Severity was identical and priority was not, because
priority combines the finding's severity with the
component's exposure and criticality into a single, ordered answer.

The third input, whether anyone is exploiting it

Exposure and criticality describe your side. There's one more signal, and it comes from the
world: exploitability.

A CVE on CISA's KEV catalog is known to be exploited in the wild, not
theoretically exploitable, and used against real systems. That escalates a finding whatever
its CVSS score says, because a modest score being exploited today outranks a 9.8 nobody has ever
weaponized. A high EPSS probability, the likelihood a CVE gets exploited
in the next thirty days, raises a finding's severity one level on the same logic.

The severity did not change and neither did the code. What changed is that one of them is being used, which is a fact about the world rather than about your repository, and it is the input almost nobody feeds in.

Both are opt-in and read from feeds you provide, so the ranking stays reproducible, because the same
inputs give the same order, and you can point at where each escalation came from.

An order is still a list, until it names the work

Ranking gets the right thing to the top and shortens nothing: four hundred findings ranked are
still four hundred rows, and the first twelve are often one library. So the last step groups them
by the thing that fixes them, into one list for each kind of work:

$ draugr scan . --view actions --top 4

WHAT TO DO  49 actions clear 1238 findings

Update an image you do not build  1 action clears 605 findings
  P1  Update python:3.8-slim
      component api · control images · 605 findings · upstream · CVE-2025-15467 +604

Bump a dependency  10 actions clear 38 findings
  P1  Upgrade jquery 1.8.3 → 1.12.2
      component storefront · control sca · 4 findings · web/package-lock.json:12 · and 1 more
  P1  Upgrade jquery 1.12.2 → 3.5.0  major · beyond policy minor
      component storefront · control sca · 5 findings · web/package-lock.json:12 · and 1 more
  P1  Upgrade jquery 1.8.3 → 3.5.0  major · beyond policy patch
      component api · control sca · 7 findings · …/js/jquery.min.js vendored · CVE-2020-11023 +6
  P1  Upgrade Jinja2 2.10 → 2.10.1
      component api · control sca · 1 finding · app/requirements.txt:5 · CVE-2019-10906
  … and 6 actions not listed

Change the code  14 actions clear 23 findings
  P1  Run the command as an argument list, without a shell
      Found user-controlled data used in a system call
      Semgrep: python.lang.security.dangerous-system-call.dangerous-system-call · Bandit: B605
      component api · control sast · 2 findings · app/app.py:16
  P1  Run the command as an argument list, without a shell
      subprocess call with shell=True identified, security issue
      Bandit: B602 · and 3 more
      component api · control sast · 4 findings · app/app.py:23
  P1  Turn off debug mode outside development
      Also: Bind a specific host unless the server must be reachable from outside
      Semgrep: python.flask.security.audit.debug-enabled.debug-enabled · Bandit: B201 · and 2 more
      component api · control sast · 4 findings · app/app.py:35
  P1  Remove eval(), or check no outside data reaches it
      Found user data in a call to 'eval'
      Semgrep: python.django.security.injection.code.user-eval.user-eval
      component api · control sast · 1 finding · app/app.py:29
  … and 10 actions not listed
  ⋯

That is the demo project, where 49 actions clear 1,238 findings. Each kind of work has its own
list, so whoever does one kind reads one list. The first is an image the team does not build:
upstream comes from the descriptor, which declares python:3.8-slim builtBy: upstream, so the
action is to take a newer image rather than to upgrade a package nobody there can reach, and that
one move clears 605 findings. Then come the upgrades, the lines of code to change, the
infrastructure settings and the credential to rotate. The jquery rows are one library in two
components, each with its own owner, and vendored marks a copy committed to the tree, which
bumping the lockfile leaves as it was.

A row is a remediation, not a finding. Six vulnerabilities in one library are one upgrade; the
same misconfiguration in three Dockerfiles is one habit. Listing those separately makes the
repetitive work crowd out everything else, which is how a ranked list still ends up unread.

Within each list, actions are ordered by the worst thing each one clears, and by how many only
at the end. An action clearing a single P1 outranks one clearing forty P4s, because volume is not a
reason to do something first and a P1 is not something to trade away for a bigger number. Inside a
band, an action clearing a flaw on KEV comes first, then the higher severity, and only then the
count. So in the code list, the shell call built from user input clears two critical findings and
sits above the shell=True call that clears four high ones.
What to fix first walks through every key, the upgrade policy behind
beyond policy, and where the report records each one.

Grouping is opt-in while that annotation spreads: --view actions turns it on, and the default
still lists one finding per row. The report files always carry findings separately either way, so
an auditor reading the SARIF sees one record per finding whichever way the console was asked to
show them.

What that changes

For a developer

The output stops being a 400-row dashboard and becomes a short list: these three, in this order, today. Clear action, not triage archeology.

For the business

Consistent and defensible, because the same rules apply to every service. "What is our real exposure right now?" has an answer, and the urgent gets a faster response because it is no longer buried under look-alikes.

For your coding assistant

The difference between a list and an order. Point one at Draugr and it answers from the same ranking your pipeline uses. A scanner can hand it a pile of findings; only your description says which one to fix.

This is what Draugr does: a gate that tells you the few things that matter, ranked by your own
context. Describe your app, and
the description doesn't just decide which scanners run. It decides what you fix first.