T08 · Insecure Dependencies
- Location
pyproject.toml:1- Finding
Mutable Remote Installation and Unbounded Third-Party Dependencies
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:23-26,README.md:10-14,README_EN.md:10-14, andpyproject.toml:1-3, 30-33
Vulnerability Type: Supply-chain exposure through a mutable Git installation source and unbounded dependency versions
Risk Level: MediumVulnerable Code
SKILL.md:23-26:bash ## Quick Start ```bash pip install git+https://github.com/minirr890112-byte/api-cost-compare.gitREADME.md:10-14:bash ## Quick Install ```bash pip install git+https://github.com/minirr890112-byte/api-cost-compare.gitREADME_EN.md:10-14:bash ## Quick Install ```bash pip install git+https://github.com/minirr890112-byte/api-cost-compare.gitpyproject.toml:1-3:toml [build-system] requires = ["setuptools>=68.0", "wheel"] build-backend = "setuptools.build_meta"pyproject.toml:30-33:toml dependencies = [ "click>=8.0", "rich>=13.0", ]Technical Analysis
The documented installation command retrieves the project directly from a mutable Git repository reference without selecting a reviewed commit or immutable release tag. The effective package contents can therefore change after the skill has been audited. During installation,
pipinvokes the configured Python build backend, so a future malicious repository revision could execute attacker-controlled build or package code.The build and runtime dependencies are also specified only with lower bounds. Consequently, future versions of
setuptools,wheel,click, orrichcan be selected automatically without prior review or integrity verification. This does not prove that any current dependency is malicious, but it weakens reproducibility and exposes installations to a compromised or unexpectedly incompatible future release.This finding concerns installation-time supply-chain integrity. The audited application code itself does not retrieve or execute ...[truncated 1338 chars]
- Remediation
View remediation
Remediation Suggestions
-
Publish reviewed, immutable releases to a trusted package registry and document installation using an exact version, for example:
bash pip install api-cost-compare==1.2.0 -
If Git installation remains necessary, pin the command to a reviewed full commit hash rather than the repository's default branch:
bash pip install "git+https://github.com/minirr890112-byte/api-cost-compare.git@FULL_COMMIT_SHA" -
Generate a lock file or constraints file containing exact transitive dependency versions and cryptographic hashes. Use hash-enforced installation where practical:
bash pip install --require-hashes -r requirements.lock -
Apply reviewed upper bounds or compatible-release constraints to build and runtime dependencies. Update them through a controlled dependency-review process rather than accepting every future release automatically.
-
Pin build requirements as well as runtime requirements because build backends execute during installation.
-
Protect release infrastructure with multi-factor authentication, protected tags, signed commits or tags, and automated dependency and artifact scanning.
-
Build distributions in an isolated CI environment, publish checksums or signed provenance, and instruct users to verify release artifacts before installation.
-