[vuanhphung]

Update the security scan to OSV-Scanner v2.7.0 and refresh version-specific comments. Suppression rules and severity thresholds are unchanged.

Validation: workflow YAML, shell syntax, and whitespace checks passed; the existing JSON parser accepted v2.7.0 output. Old/new scans returned the same findings on identical inputs.

[peco-review-bot]

Verdict: 1 Low

Clean, low-risk CI version bump (OSV-Scanner v2.3.8 → v2.7.0): the download URL changes and the surrounding comments are re-labelled, with scan logic, suppressions, and thresholds untouched. One low note — the comment's claim that v2.7.0 still lacks per-package CVE scoping was carried over mechanically and drives the suppression strategy, so it's worth a quick schema check before merge.

Nit (not blocking, and pre-existing — not introduced here): the install step curls the scanner binary with no checksum/signature pin (securityScan.yml:67-70). For a security-gating workflow, pinning the v2.7.0 asset's SHA256 would harden the toolchain against a tampered/substituted release artifact; the version bump is a natural moment to add it.

[peco-review-bot]

🔵 Low — This behavioral claim (and the ignoreUntil "honors it natively" claim at line 21) was mechanically re-labelled from v2.3.8 to v2.7.0 along with the version string, but a 4-minor-version jump is exactly where tool config semantics can change. Unlike the pure doc-comment edits in securityScan.yml, this one asserts a capability gap that justifies the project's suppression strategy (global [[IgnoredVulns]] over per-package scoping). If v2.7.0 has since added per-package CVE scoping, the comment now steers maintainers toward a strictly broader (less safe) suppression than necessary.

The ignoreUntil claim is implicitly corroborated by the PR's "old/new scans returned the same findings" (the braces suppression still applied), but the intersection/per-package claim is not exercised by any existing entry, so nothing in the validation actually confirms it. Worth a quick check against the v2.7.0 configuration schema before merge; if it still holds, no change needed. (I could not verify externally — web tools are disabled in this review environment.)

[github-actions]

Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase (git rebase -i main).

[peco-review-bot]

Verdict: 1 Low

Looks good: a version bump plus matching comment updates, with no change to the gating logic. One low suggestion: add a checksum check to the binary download that this PR touches.

[peco-review-bot]

Verdict: 1 Low

Looks good: a simple version bump with the matching comment updates, and suppression rules and thresholds are unchanged. One low-severity suggestion: pin a SHA-256 for the downloaded scanner binary while this line is being changed.

[peco-review-bot]

🔵 Low — The new v2.7.0 binary is fetched with curl and run straight away, with no integrity check. This gap existed before the PR, but this line is the one being changed, so it is a cheap time to close it. Someone who can tamper with the release asset or the download path could run any code they like on the protected runner group. That job also holds id-token: write, so it could mint JFrog OIDC tokens, and it could make the scan report clean. The repo already pins every action to a commit SHA, so pinning the binary's digest fits that convention. Get the SHA-256 for osv-scanner_linux_amd64 from the release's checksums file, hardcode it, and check it before the chmod. For example:

echo "<sha256>  /tmp/osv-scanner" | sha256sum -c -

That also gives you one place to update on the next version bump.