Unpinned Python Packages
Description
Workflows and composite actions that install Python packages without version pinning create security and reproducibility risks: package versions can change between runs, newer versions may introduce security vulnerabilities, and builds are not reproducible. This makes it difficult to track and fix security issues and enables supply-chain attacks through compromised packages. 1
Vulnerable Instance
- A workflow
run:step or composite action installs Python packages without version pinning (for example,pip install requests boto3). - Package versions can change between runs, introducing vulnerabilities.
- Builds are not reproducible and difficult to audit.
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: pip install requests flask # Unpinned - versions can changeMitigation Strategies
Pin packages to specific versions
Use exact version pinning:pip install requests==2.31.0 flask==3.0.0instead ofpip install requests flask.Use requirements.txt with pinned versions
Create arequirements.txtfile with pinned versions and install from it:pip install -r requirements.txt.Use pip-tools to generate requirements
Usepip-compileto generaterequirements.txtwith pinned versions from arequirements.infile. This ensures all transitive dependencies are also pinned.Regularly update and review
Periodically review pinned versions for security updates. Use automated tools like Dependabot to suggest updates.Use security scanning tools
Scanrequirements.txtfor known vulnerabilities. Use tools likepip-auditor Snyk to detect security issues.Document dependency management
Establish team guidelines for dependency management. Require version pinning for all Python package installs in workflows and actions.
Secure Version
jobs:
build:
runs-on: ubuntu-latest
steps:
- - run: pip install requests flask
+ - run: pip install -r requirements.txt
# requirements.txt:
# requests==2.31.0
# flask==3.0.0
Impact
| Dimension | Severity | Notes |
|---|---|---|
| Likelihood | Unpinned Python packages are common, and package updates can introduce vulnerabilities. | |
| Risk | Compromised or vulnerable packages can introduce backdoors, exfiltrate secrets, or enable system compromise. | |
| Blast radius | Impact depends on where the install runs, but can affect workflow jobs and any action consumers. |
References
- GitHub Docs, “Security hardening for GitHub Actions,” https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions 1
GitHub Docs, “Security hardening for GitHub Actions,” https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions ↩︎ ↩︎