The vulnerability management process most organisations run was designed for a world where exploitation took weeks. A scanner runs on a schedule. Findings are exported to a tracker. A ticket is raised, prioritised against everything else, assigned, scheduled into a change window, applied, and eventually closed. Mean time to remediate is measured in weeks for critical findings and months for everything else.
Exploitation of a newly disclosed vulnerability is now routinely observed within hours of disclosure. A pipeline measured in weeks cannot keep pace with a threat measured in hours, no matter how well it is run.
Speed to change is the metric
Every other vulnerability metric — count, severity distribution, SLA compliance — is a proxy. The quantity that determines whether you are breached is the window between exposure and remediation. Monolith is built to compress that window, and it does so by removing the queue rather than optimising it.
One continuous loop
Discover. Monolith maintains a live model of the estate and identifies new exposure as it appears — a newly disclosed CVE affecting software you run, a configuration drift that opens a port, a service exposed by a change — rather than at the next scan window.
Assess reachability. Not every vulnerability is an exposure. Monolith correlates each finding against what is actually reachable on your estate, from where, with what privileges, and against current intelligence on active exploitation. A critical CVE on an isolated host with no path to it is ranked below a medium one on an internet-facing service that is being exploited in the wild today.
Stage the fix. The remediation is prepared — patch, configuration change, compensating control, isolation — with its blast radius assessed and any dependency identified.
Execute on approval. You approve, and Monolith applies the change. Remediation classes you have pre-authorised execute without waiting.
Verify. The exposure is re-tested to confirm it is actually closed, not merely that the change was applied. A patch that did not take, or a service that restarted with the old configuration, is caught here rather than discovered by an attacker.
Local inference, no queue
The loop runs on the appliance or in your own cloud tenancy. There is no external API between a finding and a fix, no rate limit, no third-party outage that stalls remediation. Threat intelligence, vulnerability data and detection logic refresh continuously, so what the agent knows at 03:00 is what was published at 02:00.
What stays with humans
Speed without control is a different kind of risk. Monolith's authority is set by you and enforced outside the model. Irreversible changes and anything affecting production data are human-only at every autonomy setting. Every action — proposed, approved, executed, verified — is written to a tamper-evident store the agent cannot modify, and a single revocation control pauses everything.
Frequently asked questions
How is this different from a vulnerability scanner with auto-patching?
Scanners enumerate; auto-patch tools apply updates. Neither assesses reachability on your specific estate, stages compensating controls when a patch is unavailable, verifies that the exposure actually closed, or correlates findings against live exploitation intelligence. Monolith runs the whole loop and treats verification as a required step, not an assumption.
What if a vulnerability cannot be patched?
Monolith stages a compensating control — network isolation, access restriction, a detection rule for the exploitation technique — and presents it as the remediation. The exposure is reduced immediately while a permanent fix is pursued.
How does reachability assessment work?
Each finding is correlated against the live model of the estate: is the vulnerable service reachable, from which network segments, with what authentication, and is the vulnerability under active exploitation according to current intelligence. The result is a ranking by actual exposure rather than by CVSS score alone.
Can remediation be fully automatic?
For classes of change you pre-authorise, yes. Everything else is staged for explicit approval. Destructive or irreversible changes are never automatic. The autonomy setting is yours to adjust at any time.
How is verification performed?
After a remediation is applied, the exposure is re-tested — the service probed, the configuration read back, the detection exercised — to confirm the window is actually closed. The verification result is recorded alongside the change.