If you’re a reasonable developer, you probably are not fetching packages straight from the registry every time you create a new environment, so the next meaningful thing you probably should stop doing everything and configure a cooldown period for dependencies. pnpm, bun, npm, and even uv all support it.

This may sound dramatic, but that’s literally what (#82) I (#68) did (#39) the moment TanStack attack was discovered.

If you’re a python developer, you’re most likely starting from behind…

Python’s default workflow is a supply chain attack waiting to happen

In the JavaScript ecosystem, you already have the first line of defense by using npm ci, pnpm install --frozen-lockfile, or bun install --frozen-lockfile which resolve dependencies from a frozen lockfilethat specifies exact package versions and their binaries rather than fetching whatever is the latest package from the registry. Lockfiles were introduced to make developer environments reproducible, but they also happen to defend youto maybe 99% extent from supply chain attacks.

Python developers, on the other hand… have their way of doing things and are unbothered with the question of reproducibility, so will most likely yolo pip/conda install -r requirements.txt.

If you are still using system python, or python3 -m pip install, or any variation of pip-installing into an environment you didn’t explicitly create: you must stop. You must forget these commands exist:

pip install package-name
pip install -r requirements.txt
pip install -e .

These are not just “legacy workflows;” they are actively making you vulnerable to supply chain attacks. The only moderately safe alternative is resolving from an actual lockfile:

uv sync
# or, for a closer match to `npm ci`
uv sync --locked

I have a more elaborate tutorial on best practices for dependency management with uv, which explains in detail the difference between a wish-list like requirements.txt and a proper lockfile.

Jupyter notebooks are now hostile by default

I’ve been a long-time hater of Jupyter Notebooks, but previously I could still see why some researchers might prefer to share their research artifacts in this format. Now the idea of executing some unknown script by pressing “click to run” on a collapsed notebook cell feels like playing a Russian roulette. So yeah, I’m probably starting to treat all jupyter notebooks as malwareyes, of course you can run jupyter notebooks using a dedicated local environment and even using uv sync, but the priors are not in favor of notebook author being a security aware engineer

Use dependency cooldown period

Starting from uv 0.9.17, you can also specify a cooldown period for dependencies by updating pyproject.toml

[tool.uv]
exclude-newer = "7 days"

or your global uv config ~/.config/uv/uv.toml:

exclude-newer = "7 days"

which will prevent uv from installing any package version update released in the last 7 days, which, hopefully, would be enough for the general community to notice if a release was compromised.

Similar minimumReleaseAge options exist in pnpm (which, in fact, was the first one to introduce the practice) and other JS package managers.

Cooldown guard

There’s no single best number to choose for the cooldown period. The TanStack attack was detected within 20 minutes, primarily because it’s such a popular family of packages that security focused companies actively monitor them. An older liteLLM supply chain attack was detected after 2 days and relied on a month old compromise of Trivy package.

So you might be tempted to choose a very long cooldown period, but then what happens if some package releases a security patch to a high severity issue? We don’t have a good solution to this. In uv, you can manually exclude certain packages from the cooldown period, and while that helps with the installation of immediate patch, unless you remove that exclusion later, it defeats the purpose of the cooldown period.

There’s no good industry solution to this problem, and I personally came up with a simple package cooldown-guard that keeps track of cooldown exclusions for security patches and removes them after cooldown period expires.

Enable dependabot alerts on GitHub

The good news is that the infrastructure for vulnerability alerts is already quite automated. Any GitHub repository has a “Security and Quality” tab, which includes a “Dependabot” section that allows you to enable automated scanning and reporting of alerts for security vulnerabilities in your dependencies.

In fact, you can even enable automated PR creation with a dependency upgrade to patched versions, if such are already available.

This sounds like a GitHub ad read, but it truly just works for me personally (e.g. periodic group dep update (#81), security update that closes 5 moderate-high CVEs (#67), another security update closing 3 CVEs (#59).

Eventually your laptop might still get compromised

And so you should already have 2-factor authentication enabled everywhere you can, but I personally decided to take the further step and start using physical security keys: YubiKeys.

Physical keys are the last line

Even if my laptop gets compromised, as a next layer of defense, to prevent an attacker from having access to all my ssh keys, I started to use YubiKeys.

Does everyone need to use one? Probably not. But I use my SSH keys to:

• access clusters with significant GPU allocations
• access the servers where my websites are deployed, and if getting ischemist.com temporarily pwned is not the end of the world, I’m much, much more inclined to protect access to say syntharena.ischemist.com or, especially, grow.ischemist.com

So it felt like an obvious next step to take.