Dependency security
This project treats the locked test dependency set as the dependency-review
surface. Local bootstrap, pull-request CI, and the weekly scheduled audit all
check constraints-test.txt with pip-audit.
What gets audited
constraints-test.txtpins the[test]extras frompyproject.tomlplus their transitive dependencies.- The bootstrap scripts install the test extras against that lock, then run
pip-auditon the installed environment. - CI audits the committed lock with
pip-audit -r constraints-test.txton each pull request and on a weekly schedule, so newly disclosed CVEs in old pins are caught even when nobody has touched the dependency files. - Bandit remains a separate first-party-code scan. A green Bandit job does not mean the dependency lock is clean.
Regenerating the lock
Regenerate the lock only as an intentional dependency-change PR:
scripts\bootstrap_test_env.ps1 -Force -Relock
bash scripts/bootstrap_test_env.sh --force --relock
Review and commit the resulting constraints-test.txt diff. Do not hand-edit
individual pins unless you are immediately re-running the relock command to
prove the full resolved set.
Responding to a CVE
- Open or update a dependency-security issue with the vulnerable package, affected version, fixed version, and audit output.
- Relock with the commands above.
- Confirm
pip-auditreports no known vulnerabilities. - Run the focused bootstrap/CI contract tests:
.\.venv\Scripts\python -m pytest tests\scripts\test_bootstrap_constraints.py -q
- If the relock changes more than the vulnerable package and normal transitive bumps, call that out in the PR description so reviewers know what to inspect.
Use -NoAudit / --no-audit only for explicit offline troubleshooting. Do not
merge a dependency lock that has not passed the audit gate.