chore: seeded fixture DB for deterministic e2e tests and scenario library

[sonukapoor]

Problem

The e2e test suite currently scans against the real advisory DB in the cache. Any fixture that pins a real package name picks up that package's live CVEs and flips "clean" tests whenever a new advisory lands. A fresh checkout with no synced DB fails most offline e2e tests entirely.

This was deferred during the v1.25.0 merge rather than folded into the release PRs. Issues #726 and #727 address the immediate breakage (CVE-free fixture names), but leave two gaps open:

• A fresh checkout with no synced DB still fails most offline e2e tests
• Broad-shape tests still read the live DB and drift over time

Proposed solution

A small seeded fixture DB consumed via --offline-db, built once and committed to the repo. The machinery already exists: LocalAdvisoryDatabase.bulkUpsertVulnerabilities and the builder in global-setup.mjs.

The seeded DB contains a curated, deterministic set of advisories - one per scenario, covering the full range of finding types the test suite needs to verify.

Triple-duty design

The same seeded scenario set serves three purposes:

1. e2e fixtures - deterministic, network-free, never drifts with live OSV data
2. Educational reference - one clear worked example per rule class (direct, transitive, override hygiene rules OA001-OA009, PD001/PD002, DM001 as those ship)
3. Benchmark pool - stable baseline for performance comparisons across releases

Scenario structure

Each scenario is a self-contained directory:

examples/scenarios/
  direct-fixable/          # one direct dep with a known fix
  transitive-path/         # transitive dep with clear parent upgrade path
  override-oa001/          # orphaned override target
  override-oa009/          # stale >= floor (new)
  phantom-pd001/           # import-only-via-override
  maintenance-dm001/       # abandonware with downstream drag
  ...

Each contains a minimal package.json, lockfile, and the corresponding seeded advisory entries. The global test setup loads the seeded DB once; all e2e tests point at --offline-db instead of the live cache.

Acceptance criteria

• Fresh checkout passes all e2e tests without a network advisory sync
• Tests do not flip when new CVEs land in OSV for real package names
• Seeded DB covers all existing e2e scenario types
• Scenario directories are usable standalone as educational examples
• Builder is automated - adding a new scenario does not require manual DB editing

Related

Raised by Aaron Lamb during v1.25.0 integration. Connected to #726 and #727 (immediate fixture breakage). Scenario set will expand as OA009 (#730), PD001/PD002 (#731), and DM001 (#732) ship.

[Ayush7614]

Checked status before picking this up:

• Open PR: none on OWASP/cve-lite-cli referencing chore: seeded fixture DB for deterministic e2e tests and scenario library #734
• Branch/work: no matching branch on OWASP or contributor forks; examples/scenarios/ and a committed seeded fixture DB are not in main yet
• Related immediate fixes: fix(tests): e2e fixtures fail when new CVEs appear that match clean-project packages #726 (closed) and fix(tests): use CVE-free fixture packages so clean-scan e2e tests don't depend on the advisory DB #727 (merged) addressed CVE-free fixture names, but the deterministic --offline-db seeded DB described here is still outstanding
• Blockers/dependencies: scenario set is expected to expand as OA009 (feat: detect stale override floors that no longer change the resolved version (OA009) #730), PD001/PD002 (feat: detect phantom dependencies - packages imported but not declared (PD001/PD002) #731), and DM001 (feat: maintenance risk scoring for abandonware and downstream dependency drag (DM001) #732) land

Infrastructure pieces exist today (--offline-db, LocalAdvisoryDatabase.bulkUpsertVulnerabilities, e2e global setup), but the curated seeded DB + scenario library from the acceptance criteria are not implemented yet.

@sonukapoor — could this be assigned? Happy to take #734 if no one else is already working on it.

[sonukapoor]

Thanks for the detailed status check, @Ayush7614.

The seeded fixture DB (#734) is being handled in-house — it's tightly coupled to the engine sub-issues (#730, #731, #732) and the fixture schema will need to evolve as each rule lands. Opening it up for contributions before that shape is defined would create a lot of rework. We'll revisit once the engine is further along.