T08 · Insecure Dependencies
- Location
requirements.txt:1- Finding
Mutable and Unverified Python Dependency Installation
- Content
View full analysis
=4.14 ``` `scripts/x_publisher:75-90` and identical code in `scripts/post_thread:75-90`: ```bash # --- (re)install deps when needed ------------------------------------------- need_install=0 [ -f "$STAMP" ] || need_install=1 if [ -f "$REQ_FILE" ] && ! cmp -s "$REQ_FILE" "$STAMP" 2>/dev/null; then need_install=1 fi if [ "$need_install" -eq 1 ]; then if [ -f "$REQ_FILE" ]; then echo "[wrapper] installing dependencies from $REQ_FILE" >&2 if "$VENV_PY" -m pip install --disable-pip-version-check --no-input -r "$REQ_FILE" >&2; then cp "$REQ_FILE" "$STAMP" else echo "[wrapper] WARNING: dependency installation failed; continuing in case the script does not need them" >&2 fi else : > "$STAMP" fi fi ``` ### Technical Analysis The dependency declaration uses the lower-bound constraint `tweepy>=4.14`, allowing pip to install any current or future release satisfying that constraint. No exact version, package hash, lock file, or trusted artifact digest is supplied. The executable wrappers automatically install the dependency when the virtual environment is first created or when `requirements.txt` changes. Consequently, the code that runs can differ from the code assessed during the Skill audit. This also contradicts the documentation’s statement that Tweepy is “pinned.” Although no malicious dependency is currently present in the repository, the installation design creates a concrete supply-chain trust boundary. A compromised future Tweepy release, compromised transitive dependency, or altered package-index re ...[truncated 1583 chars]- Remediation
View remediation
