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 can patch and re-test on its own.
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
Security Validation does not quietly patch your fleet. It builds a remediation plan and proposes it. 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.
When automation cannot resolve a finding — a pinned dependency, a vendor app that breaks on upgrade, a package with no fixed version — it escalates with full context instead of retrying forever.
- 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 estate moves.
- Updates pulled from vendor and distribution repositories only.
- 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, the answer is a button: every package, every version, every source, every device — exported as CSV or as a PDF report.
Audit evidence, not samples
Auditors asking for a software inventory get the whole fleet with versions and sources, dated to the scan. No spreadsheet assembled by hand the week before.
CSV or PDF
CSV for your own analysis and asset reconciliation. PDF Report for the people who need a document, with severity breakdown and affected device counts.
Answers the awkward questions
Where is that end-of-life runtime still installed? Which machines still have the compromised package? How many devices run the vulnerable CMS plugin? Filter and export.
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