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.

Static and Dynamic Suppression

Vulnlog supports two approaches for managing generated suppression files:

Static (checked in)

The generated suppression files (e.g., .trivyignore.yaml, .snyk) are committed to the repository. When the Vulnlog file is edited, the suppression files are regenerated and the updated versions committed. This approach makes suppressions visible in code review and provides a clear history of changes.

Dynamic (generated in CI)

The suppression files are generated on the fly in the CI pipeline, just before the SCA scanner runs. They exist only temporarily during the pipeline execution and are not committed to the repository. This approach avoids keeping generated files in the repository and ensures suppressions are always in sync with the Vulnlog file.

Both approaches can be combined — for example, using static suppression for local development and dynamic generation in CI. See CI/CD Integration for pipeline examples using dynamic generation.

Suppression Rules

Entries where verdict is not affected are always included in suppression files.

Entries where verdict is affected with a resolution are not included in suppression files. The vulnerable dependency version should no longer be present after the resolution. If the scanner still reports the finding, the resolution is incomplete.

For all other cases (affected without resolution, risk acceptable, absent verdict), suppression requires an explicit suppress block on the report entry. If the suppress block includes expires_at, the suppression is temporary. If expires_at is omitted, the suppression is permanent.

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 the generated suppression file.

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)

.cargo-audit.toml

Planned

semgrep

Semgrep

 — 

No

npm-audit

npm audit

 — 

No

github-advisory

GitHub Advisory Database

 — 

No

other

Generic / non-scanner source

 — 

No

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