Known vulnerabilities in the software this deployment actually runs — the applications behind the proxy and the packages on the edge nodes themselves.
Attack Surface answers what is exposed. This page answers what is vulnerable in it.
¶ Getting here
Monitoring → Vulnerabilities, or from the dashboard, where three figures sit under the traffic metrics and each opens this page.
Everything above that row is traffic — what arrived. This row is the standing state of what you are running, and it lives on the dashboard rather than in the bell for a reason: the bell carries change, a thing that became true without anybody asking, and these are totals that stay true until somebody acts on them. A number that is simply true every morning is how a bell becomes a red dot nobody reads.
| Affected tenants | Sites with findings, over sites total. 3 of 13 is a different picture from 3 of 3. |
| Unpatchable components | Withdrawn from distribution, or on an end-of-life branch. No advisory applies because no upstream exists to issue one. |
| Nodes pending patch | Nodes, not CVEs — and that is deliberate. Two ordinary Debian machines carry a few thousand issues an upgrade would clear; 2,334 as the headline reads as "we have 2,334 vulnerabilities", which is true of any Debian install not updated this morning. The action is to update two nodes, and the count sits underneath as the reason. |
Each tenant and each agent carries its own findings, and that is where the detail lives. Reading them one at a time answers "is this one exposed" once per site, and never answers the question somebody opens the console with — where is the worst of it. This page is one list, sorted by severity, with the asset named in its own column.
¶ Two tabs, because they are two kinds of evidence
| Web components | Versions read from the URLs visitors request, correlated against the vendors' published advisories. An observation, with the requests and addresses that back it. |
| System packages | Read from each machine's own package database — agents and collectors both — correlated against the Debian Security Tracker. A reading. |
They are deliberately not one list. A single severity-sorted table would place "jQuery 1.11.2, seen in 238 requests, probably" next to "php8.4 is two security releases behind, read from dpkg" and imply the two carry the same weight. They do not, and this page should not be where that gets blurred.
¶ Web components
One row per finding, with the tenant it belongs to. The Advisory column carries the vendor that published it, linked to the page where they published it — a finding nobody can check is an assertion — and the CVE identifiers where the advisory has them.
Severity sorts by rank rather than alphabetically. Sorted as text, critical falls between low and medium; clicking the column reverses it.
The tenant filter in the bar at the top applies here, so this page narrows with every other one.
¶ Where each version came from
Every row says whether its version was reported by a collector — read from a file on an application server — or inferred from traffic. The Version source filter above the table narrows to either.
The distinction is the whole weight of the finding. A version in a URL can be stale, can belong to one of several applications behind one hostname, and can be forged by anybody able to make a request. A version in a composer.lock is what is installed.
Readings sort above inferences within a severity, because a reading has no request count at all and ordering by traffic alone would bury the stronger claim beneath the weaker ones.
¶ What opening a finding shows
For a finding inferred from traffic: how much traffic stands behind it — the request and address counts, when it was first and last seen, and one sample request URI the version was fingerprinted from.
The addresses themselves are not retained. The engine records how many were distinct and keeps one sample request per observation; no client list is shipped to the management plane. The absence of a client list is the design, not a gap.
A finding seen in 238 requests from 6 addresses over days is a different proposition from one seen once from one address, and the second is what a forged version looks like. The page shows you which you are reading.
For a finding reported by a collector: the file it was read from and the backend it was read on, with the collector's name linked to its own page. The request counts are deliberately absent — zero requests about something read off a disk would read as "seen nowhere" rather than "not seen in traffic, which is not how we know".
¶ System packages
One row per machine and source package. Source package, because that is what apt upgrades — a single CVE affecting fifteen binaries built from one source is one upgrade, not fifteen.
The Machines filter narrows to agents or collectors. Both are machines you own, and to somebody deciding what to patch the difference is only where they go to do it — so a collector's row says so, and its name links to that collector rather than to an agent.
The counts are distinct CVEs. A CVE of a source package appears once for every installed binary built from it, and counting those separately inflates the figure without adding meaning: one backend's
libreofficehas 29 installed binaries, so 14 issues read as 406 until this was fixed. If these numbers dropped sharply for you, the smaller ones are the true ones.
| Upgrade to | The version to install: the greatest published fix, not one per advisory. Debian's upgrades are cumulative, so a package with fixes in 6.12.107-1, 6.12.111-1 and 6.12.113-1 has one action and not three. |
| CVEs | how many distinct identifiers the row covers |
| CVEs with a fix | the ones an upgrade settles |
| CVEs with no fix | the ones no version settles. This is the set where a WAF rule in front of the machine is the only mitigation available — virtual patching — and it is the part of this data the product itself can act on. |
Their sum is deliberately not shown: it would be a number with no decision attached to it.
Urgency is Debian's own word for how it rates the issue, and sorts by what it means. Note that not yet assigned is the commonest value on an ordinary Debian machine: the tracker assigns urgency mainly when it issues an advisory, so its absence is not reassurance.
¶ Clicking a count shows the identifiers behind it
A count nothing stands behind cannot be checked against an advisory, looked up, or quoted in a ticket. Every count opens, and each shows its own set — clicking CVEs with a fix never lists the ones with no fix.
The identifiers are read when the row is opened rather than with the page: the kernel source package carries thousands on an ordinary machine, and the panel says when it is showing the newest of a larger set.
¶ "No fix" is three different situations, and the panel tells them apart
Opening a No fix count groups the identifiers by the reason Debian recorded, because no fix available flattens three states that call for different responses:
| Debian decided against a fix | The panel shows its own words — Minor issue, Minor issue, revisit when fixed upstream, Wait for exposure unstable and coordinate with Perl maintainers. Somebody assessed it and said so. |
| Open in this release | No decision recorded: acknowledged, no fix published, and not ruled out either. Work may still be in progress. |
| Nothing will fix it at any version | The set where the WAF in front of the node is the mitigation. |
On an ordinary fleet roughly one unremediated CVE in twelve carries a recorded decision; the rest are open. A row whose issues all carry one shows no No decision group at all, and vice versa.
Debian's tracker carries
TEMP-placeholders for issues with no CVE assigned yet. Those link to the tracker; CVE identifiers link to the NVD, which has no page for a placeholder.
¶ Why the numbers are large, and what to read in them
A single ordinary Debian node carries a few thousand findings. That is normal, and it is why this page does not put the total anywhere near the top. The figures that correspond to a decision are:
- CVEs with a fix — one command settles these.
- No fix — nothing settles these, and the WAF is the mitigation.
- Urgency — Debian's own triage, where it has made one.
The checkbox above the table adds the issues Debian marks unimportant — its own judgement that they are not security concerns worth fixing. They are excluded by default because including them buries everything else.
¶ Where the scoping notice comes from
The tenant filter does not apply to System packages, and the page says so rather than ignoring it. Those packages are installed on the edge nodes; they are not scoped to any tenant, and a filter that appears to be on while doing nothing is how a partial list gets read as the whole one.
¶ When a list is empty
Three different reasons, and only one of them is good news:
- No correlation pass has completed. The scanners run every 24 hours. Said in a banner rather than shown as an empty table.
- Nothing was correlated for that asset — a node whose package database could not be read, a site whose traffic has revealed nothing often enough to correlate. Named, with the reason.
- The sources were asked and report nothing. Only this one means what an empty table looks like it means.
A vendor source that could not be read on the last pass is also said in a banner, because the findings it would have produced are simply absent.
¶ References
- Agents — the same package findings for one node, with its full inventory beside them
- Tenants — observed software for one site, which is the evidence these findings rest on
- Attack Surface — what is reachable, as opposed to what is vulnerable
- Rules & Rulesets — the CVE channel, which is how a virtual patch reaches the fleet