Ask whether the scanner reads Windows base image versions and installed updates, not just Linux package databases. Windows container images get fixes only when the publisher rebuilds the base image, so the useful finding is "this image is behind the current monthly base". Many tools built around Linux do this poorly, so test with a real image.
How Windows container patching differs
Microsoft states that Windows Server containers don't have a servicing stack like Windows Server, so you cannot get updates inside a container. Instead the Base OS images are rebuilt each month, and images such as .NET or IIS are rebuilt on top of them. The updated images are published on the second Tuesday of each month, and that monthly release is the only regular one that includes new security fixes, according to the same page.
Two consequences follow for scanning.
- The fix for an operating system flaw is a newer base image, not a package upgrade command.
- The version of the base image, the OS build and revision, is the key fact. It is what you compare against the current release.
The host matters too
Process isolated Windows containers share the kernel with the host. Microsoft documents a compatibility baseline introduced with the February 2020 security update: hosts and containers both before it work together, both after it work together, and combinations on different sides do not work. The version compatibility page covers isolation modes in more detail, including Hyper-V isolation, which is more flexible.
So when you rebuild an image for a patch, check that the hosts in your cluster are also current enough to run it. A scanner will not tell you this, but your rollout plan must.
Questions to ask
| Question | Why it matters |
|---|---|
| Which Windows base images and versions do you recognise? | Unrecognised versions produce empty results that look clean |
| Do you report the OS build and revision? | You need it to judge currency |
| Do you read .NET and other language packages inside the image? | Application dependencies still carry findings |
| Is the output an SBOM with those components? | Needed for sharing and audits |
| Can you scan without a Windows host? | Affects where CI runs |
| How do you handle images based on Nano Server? | Minimal images expose fewer details |
Run the same Windows image through any candidate and compare the results with what you know is inside. An empty report on an image you know is old is a failed test, not a good result.
Practical routine
- Inventory Windows images and record the base tag and the OS revision.
- Rebuild on a schedule that follows the monthly base release.
- Scan the application layer on every build, as you would for Linux.
- Gate on the same policy for application dependencies, and add an age rule for the base.
- Test new images on a canary host group before wide rollout.
Check the current list of supported Windows Server versions on Microsoft pages before you pin to one, since support dates change.
Where Safeguard fits
Safeguard scans container images and application dependencies, produces SBOMs, and applies policies. For Windows images, test with your own image first, the way the table above suggests. You can start with a free scan.
Quick check
Can I patch a Windows container by running updates inside it?
Microsoft says no. Containers have no servicing stack, so you rebuild on the updated base image and redeploy.
Does a clean scan on a Windows image mean it is current?
Not necessarily. Confirm the scanner recognised the base version, then compare the OS revision with the latest monthly release.
Sources
- Microsoft Learn: Update Windows Server containers
- Microsoft Learn: Windows container version compatibility
Last reviewed: 19 October 2026.
