Output the operations team will actually work
Backport-aware matching removes the false positives that destroy a report’s credibility. A team that has chased three phantom findings stops reading the fourth — including the one that was real.
SOC 2 Readiness
24/7 Security Monitoring
Canadian-Based SOC
GuardsArm Platform · Govern
Vulnerability Management
Continuous, accurate vulnerability detection tied to real assets.
Vulnerability data is only useful when it is accurate and attached to an asset someone owns. GuardsArm scans natively, matches carefully, and ties findings to the inventory the agent already reports.
- Backport-aware
- ~361k CVEs
- Correlated with attacks
What is at stake
A report with thousands of findings and a meaningful false-positive rate does not get actioned, and the scanning programme quietly becomes theatre.
Remediation effort goes where the consequence is
Per-asset risk scoring means patching is prioritised by what the system does and where it sits, not by a base score assigned without reference to your environment.
Exposure and attack are joined up
An exploitation attempt against a host confirmed vulnerable to it is a different conversation from either signal alone, and it is the one that justifies an emergency change.
Who carries this
Security produces it, platform and infrastructure teams act on it — which is why precision matters more here than coverage.
The problem
Most vulnerability reports are ignored, and usually for a good reason
Hand an operations team a scan result with several thousand findings, a meaningful fraction of which are wrong, and they will stop reading it. That is not negligence; it is a rational response to a report whose precision does not justify the time to verify it. The scanner keeps running, the report keeps arriving, and the exercise becomes compliance theatre.
Two things cause it. The first is backporting. Enterprise distributions fix vulnerabilities without advancing version numbers, so a scanner that compares versions reports long-fixed issues as open. Once a team has chased three of those, they discount the fourth — including the one that was real.
The second is missing context. A list of CVEs ranked by base score tells you nothing about which host matters, which is reachable, or which is currently being attacked. Prioritisation gets done by hand, inconsistently, by whoever has time.
A scanner that cries wolf three times has not found three vulnerabilities. It has lost the audience for the fourth.
Capabilities
What vulnerability management does
Backport-aware matching
A large OVAL dataset with backport awareness, so a distribution that patches a vulnerability without changing the version string is not reported as vulnerable. This is the difference between a usable report and one analysts learn to ignore.
Full CVE feed
Roughly 361,000 CVEs, kept current, matched against what the agent actually found installed rather than against an assumed build.
Per-asset risk scoring and remediation views
Findings roll up per asset with remediation views, so the question "what do I fix on this host" has an answer.
Correlated with live attack activity
Exploitable and known-exploited vulnerabilities are correlated with actual attack activity against the same host, which is what separates the vulnerability that matters today from the backlog.
How it fits the platform
Because the scanner draws on the agent inventory, vulnerability findings share asset identity with detections. A correlation family exists specifically for exploitation attempts against a confirmed-vulnerable host.
How it works
From agent inventory to prioritised exposure
Agent-based rather than network-scan based, which removes both the scan window and the credential-management problem that comes with authenticated scanning.
Inventory comes from the agent, not a scan window
The endpoint agent maintains a continuous software, package, port and process inventory. There is no network sweep to schedule, nothing to authenticate against each host, and no blind spot for a machine that was off at 2am.
Packages are matched against the OVAL dataset
Matching runs against a large OVAL dataset covering the distributions and platforms in the estate, joined to a full CVE feed of roughly 361,000 entries.
Backport awareness filters the false positives
Enterprise distributions patch vulnerabilities while keeping the upstream version string. A naive scanner reads the old version and reports a vulnerability that was fixed months ago. The matcher accounts for this, which is the difference between a report that gets actioned and one that gets dismissed.
Findings are scored per asset
Risk is calculated against the asset, not just the CVE. The same vulnerability on an internet-facing host and on an isolated test box are not the same problem, and the remediation view reflects that.
Exposure is joined to live attack activity
Because vulnerability findings and detections share asset identity, the correlation engine can join them. There is a dedicated family for an exploitation attempt against a confirmed-vulnerable host, and another for a known-exploited vulnerability being present at all.
Accuracy
What backport awareness actually changes
This is the detail that decides whether the output gets actioned. It is also the easiest thing to test against your own estate during an evaluation.
| Scenario | Version-comparison scanner | GuardsArm |
|---|---|---|
| A patched package carrying the original upstream version string | Reported vulnerable. The version number looks old. | Correctly identified as patched. The distribution security metadata is consulted, not just the version. |
| A genuinely unpatched package at a current-looking version | Frequently missed, for the same reason in reverse. | Reported, because the match is against the security dataset rather than a version comparison. |
| A vulnerability with no vendor fix available yet | Reported identically to everything else. | Reported with the asset risk context that determines whether compensating controls are urgent. |
Correlation
Where exposure meets attack
Vulnerability data stops being a report and starts being a detection input the moment it shares asset identity with the detection engine.
- A known-exploited vulnerability present on a reachable hostAn exposure incident raised before anything has happened — the one case where a vulnerability deserves to behave like an alert.
- An exploit attempt against a host confirmed vulnerable to itA high-confidence incident. The attempt alone could be noise; the attempt against a host that would actually fall to it is not.
- A vulnerable service and anomalous process ancestry on the same hostProbable successful exploitation, assembled from two signals that individually say little.
Terms
Four words that decide the output quality
OVAL
Open Vulnerability and Assessment Language — the structured format distributions publish their security state in. Matching against it is what makes distribution-aware assessment possible at all.
Backporting
When a vendor applies a security fix to an older release without moving the version number forward. Universal in enterprise Linux, and the single largest source of vulnerability-scanner false positives.
Known-exploited vulnerability
A vulnerability with confirmed exploitation in the wild. It belongs at the top of the queue regardless of its base score, and the correlation engine treats it accordingly.
Per-asset risk scoring
Severity weighted by what the affected asset is and where it sits, so remediation effort goes where the consequence is, rather than to whatever scored highest in the abstract.
Background
Understand the concept first
Plain explainers on the underlying ideas, written for someone evaluating rather than buying.
Questions
Common questions
Will it false-positive on backported patches?
No. Matching is backport-aware, so a distribution that patches a vulnerability without changing the version string is not reported as vulnerable. That distinction is the difference between a usable report and one analysts learn to ignore.
Do we need to deploy a separate scanner?
No. Scanning is native and draws on the inventory the agent already reports, so vulnerability findings share asset identity with detections.
How do we know which vulnerability to fix first?
Per-asset risk scoring and remediation views, with exploitable and known-exploited vulnerabilities correlated against actual attack activity on the same host. A correlation family exists specifically for exploitation attempts against a confirmed-vulnerable host.
Works with
The modules next to this one
Every module runs in the same self-hosted stack and shares the same telemetry, severity model and response engine.
XDR — Detection & Correlation
Turn raw events into severity-graded, ATT&CK-mapped alerts — then connect them into real attacks.
ExploreEDR — Endpoint Detection & Response
Deep endpoint visibility and on-box response, from a lightweight native agent.
ExploreCompliance
Map every event to the frameworks your auditors care about.
ExploreSee Vulnerability Management running on your own infrastructure
We will walk through the console, the deployment model and what it takes to stand it up in your environment.
24/7 SOC Monitoring Available