VMware Harden

vmware-harden

For a read-only check of this skill with your model and agent host, use the shared model-fit self-test in the marketplace root.

Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by VMware, Inc. or Broadcom Inc. "VMware", "vSphere", "ESXi", and "NSX" are trademarks of Broadcom. Source code is publicly auditable at github.com/vmware-skills/VMware-Harden under the MIT license.

English | 中文

AI-native VMware compliance and baseline enforcement. Sibling to the vmware-* skill family.

• Read-only against vSphere: all 8 MCP tools carry the [READ] marker and none mutate managed VMware infrastructure; scan_target writes only to the local twin DB (a cache of its own observations). See Read-only by design.

GA family member (since v1.5.18)

Production-ready compliance platform with 9 built-in baselines (CIS ESXi 8.0 + 9.0, vSphere SCG v8 + v9, vSphere 9 STIG-aligned, 等保 2.0 三级, PCI-DSS 4.0, EU NIS2, BSI IT-Grundschutz) carrying 99 rules, a VMSA known-vulnerability check for ESXi and vCenter builds, multi-vCenter Twin, drift detection, LLM Remediation Advisor, MCP server with 8 audited tools, web dashboard, and vmware-harden doctor environment diagnostics.

Quickstart

# The collectors extra is what makes `scan` work: harden reads inventory

through vmware-aiops / vmware-storage / vmware-nsx-security, and `uv tool

install` gives each tool its own environment — installing them separately

puts them where harden cannot import them from.

uv tool install "vmware-harden[collectors]"

Reporting on an existing twin DB needs no collectors:

uv tool install vmware-harden

List built-in baselines

vmware-harden baseline list

Run a scan

vmware-harden scan --target --baseline cis-vmware-esxi-8.0-subset

Or use 等保 2.0 三级 (国内合规独家)

vmware-harden scan --target --baseline dengbao-2.0-level3-vmware

View results

vmware-harden report vmware-harden drift

Generate remediation suggestions

export ANTHROPIC_API_KEY=... # optional; falls back to mock without vmware-harden advise --all-critical

Web dashboard

vmware-harden web --port 8080 # → http://127.0.0.1:8080

Reading a result: violations alone are not a verdict

A rule can only judge configuration that was actually gathered, and that fails in two independent ways. A rule whose attribute no collector produces is not executed at all. A rule that *does* run can still learn nothing about one particular host, because there the value came back absent or as the N/A sentinel — an unreachable host, an account without the privilege, a setting the ESXi build does not have. Neither is reported as passing:

$ vmware-harden report

No violations among the checks that could be made.

16 of 20 rules could not be evaluated — no collector provides the data they check, so their result is unknown, not compliant. 6 of 8 per-node checks could not be made across 2 node(s): the rules ran, but the values they read were missing on those nodes, so those nodes are unknown rather than compliant. Not evaluated: cis-esxi-2.1.1 no collector writes host.ntp_enabled ... Not judged on these nodes (data missing): cis-esxi-2.2.1 esx-02 esxi_build ...

--format json returns {"violations": [...], "coverage": {...}}, and the MCP tools return the same coverage block, so an agent reading violations: 0 cannot conclude "compliant" on its own. Before v1.9.0 the uncollected-attribute rules matched zero rows and were silently counted as passes; before v1.10.0 the per-node case was, too. See RELEASE_NOTES.md.

The two lists call for different work: the first is waiting on a collector, the second on that node's reachability and the scanning account's privileges.

Offline / Air-Gapped Install (from source)

This project uses the modern PEP 517 build system (hatchling), so there is no `setup.py` by design — that is expected, not a missing file. If you cloned the source and hit ERROR: File "setup.py" or "setup.cfg" not found ... editable mode currently requires a setuptools-based build, your pip is older than 21.3 and cannot do an *editable* (-e) install with a non-setuptools backend. Editable mode is a developer convenience, not needed to run the tool — do one of:

# From the source tree — a normal (non-editable) install builds a wheel:

pip install . # NOT pip install -e .

...or upgrade pip first, and editable works too:

pip install --upgrade pip && pip install -e .

For a truly air-gapped host, build the wheels on a connected machine and copy them over — the target then needs no network:

# On a connected machine, collect this package + its dependencies as wheels:

pip wheel . -w dist # → dist/*.whl (or: uv build, for just this package)

Copy dist/ to the air-gapped host, then install offline:

pip install --no-index --find-links dist vmware-harden

Read-Only by Design

vmware-harden is read-only against vSphere and NSX — all 8 MCP tools carry the [READ] marker, and none mutate managed VMware infrastructure. scan_target writes only to the local twin DB (~/.vmware-harden/twin.duckdb), a cache of its own observations rather than managed infrastructure. Remediation is never applied by this skill; it is deferred to vmware-pilot, which provides approval gating and audit trails for write operations.

Built-in baselines

baseline list returns 10 IDs: the 7 rule-bearing YAML baselines above (99 rules total), the two v9 aliases, which carry no rules of their own and resolve to their v8 parent's, and vmsa-advisories, which is generated from the advisory catalog rather than read from a file.

Known vulnerabilities (VMSA)

vmsa-advisories judges each ESXi host's and the vCenter's own version and build against an offline catalog of VMware security advisories shipped in the package (vmware_harden/advisories/catalog.yaml, checked against its sources on the catalog date). One rule per advisory; each rule's text quotes the 等保 2.0 三级 control it evidences (安全计算环境·入侵防范: find known vulnerabilities and patch them after testing).

vmware-harden scan --target prod-vc --baseline vmsa-advisories

vmware-harden report # each affected component: its fix, and whether the CVE is in CISA KEV vmware-harden report --format csv > vmsa.csv

A clean result means no open advisory known as of the catalog date, not "not vulnerable": advisories published later are not in the catalog. Builds are compared only within one major.minor line (a 7.0 U3 build can be numerically larger than an 8.0 GA build).

How the catalog is built. Broadcom's advisory pages are behind a bot challenge and cannot be read by a script, and Broadcom publishes no CSAF feed. Each entry is assembled from the NVD CVE API (CVEs, CVSS, vulnerable versions), the CISA KEV feed (exploited in the wild), and Broadcom's build-number KB articles (fixed builds), with each fixed release confirmed against an independent source quoting the advisory. Every fix is checked mechanically against a snapshot of the build KB in builds.yaml. The first catalog (2026-10-19) carries three KEV-listed advisories: VMSA-2025-0004 (ESXi), VMSA-2024-0019 and VMSA-2026-0006 (vCenter; its ESX half is not catalogued yet and reports unknown).

Optional refresh. vmware-harden advisories update downloads the CISA KEV feed (and, with --nvd, NVD scores) into ~/.vmware-harden/advisories-cache.json, which the catalog loader overlays: KEV flags are only ever added, CVSS only filled where missing, and fixed builds are never taken from it. It also lists ESXi/vCenter CVEs in KEV that no catalogued advisory covers. A failed KEV fetch exits 1 and leaves the previous cache unchanged; an NVD record that cannot be read is reported and does not block the KEV refresh. A running MCP server picks up a new cache on its next call. Reports show when KEV was last checked. vmware-harden advisories show prints the catalog date and the last refresh.

VCF 9.0 / 9.1 Compatibility

The existing baselines (cis-vmware-esxi-8.0-subset, vsphere-scg-v8, dengbao-2.0-level3-vmware, pci-dss-4.0-vmware) scan VCF 9.0 / 9.1 clusters successfully — most rules target host advanced settings stable across 8.x → 9.x. cis-vmware-esxi-9.0-subset and vsphere-scg-v9-subset ship today as extends: aliases of their v8 parents — same rules, a v9-named ID to scan and report under. Rules specific to 9.x will be added to them as Broadcom publishes the v9 guides.

vsphere-stig-v9-subset is a rule-bearing STIG-aligned baseline: 12 host advanced-setting controls (account lockout, password policy, DCUI access, shell/DCUI timeouts, MOB, guest BPDU, remote syslog) mapped to the official open-source vSphere STIG content (MITRE InSpec / Cinc Auditor). Status: experimental. Its checks read ESXi host advanced settings the host collector fetches via a config.option PropertyCollector pass. That pass was verified end-to-end on 2026-08-13 against a live standalone ESXi 8.0.3 (build 24280767): all 12 attributes came back populated, with values in the shapes the rules expect (account_lock_failures=5, dcui_access='root', password_quality_control='retry=3 min=disabled,disabled,disabled,7,7', mob_enabled=False, syslog_remote_host=''), and the scan raised 3 genuine violations. Still unverified, and why the status stays experimental: ESXi 9.x, which is what this baseline actually targets, and any vCenter-managed multi-host inventory. Treat results on 9.x as non-authoritative. The v1.9.0 undetermined mechanism does not cover a failed fetch on its own: it refuses a rule when *no collector declares* the attribute, a static check against the vocabulary, and these STIG attributes *are* declared, so their rules do run. If the real PropertyCollector pass comes back empty on live hardware, the attribute is simply absent and the rule again matches zero rows. **v1.10.0 catches that c