T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:11
- Finding
- Privileged functionality is delegated to an externally retrieved package without locally verifiable integrity<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:11-12`, `SKILL.md:53-57`, and `references/setup-guide.md:15-31` **Vulnerability Type**: Supply-chain integrity and auditability weakness **Risk Level**: Medium ### Vulnerable Code ```yaml installer: kind: uv package: vmware-nsx-mgmt ``` ```bash uv tool install vmware-nsx-mgmt==1.9.0 vmware-nsx init vmware-nsx doctor ``` The setup guide also permits installation through multiple external retrieval paths: ```bash uv tool install vmware-nsx-mgmt==1.9.0 ``` ```bash pip install vmware-nsx-mgmt==1.9.0 ``` ```bash git clone --branch v1.9.0 https://github.com/vmware-skills/VMware-NSX.git cd VMware-NSX pip install -e . ``` ### Technical Analysis The reviewed project contains documentation and evaluation data but not the implementation of the `vmware-nsx-mgmt` package. All credential processing, HTTPS authentication, NSX API requests, write confirmations, audit logging, policy enforcement, and output sanitization are delegated to an artifact retrieved from PyPI or GitHub. Pinning version `1.9.0` reduces ordinary version drift, but the installation instructions do not specify a package hash, signed provenance, immutable commit identifier, or trusted repository configuration. The reviewed files therefore cannot establish that the installed package is the same implementation that was security-reviewed. This is especially sensitive because the installed executable is expected to: - Read NSX credentials from the process environment or `~/.vmware-nsx/.env`. - Connect to NSX Manager over HTTPS. - Create, modify, and delete network infrastructure. - Run under the local user account with the Skill's allowed Bash access. - Write configuration and audit files under the user's home directory. The audit found no evidence that the named dependency is currently malicious. The vulnerability is the absence of locally verifiable integrity and implementation evidence for a dependency receiving substantial priv ...[truncated 1770 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Publish a lock file containing cryptographic hashes for the package and all transitive dependencies. 2. Install with mandatory hash verification, such as a generated requirements file used with `pip --require-hashes`, or an equivalent locked `uv` workflow. 3. Document the expected SHA-256 digest of the reviewed wheel and verify it before installation. 4. Publish signed release artifacts and verifiable build provenance, such as Sigstore attestations. 5. Pin source installations to an immutable commit hash rather than only a mutable tag: ```bash git clone https://github.com/vmware-skills/VMware-NSX.git cd VMware-NSX git checkout <reviewed-commit-sha> ``` 6. Use an allowlisted internal package repository or mirror with controlled promotion and malware scanning. 7. Include the executable implementation in the review artifact, or provide a software bill of materials and source-to-wheel reproducibility instructions. 8. Run the MCP process under a dedicated, restricted OS account with no access to unrelated user secrets. 9. Use a read-only NSX service account unless write functionality is explicitly required. Separate read-only, network-write, and Tier-0 administration identities. 10. Enforce production deny rules independently of the package where possible, rather than relying solely on policy checks implemented by the same dependency. ]]>