In Trivy 0.74, how do .trivyignore and .trivyignore.yaml differ when you must waive one CVE for one package until a date?

## Two file formats, one filter step **Trivy** waives findings by ID after the severity and status filters and before any Rego `--ignore-policy` or VEX statement. Two file formats feed that step. Trivy 0.74 loads `.trivyignore` from the **current working directory** automatically; any other file, including a YAML one, has to be named with `--ignorefile` (config key `ignorefile`). A file whose extension is `.yml` or `.yaml` is parsed as YAML, anything else as the plain format. ## `.trivyignore`: one ID per line - Each non-blank line that does not start with `#` holds an ID: a CVE or other vulnerability ID, a misconfiguration check ID such as `AVD-DS-0002`, a secret rule ID such as `aws-account-id`, or a license name. - An optional `exp:yyyy-mm-dd` field on the same line sets an expiry. - Trivy cannot tell what kind of finding a bare ID refers to, so it applies every plain ID to **all four** finding types, and to every package, file and target in the scan. - If the `exp:` date does not parse, Trivy logs a warning and **skips the whole line**: the finding stays reported. That breadth is the problem the question is about. `CVE-2023-3817` waived for one library also disappears from every other package and every image scanned with the same file, and nothing in the file records why. ## `.trivyignore.yaml`: scoped waivers The YAML format is marked **EXPERIMENTAL** in 0.74 and is not loaded automatically; the docs say it will be once it is stable. It has four sections (`vulnerabilities`, `misconfigurations`, `secrets`, `licenses`), and each entry takes these fields: | Field | Required | Effect | |---|---|---| | `id` | yes | the vulnerability, check, secret rule or license to waive | | `paths` | no | glob patterns; without it the entry applies to all files | | `purls` | no | package URLs; vulnerabilities only; without it all packages match | | `expired_at` | no | `yyyy-mm-dd`; without it the entry never expires | | `statement` | no | the reason; recorded and shown, never used for matching | A purl without a version, such as `pkg:apk/alpine/libcrypto3`, scopes the waiver to that package whatever its installed version. ## What expiry does When Trivy loads either file it drops every entry whose date has passed. The finding then reappears, and a scan run with a non-zero `--exit-code` fails from that day on. That is the intended behaviour: a waiver that lapses fails loudly instead of hiding a finding forever. Both failure modes of expiry point the same way: an expired entry and a malformed date each leave the finding reported. ## Finding the file in CI 1. The default `.trivyignore` is resolved against the working directory. If it is absent, Trivy carries on with only a debug message, so a job that runs from a subdirectory quietly loses every waiver. 2. A path set explicitly with `--ignorefile` (or the `ignorefile` key) that does not exist stops Trivy with an "ignore file not found" error. 3. The official GitHub Action's `trivyignores` input takes a comma-separated list of plain files, which it concatenates, or exactly one YAML file; mixing the two kinds, or naming a missing file, fails the step. ## Choosing between them - Use `.trivyignore` for a quick, repository-wide waiver of an ID that genuinely does not apply anywhere, always with an `exp:` date. - Use `.trivyignore.yaml` when the waiver belongs to one package, one lockfile or one Dockerfile, or when the reason must travel with it. - Never rely on the YAML file being picked up by default in 0.74: name it with `--ignorefile` or the `ignorefile` config key. ## Auditing and going beyond IDs - `--show-suppressed` (experimental) prints the suppressed findings with their status, statement and source file; the JSON report carries them under `ExperimentalModifiedFindings`. - `--ignore-policy` takes a Rego file whose package is `trivy` and whose `ignore` rule is evaluated once per finding, with the finding as `input` and a `Type` field of `vulnerability`, `misconfiguration`, `secret` or `license`. Use it when the waiver is a rule (every finding with one CWE, one package across many CVEs) rather than a list. Trivy 0.74 evaluates these files with the older Rego v0 syntax, and a broad rule also hides findings that do not exist yet. Who may approve a waiver, and how waivers are reviewed, belongs to suppression governance; the file formats and how Trivy reads them are what the operator has to know.