Patch Management is where a decision to fix something becomes an actual change on an actual machine. It takes approved remediation, turns it into tracked jobs, hands those jobs to the SITEY agents running on your servers and workstations, records exactly what ran and what came back, and keeps a documented way to undo it. It is the largest module in the platform, and it is deliberately the most conservative one: on the manual path, nothing reaches a host without an approval and a pre-flight record. If you later switch on Autonomous Operations, that first approval can be delegated to the engine under a policy you configure, and the pre-flight record is written either way.
The problem
Without a patch pipeline, closing a vulnerability means a person repeating the same sequence by hand. Read the finding. Work out which KB or package actually fixes it. Search the vendor catalog, pick the build that matches the host architecture, download it, remote into the machine, run the installer, watch for a reboot prompt, then go back to the ticket and mark it done.
Nobody does a hundred and fifty of anything consistently. The ones that fail quietly stay failed. The registry change someone made on a domain controller last March has no approval record and no written way back. And the one operation that genuinely breaks something, a firewall rule with no port on it, a service disabled on the wrong box, happens with nothing standing between the idea and the endpoint.
How it works
- Work is grouped into batches, not rows
Select the hosts and the KBs, and the platform creates one parent batch plus one child job per host-and-KB pair, so a fifty-host, three-KB operation is a single line in your queue rather than a hundred and fifty. The batch carries live counters, total, succeeded, failed, in progress, pending, recomputed from the child jobs. A separate view derives which hosts need patching at all by reading open, non-archived findings and extracting KB identifiers from the finding name, CVE, description and solution text.
- Nothing runs until an approver says so
Every job is created in pending approval. Approving, rejecting, cancelling, retrying, editing a job payload and setting a maintenance window are all restricted to the admin role: including the bulk endpoints, so approving a batch cannot be used to bypass the per-job gate. Two rules close the obvious loopholes: editing a job’s payload drops any approval it already had and sends it back to the queue, and retrying a failed job returns it to pending approval, not straight to dispatch. This describes the manual path, which is the default. Autonomous Operations can approve its own first gate when you deliberately enable full-auto mode, and only within the guardrails you set there.
- Pre-flight runs before the change, not after
Before a job goes out, the platform records agent reachability, free disk, CPU load, pending reboot state, security posture, OS compatibility, conflicts with other queued patches, and how fresh the host inventory is. It writes a pre-state snapshot, a rollback plan specific to the job type, and a risk assessment covering service disruption, data loss, estimated downtime and whether a reboot is expected. Job types are also classified into risk tiers, with firewall rules and snapshot restores defaulting to a human gate.
- Delivery is leased, not fire-and-forget
An agent claims a job atomically and receives a lease with an expiry and an execution generation. It sends heartbeats while working. If it dies mid-job, the lease expires and the job returns to the queue with backoff and an attempt counter, so it is retried a bounded number of times rather than forever. A host that is busy can defer a job instead of failing it, within an hourly defer budget. Maintenance windows are enforced at claim time, a job outside its window is simply not handed out. Duplicate result posts are recognised and answered idempotently.
- Verification, rollback and learning
When a result arrives, the terminal write and its follow-up effects are queued in the same transaction, then processed by a worker with retries and a dead-letter state, so a crash between “job finished” and “consequences applied” cannot lose either. Post-validation checks execution status, reboot requirement and service-count drift against the pre-state. When a job the autonomous engine started fails, the platform can queue a snapshot restore job and a rollback job on its own; for a job you created by hand, the snapshot and the rollback plan are still there, but an operator decides when to use them. Scripts that succeed feed the learned-script library; scripts that fail raise a negative counter and are quarantined once they cross a reliability threshold.
What you can do
- Create a single bulk operation across many hosts and many KBs, and track it as one batch with live counters.
Run fifteen job types, covering both Windows and Linux hosts, plus the full snapshot lifecycle:
Resolve real download links for a KB from the vendor catalog, with the architecture-appropriate build (x64 or arm64) selected at approval time from the agent’s reported architecture.
Restrict agent downloads to HTTPS and a fixed allowlist of official vendor hosts; installer arguments are sanitised before use.
Set a maintenance window per job. Windows that are in the past or that end before they start are rejected at the API, so a bad window cannot silently park approved work forever.
Take a real snapshot before a change: VSS on Windows, timeshift or LVM on Linux, registry export for registry-only fixes, and reuse a recent host snapshot instead of taking a redundant one. Snapshots carry a TTL, and a background pass queues a delete job for the ones that expire.
Read each job’s pre-flight checks, rollback plan, risk assessment and post-validation results on one detail page, alongside the host’s inventory snapshot, the linked finding, and the AI triage record that produced it.
See the actual script that will run, with its provenance: reused from the learned library, adapted, newly generated, or manual, plus the diff against its parent.
Edit a job’s payload, retry it, or cancel a single job or a whole batch.
Review remediation history by category (auto patch, vendor contact, manual review, config change, compensating control) and by software type, with per-host success rates and a list of learned patterns.
Open a re-evaluation conversation that gathers every script run against that host and finding, together with the engine’s recorded reasoning, when a fix is not behaving.
Offline packages are already supported: upload an .msu through the platform API, where it is stored content-addressed by SHA-256, and the agent fetches it through an authenticated endpoint with hash verification on both sides. This path is API only today, the web interface does not yet expose an upload button for it.
Who it is for
| Role | What they use it for |
|---|---|
| System and Windows administrator | Bulk KB deployment, maintenance windows, offline packages for isolated hosts, rollback plans they can read before saying yes. |
| SOC analyst | Turning a triaged finding into a job and watching it through to a verified result, without leaving the platform. |
| Security engineer | Registry, service, firewall and config remediation with pre-state capture and a documented undo path. |
| CISO and security manager | Per-host and per-category success rates, and a clear picture of what is stuck waiting for approval. |
| Compliance officer / auditor | An approval record per change: who approved, when, on which host, with what payload and what result. |
Why it matters
The expensive part of vulnerability management is not finding things. It is the distance between a finding and a fixed machine, and that distance is usually made of manual steps that nobody has time to repeat. Batching collapses a hundred and fifty manual operations into one reviewed decision and a queue that reports its own progress.
The second cost is the patch that goes wrong.
A rollback plan written after an outage is not a rollback plan.
Here the snapshot, the pre-state and the undo steps exist before the change is dispatched, and when the autonomous engine is the one driving the change, a failure can trigger the restore path on its own.
The third cost is the audit. When every change carries its approver, its payload, its pre-flight record and its result, “prove this change was authorised” stops being an archaeology project.
Works with
- AI Remediation, produces the fix plan and the script that this module executes.
- Approval Gates, the human checkpoints around autonomous execution and snapshot cleanup.
- Agent Management, the endpoint agents that claim, run and report these jobs.
- Retest & Closure, independent verification that a finding is actually gone before it is closed.
Frequently asked questions
Do the endpoints need internet access?
Not necessarily. Agents can download update packages directly, but only over HTTPS and only from a fixed allowlist of official vendor hosts. For isolated hosts, you can upload the package to the platform through its API instead, and the agent fetches it from your own server, with SHA-256 verified on both ends.
What happens if a patch breaks the machine?
Each job carries a rollback plan written before dispatch, and a pre-state snapshot of the host. Where a real snapshot is required by policy, one is taken first (VSS, timeshift, LVM, or registry export) and the remediation waits for it. If a remediation that the autonomous engine started fails, the platform can queue a restore job against that snapshot plus a rollback job, rather than leaving the host in an unknown state. For a job you created and approved by hand, the same snapshot and rollback plan are recorded, and the restore is a decision you trigger from the job page.
Can it patch Linux as well as Windows?
Yes. Linux hosts support package updates, service disabling, config fixes and generated remediation scripts, with timeshift or LVM as the snapshot provider. The Windows side additionally covers KB and package installs, registry fixes and firewall rules.
Can someone accidentally patch the entire fleet at once?
Bulk approval requires the admin role, and every child job is still a separate, cancellable record. When the AI side proposes work across multiple machines, it must pass an explicit target list through a blast-radius cap that defaults to one host per call and always excludes machines you have marked exempt; raising that cap is a deliberate configuration change. Be aware that once you approve a batch yourself, its jobs are handed out as the agents claim them: the module does not currently split a rollout into timed waves, so the approval and the maintenance window are the throttles you have.
Patch Management is included in every SITEY deployment. It installs in your own infrastructure, and the hosts it touches are yours alone. See pricing for the full platform, or read how it connects to Autonomous Operations when you are ready to let the engine drive more of the loop itself.