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

[seonghobae]

Fresh downstream evidence

Naruon central Security Scan run 34686593891 at exact ContextualWisdomLab/naruon@17c0a5c9198eeda95f6a7d86f6a35a8b05abe774 checked out the exact head correctly, but its shared trivy-fs lane emitted two non-finding diagnostics before the real vulnerability gate:

WARN [pip] Unable to find python `site-packages` directory. License detection is skipped. err="site-packages directory not found"
Notices:
- Version 0.74.0 of Trivy is now available, current version is 0.70.0

The same run then correctly failed on three inherited frontend findings (CVE-2026-75604, GHSA-2xp9-vwfh-vxw4, GHSA-rgj7-g3m4-5g8c), so this issue is not a request to weaken the vulnerability gate or to fix Naruon dependency ownership here.

Problem

The required security workflow currently accepts scanner/runtime warning and version-drift output as routine noise. CWL execution policy treats warnings/deprecation/notice drift as actionable evidence: either remove the root cause or track it explicitly. Leaving it in every downstream run makes real regressions harder to distinguish and leaves the scanner freshness policy implicit.

Required owner repair

1. Determine why the central Trivy filesystem configuration attempts Python license detection without a materialized site-packages tree.
2. Choose and document the intended contract:
   • if license evidence is required, materialize the dependency metadata deterministically before scan; or
   • if license evidence is not part of this lane, configure the scanner so it does not enter an unsupported license-detection path. Do not merely hide stderr.
3. Re-evaluate the pinned Trivy v0.70.0 against current v0.74.0; upgrade through the normal pinned-SHA/versioned owner path if compatible, with fixtures proving SARIF/fail-closed parity. If the old pin is deliberately retained, record the compatibility reason and an explicit freshness/revisit condition rather than tolerating the update notice indefinitely.
4. Preserve exact-head checkout verification, CRITICAL,HIGH,MEDIUM fail-closed findings, SARIF upload, and shared-base remediation ownership.
5. Add an executable regression that fails if the required lane emits unexpected WARN/deprecation/version-drift diagnostics.

GREEN acceptance

• a current exact-head downstream Security Scan is warning/notice-clean before actual findings;
• vulnerability findings still fail the gate and retain their severity/location evidence;
• scanner version/pin provenance is explicit and reproducible;
• no consumer repository copies or locally patches the central workflow to obtain silence.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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).