Add OSV-Scanner-based security workflow

[vikrantpuppala]

Summary

• Adds .github/workflows/securityScan.yml — single workflow, single job, three triggers (PR / weekly cron / manual). PR runs fail on CVSS ≥ 7 only; weekly runs report all findings and email the team.
• Adds osv-scanner.toml — empty suppressions file (populate iteratively as real false positives surface).
• Reuses the existing ./.github/actions/setup-jfrog composite action — no duplicate OIDC-token logic.

Mirrors the JDBC driver's workflow (databricks-jdbc#1460), adapted for Go: reads go.mod natively via OSV-Scanner (no separate SBOM tool needed).

Day-one results

The workflow is not yet wired into branch protection, so its first PR-time runs are advisory. A dry-run against current main surfaces:

• 5 HIGH (CVSS ≥ 7) — golang-jwt/jwt/v5@5.2.1, apache/thrift@0.17.0, golang.org/x/crypto@0.31.0, golang.org/x/oauth2@0.7.0, google.golang.org/protobuf@1.28.1
• 5 MEDIUM, 60 LOW (mostly stdlib@1.20.99 advisories — addressed by bumping the Go toolchain)

All are legitimate findings, not false positives. A follow-up dep-bump PR will clear them. Once that's green, branch protection can be flipped to require this check.

Test plan

• Dry-run OSV-Scanner v2.3.8 locally against go.mod — produces expected findings
• YAML validates
• First CI run on this PR exercises the PR path (will fail by design — the 5 HIGHs above)
• Manual workflow_dispatch after merge exercises the weekly path
• Secrets (SMTP_USERNAME, SMTP_PASSWORD, EMAIL_RECIPIENTS) wired in repo settings before the first scheduled run

This pull request was AI-assisted by Isaac.

[gopalldb]

📄 .github/workflows/securityScan.yml (file-level)

▎ ⚠️ [MAJOR] Empty max_severity silently bypasses the CVSS>=7 PR gate (fail-open) — bug | logical_claude_agent
▎
▎ HIGH findings with an empty max_severity are counted as severity 0, silently passing the PR gate. At securityScan.yml:112 the pipeline uses severity: (.max_severity // "0"), but jq's // only substitutes null/false — an empty string "" is truthy and passes through unchanged. Then at :121 "" | tonumber? // 0 evaluates to 0, so the finding is excluded from high_count. OSV-Scanner commonly emits an empty max_severity for advisory groups that lack a CVSS vector (frequently the Go vuln DB GO-xxxx groups), even when the true CVSS score is present on a duplicate GHSA group or in the per-vuln .severities[] array that this pipeline never inspects. A real CVSS>=7 vulnerability can therefore land with high_count=0, turning the high_count != '0' PR gate (:164) green while a genuine HIGH exists — a silent fail-open of the exact check this workflow is built to enforce.
▎
▎ 💡 Suggested Fix: Do not rely on group-level max_severity alone. Treat an empty/missing max_severity as unknown and fall back to the maximum numeric CVSS across the group's vulnerabilities' .severities[] scores (and across duplicate GHSA groups), rather than coercing empty to 0. Concretely: when max_severity is empty, compute severity from the per-vuln .severities[].score entries; and/or treat any finding whose severity cannot be resolved to a number as suspicious (surface it in high_count or fail explicitly) instead of silently scoring it 0.

📄 .github/workflows/securityScan.yml (Line 89)

▎ ⚠️ [MAJOR] Scanner exit code discarded; errored/partial OSV output can silently pass the gate — bug | logical_claude_agent
▎
▎ A failed OSV-Scanner run that still writes an empty-results JSON is indistinguishable from a clean scan, silently passing the gate. At securityScan.yml:82-87 the scan is run with || true, discarding OSV-Scanner's exit code, and the only robustness check (:89) is [ ! -s /tmp/osv-out.json ] — file non-emptiness. If the scanner errors mid-run (network failure reaching OSV.dev, partial database load, etc.) but still emits a syntactically valid {"results":[]} (or {"results":[{...,"packages":[]}]}), the file is non-empty so the guard passes, and the downstream Collect step parses it to total_findings=0/high_count=0 — identical to a genuinely clean scan. The workflow never inspects OSV's exit status nor asserts that .results came from a completed scan, so an errored scan fails open (gate goes green with no vulnerabilities reported). (Note: a {"results":null} output would instead error in jq and fail closed via empty outputs; the live fail-open is the empty-but-valid-array case.)
▎
▎ 💡 Suggested Fix: Capture and check OSV-Scanner's exit code explicitly instead of blanket || true: OSV-Scanner uses distinct exit codes (0 = no vulns, 1 = vulns found, and other non-zero/128+ codes = scanner errors). Tolerate only the 'vulns found' code and treat any error exit as a hard failure of the job. Additionally validate the JSON shape before parsing (e.g. assert .results is present and is an array via jq -e 'has("results") and (.results|type=="array")') so a malformed or partial output fails the step rather than being read as zero findings.

[vikrantpuppala]

Thanks for the review — both [MAJOR] findings were real fail-open holes. Addressed both, plus a related issue they surfaced. Summary:

1. Empty max_severity bypassed the CVSS≥7 gate (fail-open)

Fixed in f691171. The gate no longer trusts group-level max_severity alone:

1. Try group max_severity (numeric only; empty "" → null via try (x|tonumber) catch null, not tonumber? — the latter yields empty inside a jq binding and would silently drop the whole finding row).
2. Fall back to the max CVSS across the group's vulnerabilities[].severities[].score.
3. If still unresolved → sentinel UNKNOWN, never scored 0.

UNKNOWN findings on third-party packages are treated as blocking (so scoreless GHSA-only / MAL-* malware advisories fail the gate). Scoreless stdlib advisories are report-only — see note below.

2. Scanner exit code discarded; errored/partial output passed the gate (fail-open)

Fixed in f691171. Replaced || true with || scan_rc=$?; we now tolerate only exit 0 (clean) and 1 (findings present) and fail closed on any other exit code. Added a jq -e 'has("results") and (.results | type == "array")' shape check so a truncated/partial-but-non-empty JSON is rejected rather than parsed as zero findings. The count-derivation step also fails closed if the counts don't resolve to integers.

Related: scoreless stdlib advisories

Once (1) was fixed, ~39 scoreless Go-vuln-DB stdlib advisories (flagged against the go 1.25.0 directive floor) correctly stopped scoring 0. Rather than inflate the customer-facing floor to the latest patch purely to silence the scanner (which also created a CI-toolchain maintenance treadmill), the gate now treats scoreless stdlib findings as report-only: they're Go stdlib advisories delivered to consumers via GOTOOLCHAIN patch auto-download, not a real exposure of the module. Scoreless non-stdlib findings still block. Gate = (CVSS≥7) OR (UNKNOWN and not is_stdlib).

One genuinely-unfixable third-party advisory remains — GO-2026-5932 (golang.org/x/crypto/openpgp, "unmaintained/unsafe by design", no fixed version ever). We don't import openpgp (verified via go list -deps ./... — we use chacha20poly1305/pbkdf2/cryptobyte only), so it's suppressed in osv-scanner.toml with an expiring ignoreUntil (2027-01-02) so the ignore isn't permanent and gets re-reviewed.

Verified locally with osv-scanner v2.3.8: real scan → 39 stdlib UNKNOWNs, all report-only, 0 blocking; synthetic mix (malware + CVSS 9.1 + stdlib) → malware & 9.1 block, stdlib does not. Security Scan CI job is now green.