Skip to content

CVE-Ignore Converter · Security

CVE-Ignore Converter: Translate vulnerability ignore files in one click.

Convert a vulnerability ignore file between.trivyignore,.grype.yaml,.snyk, andosv-scanner.toml — paste one, pick a target, get the equivalent file.

Runs in your browser — nothing you paste leaves this page. How we prove that

Runs in your browserNo signupFree & openUpdated Sep 4, 2026

CVE-Ignore Converter playground

Example
input

Tip: press Esc to release focus.

output
read-only
Notes

Pick a source format, paste a suppression file, then convert to see the translated policy and any lossy-conversion notes here.

The Gap

One decision, four file formats.

Deciding to suppress a CVE is real work: you investigate reachability, accept the risk, and write down why. But that single decision has to be re-encoded for every scanner you run. Trivy wants a line in.trivyignore;Grype wants a structured matcher in.grype.yaml;Snyk wants a keyed entry in.snyk; andosv-scanner wants a TOML table inosv-scanner.toml.

Maintaining four hand-edited files for the same policy is how drift creeps in — a CVE ignored in one tool but live in another, an expiry that lapsed in only one place. This converter translates between all four formats so you can unify your CVE suppression policy across scanners: approve once, generate everywhere, consistently.

New to a format? Jump to the four files or try the live converter above.

The Pipeline

How it works.

Four deterministic steps run end-to-end on every conversion — all inside your browser tab, every time.

  1. Detect the source.

    The pasted ignore file is sniffed and parsed against the format you select — Trivy, Grype, Snyk or osv-scanner.

  2. Build a neutral model.

    Each suppression becomes a format-agnostic record: vulnerability ID, optional scope, reason, and expiry.

  3. Emit the target.

    That model is rendered into the target format's exact syntax — line list, YAML matcher, or TOML table.

  4. Flag what won't map.

    Any field with no home in the target — expiry, package scope, paths — is surfaced as a warning, never dropped silently.

Trivy → Snyk

Convert .trivyignore to a.snyk policy.

Paste the Trivy file, choose .snyk as the target format. This is what the converter above returns, verbatim.

Paste this

.trivyignore
# Accepted risk — no upstream fix (review 2026-09).
CVE-2023-12345
GHSA-xxxx-yyyy-zzzz

Get this

.snyk
version: v1.25.0
ignore:
  CVE-2023-12345:
    - "*":
        reason: Accepted risk — no upstream fix (review 2026-09).
  GHSA-xxxx-yyyy-zzzz:
    - "*": {}

  • ID → ignore key

    Every bare line in the .trivyignore becomes a key in the Snyk ignore: map — CVE, GHSA and RUSTSEC identifiers alike.

  • # comment → reason

    A comment sitting directly above an ID, or trailing on the same line, is carried into that rule's reason field, so the justification moves with the suppression.

  • no path → "*"

    Snyk keys every rule by path and .trivyignore has none, so each rule is written against "*" — all paths — and a warning records that the converter defaulted it.

  • same ID twice → merged

    Two source lines for one vulnerability are folded into a single ignore key rather than overwriting each other; if their reasons disagree, you get a warning instead of a silent loss.

Both Ways

Snyk back to Trivy — and every other direction.

The converter is not one-way. Any of the four formats can be the source and any other can be the target, so the same page covers.snyk →.trivyignore,.trivyignore →.grype.yaml, and.trivyignore →osv-scanner.toml.

Coming back to Trivy, each Snykreason is re-emitted as# comment lines above its ID — every line of it, because an uncommented line in.trivyignore is a suppression. What Trivy cannot hold is reported instead of quietly edited: anexpires date has nowhere to go, so you are told exactly which ID lost it.

.snyk → .trivyignore

.trivyignore
# .trivyignore — generated by OpsCanopy CVE-Ignore Converter

# No reachable code path; tracked in JIRA-481.
SNYK-JS-LODASH-1040724
# Accepted risk — no upstream fix.
CVE-2023-12345

Converted from the .snyk policy shown below, with one warning: “Trivy cannot represent the expiry onSNYK-JS-LODASH-1040724 — dropped.”

File Formats

What .trivyignore,.grype.yaml,.snyk andosv-scanner.toml each store.

The same suppression — “ignore CVE-2023-12345, accepted risk” — looks different in each scanner. Here is how the four formats encode it.

Trivy — .trivyignore

A plain list of vulnerability IDs, one per line, with# comments for the human reason. It carries no machine-readable expiry or package scope, so those fields are dropped (with a warning) when converting from richer formats.

.trivyignore
# .trivyignore — one ID per line; '#' starts a comment.
# Accepted risk: no fixed version upstream yet (review 2026-09).
CVE-2023-12345
CVE-2024-0001

Grype — .grype.yaml

A YAMLignore list of structured matchers. Each rule can scope a suppression to a specificpackage name and version, but it carries no expiry.

.grype.yaml
# .grype.yaml — ignore rules are structured matchers.
ignore:
  - vulnerability: CVE-2023-12345
    # Optional scoping by package narrows the suppression.
    package:
      name: libfoo
      version: 1.2.3
  - vulnerability: GHSA-xxxx-yyyy-zzzz

Snyk — .snyk

A YAML policy keyed by issue ID. Each entry scopes by path ('*' for all) and carries a human-readable reason and anexpires timestamp.

.snyk
# .snyk — a YAML policy file. Each ignore is keyed by issue ID.
version: v1.25.0
ignore:
  SNYK-JS-LODASH-1040724:
    - '*':
        reason: No reachable code path; tracked in JIRA-481.
        expires: 2026-09-01T00:00:00.000Z
  CVE-2023-12345:
    - '*':
        reason: Accepted risk — no upstream fix.

osv-scanner — osv-scanner.toml

A TOML file with an array of[[IgnoredVulns]] tables. Each holds an id, an optionalignoreUntil expiry, and areason.

osv-scanner.toml
# osv-scanner.toml — TOML array of ignored advisories.
[[IgnoredVulns]]
id = "CVE-2023-12345"
# 'ignoreUntil' is the expiry equivalent.
ignoreUntil = 2026-09-01
reason = "Accepted risk — no upstream fix."

[[IgnoredVulns]]
id = "GHSA-xxxx-yyyy-zzzz"
reason = "Not exploitable in our build."
What each scanner ignore format can express.
ScannerFileShapeExpiryScopeReason
Trivy.trivyignoreLine listNo (comments only)NoComments
Grype.grype.yamlYAML matchersNoPackageNo
Snyk.snykYAML policyPer-rule datePathYes
osv-scannerosv-scanner.tomlTOML tablesignoreUntilNoYes

When It’s Lossy

A note on fidelity: because the formats carry different metadata, not every field survives every conversion. Expiry dates have no home in .grype.yaml;package and path scope can’t be expressed in.trivyignore orosv-scanner.toml; andreason metadata downgrades to a comment where a target has no dedicated field. When a field can’t map, the converterflags it as a warning rather than dropping it silently — so you always know exactly what didn’t carry over and can decide what to do about it.

FAQ

Questions, answered.

Tap a question to expand the answer.

What is the CVE-Ignore Converter?

It is a free, browser-based tool that translates a vulnerability-suppression policy between the four common scanner formats: Trivy (.trivyignore), Grype (.grype.yaml), Snyk (.snyk), and osv-scanner (osv-scanner.toml). Paste one ignore file, pick a target format, and get the equivalent file — so a suppression you decided once does not have to be re-typed for every scanner.

Does my data ever leave my browser?

No. The converter runs 100% client-side. Your ignore file is parsed and re-emitted inside your browser tab — nothing is uploaded to a server, and there is no account or signup. You can safely paste internal CVE policies and the comments that justify them.

Which formats can it convert between?

All four directions are supported: .trivyignore (Trivy), .grype.yaml (Grype), .snyk (Snyk policy), and osv-scanner.toml (osv-scanner). Any source format can be translated to any target format, so it doubles as a unifier when you adopt a new scanner.

How do I convert a .trivyignore file to a .snyk policy file?

Paste the .trivyignore content and select .snyk as the target format. The converter maps each vulnerability ID into a Snyk YAML ignore block keyed by issue ID, using a wildcard path scope, and carries any line comments into the reason field. The conversion runs entirely in your browser with nothing uploaded.

Can I convert a .grype.yaml ignore file to .trivyignore?

Yes. Grype structured ignore matchers — vulnerability ID, optional package name, and version scope — are reduced to a flat list of IDs in .trivyignore format. Because .trivyignore has no machine-readable package or version scoping, those fields cannot be represented in the target; the converter flags them as warnings rather than dropping them silently.

How do I unify one vulnerability suppression policy across multiple scanners?

Maintain a single source ignore file and use the converter to translate it into each scanner format you run. This avoids the fragmented-policy problem where the same accepted-risk decision has to be re-expressed separately for Trivy, Grype, Snyk, and osv-scanner, and prevents drift where a CVE is suppressed in one tool but still live in another.

What is the format of an osv-scanner.toml ignore file?

It is a TOML file containing an array of [[IgnoredVulns]] tables. Each table holds an id field (for example CVE-2023-12345, GHSA-xxxx-yyyy-zzzz, RUSTSEC-2023-0001), an optional ignoreUntil expiry date in RFC3339 format, and an optional reason string. The converter reads and writes this format alongside Trivy, Grype, and Snyk.

Why can't every field round-trip cleanly?

The formats do not carry the same metadata. Trivy .trivyignore is a list of IDs with optional comments; Snyk .snyk is a YAML policy with per-path scoping and expiry dates; Grype .grype.yaml and osv-scanner.toml sit in between. Fields with no equivalent in the target — expiry dates, package or path scope, reason metadata — are flagged as warnings rather than dropped silently, so you always know what did not map.

Is the comment / reason for each suppression preserved?

Wherever the target format supports it. Trivy and Snyk both carry human-readable reasons (Trivy as line comments, Snyk as a dedicated reason field), so justifications survive those conversions. When a target format has nowhere to store the reason, the converter keeps it as a comment where possible and emits a warning where it cannot.

Is this affiliated with Aqua Security, Anchore, Snyk or Google?

No. This is an independent, community tool and is not affiliated with or endorsed by Aqua Security (Trivy), Anchore (Grype), Snyk, or Google (osv-scanner). The vendor and format names are used only to describe what the tool reads and writes.

More free, private DevOps tools.

The CVE-Ignore Converter is one tool inOpsCanopy — a growing canopy of browser-based validators, converters and testers that never touch a server.

More in Security

Read more about this

Browse All ToolsBack to OpsCanopy

39 free tools, every one offline-capable — opscanopy.com works with no signup and nothing uploaded.

Pairs well with AlertLint, our browser-based Loki alert-rule tester. Since scanners run as gates inside your pipeline, you can also validate that config with theGitLab CI Validator and theGitHub Actions Validator, or browse the full tools directory.

Not affiliated with or endorsed by Aqua Security(Trivy), Anchore(Grype), Snyk, orGoogle (osv-scanner). All product names are trademarks of their respective owners and are used only to describe what this tool reads and writes.