Advisory detail subpanel

The advisory subpanel (#671) surfaces the OSV or GHSA advisory behind a BLOCKED install decision in the same shape the engine returned to the 403’d install request. You see it in two places: inside the row detail panel on the audit log, and on the audit page itself when a row’s advisory is rendered inline.

What you see

Four labelled fields, rendered as a compact key-value block:

• Source — osv or ghsa. Names the advisory feed.
• Advisory ID — e.g. GHSA-xxxx-xxxx-xxxx, CVE-2024-12345, or the OSV-native id. Rendered as a <code> chip; clickable when the upstream advisory page is linkable.
• Severity — LOW / MEDIUM / HIGH / CRITICAL. Pulled from the advisory’s CVSS / severity field. Blank for advisories without a severity record.
• Summary — the human-readable one-line description the advisory feed shipped. Truncated to a sensible read-length; the full body lives on the upstream advisory page.

The data is fetched via the engine’s join to the blocklist table when the audit row is rendered — the dashboard doesn’t re-derive the advisory from the bare ID, so the shape mirrors exactly what the install request’s 403 body carried.

When it appears

• The row’s decision is BLOCKED.
• The row’s verdict_source starts with blocklist:source=osv: or blocklist:source=ghsa:.
• A matching row exists in blocklist at the moment the audit row is rendered. If the blocklist row has since been deleted (e.g. a manual blocklist clean-up), the subpanel degrades silently rather than 500ing.

It does not render for:

• Cooldown blocks — the cooldown window doesn’t carry an advisory.
• Scanner-driven blocks — the scanner returns its own verdict reason; advisories are advisory-feed-only.
• Manual operator entries — an admin-added blocklist row may have no advisory attached.
• Fingerprint / size-jump blocks — the pre-scan layer flags the version; the fingerprint subpanel covers those.

What to do based on what you see

• The advisory id matches what the developer reported. Confirmation that Upwarden’s 403 is the same block the developer is seeing. Hand the summary text and the upstream advisory link to the developer; that’s all they need to triage.
• Severity is LOW and the build is failing. Your org policy may be blocking too aggressively for the noise level. Consider an allowlist entry for the specific version, with the advisory ID in the # reason suffix so the audit trail explains why; the policy overrides guide walks through the JSON-admin equivalent.
• Severity is CRITICAL and a developer is asking to bypass. The advisory subpanel’s summary text is exactly the case for not bypassing. Pin the dependency to a non-vulnerable version instead.
• The subpanel isn’t rendering on a row you expected to see it on. Check the row’s verdict_source in the audit detail’s meta block — cooldown / scanner / manual:<actor> all explain its absence.

The same advisory shape also appears as a row in the packages search’s blocklist matches table, with the same source / id / severity / summary columns — that’s the per-package lookup version of the same data.