Skip to content

ROADMAP.md

Latest commit

 

History

History
78 lines (52 loc) · 5.71 KB

ROADMAP.md

File metadata and controls

78 lines (52 loc) · 5.71 KB
Raw

Roadmap

Public roadmap for TRUSCA. Intentionally high-level — concrete priorities and target dates are decided per release cycle and announced in CHANGELOG.md.

Priorities follow three principles, in order:

  1. Fix what blocks adoption — public-facing accuracy and trust.
  2. Reach parity with running a single SCA tool directly (don't be a thinner wrapper).
  3. Differentiate with capabilities a single tool doesn't give you.

Legend: ☐ planned · ◐ in progress

Recently shipped (v0.11.0 - v0.22.4)

Highlights only, and only what closes a roadmap line — the itemised history, including the v0.10.0 foundation (Trivy as the single matching engine, VEX, EPSS, the Helm chart, the design system), is in CHANGELOG.md.

  • Known-malicious package detection — OSV MAL- advisories as a build-gate axis, with expiry-capped exceptions and a weekly re-check that catches a package flagged after it shipped
  • Automated remediation pull requests, with a dry run, on top of the minimum-safe-upgrade engine and a "group by upgrade" view of the findings one bump resolves
  • Dynamic license policy — per-team and per-organization category overrides, exceptions, and gate posture
  • Signed SBOMs — cosign signatures plus an in-toto / SLSA provenance attestation on every source scan, verifiable outside the portal
  • SBOM conformance scoring for uploaded documents, with a regulatory crosswalk (BSI TR-03183-2 for the EU CRA, the NTIA minimum elements, EU AI Act Annex IV, the Korean AI Framework Act) and CycloneDX 1.7 ML-BOM support
  • CISA KEV badges and remediation due dates, with a KEV-first Priority sort
  • Vulnerability SLA / aging — a first-detection clock that survives re-scans, severity-based due dates, and a daily breach sweep
  • End-of-life components, a "behind latest patch" signal, and base-image OS end-of-service-life on container scans
  • Organization-wide component inventory and search — which projects carry a package, and which projects a CVE reaches
  • Release labels as permanent snapshot addresses (?release=) across the detail endpoints, SBOM, and NOTICE
  • Dark theme alongside light, both measured against WCAG AA

Supply-chain Integrity

Align with CISA 2025 / SLSA, cut noise further.

  • ☐ Reachability-based prioritization (best-effort, rolled out per language)
  • ☐ Declared-vs-actual SBOM drift — diff an uploaded SBOM against TRUSCA's own scan of the same ref and report what each side is missing. The conformance score grades whether the document's fields are filled in; this answers whether the document matches the code.
  • ☐ Signed releases of TRUSCA itself: signed git tags, cosign-signed container images, and a provenance attestation alongside the SBOM a release already attaches. This is about the artifacts we ship, not about the scans TRUSCA runs: signing the SBOM of a scanned project already works.

For 1.0.0

Changes that break callers. They are held here rather than shipped across minors because a single breaking release is easier to absorb than a series of smaller surprises, and because SECURITY.md says a pre-1.0 minor may change the HTTP API, which is a warning rather than an invitation.

  • ☐ One pagination shape across the API. Three are in use today: limit / offset on 8 endpoints, page / page_size on 15, and page / size on 6, with page-size defaults and maxima varying inside each group. A client library needs a branch per shape. New endpoints already use one shared schema, so the count stops growing; converging the existing 29 is the breaking half. See pagination.

Documentation

  • ☐ Hardening guide: one page collecting the settings an operator should change before exposing a deployment, instead of the short list in SECURITY.md pointing at scattered references.

Threat Detection & Deeper Prioritization

Close the biggest remaining gaps vs commercial SCA, reusing best-of-breed open source rather than building from scratch.

  • ☐ Typosquat heuristics — name-distance and popularity signals alongside the OSV MAL- feed, which only names packages an advisory has already caught up with
  • ☐ Unified risk score — one 0–100 number combining CVSS, EPSS, KEV, fix availability, and dependency depth. The current score reads severity and license distribution only; the other signals are surfaced but not folded in.
  • ☐ Binary scanning (OSS-in-binary) — Syft binary classifier + Trivy filesystem mode (best-effort; no modified-binary fingerprinting)
  • ☐ AI-BOM generation — detect AI model / dataset components and their licenses at scan time via cdxgen. Uploaded ML-BOMs are already ingested and scored; producing one is not.
  • ☐ Snippet / AI-generated-code origin matching — lowest priority, RFC-gated. ScanOSS (MIT client + GPL-2.0 engine as an isolated sidecar). Requires a separate RFC on knowledge-base hosting and fingerprint egress before any work starts.

Explicitly out of scope

  • Building our own vulnerability database — we aggregate through Trivy's unified DB (NVD + OSV + GHSA + EPSS + KEV) and augment with VEX.

Backlog (not yet scheduled)

Native Jenkins plugin, per-project / per-scan exclude paths (ignore generated / test / vendored trees in first-party license detection), a daily rather than weekly malicious re-check (the re-stamp half needs no network, and a package can be flagged hours after it ships).

Roadmap items are proposals, not commitments, and dates are deliberately omitted. Feedback and contributions are welcome: open an issue referencing the relevant section.