Security Validation
Every system. Every night. The nightly fleet scan inventories the software on every device and correlates it against vulnerability data — apps, custom apps, CMS components, and the language ecosystems your developers pull from.
It finds the software package managers do not know about, flags what is actively exploited, hunts for supply-chain compromise, and turns what it finds into remediation jobs your team approves.
Enumerating every package manager on every device
The dashboard
The whole fleet, scored by what actually matters
Raw CVE counts are noise. Security Validation separates the total from the four that are critical, the one that is on CISA's actively-exploited list, and the twenty-five sitting on internet-facing components. That is the queue you work.
Shown in the portal's dark theme. AlertMonitor ships with both dark and light themes — pick per user.
Coverage
Every package manager. Every language. Every device.
Most vulnerability tools ask the package manager what is installed and stop there. That answer is incomplete on every real fleet. Security Validation collects from the package databases and from the filesystem, so the inventory includes the software nobody registered.
OS Packages
The system package databases, read directly on the device — no credentialed remote scan, no scan window.
Language Ecosystems
Where modern risk actually lives. Dependencies are inventoried per interpreter and per project, not just globally.
Unmanaged Software
Software no package manager knows about. This is the category conventional scanners report as clean.
Discovery, not just enumeration
- Python virtualenvs found by walking the filesystem for pyvenv.cfg, then reading each dist-info METADATA file.
- Per-project node_modules trees found by locating package.json files outside node_modules.
- Manually installed binaries that never touched apt, rpm, or an installer.
- Applications dropped into /opt by a vendor script or a helpful contractor.
- Language runtimes installed side-by-side with the distribution version.
Findings
Component, version, fix, and exactly where it lives
Each finding names the component, the installed version, the fixed version, the collector that found it, and how many devices carry it. No vague “host is vulnerable” — the row tells your engineer what to change.
Sorted by exploitability
KEV listing and internet exposure move a finding up the queue regardless of its CVSS score. A 6.9 that is being exploited on a public host beats a 9.8 on an air-gapped box.
Source-attributed
The Source column tells you which collector found it — gem, pip-venv, nuget, opt-app. That is the difference between a five-minute fix and an afternoon of hunting.
Fleet-aware
The Devices count shows blast radius immediately. One finding on six machines is one change rolled six times, not six tickets.
Supply chain
It doesn't just find vulnerabilities — it hunts for compromise.
A compromised npm or PyPI release is not a CVE. There is no advisory to match, no fixed version to upgrade to, and often no signal at all until someone publishes a post-mortem weeks later. By then the package has been installed on developer laptops, build agents, and production servers.
That is why conventional vulnerability tooling misses supply-chain attacks: it is built to compare version strings against a database of known-bad versions. If the database does not know yet, the scan comes back clean.
Security Validation looks for signs of compromise inside the language ecosystems themselves — npm, PyPI, RubyGems, and NuGet packages — across the whole fleet, every night. Not one build server. Not one repo. Every device that has the package on disk.
- Sweeps npm, PyPI, RubyGems, and NuGet packages wherever they are installed.
- Covers per-project virtualenvs and node_modules, not just global installs.
- Runs nightly on every device — laptops included, not just CI.
- Findings land in the same queue as CVEs, with the same device attribution.
Remediation
Remediation you approve, not remediation that surprises you
This can be automated. We generally recommend it is not. Upgrading a library inside a running application is a different risk from a routine OS patch, so by default Security Validation builds the remediation plan and proposes it rather than acting. Every job lands in a queue with the host, the exact path, the packages involved, the versions it wants to move between, and the CVEs it closes — then waits for an admin.
From there you have two moves. Dry run executes the plan without committing it, so you can see precisely what would change before anything does. Approve runs it for real. A backup is held first, so a patch that breaks a vendor app can be rolled back rather than argued about.
Updates come from the OS vendor or distribution repositories. The remediation path uses the same trusted sources as your normal patch process, so fixing a supply-chain problem never introduces one.
Closed-source software is handled honestly. If an application ships as a compiled or encrypted binary, nobody can patch its internals from the outside — the fix has to come from the vendor. Those findings are flagged as a manual upgrade so they land on a call with the vendor instead of silently failing in a queue.
And when an upgrade is genuinely awkward — a pinned dependency, a package with no clean fixed version — the Ask AI tab works the problem with you: what the finding affects, what is likely to break, and how to confirm the upgrade actually worked.
- Every job is proposed first — nothing changes on a device without an approval.
- Dry run any job to see exactly what would change before committing it.
- Backups are held before a run, so a bad patch can be rolled back.
- Jobs carry host, path, package versions, severity and CVE up front.
- Re-plan rebuilds the queue against the latest scan when your infrastructure moves.
- Updates pulled from vendor and distribution repositories only.
- Closed-source binaries are flagged as a manual, vendor-side upgrade.
- Ask AI helps you work through and validate the difficult upgrades.
- Every attempt is recorded in the History tab.
Reporting
One click, full enterprise software inventory
Most organizations cannot answer “what software is installed here?” without a project. Because the nightly scan already collects it across every system, the answer is a button. Everything it finds — including software somebody installed by hand that no package manager ever registered — rolls into the Software Audit and Software Reporting automatically. And because the platform already manages those devices, you can push software out to any set of them from the same place.
Software Audit
Every install across every system lands in the audit — including manually installed applications that never went through apt, rpm, or an installer. That is the category most inventories quietly miss.
Software Reporting
Run a report over the whole fleet, dated to the scan, with versions and sources. CSV for your own analysis and asset reconciliation, PDF for the people who need a document.
Install, not just observe
Select devices and deploy software to them from the same console that found the gap. Reporting and remediation are the same system, so what you discovered is what you act on.
The same data set drives the findings queue, the remediation runs, and the export. One collection, three uses.
Security Validation — Questions We Get
See what is actually installed on your fleet
Most first scans surface software nobody knew was there. Book a demo and we will walk the findings queue, the supply-chain sweep, and the export with your environment in mind.
← Back to AlertMonitor