Accepting findings in-repo

There are two ways to accept a scanner finding: in-repo, with a Trivy ignore file that travels with the code, or over the API, with a dismissal. This page covers the first.

In-repo is the better fit when the acceptance is a property of the code — a vulnerable library vendored inside a tool you can’t patch, a container running as root on purpose. The reason sits next to what it describes, and it applies to every scan from the moment it merges.

The one rule that catches people

If your repository contains .trivyignore.yaml, the plain .trivyignore is ignored completely.

Not merged, not consulted as a fallback — ignored. Every entry in it stops suppressing anything.

This happens because our scanners point Trivy at the structured file with --ignorefile, and that flag replaces Trivy’s automatic discovery of the plain file rather than adding to it. It is Trivy behaviour, not a fremforge policy, and it is easy to miss because a plain .trivyignore sitting in your repo looks like it is doing something.

So pick one file and use only that one. If you need anything the plain form can’t express, move all of your entries to the YAML at the same time.

Which form to pick

Both forms accept the same identifiers — CVE ids, GHSA ids, and misconfiguration ids such as DS-0002. The difference is what you can say about an entry.

Use the plain form for a short list. Use the YAML when you need to scope an accept to one vendored path, or when you want the justification carried as data rather than a comment.

Plain form

# grpc is statically linked into the pulumi binary and only speaks over
# localhost, so this server-side advisory is not reachable in CLI use.
GHSA-hrxh-6v49-42gf exp:2026-08-30

Structured form

vulnerabilities:
  - id: GHSA-hrxh-6v49-42gf
    expired_at: 2026-08-30
    paths:
      - usr/local/bin/pulumi
    statement: >-
      grpc is statically linked into the pulumi binary as its engine<->plugin
      transport and only speaks over localhost, so this server-side advisory is
      not reachable in CLI use. Fixed in grpc 1.82.1; drop this when pulumi
      ships it.

misconfigurations:
  - id: DS-0002
    expired_at: 2027-01-23
    statement: >-
      CI runner base image; it must run as root to drive the container runtime.

Top-level sections are vulnerabilities, misconfigurations, secrets and licenses.

Always set an expiry

An accept written without a date is permanent by accident. The vendored library gets patched, the vulnerable file leaves the image — and the entry stays, suppressing anything that later shares its id.

Both forms support expiry, and Trivy enforces it itself: once the date passes the finding comes back. That turns “we should re-check this someday” into a specific day where the gate asks you.

Pick a date you would genuinely re-verify on — the next release of the upstream tool, or a quarter out.

When to dismiss over the API instead

Reach for a dismissal rather than an ignore file when:

• the finding is stale — you already fixed it at source and just want the row cleared. Usually you don’t even need this; the hourly auto-resolve supersedes it once a newer scan runs.
• the acceptance is about this repository’s situation right now, not the code — a finding on a branch that has since merged, for instance.
• you want the reason in the audit log. Dismissals are recorded with who and why; an ignore file is recorded in Git history instead.

An ignore file is the durable choice; a dismissal is the point-in-time one.

Checking it worked

Re-run the scan and confirm the finding is gone — see re-running scans. If the entry appears to have no effect, check the rule at the top of this page first: a .trivyignore.yaml anywhere in the repository root disables the plain file entirely.

See also

• Findings API — read and dismiss findings over REST.
• Image scanning — what blocks a merge, and the severity threshold.
• License scanning — policy categories and allowlisting.