Coverage Matrix

What the suite audits

Coverage is described by what we audit, not by how many scripts do the auditing. Content is added continuously and coverage packs install further controls into deployments already running, so any single total is out of date the moment it is published. The platforms and control domains below are what a deployment audits.

Platforms audited

Linux Debian and Ubuntu, RHEL derivatives including Rocky and AlmaLinux, Fedora, openSUSE, Arch, Alpine, Gentoo, Void, NixOS, Clear Linux, Solus and Slackware
Windows Windows 10 and 11, Windows Server 2019 and 2022, collected over WinRM and PowerShell
macOS macOS 11 Big Sur and later
Hypervisors VMware ESXi, Proxmox, Xen, KVM and Nutanix
Network and web Switch and network device exposure, and web server configuration

These are the hosts the suite can audit, which need only a shell and access. The management server itself installs on a narrower set — see the server requirements in the documentation library.

Control domains

Each domain is a family of checks that grows as benchmarks and advisories are published.

Windows

  • ✓Baseline and common configuration
  • ✓Known-vulnerability probes
  • ✓Installed applications
  • ✓Server roles
  • ✓Desktop and endpoint
  • ✓Platform and identity

Linux

  • ✓Host platform and baseline hardening
  • ✓Security controls and advanced controls
  • ✓Installed applications and web services
  • ✓Network, storage and data
  • ✓Cloud and container workloads
  • ✓Automation, scheduling and distribution-specific checks

Environments

Bare metal and virtual machines Physical servers and VMs, including air-gapped estates
Containers Docker on Linux
Kubernetes Kubernetes 1.20 and later
Cloud AWS, Azure and Google Cloud compute and container services

How coverage grows — and why we publish no total

Two independent axes.

Hardening coverage follows benchmarks and grows with each release. Vulnerability coverage follows published advisories and arrives between releases in coverage packs you install into a deployment already running. They grow independently, so no single number describes both.

A total would be wrong on arrival.

Any figure describes one tree at one moment. A deployment that has taken pack updates holds more than a freshly installed one, so a published total understates some estates and overstates others. Where a count is genuinely useful it belongs in release notes, tied to a version and to the evidence for it.

We publish no remediation script count.

AuditToolkit ships automated remediation for Linux, Windows and hypervisors, and Emendian extends it with approval gating and rollback. A defensible total would need a rule the repository does not have — hand-written scripts only, or everything a dispatcher can invoke — and the dispatchers use different formats that give different answers depending on how they are read. A number that changes with how you count it is not worth quoting. Remediation coverage is described on the remediation page instead.