Block-source mix

The block-source mix widget (#672) sits below the per-project / per-team strips on the org overview. It’s a horizontal stacked bar plus a legend showing how this org’s 7-day BLOCKED decisions break down by verdict_source.

What you see

A title-row reading Blocks by source · <total> (the count formatted as 1.2k, 47, etc.), a single horizontal SVG bar split into proportionally-sized slices, and a legend below listing each slice with its label, count, and percentage.

Slices are ordered largest-first left-to-right. Ties break by label alphabetically so render order is stable across refreshes. Each slice carries a data-source-label attribute that mirrors the legend label — useful when scraping the page for offline reporting.

Bucket roll-up:

• blocklist:source=osv:id=… → bucket osv. Most common shape; one slice covers every OSV-driven block.
• blocklist:source=ghsa:id=… → bucket ghsa.
• Everything else → the raw verdict_source string verbatim (e.g. cooldown, fingerprint, size-jump, policy-denylist, scanner).
• Engine caps the source list at ~10 entries; any tail rolls into a single other bucket.

The same verdict_source strings appear in the audit log’s verdictSource column and on the packages search assessed-versions table’s source column — you can pivot freely between this widget and either of those.

When it appears

Only when the tenant has at least one BLOCKED row in the 7-day window. Orgs that haven’t been blocked at all in the last week don’t see a “0 blocks” bar — the card is suppressed.

The widget is automatic in the sense that new verdict_source strings light up without code changes. When the cross-tenant verification work (#537) and cross-eco lineage (#538) ship, their new source strings will appear in this mix the next time data lands.

What to do based on what you see

• osv / ghsa dominant — most of your blocks are advisory-driven. This is the steady state for an org with active dependencies; not actionable on its own. Pivot to the audit log filtered to decision=BLOCKED if a specific package is blowing up CI.
• fingerprint slice non-trivial — the pre-scan layer is catching transitives of a vulnerable build tool. Open the row’s advisory subpanel in the audit log to read the tool name and remediation text. Often the fix is a top-level dependency pin.
• size-jump slice non-trivial — the 5×-median tarball check is catching things. Could be a real supply-chain compromise (event-stream@3.3.6, ua-parser-js@0.7.29 shape) or an upstream that genuinely grew. Open the size-anomaly chip on the packages page for the version to see which.
• scanner slice non-trivial — a built-in or BYOS scanner is producing block verdicts. Cross-check the scanner’s own dashboard / logs to see what’s tripping it.
• cooldown slice present — fresh versions are being held by the cooldown window before they’re eligible to be cached. Expected on orgs that pulled a brand-new release in the last day; transient.

The mix bar’s clickthrough link is the “viewing 7d audit” hint at the top right — it lands you on the audit log filtered to decision=BLOCKED, where every individual block is enumerable.