Build a vulnerable-function watchlist from advisories #52

To check a vulnerable function at runtime, the sensor first needs its name. Add secfoo runtime watchlist --project <name> -o watchlist.json, which builds the list for a project's open SCA findings.

Sources, in priority order:

1. OSV affected[].ecosystem_specific.imports[].symbols. Go advisories fill this in well. The raw OSV records are already cached in the osv_lookups.vulns_json column, so no new network calls are needed.
2. The GitHub advisory REST API's vulnerabilities[].vulnerable_functions. It is often empty and needs no auth for public advisories, but respect rate limits and keep it optional.
3. When neither source has symbols: put the package in the watchlist with "symbols": [] and "granularity": "package". The sensor then only records whether the package was imported or used.

Format (proposal, please discuss in the thread before building):

{
  "version": 1,
  "generated_at": "2026-11-08T12:00:00Z",
  "entries": [
    {
      "finding_fingerprint": "<sca_findings.fingerprint>",
      "advisory": "GHSA-xxxx-xxxx-xxxx",
      "ecosystem": "PyPI",
      "package": "pyyaml",
      "version": "5.3",
      "granularity": "symbol",
      "symbols": ["yaml.load", "yaml.unsafe_load"],
      "source": "osv"
    }
  ]
}

Symbol notation per ecosystem. Probes in every runtime (#51) match on these exact forms, so normalise advisory symbols into them:

When a symbol can't be normalised, keep the entry at "granularity": "package". Never drop it.

Where to look: src/secfoo/osv.py, src/secfoo/report/sca.py (fingerprint_for_row), the osv_lookups and sca_findings tables in src/secfoo/storage/schema.sql.

Done when: there's a JSON Schema for the file in src/secfoo/runtime/, and tests use fixture OSV records with and without symbols (no network).