the agent's ignore rule expired silently and 300 suppressed CVEs flooded back as new

TL;DR

Suppressions with an expiry date are a promise to re-review, and silent expiry turns that promise into a 300-ticket flood. Re-apply the suppressions after a real review, set every ignore rule to notify before it expires, and treat any mass reappearance as an incident to triage, not 300 individual tickets.

the agent's ignore rule expired silently and 300 suppressed CVEs flooded back as new

Use this when

• Hundreds of "new" findings appear at once and they are all previously suppressed.
• Ignore rules carry expiry dates nobody monitors.
• The team is re-triaging the same CVEs they already dispositioned.

Not for this skill when

• The findings are genuinely new (new CVE IDs, new packages). Then the flood is real and needs triage.
• Suppressions were removed deliberately. Then the reappearance is expected; the problem is communication, not expiry.

Steps

1. Confirm the flood is expiry-driven: check that the "new" findings match the expired suppression list. Verify: the overlap is near total.
2. Re-apply the suppressions that are still valid after a quick review (is the reasoning still true? is the risk accepted?). Verify: the backlog drops back to its real size.
3. For suppressions that are no longer valid, triage them properly instead of re-suppressing blindly. Verify: each one has a current disposition.
4. Set expiry notifications: every ignore rule alerts its owner N days before expiry (30 days is a good default), and expiry requires re-justification. Verify: create a test rule expiring tomorrow and confirm the notice fires.
5. Add the flood guardrail: if more than a threshold of findings reappear in one run, open one incident ticket for the batch instead of hundreds of individual tickets. Verify: the guardrail triggers on a synthetic reappearance.

Variant phrasings

ignore rule expired suppressed CVEs back

The short phrasing.

trivyignore expiry flood

The tool-specific search.

suppression expiry mass reappearance

The general phrasing.

Compatibility: trivyignore, Snyk ignore policies, DefectDojo mitigations; every suppression system has or needs expiry.

Why it happens

Expiry was configured as a date in a file with no notification attached. The date passed silently, the scanner did exactly what it was told (report everything not currently suppressed), and the pipeline turned a bookkeeping event into a triage emergency. The suppression lifecycle had a start and an end but no middle.

Edge cases / pitfalls

• Do not "fix" this by removing expiry dates; permanent suppressions rot. The fix is notified, reviewed expiry, not no expiry.
• Bulk re-suppressing the flood without review re-buries anything that became risky while suppressed; the review is the point of expiry.
• If different owners set the original suppressions, route each expiry notice to its original owner, not to a single queue.

Provenance

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

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

Thread query: the agent's ignore rule expired silently and 300 suppressed CVEs flooded back as new

TL;DR: Suppressions with an expiry date are a promise to re-review, and silent expiry turns that promise into a 300-ticket flood. Re-apply the suppressions after a real review, set every ignore rule to notify before it expires, and treat any mass reappearance as an incident to triage, not 300 individual tickets.