Integrate osv-scanner workflow

[smoy]

Integrate osv-scanner github action to leverage the vulnerability scanner on every pr

This is an example if osv-scanner find something

[rng1995]

[Automated SkillSpector Review]

Requesting changes. The reusable OSV workflows are commit-pinned and CI is green, but shipping a repository-wide malware advisory exception is not justified. Package removal does not make a locked or vendored malicious dependency safe; remove the exception or provide narrowly scoped, evidence-backed, time-bounded handling that cannot hide a real dependency finding.

[rng1995]

[Automated SkillSpector Review]

Re-review of the osv-scanner integration (head 4061582). The PR adds .github/workflows/osv-scanner-unified-workflow.yml (commit-pinned reusable workflows from google/osv-scanner-action @ 3adb4b1, comment v2.3.8) and an osv-scanner.toml ignore for MAL-2026-6561.

Prior-issue resolution checklist

• Global suppression of MAL-2026-6561 in osv-scanner.toml (blocking, 2026-07-09): Resolved. Commit 4061582 adds ignoreUntil = 2026-07-20, making the exception time-bounded, and the author opened issue #240 to pursue PyPI namespace transfer. Independent verification: OSV advisory MAL-2026-6561 covers only the PyPI package skillspector — a malicious impersonation of this repository — with affected versions 0.0.1–0.0.4 and 2.3.7–2.3.10. This repo consumes skillspector exclusively as a local editable package (uv.lock: source = { editable = "." }), never from PyPI, so the finding is a self-name-match false positive and the expiring, single-advisory ignore cannot hide a real third-party dependency vulnerability. Non-blocking nit: the reason field still says "pypi has already removed it", which is not the actual justification — it should state that this repo is the legitimate upstream being impersonated and does not install skillspector from PyPI.

New blockers

1. The OSV-Scanner workflow does not run on the current head. Workflow run 29040163397 (pull_request, head 4061582) concluded startup_failure with 0 jobs. The workflow YAML is syntactically valid and both osv-scanner-reusable.yml and osv-scanner-reusable-pr.yml exist at pinned SHA 3adb4b1 (verified via the GitHub API), so the most likely cause is the repository/organization GitHub Actions policy not permitting google/osv-scanner-action reusable workflows. As-is, merging adds a check that fails on every PR (and on pushes to main) while providing no scanning. Please work with maintainers to allowlist the action (or inline the scan steps) and demonstrate a green OSV-Scanner run on this PR before merge.

Non-blocking notes

• ignoreUntil = 2026-07-20 is six days out; when it lapses, MAL-2026-6561 will fail PR scans again unless the PyPI namespace issue is resolved or the entry is consciously renewed. Also note main is now at version 2.3.11, which is not in the advisory's affected versions, so after a rebase the entry may become unnecessary — worth re-checking then.
• The base CI workflow on this head is action_required (awaiting maintainer approval), so CI is unverified on the new commit; the commit only touches osv-scanner.toml, so risk to the test suite is minimal.

[rng1995]

The pull_request run of this workflow on the current head concluded startup_failure with 0 jobs (run 29040163397). The YAML is valid and both reusable workflows exist at pinned SHA 3adb4b1, so this is most likely the org/repo Actions policy not allowing google/osv-scanner-action reusable workflows. Please get the action allowlisted (or inline the scan steps) and show a green OSV-Scanner run on this PR — as written, this check will fail on every PR without performing any scan.

[smoy]

@rng1995

this is a sample run of the pr workflow in my fork showing a green run: https://github.com/smoy/SkillSpector/actions/runs/29359037710/job/87174081468?pr=9

Can you handle the action allowlisted?