Publishers can't see which MTF controls failed (no path from L0 → L1)

[mgoldsborough]

Problem

The bundle API and mpak.dev page both expose only counts for the security scan (controls_passed, controls_failed, controls_total) — never the list of which controls failed. So when a freshly-published bundle lands at certification_level: 0 with, say, 12/16 passing, the publisher has no way to discover which 4 are blocking L1 or what to change to clear them.

There's no actionable path from "I published a bundle" → "I have an L1-eligible bundle."

Concrete example

@nimblebraininc/synapse-db-query@0.3.0 (release):

GET https://registry.mpak.dev/v1/bundles/@nimblebraininc/synapse-db-query

{
  "verified": false,
  "certification_level": 0,
  "certification": {
    "level": 0,
    "level_name": null,
    "controls_passed": 12,
    "controls_failed": 4,
    "controls_total": 16
  }
}

This bundle:

• Published via OIDC from a GitHub release (provenance recorded in the registry).
• MIT-licensed, signed manifest, declared tools, declared MTF permissions (_meta.org.mpaktrust).
• mtf_version 0.1 declared.

Yet it sits at L0 with no surfaced reason. Per MTF-0.1 §1.4, L1 needs roughly AI-01, SC-01, CQ-01/02, CD-01, IN-01/03 — but I can't tell from the registry which of those (or others in the 16) the scanner actually ran, let alone which it failed.

Secondary issue: control count mismatch

mpak.dev marketing says 25 security controls; this bundle was scored against 16. Either the scanner is running a subset (worth surfacing why), or the marketing copy is stale.

What would unblock publishers

Minimum viable fix — expose per-control results on the bundle / version response (or as a sub-route):

GET /v1/bundles/@scope/name/versions/0.3.0/scan

{
  "level": 0,
  "level_required_for_l1": ["AI-01", "SC-01", "CQ-01", "CQ-02", "CD-01", "IN-01", "IN-03"],
  "controls": [
    { "id": "AI-01", "status": "pass" },
    { "id": "SC-01", "status": "fail", "reason": "no SBOM detected at sbom.json" },
    { "id": "CQ-01", "status": "pass" },
    ...
  ],
  "next_level": {
    "target": 1,
    "blocking": ["SC-01", "CD-01"]
  }
}

Even a flat list of failing control IDs (without remediation text) would be a huge improvement over the current "12/16, good luck."

A nice-to-have follow-on: render the same breakdown on the mpak.dev/<scope>/<name> page so publishers don't have to hit the API to debug their score.

Why this matters

Trust-score-as-product only works if the score is actionable. Right now it's a black box: bundles can be perfectly well-formed and still stuck at L0 with no diagnostic. The whole MTF L1→L4 ladder loses its UX value if publishers can't climb it.

Related

• MTF-0.1 spec: https://github.com/NimbleBrainInc/mpak-trust-framework/blob/main/MTF-0.1.md
• Existing scanner work: Scanner: Generate PDF security reports #2 (PDF reports — adjacent but different, that's for end-users; this is for publishers)