Put the safe version range in a pip constraints file and install with the constraint flag. A constraints file controls which version of a package pip may pick, but it never causes that package to be installed. That makes it the cleanest way to fix a transitive Python dependency you do not import yourself.
What a constraints file is
A constraints file looks like a requirements file, with a narrower job. The pip documentation describes it as a file that only controls which version of a requirement is installed, not whether it is installed at all. Listing a package there does not trigger installation.
That one property is why it suits security fixes. Say a scanner flags a library that arrives through three different parents. You do not want to add it to your own requirements, because then you own a dependency you never chose. A constraint line sets the floor or the exact version, and pip only applies it if something pulls the package in.
There are rules. Per the pip docs, constraint entries must have a name, cannot be editable, and cannot specify extras. Support arrived in pip 7.1, and the 20.3 resolver overhaul stripped constraints down to a pure version limit.
Steps to apply a fix
- Find the vulnerable package and the safe version from the advisory.
- Create a file such as constraints.txt with one line per package, for example a name plus a minimum version.
- Install with the constraint flag pointing at that file.
- Run pip check and your tests.
- Commit the constraints file next to your requirements so CI uses the same one.
# constraints.txt
examplelib>=2.4.1
python -m pip install -r requirements.txt -c constraints.txt
The docs add that a constraints file can also be served over a URL, so an organisation can keep one central file and use it everywhere. That is useful when one advisory affects many services.
Constraints versus the alternatives
| Approach | Adds package to your install? | Suited to |
|---|---|---|
| Constraints file | No | Fixing a transitive package you do not import |
| Direct requirement | Yes | A package your code imports |
| Pinned lockfile | Yes, exact | Reproducible builds |
If you also keep a fully pinned lockfile, regenerate it after changing the constraint so the lock reflects the new version.
Limits to know
A constraint cannot fix a conflict. If a parent package declares an upper bound that excludes the safe version, pip will report that no resolution exists. Your options then are to upgrade the parent, ask the maintainer to relax the bound, or use another tool's override feature. Do not loosen the constraint to hide the conflict.
Also note a recent change: the pip docs say that as of pip 26.2, regular constraints no longer affect isolated build environments. If the vulnerable package is a build dependency, use build constraints, which were added in pip 25.3.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one package appears under several parents, which is the case a constraint handles in one line.
Where Safeguard fits
Safeguard scans dependencies, runs reachability analysis to show which findings your code can actually reach, and can open fix pull requests through autonomous remediation. That last feature is off by default and every category starts on Manual, so a person approves each change. You can try a free scan on a repository first.
Quick check
Does a constraints file install the package it lists?
No. It only limits which versions pip may choose when something else requires the package.
Why does pip still refuse my safe version?
A parent package probably declares an upper bound that excludes it. Upgrade the parent or ask its maintainer to widen the range.
Should the constraints file be committed?
Yes. Keeping it in the repository means local installs and CI resolve the same way.
Sources
Last reviewed: 19 October 2026.
