fix: reject symlinked scan result paths in PR reusable workflow

[w1j0y]

Fixes #136.

Summary

The PR reusable workflow writes the base scan to old-results.json, checks out the untrusted PR commit with git checkout -f, then writes the PR scan to new-results.json before comparing the two with the reporter. A pull request can add a symlink such as new-results.json -> old-results.json. Since the scanner and reporter write and read these paths with calls that follow symlinks, the PR scan output overwrites the base scan output, so the reporter compares the PR scan against itself and reports no newly introduced vulnerabilities. Full detail and a standalone reproduction are in #136.

Fix

Add a guard step right after the untrusted checkout that refuses to continue if old-results.json, new-results.json, or the reporter output path is a symlink.

Testing

I do not have a way to trigger this repository's CI on a fork branch before opening the PR, so I validated the guard logic locally with a shell reproduction outside GitHub Actions.

Case 1, malicious PR symlink: reproduced the git checkout -f sequence from the issue, then ran the same guard logic used in the new workflow step. It correctly refused with Refusing to scan through a symlinked result path introduced by the pull request: new-results.json and exited non zero.

Case 2, normal run with plain files: ran the same guard logic against ordinary old-results.json, new-results.json, and results.sarif files. It passed without blocking, so the change should not affect a normal scan.

This fix corresponds to a report originally submitted through Google's OSS VRP intake at g.co/vulnz. The triage response asked that it be coordinated here via a public issue and pull request, so filing accordingly.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.