Suppression

Suppression directives exclude specific vulnerability findings from a scanner’s output. The Vulnlog CLI generates scanner-specific suppression files from the Vulnlog file, keeping the triage rationale alongside the suppression rules.

Whether the generated files are committed or created on the fly in CI is a workflow decision, covered in Generate suppression files for your scanner.

Suppression rules

Four rules decide whether an entry appears in the generated suppression file:

Resolved findings are never suppressed

Once a resolution is recorded, the vulnerable dependency is gone and the scanner stops reporting the finding on its own. These entries are excluded regardless of verdict or suppress block. If the scanner still reports one, the resolution is incomplete and should be fixed rather than suppressed.

Expired suppressions are always dropped

A suppress block whose expires_at date has passed is excluded, regardless of verdict. Expiry takes precedence over every other rule, so even a not affected finding is removed once its expires_at lapses. A finding without a suppress block has no expiry and stays suppressed.

not affected findings are always suppressed

The finding does not impact the release, so it is noise and is suppressed automatically; no suppress block is required. The one exception is the expiry rule above: if a suppress block is present and its expires_at has passed, the entry is dropped.

Everything else needs an explicit suppress block

affected, risk acceptable, and not-yet-triaged findings are still a live or unknown risk. Suppressing one is a deliberate decision, so it happens only when the report entry carries a suppress block.

Permanent suppression

reports:
  - reporter: trivy
    suppress: {}

Temporary suppression

reports:
  - reporter: trivy
    suppress:
      expires_at: 2026-06-01

After the expiration date, the entry is excluded from every generated suppression file. Vulnlog manages expiry itself so that each generated file lists only active suppressions and never an expired one.

Multiple reporters

When multiple scanners report the same vulnerability, each scanner is listed as a separate report entry. Suppression is configured independently per reporter, allowing different suppression strategies per scanner.

  - id: CVE-2021-002
    releases: [ 8.1.1 ]
    packages: [ "pkg:maven/example.org/some-dependency@1.1.2" ]
    reports:
      - reporter: trivy
        at: 2021-03-03
      - reporter: snyk
        at: 2021-03-03
        vuln_ids: [ SNYK-2021-002 ]
    verdict: not affected
    justification: vulnerable code not present

In this example, both Trivy and Snyk reported the same CVE. The Snyk report entry includes a vuln_ids field with the scanner-specific identifier, which is used instead of the CVE ID when generating the Snyk suppression file.

Since the verdict is not affected, both reporters are automatically included in suppression output. Adding a suppress block to only one reporter limits suppression to that specific scanner.

Suppression identifier resolution

The CLI determines which identifiers to write into the suppression file using this order:

  1. vuln_ids values from the report entry for the target reporter type, if present.

  2. The vulnerability’s id field.

aliases are not used for suppression.

Supported reporters

Value Scanner Default Suppression Path Suppression Support

trivy

Trivy

.trivyignore.yaml

Yes

snyk

Snyk

.snyk

Yes

dependency-check

OWASP Dependency Check

dependency-check-suppressions.xml

Planned

grype

Grype

.grype.yaml

Planned

cargo-audit

Cargo Audit (Rust)

audit.toml

Yes (RUSTSEC IDs only)

semgrep

Semgrep

(none)

No

npm-audit

npm audit

(none)

No

github-dependabot

GitHub Dependabot

(none)

No

other

Generic / non-scanner source

(none)

No

For reporters of type other, the source field on report entries is required.