Roadmap

Vision

BOMHort is transitioning from a single-instance SBOM visualization tool into an enterprise-grade, multi-cluster Software Supply Chain Security platform. Phase 1 (foundation, auth, multi-cluster model, push ingestion) shipped in v0.4–v0.7.

The roadmap is organised around one hard deadline — the v1.0.0 schema and API freeze — and one regulatory fact: the EU Cyber Resilience Act’s vulnerability-reporting obligations are in force since 2026-09-11, and customers already ask for a CRA-grade vulnerability register. The CRA scope therefore moved into 1.0 (re-plan 2026-09-25), and 1.0 is reached in three steps:

Two rules drive sequencing:

• If it can’t be back-filled, it lands before 1.0; if it’s additive, it lands after. The register work is additive and lands before 1.0 for market reasons, not contract reasons — the Schema Change Register says which is which.
• Issues raised by the consumer side ship first. #398 and #399 came from someone building on BOMHort; they opened v0.8.0.

Phase 1: Foundation & Security ✅

Q1–Q2 2026 · Complete. Production-ready with real security requirements.

Schema wave 014–022 — complete: document_store (#256), namespace/project (#138, #57), source_repo/source_ref (#332), VEX provenance (#334), VEX SBOM scope (#350), OSV aliases, VEX product_ref, document_version, tags (#357). 023–026 followed in v0.8.0; the v0.9.0 register work starts at 027.

Delivered beyond the roadmap: Global Search, Package Search, in-toto attestation unwrapping, protobom parsing backend, license resolution via GitHub + npm + NuGet with license-text classification, SPDX license expression evaluation (#402), dark mode, white-label theming, Prow chat-ops (#405).

Phase 2: The road to 1.0

Oct 2026 – Jan 2027 · Theme: Freeze a contract that an external consumer has already exercised (#399), and ship a CRA-grade vulnerability register inside the frozen surface rather than bolting it on after.

v0.8.0 — Contract ✅

v0.9.0 — Vulnerability register

Due 2026-11-30. The #414 umbrella: CRA Annex I Part II made queryable — per finding and per deployed version: CVE, CWE, CVSS, EPSS, KEV status, remediation status, due date, and a timestamp proving it is current.

v1.0.0 — Freeze + CRA dashboard

Due 2027-01-31, after a four-week soak of v0.9.0 on the CNCF instance.

What v1.0 means

• API contract frozen — no endpoint removals or response shape changes without v2.0
• ClickHouse schema stable — no ORDER BY or column-type changes; ADD COLUMN … DEFAULT and new tables remain allowed
• Helm values stable — existing values.yaml keys won’t be renamed
• Supported ClickHouse floor — 24.8 LTS, covered by CI (#392) ✅
• Support policy active — current release + 2 previous minors receive security patches (see Support Policy)
• A CRA-grade vulnerability register is exportable per deployed version, and a readiness score is computed from it

All v0.x releases are development milestones and may contain breaking changes between minor versions — read the release notes before upgrading.

Phase 3: Automation, Fleet & Cryptography

v1.1.0 · due 2027-04-30.

Epic #338 — Automated VEX generation (VEXViper)

VEXViper is an out-of-tree Go sidecar: it reads findings via the REST API, gathers evidence, asks a configurable LLM or rule engine, and uploads validated OpenVEX back. The correctness blockers (#332, #335, #355) have all landed.

Fleet operations

Cryptography — #420 (CBOM)

Phase 4: Analytics

v1.2.0 · due 2027-07-31. CRA scoring left this phase for 1.0; what remains is prioritisation and dependency-health depth.

Schema Change Register

Everything that touches db/migrations/ or a frozen response shape. The authoritative register — including the “needs pre-1.0?” reasoning per row — is the one in ROADMAP.md; check it, upstream main and open pull requests before claiming a number. After 1.0, ORDER BY and column-type changes are never allowed; ADD COLUMN … DEFAULT and new tables are fine at any time.

Dependency Graph

PRE-1.0 contract:
#398 ✅ ──┬── #58 ✅ (Aggregated SBOM View)                      v0.8.0
          └── #399 ✅ (MCP: get_project) ── post-1.0: write tools

REGISTER (#414):
#412 ✅ (cve_id/aliases) ── #410 (KEV, matched by alias) ──┐
#408 (CVSS) ─────────────────────────────────────────────┼── #411 (SLA due date; KEV due date overrides) ──┐
#409 (CWE) ──────────────────────────────────────────────┤                                                  ├── #141 (CRA score)  v1.0.0
#64  (EPSS) ─────────────────────────────────────────────┤                                                  ├── #62  (report bundle)
#413 (VEX action statement) ─────────────────────────────┘                                                  └── #7   (MTTR)
#266 ✅ (CSV) ── grows with every row above ── #62

CRYPTO (#420):
#419 (library inventory, SBOM-only)                         v1.0.0
#415 (CBOM ingest) ── #416 (inventory) ── #417 (policy) ── #418 (PQC)   v1.1.0
                                                 └── #409 (CWE-327 filter on the register)

VEXVIPER (#338):
#355 ── #336 (idempotent upload) ── #333 (since/cursor) ── #337 (webhooks) ── #334 UI

FLEET:
#131 ── #132/#133 ── #177 ── #267 ── #176
     └── #138 ── #140 ──┐
#143 (Witness) ─────────┴── additional #141 inputs (v1.1.0)

#60 (OSV/KEV/EPSS mirror) ── standalone
#61, #82 ── extend internal/github        #254 ── informs #255        #268 ── v2.0

Prioritization

Why the CRA moved into 1.0

The reporting obligation is in force, and its 24-hour clock for actively exploited vulnerabilities is exactly what KEV status (#410) makes visible. Customers ask for a register now, column by column. Every register item is additive, so this does not break the back-fill rule — it is pre-1.0 because 1.0 is the release adopters evaluate against the CRA.

Why three releases instead of one

One milestone with 21 issues and a tag at the end slips. v0.8.0 kept its October date, v0.9.0 is the self-contained register, and v1.0.0 adds the score on top with a December soak.

Why VEXViper after the register

The register is what VEX statements are written against: #413 fixes what a statement records, #411 defines what “open” means, #410/#64 define what to triage first.

Cluster vs. namespace vs. project

All three are LowCardinality(String) DEFAULT '' columns, none in ORDER BY. tags label projects across these dimensions; they do not replace them.

Non-Goals

• ❌ Custom Kubernetes Operator (Helm + ClickHouse Operator)
• ❌ In-tree VEX generation / LLM calls (stays in the VEXViper sidecar; the MCP server is a transport)
• ❌ MCP write tools in 1.0 (read-only by design)
• ❌ Write APIs for policies or exceptions — license, remediation, crypto (frontend is public)
• ❌ Per-finding manual status or due dates (status from VEX, due dates from policy)
• ❌ CBOM generation or crypto scanning (BOMHort consumes CBOMs)
• ❌ CRA reporting to ENISA/CSIRTs (BOMHort tells you what and when; filing is your process)
• ❌ Multi-repo split (monorepo is a hard constraint)
• ❌ Real-time streaming (batch + webhooks is sufficient)
• ❌ RBAC/multi-tenancy (auth is binary for now)
• ❌ Full OIDC in BOMHort (upstream proxy responsibility)
• ❌ Relational rewrite of sbom_packages (#254 informs the overlay only)

Contributing

Want to pick up an issue from the roadmap? Check the Project Board for items in the Todo column. Issues labeled help wanted or good first issue — for example #267 — are especially good for new contributors.

See Development Guide for setup instructions.