If you follow security news, you know that more and more attacks happen by picking "boring" packages that we all import as dependencies, building trust, and then slipping malware into a minor patch. This happened famously with the "XZ utils" but also in other projects that are not as well advertised as this.
Open source developers are the most underappreciated people on earth. Many times they develop, for free, the tools that you and I use every day and that huge companies depend on. You might think that this doesn't make sense, but this happens every day, so if you know someone that has an open source project and are in the position of helping out financially, ask them how you can help. It would allow them to continue to work on the things that all of us use.
One solution is to reduce the number of dependencies, and I touched on that here, but another solution is to delay the update of a dependency altogether. These types of attacks are usually caught quickly, so simply by delaying a bit the update of the dependency you can avoid a lot of issues.
Of course delaying has the opposite effect sometimes. Imagine a huge problem is detected and a dependency already ships the fix, so deploying fast would solve it.
I'll show the solution in Python using uv since it's the technology I use the most, but I'll point you to the equivalents in other ecosystems at the end.
The key is to find a middle ground that we're all comfortable with, so here's a quick strategy to do it in Python.
Delay the updates
Here are simple ways to do this in Python.
uv has it simple
If you're using uv then it's easy. In your pyproject.toml file you can add the following
[tool.uv]
exclude-newer = "7 days"
I use 7 days but there are cases where this could be increased or reduced depending on your use-case. Again, it's a compromise between blocking packages that were not "battle tested" (if we can call it that in 7 days), while also delaying packages that cover legit issues that were found in the meantime.
pip is not bad as well
If you use pip you can use:
pip install --uploaded-prior-to P7D -r requirements.txt
It's a bit more manual, but you can also control your threshold for security. Keep in mind that you need pip 26.1 or later for this. Version 26.0 introduced the flag but only accepted a full timestamp, so P7D will fail there.
The same idea in other ecosystems
This concept isn't new. uv has had exclude-newer since 2024, originally as a way to get reproducible resolutions rather than as a security control.
What changed recently is that the package managers themselves picked it up, and everyone settled on a name for it: cooldown.
Here's an overview of other package managers.
| Tool | Setting | Units |
|---|---|---|
| npm | min-release-age |
days |
| pnpm | minimumReleaseAge |
minutes |
| Yarn | npmMinimalAgeGate |
duration, like 1w |
| Bun | minimumReleaseAge |
seconds |
| Deno | minimumDependencyAge |
minutes or ISO duration |
| Bundler | cooldown |
days |
| Poetry | solver.min-release-age |
days |
| pixi | exclude-newer |
duration or date |
pnpm and Yarn now turn this on by default, so there you opt out rather than in. Cargo, Go, Composer, NuGet and conda don't have it natively yet.
I don't use a lot of the tools above, so be aware that this section is based on internet searches rather than experience. If I made a mistake, just let me know and I'll fix it.
Final Thoughts
Of course one of the main recommendations is to test packages before we import them, but it's not always possible. It's not always as simple as "Read the code and find the issue". The XZ Utils backdoor I mentioned above almost made it to production in basically all server machines that you could think about, if it wasn't for a researcher that got curious about something that was not quite right.
Please find your balance of time vs security and try to use your own strategy.
Photo by Karim MANJRA on Unsplash
No comments yet
Be the first to share your thoughts on this article!