fix: route failing scanner commands to stderr

[lindycoder]

The scan CLI's failure telemetry reports a command's stderr, not stdout, so scanner failures whose error lands on stdout surface only as a bare exited with non-zero exit status: N. This makes those errors actionable again.

Trivy modules (trivy-fs, trivy-sbom, boost-sca) — the trivy post-processor detects "no language files" by reading trivy's Number of language-specific files … num=0 log line, which reaches it only because the scan command merges stderr into stdout. Simply dropping 2>&1 would regress that (an empty report can't substitute — a clean scan can also be empty; see no_venv). Instead, redirect trivy's logs to a file and emit them to both streams, preserving the real exit code:

$SETUP_PATH/trivy fs … . 2>"$LOG"
ec=$?
cat "$LOG"        # logs -> stdout: post-processor keeps its num= detection, unchanged
cat "$LOG" >&2    # logs -> stderr: the CLI now surfaces hard failures
exit "$ec"        # preserve the exit code (do NOT force exit 0)

semgrep — the Validate rules step now echoes its rejection to stderr (>&2).

osv-scalibr-sbom — dropped the stray 2>&1 on cat result.spdx.json (its post-processor reads the SPDX file, not merged logs, so this is safe).

Validated locally (trivy 0.69.2) across: no-language-files (exit 0, num=0 reaches the post-processor), scanned-clean, and hard failure (exit ≠ 0, real error on stderr). End-to-end dev validation via test-repo PRs to follow.

Part of boostsecurityio/workspace#79
Jira: BOOSTSP-795

[Franck-Boost]

@lindycoder shouldn't the trivy-image and the trivy-image-sbom modules be updated as well ?

[lindycoder]

@Franck-Boost the fact that those did not have the 2>&1 log merge tells me they might not need it, i'll expand the test to those as well to check, but I would make this a separate change

[Franck-Boost]

@lindycoder based on my testing it seems to be fair to not update the trivy-image and trivy-sbom-image for the use case we support. Yet there is another use case that might requires it. I'll create an issue for that.

[lindycoder]

On the failed checks

• Azure devops timeout is normal, we don'T have parallelism, the scans succeeded
• Gitlab had a transient 500

Enough scans have run to prove the happy path is not broken