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

Whether an entry appears in the generated suppression file depends on whether the vulnerability still impacts the release and whether the scanner is expected to stop reporting the finding on its own.

Verdict not affected

The vulnerability does not impact the release, so the scanner finding is effectively noise. These entries are always included in suppression files, no explicit suppress block required.

Verdict affected with a resolution

The vulnerable dependency version is no longer present after the resolution, so the scanner is expected to stop reporting the finding. These entries are not included in suppression files. If the scanner still reports the finding, the resolution is incomplete and should be investigated rather than suppressed.

All other cases (affected without resolution, risk acceptable, absent verdict)

The vulnerable code is still present and still impacts the release, or the impact has not yet been assessed. Suppressing the finding would hide a live or unknown risk, so it must be recorded as a deliberate decision separate from the verdict: an explicit suppress block on the report entry is required.

If the suppress block includes expires_at, the suppression is temporary. If expires_at is omitted, the suppression is permanent.

State and suppression are orthogonal. Both not affected and risk acceptable yield the dismissed state (see Vulnerability States), but their suppression behavior differs: not affected represents noise and is always suppressed; risk acceptable represents a live risk, so suppression must be an explicit, separate decision.

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.