T08 · Insecure Dependencies
Note
- Location
- requirements.txt:1
- Finding
- Unpinned Third-Party Dependency## Vulnerability Details **File Location**: `requirements.txt:1` **Vulnerability Type**: Unpinned third-party dependency **Risk Level**: Low ### Vulnerable Code ```text requests ``` ### Technical Analysis The project declares the `requests` package without an exact version or an integrity hash. Consequently, separate installations may resolve to different releases. If a future release or the configured package repository is compromised, installation could introduce attacker-controlled code into the environment. This finding concerns supply-chain hardening. The audited package name is legitimate, and the audit found no evidence that the current dependency is malicious. ### Attack Path 1. An attacker compromises the dependency's release process, a package repository, or the dependency-resolution path used by a victim. 2. The attacker publishes or serves a malicious version of `requests`. 3. A user installs the project dependencies from the unpinned `requirements.txt`. 4. The package manager resolves the attacker-controlled version because no exact version or hash is required. 5. Malicious package code executes during installation or when the application imports or uses the dependency. ### Impact Assessment Successful exploitation could execute arbitrary code with the privileges of the user or automation account installing or running the project. The resulting scope could include access to that account's files, environment variables, network permissions, and application data. This project does not itself request elevated privileges, so exploitation would not inherently grant administrative access.
- Remediation
- ## Remediation Suggestions 1. Pin `requests` to an explicitly reviewed version: ```text requests==<reviewed-version> ``` 2. Generate and commit a lock file containing exact transitive dependency versions. 3. Record package hashes and enforce hash verification during installation, such as with pip's `--require-hashes` option. 4. Obtain packages only from a trusted, explicitly configured repository. 5. Integrate dependency vulnerability and update monitoring into CI. 6. Review and deliberately update the pinned version on a regular schedule rather than accepting releases automatically.