fix(security): remove Trivy scanner warning/notice drift from required workflow #2107

Activity

1. seonghobae

   added

   area: ci-cdCI, GitHub Actions, checks, release, or supply chainCI, GitHub Actions, checks, release, or supply chain

   priority: mediumNormal-priority or P2 workNormal-priority or P2 work

   type: bugDefect or incorrect behaviorDefect or incorrect behavior

   bugSomething isn't workingSomething isn't working

   on Sep 12, 2026
2. seonghobae commented on Sep 12, 2026

   

   seonghobae

   on Sep 12, 2026 – with ChatGPT Codex Connector

   Last edited by seonghobae

   ContributorAuthor

   More actions

   Upstream-root RCA — 2026-09-12

   The two diagnostics have different causes and must not be “fixed” by one blanket quiet flag.

   1. Version notice. The pinned trivy-action@a9c7b0f… is the latest immutable action release, v0.36.0 (2026-04-22), but its declared default is Trivy v0.70.0. The current upstream Trivy release is v0.74.0 (2026-08-14). The action already supports an explicit version input, so freshness can be repaired without changing the action identity. Trivy's official scan.skip-version-check config is specifically defined to suppress update notices; use it only after the binary is explicitly current/pinned and record the revisit condition.

   2. Python license warning. Upgrading alone does not remove it. Current Trivy v0.74.0 still unconditionally calls pythonSitePackagesDir() in the pip post-analyzer and logs the warning when no site-packages tree exists: upstream source. The central lane requests only vuln,secret,misconfig, yet this analyzer still attempts optional license enrichment for requirements.txt.

   Therefore:

   • do not add hide-progress, --quiet, stderr redirection, an empty fake venv, or skip Python requirement files;
   • do not install untrusted PR dependencies/build hooks merely to manufacture package metadata;
   • preserve vuln,secret,misconfig, MEDIUM+, SARIF, and exact-head gates;
   • RED should first prove explicit Trivy version/config provenance and distinguish the single known upstream optional-license diagnostic from any other WARN;
   • the implementation must retain the raw diagnostic as evidence while publishing a bounded classified notice, and fail on any new/unclassified warning. If that cannot be achieved with the action's composite boundary, use the already pinned setup action plus direct CLI invocation rather than copying upstream source.

   No source PR is opened from this RCA because a naïve version bump demonstrably leaves half of the acceptance failure, while quieting or dependency installation would weaken the security boundary. This issue remains the canonical owner; no consumer workaround is authorized.
3. seonghobae commented on Sep 13, 2026

   

   seonghobae

   on Sep 13, 2026 – with ChatGPT Codex Connector

   ContributorAuthor

   More actions

   Fresh downstream reproduction on Naruon #1674 exact 24e6e80bc7341cfd4fc3a1b0af09a21f7b6eafe1, Security Scan run 34733739231, trivy-fs job 103661531163 (2026-09-13):

   • WARN [pip] Unable to find python site-packages directory. License detection is skipped.
   • Trivy update notice: current 0.70.0, available 0.74.0.
   • The actual gate then correctly failed on the three inherited frontend findings (CVE-2026-75604, GHSA-2xp9-vwfh-vxw4, GHSA-rgj7-g3m4-5g8c).

   This confirms the warning/version-drift noise persists independently of the real vulnerability failure. No Naruon-local suppression or workflow copy was added.
4. seonghobae commented on Sep 13, 2026

   

   seonghobae

   on Sep 13, 2026

   ContributorAuthor

   More actions

   Root-cause check against the scanner source (read-only, 2026-09-13):

   1. The site-packages WARN is not gated by the license scanner. In Trivy v0.70.0 (the version the pinned trivy-action@a9c7b0f… v0.36.0 currently runs) pkg/fanal/analyzer/language/python/pip/pip.go calls pythonSitePackagesDir() unconditionally at the top of PostAnalyze and logs Unable to find python \site-packages` directory. License detection is skipped.whenever no venv/python executable is found — before it even looks at--scanners. Our trivy-fslane runsscanners: vuln,secret,misconfig, so license detection is never requested, yet the analyzer still attempts it. The same code is unchanged in v0.74.0 (pip.go:58-61`), so a version bump alone does not remove this warning.
   2. The version notice is real drift, not noise: aquasecurity/trivy-action latest release is still v0.36.0 (2026-04-22), i.e. our action pin is current, but the action's version input selects the Trivy binary; the run used 0.70.0 while 0.74.0 is available.

   Options that do not weaken the gate (materializing site-packages just to silence a license path we do not use is not one of them):

   • (a) Upstream: ask Trivy to skip pythonSitePackagesDir() unless the license scanner is enabled (--scanners license / --license-full). That is the root-cause fix for warning 1; until it lands, the warning is an accepted-with-owner upstream defect and should stay tracked here, not suppressed.
   • (b) Central: set the action's version input explicitly to the current Trivy release after checking its changelog for scanner/SARIF behaviour changes, and add the pin to the existing runner/image contract tests so drift becomes a test failure rather than a log notice. This removes warning 2 only.

   Not changed in this session: security-scan.yml is currently being modified by #2143 (OSV flags, same file), so a Trivy edit should sequence after it to avoid a hot-file conflict. Next review date for this issue: 2026-09-20 (same as #2142, both are security-scan.yml runtime-quality items).