2026-07-27 15:37:30 +08:00
|
|
|
# Trivy suppressions for the release and bundle scans.
|
|
|
|
|
#
|
|
|
|
|
# This file is empty on purpose. Every entry it used to hold (21 IDs covering
|
|
|
|
|
# pnpm 9.x and its bundled glob/minimatch/picomatch/tar, plus npm's vendored
|
|
|
|
|
# sigstore) suppressed something that is not in any shipped artifact: the
|
|
|
|
|
# production image purges pnpm and npm before the final layer, so raw and
|
|
|
|
|
# policy-filtered scans of both architectures return identical counts. Two of
|
|
|
|
|
# the rationales were also wrong on their own terms. A suppression list that
|
|
|
|
|
# suppresses nothing still costs review attention and hides the next real one.
|
|
|
|
|
#
|
|
|
|
|
# Before adding an ID here, check that it fires against a shipped artifact:
|
|
|
|
|
#
|
|
|
|
|
# trivy image --ignorefile /dev/null <ref>
|
|
|
|
|
#
|
|
|
|
|
# If it does, the entry needs three things in a comment directly above it: who
|
|
|
|
|
# owns getting it fixed, what unblocks the fix, and the date to re-check.
|
|
|
|
|
#
|
|
|
|
|
# Suppression is for findings that are genuinely absent from what we ship. For
|
|
|
|
|
# findings that ARE present and have no upstream fix, do not suppress them. Add
|
|
|
|
|
# the ID to .trivy-unfixed-allow instead, so the release scan keeps reporting
|
|
|
|
|
# it and a new one still fails the build.
|
