Deployed, or not
Filter to findings on a release that is running right now, in any environment or only in production.
Vulnerabilities and VEX
Triage by exposure
Every finding shows whether the affected release is deployed. That one column separates a backlog from an incident, and most vulnerability lists cannot fill it in.
The number that should move
Most dashboards lead with a total number of findings. That number does not tell you what to do. It also rises whenever you ingest more SBOMs. A team doing the work you want sees it get worse.
The figure this platform leads with is deployed criticals with no assessment recorded. It is small and actionable, and documenting "we are not affected" moves it, provided a second person approves the suppression. Findings that have been assessed away are shown separately and never folded in. Hiding things cannot improve the headline.
Unassessed, or not
See what nobody has taken a position on yet, and work through it.
Proposed, and waiting
A suppression awaiting approval is shown as proposed, never as the position in force. It has no effect until a person signs it.
Separation of duties, enforced in the database
No API key can ever perform three actions in this platform, whoever holds it, an administrator included: approving a VEX position, disposing of an asset and accounting for a break in the audit chain.
The author of a VEX statement cannot approve it, and a database constraint enforces that. The API is bound by the same constraint as the screen.
Evidence that an alert was not silenced
Alerts often fail silently: the query works and the mail client works, but nothing calls them. provenance writes a row for every dispatch with its outcome (accepted, refused or undetermined), so you can check who was told about a finding, and when.
Vulnerability management questions
What makes a finding urgent here?
Whether the affected release is deployed. A critical CVE in a release nobody runs is a backlog item, and the same CVE in production is an incident. Only the register knows the difference, so deployment is a column of its own.
What is VEX and why does it need approval?
A VEX statement records your position on a vulnerability (affected, not affected, fixed or under investigation) with the reasoning. "Not affected" and "fixed" remove a finding from your exposure count and silence its alert, so on a critical finding they require a human approval, and the author cannot approve their own.
How do you know the scanner is working?
The scanner has to pass a self-test first. A broken scanner can return the same clean result as a clean estate, so it must find a set of vulnerabilities we planted before its output is treated as evidence. Until it does, the dashboard says that scanner trustworthiness is not established and that the counts may understate exposure.
Do you rank by EPSS or CISA KEV?
Not today. Ranking uses severity, CVSS score and real deployment. Exploit-probability and known-exploited feeds are on the roadmap.
Does it alert anyone, or just display?
Yes, and it keeps a record of each alert. Dispatch is idempotent: a second run sends nothing that was already notified. Every dispatch is written to a ledger with the outcome the mail relay gave. That ledger is the durable evidence that an alert was not silenced. A dry run only tells you what would be sent now, and that list is empty both when a finding is suppressed and when it was notified last week.
Is a scan ever finished?
No. Releases are re-scanned nightly against the latest advisory feeds. A night that did not run leaves a row marked failed, and a missed scan cannot pass for a clean one.
See your real exposure
Publish one SBOM and the deployment map does the rest.