Your servers do not need another list of CVEs. They need risk taken off the table.
A lightweight agent inventories every enrolled Windows, Linux and macOS host: hardware, software, services, patch state and security configuration. The cloud correlates each installed package against published vulnerabilities, scores every host with the Viking Exposure Score, recommends the fixes that pay best, executes the approved ones, and proves the result on the next inventory. The cycle ends at risk reduced and measured, not at a report.
A scanner ends at a list. A patch tool ends at "installed". Nobody closes the loop.
Most teams run one product that finds vulnerabilities and another that deploys updates, and the two never agree on what actually changed. The scanner's list grows, the patch tool reports success, and the question that matters stays unanswered: how much risk did this month's work remove?
Infrastructure Defense keeps the whole cycle in one place. Detection, prioritization, execution and verification work from the same inventory, so when a job finishes, the platform does not assume the fix worked. It reassesses the host and states which vulnerabilities closed and how far the score dropped. If a reboot is still pending, the job says so instead of declaring victory.
[inventory] web-prod-02: 412 packages, 6 listening services
[correlate] 11 CVEs match installed versions, 2 in CISA KEV
[score] VES 82 High: CVSS 9.8, EPSS 89%, internet exposed
[resolve] apply 9 security updates, expected 82 → 54
[approve] window Sunday 02:00, auto-reboot stays off
→ pre-checks passed, updates applied by the agent
→ verified by reassess: 11 closed, VES 82 → 54
Inventory, detection, patching and compliance, from one agent.
The WASViking Sentinel Host agent reports over mutual TLS and never decides anything on its own. Every detection, score and recommendation is computed centrally; the agent only collects, executes what a person approved, and verifies. It reads posture, never the content of user files.
An asset inventory that answers questions
Hardware down to processor, memory, volumes and GPU. Network interfaces with MAC addresses, cloud instance metadata, running services and listening ports, installed software with publisher and install date, local accounts, and the host's last connection location. "Show me every server running OpenSSL 3.0" is a search, not a project.
Detection qualified by the exact release
Installed packages are matched against the OSV vulnerability database, qualified by the distribution branch so a patched host is never flagged for another release's bug. Windows security updates come from the platform's own update service, macOS from the published security releases, and third-party Windows applications from the package manager inventory.
Missing patches stated as impact
A pending update is not a row in a list. It is the set of open vulnerabilities it closes and the score drop it is expected to deliver, computed before anyone approves anything. The team always knows which change pays best next.
Configuration and compliance, continuously
Checks aligned with CIS benchmark sections run on every inventory: SSH hardening, host firewall, legacy cleartext services, remote desktop exposure, endpoint protection. Platform posture is collected too: disk encryption, Secure Boot and TPM on Windows, System Integrity Protection, Gatekeeper and MDM enrollment on macOS. Each host carries a compliance percentage with a PCI DSS mapping of the same results.
Patch execution under your rules
Approved jobs run through the native mechanism of each platform: the system package manager on Linux, the update service on Windows, software updates on macOS. Pre-checks confirm disk space, host health and elevation before anything changes. Manual approval is on by default; automatic deployment and automatic reboot are off by default; maintenance windows are enforced per policy.
End of life, before it becomes a CVE
An operating system or a tracked software product past its vendor's end of support raises the score on its own, because no patch is coming. The factor lights up from published lifecycle data, with the date on the label, before the next advisory ever ships.
The score reads the whole platform, not just the host.
Standalone vulnerability management tools score a host from what the host reports. WASViking also runs your external attack surface discovery, your application and API testing, and your edge telemetry, so Infrastructure Defense scores each server with evidence no host agent can produce alone.
Internet exposure is proven, not assumed
The exposure flag lights when the platform's own attack surface discovery shows a public asset resolving to an address assigned to the host, and the proof is named on the score: which hostname, which address. A shared office egress address never counts, and a manual decision by your team always wins over the automation.
Active attacks raise the score while they happen
When edge telemetry shows blocked attack traffic in the last seven days against a hostname a server actually serves, that server's score rises, with the count and the target on the label. Known crawlers are verified and excluded. When the traffic stops, the factor decays on its own.
Every number explains itself
The Viking Exposure Score is a sum of named factors with visible points: worst CVSS, exploitation evidence, exposure, business criticality, environment, end of life, active attack. Every screen shows the exact arithmetic, so "why is this critical" always has a concrete answer a director and an engineer both accept.
Risk reduction you can put in front of a board.
Patch counts do not survive a hard question. Measured risk does. Infrastructure Defense reports the fleet the way leadership reads it: infrastructure risk before, infrastructure risk after, and the verified work in between.
Verified numbers, not activity metrics
A completed job records the vulnerabilities the reassessment actually closed and the score movement it produced. The branded PDF report tells the same story for stakeholders: fleet posture, verified risk reduction, top risks with their reasons, compliance per host.
Minutes from key to first score
Generate an activation key, pick the platform on the install page, and run one command; Windows fleets get a standard MSI for mass deployment. The agent registers, inventories and scores within minutes, keeps itself current with one-click updates, and can be restarted or removed remotely from the console.
Control an auditor recognizes
Every approval, execution and policy change lands in the audit trail with who and when. Patch job outcomes notify Slack, Teams, email or webhooks. Policies state per host group what may be assessed, what requires approval, and when changes are allowed.
Evidence mapped to the controls your auditor already asks about.
Vulnerability management, patching discipline, hardening and asset inventory are named controls in every major framework. Infrastructure Defense produces the per-host, per-change record those controls expect.
| Framework | Control | What Infrastructure Defense contributes |
|---|---|---|
| CIS Benchmarks | Hardening sections for SSH, host firewall, legacy services and remote access | Continuous checks aligned with benchmark sections, a compliance percentage per host and per fleet, and the failing controls named on each asset |
| PCI DSS v4.0 | Req 6.3.1 vulnerabilities identified and ranked · Req 6.3.3 patches installed within a defined timeframe · Req 2.2 system hardening | Ranked vulnerability detections with exploitation context, a dated record of each patch job from approval to verification, and hardening checks mapped to the requirement |
| ISO 27001:2022 | Annex A.8.8 management of technical vulnerabilities · A.8.9 configuration management · A.5.9 inventory of assets | Per-host vulnerability lifecycle with evidence, configuration state with drift visible on reassessment, and a live asset inventory with ownership context |
| NIST CSF 2.0 | ID.AM asset inventories · PR.PS-02 software is maintained and patched | Hardware and software inventories refreshed on every report, plus the measured record that maintenance actually happened and what it changed |
| LGPD · GDPR | Article 46 · Article 32 technical and organisational measures | Demonstrable, dated evidence that the servers processing personal data are inventoried, assessed, patched under control and measurably improving |