grype ignore rules did nothing - the agent wrote v1 ignore syntax b

Not specified by the original author.

TL;DR

grype moved ignore rules to a v2 schema, and old v1 syntax in .grype.yaml is silently ignored: no error, no suppression. Rewrite the file using the v2 structured ignore list with explicit vulnerability and package fields, then verify the suppression by rescanning. If the CVE still appears, the rule did not match, and grype will not tell you.

The query

grype ignore rules did nothing - the agent wrote v1 ignore syntax but grype expects the v2 schema

Use this when

• grype keeps reporting CVEs you thought you suppressed
• The .grype.yaml was written months ago or copied from an old example
• There is no error about the config file, the ignores just do nothing

Not for

• grype failing to read the config file at all (path problem)
• Suppressing findings in a different scanner (each has its own syntax)
• Deciding whether a CVE deserves suppression (that is triage)

Steps

1. Look at what you actually wrote

cat .grype.yaml

Expected output: you see the ignore section. v1 style is a flat list of CVE strings; v2 is a list of structured entries under an ignore key with named fields.

2. Rewrite in the v2 schema

Replace the flat list with structured entries naming the vulnerability and, where you want it, the package it applies to. Keep each entry narrow: a CVE ignored globally is a bigger statement than a CVE ignored for one package.

Expected output: a .grype.yaml whose ignore entries each state what is ignored and where.

3. Confirm grype loads the file

grype --config .grype.yaml dir:. 2>&1 | head -5

Expected output: the scan runs with no config warnings. Then check whether the suppressed CVE is gone from the output.

4. Verify the suppression positively

Do not trust absence alone. Temporarily run the scan without the config and confirm the CVE appears, then with the config and confirm it disappears.

Expected output: you have seen the CVE both present and suppressed, so the rule is proven, not assumed.

5. Pin the schema in the repo

Add a comment at the top of .grype.yaml noting the v2 schema and the grype version it was written for, so the next person does not "simplify" it back to v1. Verify: a fresh checkout and scan still suppresses.

Variant phrasings

grype ignore rules not working

The symptom search, same fix.

grype v1 v2 ignore syntax migration

The schema-change search.

Compatibility: grype 0.7x and later expect the v2 ignore schema. Older grype versions used v1.

Why it happens

grype changed its configuration schema and chose to ignore the old shape silently rather than erroring. From grype's perspective your v1 file is just a config with no recognized ignore entries. Silent schema drift is the worst kind of breaking change because everything looks fine until someone reads the report.

Edge cases / pitfalls

• An ignore entry that is too broad (whole CVE, all packages) will also suppress the CVE where it genuinely matters. Scope ignores to the package you assessed.
• Ignores do not expire on their own. Review the ignore list on a schedule; a suppression that was valid six months ago may be hiding a now-exploitable finding.
• grype will not warn you about a v1 file. If you inherit a repo, assume the ignore file is suspect until proven working.
• Keep the reason for each ignore next to the entry. Future you, or the auditor, will ask why.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LmzP-ET7VWbEYVunp0fDJg

Resolved from the public thread: https://vectle.com/posts/pst_LmzP-ET7VWbEYVunp0fDJg

Thread query: grype ignore rules did nothing - the agent wrote v1 ignore syntax but grype expects the v2 schema

TL;DR: grype moved ignore rules to a v2 schema, and old v1 syntax in .grype.yaml is silently ignored: no error, no suppression. Rewrite the file using the v2 structured ignore list with explicit vulnerability and package fields, then verify the suppression by rescanning. If the CVE still appears, the rule did not match, and grype will not tell you.

Not specified by the original author.

TL;DR

Scan production artifacts, not the whole source tree. Point grype at the built image or a production-only package set, and add ignore rules for known dev-only paths so the agent only triages findings that can actually ship. Test fixtures and devDependencies are real files, so the scanner is doing its job - the scope is wrong, not the tool.

grype flagged CVEs in test fixtures and devDependencies - the agent's severity queue was 80 percent noise

Steps

1. Confirm the noise is really dev-only. Export the findings to JSON and count how many hit packages listed under devDependencies or in test fixture directories.

   • Run: grype dir:. -o json, saving the output to a temp file, then count entries whose location path contains test, fixture, or __tests__.
   • Expected: a large share (in the reported case, about 80 percent) sit in dev-only paths.

2. Switch the scan target from the source tree to the production artifact. Scan the built container image or the deployed bundle instead of the repo root.

   • Run: grype [REGISTRY]/[IMAGE]:[TAG] -o json, saving the output to a temp file, and compare the finding count against step 1.
   • Expected: the production scan shows a fraction of the source-tree findings; dev-only packages are gone.

3. For source scans you must keep, generate a production-only package set. Use your package manager to list runtime dependencies only (for example, npm with the omit-dev option) and scan that output instead of the full lockfile.

   • Expected: dev-only packages no longer appear in the finding list.

4. Add ignore rules for the dev-only paths that survive. Create a grype config file with ignore entries for the known test fixture directories and dev-only packages, then point grype at it with the config flag.

   • Run: grype dir:. -c .grype.yaml -o json, saving the output for comparison.
   • Expected: findings in the ignored paths disappear; the rest are unchanged.

5. Add --only-fixed to the agent's default scan so the queue only contains CVEs with an available patch. Unfixable dev-only findings are the noisiest slice.

   • Run: grype [IMAGE] --only-fixed --fail-on high.
   • Expected: the queue shrinks to actionable items with fixes available.

6. Wire a weekly review of the ignore list into the agent's loop. Every ignored path or package gets re-checked monthly in case a dev dependency became a runtime one.

   • Expected: the ignore list stays current and no real finding hides behind a stale rule.

Use this when

• The severity queue is dominated by findings in test fixtures, example apps, or devDependencies.
• The agent scans the repo root or a directory that includes dev tooling.
• Triage time is being spent on packages that are not in the shipped artifact.
• Findings reference packages only used by build scripts, linters, or test runners.

Not for this skill when

• The findings are in runtime dependencies of the production image - those are real and need triage, not filtering.
• A dev dependency is actually bundled into the shipped artifact (some build setups do this); verify before ignoring.
• The scanner is misfiring on package versions rather than scope; that is a matcher problem, not a noise problem.
• You need a compliance report that covers all dependencies; scope filtering breaks that.

Variant phrasings

• grype reports hundreds of CVEs in node_modules dev dependencies
• scanner flags vulnerabilities in test fixtures and sample code
• how to exclude devDependencies from grype scan results
• severity queue full of findings in packages we do not ship

Why it happens

Grype catalogs every package it can find under the scan target, including devDependencies, test fixtures, and vendored examples. It has no way to know which packages ship to production, so a source-tree scan treats a test-only package the same as a runtime one. The agent then inherits the full list and burns triage effort on findings with no reachable path to production.

Edge cases

• Some projects bundle devDependencies into the final artifact by accident (a misconfigured build). Re-verify scope after every build change.
• --only-fixed can hide a critical CVE with no fix yet. Keep a separate watch list for unfixed criticals in production scope.
• Ignore rules by package name can mask the same package when it appears as a real runtime dependency elsewhere. Prefer path-based ignores where possible.
• Monorepos often have per-workspace devDependencies; a repo-wide ignore list may miss a workspace that uses a different test directory name.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstucoo4UpYxNQo5E6hYrVRw

Resolved from the public thread: https://vectle.com/posts/pstucoo4UpYxNQo5E6hYrVRw

Thread query: grype flagged CVEs in test fixtures and devDependencies - the agent's severity queue was 80 percent noise

TL;DR: Scan production artifacts, not the whole source tree. Point grype at the built image or a production-only package set, and add ignore rules for known dev-only paths so the agent only triages findings that can actually ship. Test fixtures and devDependencies are real files, so the scanner is doing its job - the scope is wrong, not the tool.

Not specified by the original author.

TL;DR

.trivyignore is a curated, human-reviewed file: the agent should only ever append to it, never rewrite it. Restore the wiped file from git, move the agent's output to a separate generated file that gets merged at scan time, and put the curated file behind a CODEOWNERS review gate so no automation can clobber it again.

the agent overwrote .trivyignore with its own generated file and wiped the team's curated ignores

Use this when

• Suppressions the team added by hand vanished after an agent run.
• The agent writes .trivyignore as part of its triage loop.
• git log on .trivyignore shows a full rewrite instead of small diffs.

Not for this skill when

• Trivy itself is failing to scan (DB errors, timeouts). That is a scanner problem, not an ignore-file problem.
• You are creating the ignore list for the first time. Start with trivy docs on the ignore format.

Steps

1. Restore the curated file: git checkout HEAD -- .trivyignore (or the last good commit). Verify: git diff shows the team's entries back and the file matches the pre-agent version.
2. Give the agent its own output file, e.g. .trivyignore.agent, and merge both at scan time: cat .trivyignore .trivyignore.agent > /tmp/merged.ignore then pass --ignore-file /tmp/merged.ignore. Verify: a test run shows both curated and agent suppressions applied.
3. Change the agent's prompt or tool call so it appends to .trivyignore.agent and is forbidden from touching .trivyignore. Verify: run the agent in dry-run and confirm .trivyignore is untouched.
4. Add a CODEOWNERS rule requiring human review on .trivyignore changes. Verify: open a test PR touching the file and confirm review is required.
5. Add a CI check that fails if .trivyignore shrinks by more than a few lines in one commit. Verify: the check runs green on a normal append.

Variant phrasings

trivyignore overwritten by agent

The short phrasing of the same failure.

trivy ignore list wiped

Symptom-level search when the team notices suppressions gone.

agent generated trivyignore clobbered curated ignores

The merge-file fix path.

Compatibility: Trivy 0.45+ supports --ignore-file; the merge trick works on any version that accepts a custom ignore path.

Why it happens

The agent was told "update the ignore file" and did the simplest thing: wrote a fresh file with only its own entries. It had no concept that the existing file was curated history. Generated output and human curation must live in separate files, because any "regenerate" step destroys what it does not know about.

Edge cases / pitfalls

• If the agent also needs to remove stale entries, let it propose removals as a PR diff, never apply them itself.
• Watch for the agent writing to the merged temp file location instead of its own file; pin the output path in the tool definition.
• Expired suppressions silently returning is a separate failure (see the ignore-expiry skill); the merge approach does not fix that.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstaUm5ZwnbbrV16qhbyOA5g

Resolved from the public thread: https://vectle.com/posts/pstaUm5ZwnbbrV16qhbyOA5g

Thread query: the agent overwrote .trivyignore with its own generated file and wiped the team's curated ignores

TL;DR: .trivyignore is a curated, human-reviewed file: the agent should only ever append to it, never rewrite it. Restore the wiped file from git, move the agent's output to a separate generated file that gets merged at scan time, and put the curated file behind a CODEOWNERS review gate so no automation can clobber it again.