Vulnerabilities

• Back to Artica EdgeGuard Overview

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

Exposure → 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.

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

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 libreoffice has 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.

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:

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.

Which tracker answered, and for which machines

Debian publishes security data for the releases it still supports — at the
time of writing sid, trixie, bookworm and forky, and nothing older. A
release leaves that feed about five years after it arrives.

That is a problem for exactly the machines most likely to need this page. A
node on Debian 9, 10 or 11 matched nothing in Debian's data, produced no
findings, and was written down as scanned — a Debian 9 host running PHP 7.3
from 2019 reported clean.

So older releases are correlated against Freexian's Extended LTS tracker,
which carries stretch, buster and bullseye. The node's panel names
whichever one answered, because it changes what you do next: a Debian fix is
an apt upgrade, while an ELTS fix lives in Freexian's archive, which is a
paid subscription.

Which release goes to which tracker is not a list kept in the product. A list
would be wrong within a year — bullseye is in both feeds today and leaves
Debian's when it leaves LTS — and being wrong would mean reporting an old
machine as clean. The rule is what actually happened: a release that matched
nothing in Debian's feed is tried again against ELTS.

Packages neither tracker covers

Both trackers cover a distribution's own packages. Software installed from a
third-party repository is in neither, so no finding on this page can be about
it — and an absence of findings looks exactly like an absence of problems.

Each node's panel therefore lists what it could not speak for, by where it
came from:

The third line is the one worth reading twice. It means no configured
repository offers that package at all — the repository was removed from the
sources, or it stopped publishing for this release. On the node above those
two are old kernel images left behind by point releases, which is harmless;
on another node the same line could be software nothing updates any more.

The first line is the one that matters there. deb.sury.org has dropped
Debian 9 entirely — its suites are now bookworm, bullseye, jammy, noble,
resolute and trixie — so a PHP 7.3 installed from it receives nothing from
anywhere, and no tracker has an opinion about it either. The only source that
covers PHP on an old Debian is Freexian's PHP LTS, which is a separate
subscription from ELTS and is not published openly.

The origin comes from apt's own index files, so it costs nothing and needs no
extra tooling on the node. A machine without apt simply reports no origins,
which is treated as not known rather than as not packaged — the two look
the same and only one of them is a finding.

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

Four different reasons, and only one of them is good news:

1. No correlation pass has completed. The scanners run every 24 hours, and also as soon as a node reports an inventory that has changed. Said in a banner rather than shown as an empty table.
2. Nothing was correlated for that asset — a node whose package database could not be read, one running a package manager this does not correlate, or a release neither tracker publishes for. Named, with the reason, and such a node is counted apart from the scanned rather than among them.
3. The packages are not ones either tracker covers. Listed by origin, above.
4. The sources were asked and report nothing. Only this one means what an empty table looks like it means.

A fifth state is not an empty list but a short one: a node with more findings than the page will hold says so, and its counts are a floor rather than a total. That is deliberately not grouped with the reasons above — a node with thousands of findings is the opposite of a node nothing is known about, and for one release they were briefly counted together.

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