SchildmarkGuide
XDR with built-in patch management: detection and verified patching in one product
An XDR with built-in patch management finds a vulnerability, fixes it and proves the fix from the same console, so nothing falls between a security tool and a separate patch tool. The part to check is verification: a patch counts as done only when a fresh scan confirms the vulnerability is gone, not when the installer reports success.
Why detection and patching belong together
Many attacks use vulnerabilities for which a fix already exists; CISA keeps a public catalogue of known exploited vulnerabilities for exactly that reason. The fix is rarely the hard part. Knowing which machine needs which fix first, and being sure it went in, is.
With two products, the security tool sees the attack while the patch tool has its own inventory, its own priorities and its own idea of done. Someone reconciles the two, usually by hand, and the gap between them is where an exposed server stays exposed for another month.
In one product, the same agent reports the vulnerable package, the same console ranks it next to the alerts on that machine, with known exploited vulnerabilities first, the fix is planned and approved there, and the next scan closes the finding. The auditor gets one record from finding to verified fix. The patching page shows it in the console, and the AI analyst can find the vulnerable package and propose the fix for you.
What “verified patching” means
Installed is not the same as fixed. A verified patch takes six steps, and the last one is a re-scan, not the installer’s exit code.
Confirm
Start from a vulnerability confirmed against vendor and NVD data, and read the machine’s current state.
Choose the version
The exact package version, or Windows KB, that fixes it. Not “latest”.
Rehearse
A dry run of the install on the machine, without changing it.
Approve
A person, or a policy you turned on. Critical machines need two different people.
Install
In the machine’s maintenance window, restarting only if the machine allows it.
Re-scan
Done only when the version is in place and the scan confirms the vulnerability is fixed.
In Schildmark a job ends Remediated only when the installed version is at least the target, the machine’s software list shows it, and verification reports every fixable vulnerability of the job as fixed. Otherwise it says Not verified or Reboot required. A kernel fix waits until the machine has restarted, and a finding that returns within 30 days is reopened.
Automated patch approval: what to approve unattended, and what never
Unattended approval takes the routine work off your team, not the judgement. A sound policy limits it by environment, by machine criticality and by package, and every automatic decision stays on the record.
- Routine fixes
- Unattended approval only in the environments you list, on machines that are not high or critical, and for plans with nothing restricted. Such jobs say Approved automatically by policy, and are still rehearsed and re-scanned.
- High and critical machines
- Never approved unattended. Critical machines need two different people.
- Restricted packages
- Packages such as container runtimes need escalated approval, whatever the policy says.
- Windows and restarts
- Scheduled jobs wait for the maintenance window; restarts outside it are refused. Without permission, neither a patch nor a person can restart the machine.
- Rings
- One package across rings of machines; the next ring starts only when the one before has succeeded.
- Fixes you cannot install
- Record an accepted risk with owner, reason and expiry, instead of a finding left open without explanation.
- The limits
- A rehearsal catches failed dependencies and conflicts, not every application regression. Keep criticality labels current, and put the machines whose failure would stop the business in the high or critical class.
Patch management for Windows, Linux and macOS: what it installs from
Ask every vendor for this table, with the status of each channel, rather than a row of logos. This is Schildmark’s today.
| Channel | Status |
|---|---|
| apt, dnf (Linux) | Available |
| Windows Update KBs | Pilot |
| winget, pip | Pilot |
| Homebrew (macOS) | Pilot |
| macOS system updates, other third-party applications | Installed on the machine; the console shows them as fixed once the scan confirms it |
Patching uses the same Schildmark Agent, installed with --patching. It connects out only, signs every request, and runs only jobs your console signed, from a fixed list of actions: exact package versions, Windows KBs, restart, start, stop, uninstall. There is no shell and no “run command”.
What to ask a vendor about XDR with patch management
Six questions that separate a patching feature from patching you can rely on.
- When is a patch “done”?
- On the installer’s exit code, or when a new scan confirms the vulnerability is gone? Ask to see a job that failed verification.
- Can I see the rehearsal?
- A dry run on the machine before anyone approves shows what would change.
- What is never approved unattended?
- Which machines, environments and packages are excluded, and can one person override the exclusions?
- Which channels are generally available?
- Per operating system and package source: available, pilot or not supported.
- What can the agent be told to do?
- A patch agent that runs arbitrary commands is a remote shell on every machine. Ask for the fixed list of actions and how jobs are signed.
- What evidence do I get?
- Approvals, rejections, runs and verified fixes for a period, as files an auditor can open.
Patching evidence for NIS2, ISO 27001 and PCI DSS
All three name vulnerability handling. NIS2 Article 21(2)(e) covers vulnerability handling and disclosure; ISO/IEC 27001:2022 Annex A 8.8 asks for the management of technical vulnerabilities; PCI DSS v4.0.1 requirement 6.3.3 asks for critical patches within one month of release.
Schildmark’s evidence pack for a period contains vulnerabilities_fixed.csv, with the proof of each verification, and patch_activity.csv, with approvals, rejections and runs. More on the compliance page and the NIS2 page.
Questions people ask
What is an XDR with built-in patch management?
An XDR that does not only detect attacks but also installs the fixes for the vulnerabilities it finds, from the same agent and the same console. The useful kind verifies each fix with a new scan and keeps the record, so detection, remediation and audit evidence sit in one place.
Can patch approval be fully automated?
For routine fixes on ordinary machines, yes, if a policy limits it. In Schildmark unattended approval applies only to the environments you list, never to high or critical machines, and never to plans with restricted packages. Critical machines always need two people. Automatic jobs are still rehearsed and re-scanned.
How do you verify that a patch actually worked?
Check three things: the installed version is at least the fixed version, the machine’s software inventory shows it, and a fresh vulnerability scan no longer reports the vulnerability. An installer that exits without an error proves none of these on its own.
Which operating systems can Schildmark patch?
Linux packages through apt and dnf are available. Windows Update KBs, winget, pip and Homebrew on macOS are in pilot. macOS system updates and other third-party applications are installed on the machine itself, and the console shows them as fixed once the scan confirms it.
Do we still need a separate patch management tool?
Possibly. If another tool already rolls out your Windows or macOS updates, keep it. Schildmark still sees those fixes, including updates made outside it, and counts them once the scan confirms them, so your vulnerability record stays complete either way.
See a patch job from finding to verified fix
Tell us which systems you run and how you patch today. We will show you a rehearsal, an approval and a verification on a machine like yours.