{
  "markdown": "<!-- mcp-name: io.github.vmware-skills/vmware-harden -->\n\n# vmware-harden\n\n<!-- mcp-name: io.github.vmware-skills/vmware-harden -->\n\n> **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](https://github.com/vmware-skills/VMware-Harden) under the MIT license.\n\nEnglish | [中文](README-CN.md)\n\nAI-native VMware compliance and baseline enforcement. Sibling to the `vmware-*` skill family.\n\n- **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](#read-only-by-design).\n\n## GA family member (since v1.5.18)\n\nProduction-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**, multi-vCenter Twin, drift detection, **LLM Remediation Advisor**, **MCP server** with 8 audited tools, web dashboard, and `vmware-harden doctor` environment diagnostics.\n\n## Quickstart\n\n```bash\n# The collectors extra is what makes `scan` work: harden reads inventory\n# through vmware-aiops / vmware-storage / vmware-nsx-security, and `uv tool\n# install` gives each tool its own environment — installing them separately\n# puts them where harden cannot import them from.\nuv tool install \"vmware-harden[collectors]\"\n\n# Reporting on an existing twin DB needs no collectors:\n#   uv tool install vmware-harden\n\n# List built-in baselines\nvmware-harden baseline list\n\n# Run a scan\nvmware-harden scan --target <vcenter-name> --baseline cis-vmware-esxi-8.0-subset\n\n# Or use 等保 2.0 三级 (国内合规独家)\nvmware-harden scan --target <vc> --baseline dengbao-2.0-level3-vmware\n\n# View results\nvmware-harden report\nvmware-harden drift\n\n# Generate remediation suggestions\nexport ANTHROPIC_API_KEY=...  # optional; falls back to mock without\nvmware-harden advise --all-critical\n\n# Web dashboard\nvmware-harden web --port 8080  # → http://127.0.0.1:8080\n```\n\n### Reading a result: violations alone are not a verdict\n\nA rule can only judge configuration that was actually gathered, and that fails\nin two independent ways. A rule whose attribute **no collector produces** is not\nexecuted at all. A rule that *does* run can still learn nothing about one\nparticular host, because there the value came back absent or as the `N/A`\nsentinel — an unreachable host, an account without the privilege, a setting the\nESXi build does not have. Neither is reported as passing:\n\n```\n$ vmware-harden report\nNo violations among the checks that could be made.\n\n16 of 20 rules could not be evaluated — no collector provides the data they\ncheck, so their result is unknown, not compliant. 6 of 8 per-node checks could\nnot be made across 2 node(s): the rules ran, but the values they read were\nmissing on those nodes, so those nodes are unknown rather than compliant.\nNot evaluated:\n  cis-esxi-2.1.1   no collector writes host.ntp_enabled\n  ...\nNot judged on these nodes (data missing):\n  cis-esxi-2.2.1   esx-02    esxi_build\n  ...\n```\n\n`--format json` returns `{\"violations\": [...], \"coverage\": {...}}`, and the MCP\ntools return the same `coverage` block, so an agent reading `violations: 0`\ncannot conclude \"compliant\" on its own. Before v1.9.0 the uncollected-attribute\nrules matched zero rows and were silently counted as passes; before v1.10.0 the\nper-node case was, too. See RELEASE_NOTES.md.\n\nThe two lists call for different work: the first is waiting on a collector, the\nsecond on that node's reachability and the scanning account's privileges.\n\n\n### Offline / Air-Gapped Install (from source)\n\nThis project uses the modern PEP 517 build system (hatchling), so there is **no\n`setup.py`** by design — that is expected, not a missing file. If you cloned the\nsource and hit `ERROR: File \"setup.py\" or \"setup.cfg\" not found ... editable mode\ncurrently requires a setuptools-based build`, your `pip` is older than 21.3 and\ncannot do an *editable* (`-e`) install with a non-setuptools backend. Editable\nmode is a developer convenience, not needed to run the tool — do one of:\n\n```bash\n# From the source tree — a normal (non-editable) install builds a wheel:\npip install .              # NOT  pip install -e .\n\n# ...or upgrade pip first, and editable works too:\npip install --upgrade pip && pip install -e .\n```\n\nFor a **truly air-gapped host**, build the wheels on a connected machine and copy\nthem over — the target then needs no network:\n\n```bash\n# On a connected machine, collect this package + its dependencies as wheels:\npip wheel . -w dist        # → dist/*.whl   (or: uv build, for just this package)\n\n# Copy dist/ to the air-gapped host, then install offline:\npip install --no-index --find-links dist vmware-harden\n```\n\n## Read-Only by Design\n\nvmware-harden is read-only against vSphere and NSX — all 8 MCP tools carry the `[READ]`\nmarker, and none mutate managed VMware infrastructure. `scan_target` writes only to the\nlocal twin DB (`~/.vmware-harden/twin.duckdb`), a cache of its own observations rather than\nmanaged infrastructure. Remediation is never applied by this skill; it is deferred to\nvmware-pilot, which provides approval gating and audit trails for write operations.\n\n## Built-in baselines\n\n| Baseline | Rules | Applies to | Source |\n|----------|-------|-----------|--------|\n| `cis-vmware-esxi-8.0-subset` | 20 | host | CIS Benchmark v1.0 |\n| `vsphere-scg-v8-subset` | 15 | host, vm | [VMware vcf-security-and-compliance-guidelines](https://github.com/vmware/vcf-security-and-compliance-guidelines) |\n| `dengbao-2.0-level3-vmware` | 20 | host, vm, datastore, dfw_rule | GB/T 22239-2019 三级 |\n| `pci-dss-4.0-vmware` | 10 | host, dfw_rule | PCI-DSS v4.0 |\n| `eu-nis2-vmware` | 12 | host, dfw_rule | EU NIS2 Directive (Articles 21/23, Annex I) |\n| `bsi-itgs-basisabsicherung-vmware` | 10 | host | BSI IT-Grundschutz (OPS.1.1.4 + SYS.1.1) |\n| `cis-vmware-esxi-9.0-subset` | 20 | host | Inherits `cis-vmware-esxi-8.0-subset` via `extends:` |\n| `vsphere-scg-v9-subset` | 15 | host, vm | Inherits `vsphere-scg-v8-subset` via `extends:` |\n| `vsphere-stig-v9-subset` ⚠️ *experimental* | 12 | host | vSphere 9 STIG-aligned host advanced settings ([DoD/DISA STIG content](https://github.com/vmware/dod-compliance-and-automation)) — collector verified on ESXi 8.0.3; not yet run against 9.x |\n\n`baseline list` returns 9 IDs: the 7 rule-bearing baselines above (99 rules total) plus the\ntwo v9 aliases, which carry no rules of their own and resolve to their v8 parent's.\n\n### VCF 9.0 / 9.1 Compatibility\n\nThe 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.\n\n`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 case** — such a host is recorded as a per-node gap (`coverage.undetermined_node_checks`) rather than a pass, so an unverified collector shows up as unjudged hosts instead of a clean report. What remains unverified is whether the pass returns the *right* values, which no coverage mechanism can tell you. The baseline's `status` field is surfaced by `list_baselines` and `describe_stig_content_sync` so a scan self-declares this caveat. It is a **content sync**, not an API wrapper — VCF Operations 9.1 Automated Configuration Compliance (ACC) / Security Posture Management (SPM) is UI- and schedule-driven and exposes **no public compliance REST API**. For continuous, fleet-wide enforcement and automated remediation, use **VCF Operations SPM/ACC (UI)**; vmware-harden is the API-scriptable, DuckDB-persisted, cross-target point-in-time scanner. See [references/stig-content-sync.md](skills/vmware-harden/references/stig-content-sync.md) and inspect the catalog with `vmware-harden stig controls`.\n\n#### Official Broadcom References\n\n- **Security Configuration Guides**: <https://core.vmware.com/security/> — vSphere SCG v8 / future v9\n- **SDKs**: <https://developer.broadcom.com/sdks> — VCF Python SDK (for fetching host config via REST)\n- **CIS Benchmarks**: <https://www.cisecurity.org/cis-benchmarks/> — CIS VMware ESXi Benchmark v1.0 (8.0 / future 9.0)\n\n## Custom baselines\n\n```bash\nvmware-harden baseline validate ./my-strict.yaml\nvmware-harden baseline import ./my-strict.yaml --name my-strict-cis\nvmware-harden scan --target <vc> --baseline my-strict-cis\n```\n\nYAML supports `extends:` for inheriting from a built-in baseline. See `skills/vmware-harden/references/cli-reference.md`.\n\n## MCP server\n\n```bash\nvmware-harden mcp  # stdio MCP server (legacy alias: vmware-harden-mcp)\n```\n\nConfigure your MCP client with one of `examples/mcp-configs/*.json`. 8 read-only tools: `list_baselines`, `get_baseline_rules`, `list_stig_controls`, `describe_stig_content_sync`, `list_violations`, `get_remediation`, `list_drift_events`, `scan_target`.\n\n## Architecture\n\n- **Estate Digital Twin** — DuckDB single file at `~/.vmware-harden/twin.duckdb`. Multi-target safe via target prefix on all node IDs.\n- **Collectors** — lazy-import sibling vmware-* skills (no spawn overhead). All scans are READ; writes deferred to vmware-pilot.\n- **Baseline schema** — Pydantic v2, strict (`extra=\"forbid\"`), `extends:` inheritance, user-dir override.\n- **Drift** — pure diff function with optional persistence; auto-runs after every scan.\n- **Advisor** — LLM-driven Suggestion generation; Anthropic provider with prompt caching; mock fallback for tests / no-API-key environments.\n- **Audit** — every MCP tool wrapped with `@vmware_tool` from family vmware-policy.\n- **Web** — FastAPI + Jinja2 + Tailwind/HTMX/ECharts CDN.\n\n## Lab regression\n\n```bash\nexport VMWARE_HARDEN_LAB_TARGET=<your-vc>\npytest tests/eval/regression -v -m lab\n```\n\n## Family\n\n- **vmware-aiops** — host inventory + ops (used by harden's HostCollector)\n- **vmware-monitor** — read-only counterpart\n- **vmware-storage** — datastore inventory\n- **vmware-nsx-security** — DFW inventory\n- **vmware-pilot** — execute remediations (writes; out of scope for harden)\n- **vmware-policy** — `@vmware_tool` audit decorator\n\n## Acceptance criteria (v1.5.18 GA)\n\n- 221 tests passing\n- Bandit: 0 issues at any severity\n- All 8 MCP tools audited\n- SKILL.md ≤ 3000 words, family-convention compliant\n- SECURITY.md with 6 elements + Broadcom disclaimer\n- 9 built-in baselines (99 rules across 7 rule-bearing sets + 2 v9 aliases)\n- `vmware-harden doctor` for environment diagnostics\n- GA member of vmware-* family (version-aligned at 1.5.28)\n\n## References\n\n- Family CLAUDE.md: `CLAUDE.md` at the monorepo root\n\n## License\n\nMIT",
  "bytes": 12494,
  "sha": "44c8d3a0a1473144bb306d8cb5f7894e599f743ae8ae4db4123eaa46ab45dbac",
  "repo_slug": "vmware-skills/vmware-harden",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_vmware_skills_vmware_harden_221a0e11/readme"
}