fix(osv-scanner): stop OSV PR scan hitting the 1MB job-outputs cap

[seonghobae]

Problem (infra failure)

The OSV-Scanner PR workflow's osv-scan job fails with:

Job outputs exceed the maximum length of 1,048,576 bytes

Root cause is in the upstream reusable workflow we pin, google/osv-scanner-action/.github/workflows/osv-scanner-reusable-pr.yml@v2.3.8. Its osv-scan job declares:

outputs:
  old-results: ${{ steps.export.outputs.old-results }}
  new-results: ${{ steps.export.outputs.new-results }}

and its "Export results" step cats the full old/new osv-scanner JSON (advisory text, references, every severity and ecosystem) into $GITHUB_OUTPUT unconditionally. Those two job outputs are subject to GitHub's 1MB job-outputs cap, and verbose scans blow past it — so the job errors out before it can finish. Our caller doesn't even consume old-results / new-results, so this is pure overhead.

The problematic logic lives entirely inside the external pinned workflow, so it can't be fixed with the with: inputs v2.3.8 exposes.

Fix (minimal)

Bump the pinned SHA from 9a49870 (v2.3.8) to 3a7550f — which is v2.3.8 plus exactly one upstream commit, feat: gate reusable workflow outputs with a flag. That commit:

• adds an export-results input, default false, and
• gates the Export step with if: ${{ inputs.export-results }}.

We don't set export-results, so it defaults off, the full-JSON export step is skipped, the old-results / new-results job outputs stay empty, and the 1MB cap is never hit.

3a7550f is 1 commit ahead / 0 behind the v2.3.8 tag, with byte-identical nested action pins (osv-scanner-action, osv-reporter-action, checkout, upload-artifact, codeql-action — all the same SHAs as v2.3.8). The only behavioral delta is the output gate. Diff is one pin line + a comment.

Security signal preserved

• SARIF is still generated by osv-reporter and uploaded to Security > Code Scanning (upload-sarif step unchanged).
• SARIF + old/new JSON artifacts are still uploaded.
• gh-annotations still fire on the PR.
• Org merge gating is done by the code_scanning ruleset (medium_or_higher) reading that SARIF — unaffected. This PR does not touch fail-on-vuln: false, so the existing gating policy is unchanged. Real CRITICAL/HIGH findings still surface in code scanning and still block via the ruleset.

Only the redundant, oversized JSON job outputs (which nothing consumed) are dropped.

🤖 Generated with Claude Code