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, not by a list sorted on severity
Every finding carries whether the affected release is actually deployed. That single column is the difference between a backlog and an incident, and it is the one most vulnerability lists cannot fill in.
The number that should move
Most dashboards lead with a total. A total of findings is not a decision: it goes up when you ingest more SBOMs, which is the behaviour you want to encourage, so the metric punishes the work.
The figure this platform leads with is deployed criticals with no assessment recorded. It is small, it is 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, so the headline cannot be improved by hiding things.
Unassessed, or not
See what nobody has taken a position on yet. A backlog with a name is a backlog somebody can finish.
Proposed, and waiting
A suppression awaiting approval is shown as proposed, never as the position in force. It counts for nothing until a person signs it.
Separation of duties, enforced in the database
Three actions in this platform can never be performed by an API key, by anyone, including an administrator: approving a VEX position, disposing of an asset, and accounting for a break in the audit chain. Machines record and propose; a person approves.
The author of a VEX statement cannot approve it, and that is enforced by a database constraint, not by the screen that asks. A rule only the user interface applies is a rule the API does not have.
Evidence that an alert was not silenced
Alerting is where vulnerability tooling quietly fails: the query works, the mail client works, and nothing ever calls them. Here every dispatch writes a row with its outcome — accepted, refused or undetermined — so "did anyone get told about this, and when" has a durable answer and not an inference drawn from an empty inbox.
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; the same CVE in production is an incident. The register is the only thing that knows the difference, so deployment is a first-class column and not a footnote.
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. A machine credential that could approve its own suppression would be a rubber stamp producing a clean-looking audit trail, which is worse than none.
How do you know the scanner is working?
Because it is made to prove it. A clean result from a broken scanner is indistinguishable from a clean estate, so the scanner is gated on finding planted vulnerabilities before its output is treated as evidence. Until that self-test passes, the dashboard says plainly 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; we would rather name that gap than imply a capability.
Does it alert anyone, or just display?
It alerts, and it keeps the receipts. Dispatch is idempotent, so a second run sends nothing already notified, and every dispatch is written to a ledger with the outcome the mail relay gave. That ledger is the durable evidence an alert was not silenced — a dry run tells you what would be sent now, which is empty both when a finding is suppressed and when it was notified last week.
Is a scan ever finished?
No, and treating it as finished is the common failure. A scan is only as current as the advisory feeds behind it, so releases are re-scanned nightly. A night that did not run leaves a row marked failed, never an absent row, because silence must never look like success.
See your real exposure
Publish one SBOM and the deployment map does the rest.