Skip to content

Add OSV-Scanner-based security workflow#388

Open
vikrantpuppala wants to merge 1 commit into
mainfrom
vp/security-scan
Open

Add OSV-Scanner-based security workflow#388
vikrantpuppala wants to merge 1 commit into
mainfrom
vp/security-scan

Conversation

@vikrantpuppala
Copy link
Copy Markdown
Collaborator

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 or dev-only findings 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 Node.js: reads package-lock.json 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:

  • 22 HIGH (CVSS ≥ 7) — concentrated in form-data, basic-ftp, flatted, minimatch, thrift, ws, serialize-javascript, cross-spawn, path-to-regexp, braces, picomatch, @75lb/deep-merge
  • 15 MED, 5 LOW

Important: OSV scans both runtime and devDependencies (it treats everything in package-lock.json equally). Many of the day-one findings are dev-only (the mocha/nyc/eslint toolchain — flatted, serialize-javascript, nanoid, js-yaml, etc.) and don't reach dist/. The team has two options for those:

  1. Bump the offending dev-dep (cleanest — usually a npm update away).
  2. Add a documented [[IgnoredVulns]] entry to osv-scanner.toml justifying why the CVE is dev-only and doesn't affect shipped artifacts.

A follow-up PR can either bump deps or curate the suppression list once we triage what's runtime vs. dev.

Test plan

  • Dry-run OSV-Scanner v2.3.8 locally against package-lock.json — produces expected findings
  • YAML validates
  • First CI run on this PR exercises the PR path (will fail by design — the 22 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.

Single workflow, single job, three triggers:
  - pull_request to main: fails on CVSS >= 7 findings only
    (HIGH/CRITICAL block merges; MED/LOW visible but non-blocking)
  - cron weekly (Sunday 00:00 UTC): reports ALL findings via email
  - workflow_dispatch: behaves like cron

Mirrors the JDBC driver's security workflow (databricks-jdbc#1460)
adapted for Node.js:
  - Reads package-lock.json natively via OSV-Scanner --lockfile (no
    separate SBOM tool needed)
  - Reuses the existing ./.github/actions/setup-jfrog composite action
    for parity with main.yml (the workflow functionally doesn't need
    JFrog since OSV reads the lockfile directly, but keeping the
    composite action preserves the established pattern)
  - Suppressions in osv-scanner.toml ([[IgnoredVulns]] schema)

The workflow is not yet wired into branch protection. Day-one scan
against current main surfaces 22 HIGH / 15 MED / 5 LOW (42 total).
Many are in dev dependencies (mocha/nyc/eslint chains). The team can
either bump the offending deps or add documented [[IgnoredVulns]]
entries for dev-only findings that don't reach `dist/`.

Co-authored-by: Isaac
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant