Add OSV 1.7.5 parsing support

[TooFastTooCurious]

Summary

Updates pkg/advisory to parse and match OSV-shaped advisory data. Pairs with the data migration in JulietSecurity/abom-advisories#6. See #3 for the design discussion.

Struct layout change

BEFORE (legacy ABOM format)           AFTER (OSV 1.7.5)
┌─────────────────────────┐          ┌─────────────────────────────┐
│ Advisory                │          │ Advisory                    │
│   ID                    │          │   SchemaVersion             │
│   Title                 │          │   ID                        │
│   CVE                   │          │   Modified                  │
│   CVSS (float64)        │          │   Published                 │
│   Published             │          │   Withdrawn                 │
│   Updated               │          │   Aliases []                │
│   Status                │   ====>  │   Summary                   │
│   Description           │          │   Details                   │
│   References []string   │          │   Severity   []Severity     │
│   AffectedActions []    │          │   Affected   []Affected     │
│     .Uses               │          │     .Package{Ecosystem,Name}│
│     .AffectedRefs       │          │     .Ranges[].Events[]      │
│       .TagRange         │          │     .Versions[]             │
│       .SafeTags         │          │     .EcosystemSpecific.ABOM │
│       .Tags             │          │   References []Reference    │
│     .ToolNames          │          │   DatabaseSpecific.ABOM     │
│     .AffectedPeriod     │          └─────────────────────────────┘
│   Indicators            │
│   RecommendedActions    │
└─────────────────────────┘

ABOM-specific extensions preserved under two OSV-sanctioned namespaces:

• ecosystem_specific.abom (per-package, GitHub Actions flavor): tool_names, affected_period
• database_specific.abom (advisory-wide): indicators, recommended_actions

Matching logic change

The old matcher parsed a string like ">=v0.0.1 <=v0.34.2" into bounds. The new matcher walks OSV events in declaration order, tracking whether the version is inside an affected window:

events: [{introduced: v0.0.1}, {fixed: v0.35.0}]

walk for version v0.20.0:
  event 1: introduced = v0.0.1, v0.20.0 >= v0.0.1 => affected = true
  event 2: fixed      = v0.35.0, v0.20.0 >= v0.35.0 false, affected stays true
  result: true (compromised)

walk for version v0.35.0:
  event 1: introduced = v0.0.1, v0.35.0 >= v0.0.1 => affected = true
  event 2: fixed      = v0.35.0, v0.35.0 >= v0.35.0 => affected = false
  result: false (not affected)

Same shape works for multi-cycle ranges (introduced, fixed, introduced, fixed), the 0 sentinel for "from the beginning," and the last_affected event type. All covered by new tests.

Public API is stable

External callers use only three things:

• advisory.NewDatabase(LoadOptions) *Database
• advisory.LoadOptions{Offline, NoCache, Quiet, Token}
• (*Database).CheckAll(*model.ABOM)

None of those signatures changed. cmd/scan.go and cmd/check.go compile and run unchanged.

Tests

All existing tests ported to the new API plus new coverage for OSV-specific semantics:

• TestMatchesRange for core introduced/fixed walking
• TestMatchesRange_IntroducedZero for the OSV "0" sentinel
• TestMatchesRange_LastAffected for the last_affected event type
• TestBuiltinDataIsOSV as a shape sanity check on the embedded data
• TestCheck_TrivyActionVulnerable now also exercises tj-actions entries

SHA-pinned refs

Same policy as before: flagged as verify-sha since ordinal comparison against tag ranges is not meaningful for SHAs. The affected_period in ecosystem_specific.abom is available for time-based correlation, but wiring that in is a follow-up.

Coordination with advisories#6

Merging this before the advisories PR means abom fetches legacy JSON from the remote, the parser rejects it, and users fall back to the built-in snapshot (now OSV). Graceful degradation, not ideal.

Merging advisories#6 before this means abom fetches OSV JSON, the current parser rejects it, users fall back to the old built-in snapshot. Also graceful degradation.

Either order works. Merging close together minimizes the degraded window. I would suggest advisories#6 first since Ben is reviewing it, then this.

Follow-ups not in this PR

• CVSS vector backfill is already in the data migration (NVD-authoritative). No abom-side work needed.
• SHA-pinned-ref matching against affected_period for time correlation: possible future enhancement.
• Dropping legacy format handling from older abom releases: no-op since we never had formal legacy compat.

Files changed

pkg/advisory/advisory.go              +376 / -228  (rewrite)
pkg/advisory/advisory_test.go         +148 / -22   (updated + new cases)
pkg/advisory/builtin_advisories.json  +176 / -35   (format migration)

[TooFastTooCurious]

@funnelfiasco heads-up that the abom-side parser update is open here, pairs with advisories#6. Not asking for a formal review given the Go-heavy internals, just wanted you in the loop.

[funnelfiasco]

LGTM