An open-source Go security-platform lab that turns dependency evidence into explainable, reviewable remediation priorities. The current slice queries OSV, enriches findings with optional KEV data, applies deterministic policy, and preserves replayable results.
Deterministic replay of linked tests—not live telemetry.
Expected test outcome
The synthetic advisory is normalized, classified as critical from declared known-exploited context, stored, and retrieved with the same scan identifier.
Deterministic unit-test replay—not a live OSV or KEV request, HTTP end-to-end run, durable-storage proof, or automated remediation.
01Declare the synthetic componentThe test submits one Go component with a fixed name, version, ecosystem, and project identifier.input
02Inject vulnerability evidenceA deterministic HTTP transport returns one advisory with a fixed version instead of contacting the public OSV service.processing
03Apply the policy boundaryThe declared known-exploited context promotes the finding to critical without model-generated reasoning.recovery
04Store and retrieve the resultThe memory store returns the same scan identifier, proving replayable result persistence within this test boundary.verified
Animation is paused. The Previous and Next controls keep every step available.
Evidence-to-policy replay: step 1 of 4. Declare the synthetic component. The test submits one Go component with a fixed name, version, ecosystem, and project identifier.
4 / 4
public Go tests passing
The checked suite covers injected OSV normalization, fixed-version extraction, known-exploited alias priority, and in-memory result persistence and retrieval.
GitHub Actions ubuntu-latest · Go 1.26.4 · synthetic in-process fixtures
Snapshot
Limit
Small deterministic fixtures; no production deployment, live-catalog reliability, throughput, or exploit-capability claim.
1 → 1
scan result stored and retrieved
One synthetic component scan uses an injected OSV response, applies deterministic policy, writes the result to the memory store, and retrieves the same result identifier.
GitHub Actions ubuntu-latest · Go 1.26.4 · injected HTTP transport · memory store
Snapshot
Limit
In-process memory-store proof; it does not exercise the public HTTP handlers, durable storage, concurrency, or a multi-user deployment.
critical
known-exploited alias policy outcome
A synthetic advisory alias present in the injected known-exploited map is deterministically promoted to critical priority and retains its known-exploited marker.
GitHub Actions ubuntu-latest · Go 1.26.4 · synthetic known-exploited map
Snapshot
Limit
Deterministic policy-unit proof; it does not validate freshness, completeness, or availability of the live CISA KEV catalog.
Problem
The engineering question
A vulnerability list is not yet a remediation decision. The current harness connects an affected component, source evidence, known-exploitation context, fixed versions, policy rationale, and a replayable result; human approval remains a boundary for future remediation work.
Constraints
What the design must respect
The public default is read-only and must not probe arbitrary hosts or execute exploit payloads.
Every recommendation must be explainable from captured source evidence.
Fixtures and examples must remain synthetic and free of employer code, data, identifiers, or secrets.
Architecture decisions
Deliberate choices and why they exist
01
Evidence before model output
OSV results and policy decisions are first-class records; future model output can only propose structured actions from that evidence.
02
Deterministic policy boundary
Known-exploited and fixed-version signals are translated into explicit priorities and rationales before any human-gated automation is introduced.
03
Transport-injected verification
The OSV client uses injectable HTTP transport so tests are deterministic and do not depend on public network availability.
Failure modes
Designed to fail visibly
Malformed or oversized scan input.
Vulnerability catalog outage or response drift.
A known exploited alias missed during normalization.
A remediation recommendation that lacks a fixed version or validation evidence.
Verification
How claims are checked
Go unit tests for OSV normalization and fixed-version extraction.
Policy tests for known-exploited aliases and fixed-version priority.
Service tests proving results are stored and replayable.
Go vet and GitHub Actions checks.
Limitations
What remains unproven
CycloneDX ingestion, PostgreSQL persistence, isolated validation workers, and the constrained AI agent are planned next slices.
No production deployment, exploit capability, or automatic repository write is claimed.
Inspect the work
Source and evidence
The repository is the source of truth for implementation status. The case study never upgrades a planned feature into a shipped claim.