Mitigation Strategy: Explicitly Specify Package Sources
Description:
- Open
Pipfile
: Locate thePipfile
in the root directory of your project. - Define Sources: For each package listed under
[packages]
and[dev-packages]
, add anindex
key specifying the source. Ensure a[[source]]
block exists for each source you use (typically PyPI and/or a private index). - Verify SSL: In the
[[source]]
block, ensureverify_ssl = true
is set for HTTPS sources. - Example:
[[source]] url = "https://pypi.org/simple" verify_ssl = true name = "pypi" [packages] requests = {version = "==2.31.0", index = "pypi"} my-internal-package = {version = "==1.2.3", index = "my-private-index"} [[source]] url = "https://my-artifactory.com/api/pypi/my-private-repo/simple" verify_ssl = true name = "my-private-index"
- Lock and Test: After modifying the
Pipfile
, runpipenv lock
to update thePipfile.lock
. Then, runpipenv install
and thoroughly test your application. This is a crucial step, aspipenv
handles the source resolution.
Threats Mitigated:
- Dependency Confusion/Substitution (High Severity): Prevents attackers from tricking
pipenv
into installing a malicious package from a public index with the same name as an internal package or a package intended to come from PyPI. This is directly mitigated bypipenv
's handling of theindex
key. - Typosquatting Attacks (High Severity): Reduces the risk, as
pipenv
will only look at the specified index.
Impact:
- Dependency Confusion/Substitution: Risk significantly reduced (almost eliminated if a private index is used for internal packages and
pipenv
correctly enforces the source). - Typosquatting Attacks: Risk reduced, as
pipenv
limits the search space.
Currently Implemented: Partially. PyPI source is explicitly defined for most packages, but some older dependencies are missing the index
key. Private index is defined but not consistently used.
Missing Implementation: Pipfile
needs review to ensure all packages have the index
key. The project needs to standardize on using the private index for all internal packages, and ensure pipenv
is configured to use it correctly.
Mitigation Strategy: Version Pinning and Hash Checking (Leveraging Pipfile.lock
)
Description:
- Pin Versions: In your
Pipfile
, use the==
operator to specify exact versions for all dependencies. - Generate Lock File: Run
pipenv lock
to generate or update thePipfile.lock
. This is the corepipenv
command for this mitigation. - Install from Lock File: Use
pipenv install --ignore-pipfile
. This is a criticalpipenv
-specific command that enforces the use of the lock file. - Hash Verification:
pipenv
automatically verifies the hashes of downloaded packages against the values inPipfile.lock
. This is a built-in feature ofpipenv
. - Regularly Update Lock File: Periodically, update dependencies and regenerate the
Pipfile.lock
usingpipenv lock
.
Threats Mitigated:
- Dependency Hijacking (High Severity):
pipenv
's hash checking, enforced by thePipfile.lock
, prevents installation of compromised packages. - Unintentional Upgrades (Medium Severity):
pipenv install --ignore-pipfile
prevents upgrades, relying solely on the lock file. - Supply Chain Attacks (High Severity): Mitigated by
pipenv
's hash verification and version pinning.
Impact:
- Dependency Hijacking: Risk significantly reduced (almost eliminated, relying on
pipenv
's correct hash verification and the integrity of thePipfile.lock
). - Unintentional Upgrades: Risk eliminated due to
pipenv
's lock file enforcement. - Supply Chain Attacks: Risk significantly reduced.
Currently Implemented: Mostly. Versions are pinned, and Pipfile.lock
is used. However, the CI/CD pipeline sometimes uses pipenv install
without --ignore-pipfile
.
Missing Implementation: The CI/CD pipeline needs to be updated to always use pipenv install --ignore-pipfile
. A process for regularly updating the Pipfile.lock
(using pipenv lock
) needs to be formalized.
Mitigation Strategy: Keep pipenv
Updated
Description:
- Check for Updates: Regularly check for new
pipenv
releases. - Update
pipenv
: Update using the appropriate method (e.g.,pip install --upgrade pipenv
). - Test After Update: After updating
pipenv
, runpipenv install
and test your application. This is important becausepipenv
itself could have bugs affecting dependency resolution or security features.
Threats Mitigated:
- Vulnerabilities in
pipenv
(Variable Severity, potentially High): Addresses security vulnerabilities inpipenv
itself, which could affect its ability to securely manage dependencies.
Impact:
- Vulnerabilities in
pipenv
: Risk reduced, depending on the severity of the patched vulnerabilities inpipenv
.
Currently Implemented: Ad-hoc. Developers are responsible for updating pipenv
.
Missing Implementation: A policy and mechanism for ensuring all developers use an up-to-date pipenv
version are needed.
Mitigation Strategy: Verify Pipfile.lock integrity (using pipenv install --ignore-pipfile)
Description:
- Generate Checksum (Development): After running
pipenv lock
in your development environment, generate a checksum (e.g., SHA256) of thePipfile.lock
file. - Generate Checksum (CI/CD): In your CI/CD pipeline, before running
pipenv install
, generate a checksum of thePipfile.lock
. - Compare Checksums: Compare the checksums.
- Fail Build on Mismatch: If they don't match, fail the build.
- Use pipenv: Use
pipenv install --ignore-pipfile
to install dependencies. - Example (bash):
# Development: sha256sum Pipfile.lock > Pipfile.lock.sha256 # CI/CD: sha256sum -c Pipfile.lock.sha256 if [ $? -ne 0 ]; then echo "ERROR: Pipfile.lock checksum mismatch!" exit 1 fi pipenv install --ignore-pipfile
Threats Mitigated:
- Tampered
Pipfile.lock
(High Severity): Detects if thePipfile.lock
has been modified. This relies onpipenv install --ignore-pipfile
to only use the lock file.
Impact:
- Tampered
Pipfile.lock
: Risk significantly reduced. The use ofpipenv install --ignore-pipfile
is crucial here.
Currently Implemented: Not implemented.
Missing Implementation: This needs to be implemented in the CI/CD pipeline, and the use of pipenv install --ignore-pipfile
must be enforced.