Vulnerabilities

Loomscope matches the services it discovered against OSV and NVD advisories. It does not exploit anything, authenticate into hosts or run intrusive checks — it knows what version is running and what has been published about that version.

That distinction sets the whole shape of this page: a finding here is a claim about a version, and how much to trust it depends on how the version was learned.

The list

Filtered by severity and state. The default shows open and acknowledged findings, ordered by severity then age.

Matched via — the column that decides how much to trust a finding

Banner-derived matches are where false positives concentrate, and that is not a bug to fix — a service that reports Apache/2.4.6 may be a distribution build with the fix backported, and no amount of scanning from outside can tell. The column exists so you can weigh it rather than guess.

Service confidence propagates: a low-confidence version produces a lower-confidence finding.

Triage

Acknowledging records that a finding was examined and accepted for now. It stays visible, it stays counted, and it stops being noise.

Marking a false positive is useful work. It removes the finding permanently and records that somebody looked — which is what distinguishes a suppressed finding from an ignored one, six months later, in front of an auditor.

Resolved happens on its own: when a service no longer matches, the finding is closed by the matcher rather than by a person.

A CVE page

Every CVE has its own page listing the affected services and hosts across the estate — which is the right shape for "how exposed are we to this one", rather than walking every host looking for it.

It carries the advisory's description, its severity and vector, and the sources it came from.

Where the data comes from

Two feeds, both mirrored into your own database:

• OSV — the open-source vulnerability database, best for packages and language ecosystems.
• NVD — the NIST database, best for CPE-keyed product matching.

Ingest runs either as a job inside the control plane or as the separate cve-ingest worker, for deployments that want that load isolated or that need to feed an air-gapped mirror.

The matcher runs every five minutes against newly observed services, so a service discovered at 09:00 has findings by 09:05 rather than the next day.

Is the data current

This is the failure mode worth designing against, because it looks exactly like good news: a stale feed produces a short vulnerability list.

The coverage check reports how old the advisory data is and warns beyond a threshold. If the last successful ingest was three weeks ago, the list is missing three weeks of advisories, and nothing else in the interface will say so.

In an air-gapped install the mirror is only as fresh as the last copy in. See Air-gapped installation.

Alerting on findings

The event types vuln.critical and vuln.high fire when a matching finding appears, and route to Slack, Teams, PagerDuty, Jira or a signed webhook. Each announcement is deduplicated by the finding, so a matcher that runs every five minutes announces once.

See Notifications.

What this is not

• Not a scanner. No authenticated checks, no exploit attempts, no intrusive probes.
• Not a patch manager. Loomscope tells you what is exposed; it does not change anything on a host.
• Not a substitute for host-based tooling. An agent on the machine knows its package list exactly. Loomscope knows what it can observe from the network, and says how confident it is about it.