snapshot/2026-05-04 — Detection-spec axis at 100% Technique coverage

snapshot/2026-05-04 — Detection-spec axis at 100% Technique coverage

This snapshot cuts a stable reference point on main for the v0.1 detection-spec axis. Downstream consumers (oak-mcp, third-party detectors, audit-firm coverage matrices) can pin to this snapshot tag.

What landed in this snapshot

A new specs/ axis carries vendor-neutral, language-agnostic YAML detection specs alongside techniques/. Each spec captures the Technique's detection logic as orthogonal PATH A / PATH B / ... pseudocode plus data_sources, parameters, test_fixtures.{positive,negative}, false_positive_modes, mitigations cross-refs, and reference_implementations (named candidate vendors per chain — labelled aspirational where the link is not yet wired). Schema is declarative detection-rule shape; the closest existing-format analogue is Sigma (vendor-neutral YAML detection rules aligned to MITRE ATT&CK), with OAK specs aligned to OAK Techniques the same way.

Per VERSIONING.md this is a schema-minor bump (0.5 → 0.6); existing axes unchanged, the addition is additive.

Coverage

• 98 specs / 98 Techniques — 100% coverage across all 17 Tactics
• Maturity distribution: 36 stable · 21 observed · 37 emerging · 4 draft
• The conservative draft floor is held only where the Technique is itself draft and no positive fixture exists yet; the validator (tools/build_specs.py) refuses stable without a positive fixture
• Per-Tactic browseable index: SPECS.md

New tooling

• tools/build_specs.py — parses specs/*.yml with required-field validation, technique-ID cross-checks against oak.json, fixture-existence checks against examples/, 5-value maturity vocabulary
• tools/check_specs.py — per-Tactic coverage validator with --strict / --require-maturity / --json / --gaps-only / --by-tactic modes; wired into npm run site:data as advisory
• tools/build_specs_index.py — auto-generates SPECS.md repo-side index grouped by Tactic

Embedded snapshot extension

tools/embedded.json (consumed by oak-mcp and the React UI) gains specs, specs_by_technique, and spec_yaml fields. Per-Technique pages on the website render a DetectionSpecSection block with the spec body, parameters table, syntax-highlighted YAML/pseudocode, and reference-impl candidates note.

MCP server v0.3

oak-mcp ships a new oak_get_detection_spec(id, include_yaml?) tool exposing the spec axis to LLM clients. Tests at 17/17 (12 prior + 5 new). See oak-mcp/CHANGELOG.md.

Conventions established

• Pseudocode style. All specs use PATH A / PATH B / PATH C ... orthogonal-detection-path naming with consistent emit-shape (emit(PATH_X, ..., severity=...)); parameters carry type + default; mitigations cross-reference the existing OAK-M01..M40 catalogue
• Reference-implementation labelling. Named vendor targets are listed in reference_implementations with chain qualifier; url: "" indicates an aspirational / not-yet-wired entry rather than a live integration. The UI surfaces this distinction explicitly to avoid the false-credibility trap of fabricated URLs

Validators clean

build_specs.py, check_specs.py, npm run site:data, and tsc --noEmit all pass at 0 hard failures. Schema 0.6 is additive; downstream consumers pinned to 0.5 must update to 0.6 to consume the specs/ axis but no field semantics on prior axes changed.

What's not in this snapshot

• v0.1.0 proper — non-content blockers per CHANGELOG.md (visual identity, landing page, peer-review outreach, US trademark review) are still open
• Mitigation-spec layer — symmetric closure for the 40 OAK-M* entries is a v0.x candidate
• COVERAGE.md update against new T15-T17 Techniques — separate impl-coverage refactor pending

Pinning convention

Downstream consumers should pin snapshots by tag, not by commit hash. Subsequent snapshots will follow snapshot/YYYY-MM-DD per VERSIONING.md.