T08 · Insecure Dependencies
Warning
- Location
SKILL.md:39- Finding
Unpinned and Overly Broad Python Dependencies
- Content
View full analysis
=3.10", "pip_packages": [ "markitdown[docx,xlsx,pdf]>=0.1.5" ] } ``` ### Technical Analysis The documented installation commands do not pin MarkItDown or its transitive dependencies to reviewed versions, and they do not require package hashes. The manifest similarly permits any MarkItDown release equal to or newer than version `0.1.5`. As a result, identical installation commands can resolve to different package artifacts over time. The recommended `[all]` extra also expands the dependency graph to optional document, media, OCR, archive, and network-related components that may not be necessary for a particular deployment. A larger dependency graph increases the supply-chain attack surface. This issue does not establish that MarkItDown or any current dependency is malicious. The risk is that a compromised upstream account, malicious future release, dependency-confusion event, or compromised transitive package could be incorporated without a project change or an additional review. ### Attack Path 1. An attacker compromises an upstream dependency, its publishing account, or a transitive package used by one of the selected extras. 2. The attacker publishes a malicious version that satisfies `>=0.1.5` or is selected by an unconstrained `pip install` command. 3. A user follows the project documentation or an automated environment processes `manifest.json`. 4. Pip resolves and installs the malicious o ...[truncated 879 chars]- Remediation
View remediation
``` 2. Generate and commit a lock file that records all transitive versions. 3. Require cryptographic hashes during installation, for example with a hash-locked requirements file and: ```bash pip install --require-hashes -r requirements.lock ``` 4. Replace the default recommendation for `[all]` with the minimum extras required for each use case. 5. Install packages from a trusted, explicitly configured index and disable unintended fallback indexes where practical. 6. Run dependency vulnerability and provenance checks in CI before publishing the Skill. 7. Test dependency updates in an isolated environment and require security review before updating the lock file. 8. Run conversion in a sandboxed, non-privileged environment with limited filesystem and network access, particularly when processing untrusted documents. ]]>