T08 · Insecure Dependencies
Warning
- Location
scripts/requirements.txt:9- Finding
Unpinned and Unhashed Executable Python Dependencies
- Content
View full analysis
=0.3.12 # Credential management — default chain: env vars, aliyun CLI profile # (~/.aliyun/config.json), ~/.alibabacloud/credentials.ini, ECS RAM role. # >=1.0.2 is required twice over: it is the floor tea-openapi 0.4.x depends on, # and the aliyun CLI profile provider does not exist before 1.x — with an older # release `aliyun configure` alone cannot authenticate (see SKILL.md §1.1). alibabacloud-credentials>=1.0.2 # OpenAPI utilities alibabacloud-openapi-util>=0.2.2 # Tea utilities alibabacloud-tea-util>=0.3.13 ``` ### Technical Analysis The Skill directs users to execute `pip install -r scripts/requirements.txt`, but every dependency uses an open-ended minimum-version constraint. No upper bounds, lock file, or package hashes are supplied. As a result, installation does not necessarily reproduce the package versions reviewed or tested by the Skill author. Pip may resolve any later version published under these package names. Python packages can execute code during installation and subsequently run code when imported by `video_editor.py`. The dependency names are consistent with the declared Alibaba Cloud integration, and the audit found no evidence of typosquatting or an intentionally malicious package. The vulnerability is the absence of controls ensuring that installed artifacts match reviewed artifacts. ### Attack Path 1. An attacker compromises a dependency publisher account, package-index account, or upstream release process. 2. The attacker publishes a newer malicious version satisfying one of the `>=` constraints. 3. A user follows the documented installation command. 4. Pip resolves and installs the malicious release. 5. Malicious code executes during installation or when the Skill imports the package ...[truncated 829 chars]- Remediation
View remediation
=` constraints. 3. Record package hashes and install with pip's `--require-hashes` option. 4. Fetch packages only from a trusted, explicitly configured package index. 5. Test dependency updates in an isolated environment before updating the lock file. 6. Add automated vulnerability and provenance checks for every dependency update. 7. Use a dedicated virtual environment with minimal filesystem and cloud permissions. 8. Document a controlled exception process if compatibility requires multiple approved versions rather than one exact version. ]]>