Start/Praxis/Workflows/Dependency Cooldowns: Neue Packages nicht sofort installieren
25. März 2026

Dependency Cooldowns: Neue Packages nicht sofort installieren

Am 24. Maerz 2026 wurde das PyPI-Paket litellm kompromittiert. Die Version 1.82.8 enthielt einen in Base64 verschleierten Credential-Stealer, der beim blossen Installieren ausfuehrt -- ohne dass import litellm aufgerufen werden musste. Das Angriffsfenster war knapp 46 Minuten. In dieser Zeit wurden die kompromittierten Pakete heruntergeladen -- von Entwicklern, CI-Systemen, Bots. Von 2.337 Paketen, die von LiteLLM abhaengig sind, pinnten 88 Prozent keine Version, die den Angriff haette verhindern koennen.

Simon Willison nahm diesen Vorfall zum Anlass, Dependency Cooldowns wieder in die Debatte zu bringen.

Das Konzept: Cooldowns als Antwort auf kurze Angriffsfenster

Die Grundidee ist einfach: Neue Package-Versionen werden nicht sofort installiert, sondern erst nach einer konfigurierbaren Wartezeit -- typischerweise 7 bis 14 Tage. In dieser Zeit hat die Community die Moeglichkeit, Anomalien zu melden, Sicherheitstools koennen die neue Version pruefen, und PyPI kann bei Bedarf eingreifen.

William Woodruff untersuchte zehn Supply-Chain-Angriffe. Acht hatten ein Angriffsfenster von unter einer Woche. Ein Cooldown von sieben Tagen haette den Grossteil davon abgeblockt.

Der Ansatz ist kein Ersatz fuer Signaturpruefung oder reproduzierbare Builds -- aber er verschiebt das Zeitfenster zurueck in den Bereich menschlicher Reaktionszeiten.

Warum das fuer AI-Projekte besonders relevant ist

AI-Projekte haben eine ungewoehnlich hohe Python-Dependency-Dichte. LiteLLM, LangChain, Hugging Face Transformers, OpenAI SDK, Anthropic SDK -- alle entwickeln sich schnell, veroeffentlichen haeufig neue Versionen, und werden oft ohne konsequentes Version-Pinning eingesetzt. Gleichzeitig laufen viele dieser Projekte in automatisierten Pipelines mit breitem Zugriff auf API-Keys, Cloud-Credentials und lokale SSH-Keys -- genau das, was ein Credential-Stealer abgreift.

Der aktuelle Stand: Welche Tools unterstuetzen Cooldowns

Andrew Nesbitt hat im Maerz 2026 den Stand der Unterstuetzung quer durch alle grossen Package-Manager zusammengefasst. Die Adoption im JavaScript-Oekosystem war besonders schnell:

JavaScript / Node.js - pnpm ab 10.16 (September 2025): minimumReleaseAge mit minimumReleaseAgeExclude fuer vertrauenswuerdige Pakete - yarn ab 4.10.0 (September 2025): npmMinimalAgeGate (in Minuten) mit npmPreapprovedPackages - bun ab 1.3 (Oktober 2025): minimumReleaseAge in bunfig.toml - npm ab 11.10.0 (Februar 2026): min-release-age - deno ab 2.6 (Dezember 2025): --minimum-dependency-age fuer deno update und deno outdated

Python - uv ab 0.9.17 (Dezember 2025): --exclude-newer mit relativer Dauerangabe (z.B. 1 week, 30 days) und pro-Paket-Overrides via exclude-newer-package - pip ab 26.0 (Januar 2026): --uploaded-prior-to -- aktuell nur absolute Timestamps, kein relatives 7d

Rust - Cargo 1.94: Registry-seitige Cooldown-Infrastruktur; explizites Opt-in zu einer neuen Version via cargo update foo --precise 1.5.10

Dependency-Update-Tools - Renovate: minimumReleaseAge (frueherer Name: stabilityDays) seit Jahren vorhanden; seit Mend Renovate 42 ist ein 3-Tage-Minimum fuer npm-Pakete per Default aktiv - Dependabot: Cooldown-Unterstuetzung seit Juli 2025 via cooldown-Block in dependabot.yml mit default-days und pro-semver-Level-Overrides; Security-Updates sind ausgenommen - Snyk: Eingebauter, nicht konfigurierbarer 21-Tage-Cooldown auf automatische Upgrade-PRs

Praktische Umsetzung

uv (empfohlen fuer neue Python-Projekte)

In pyproject.toml oder uv.toml:

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

Oder pro Aufruf:

uv pip install litellm --exclude-newer "7 days"

pip mit Workaround (Seth Larson)

pip unterstuetzt nur absolute Timestamps. Seth Larson hat einen Workaround veroeffentlicht: Ein Python-Skript, das per Cron stündlich den Wert in pip.conf aktualisiert.

~/.config/pip/pip.conf:

[install]
uploaded-prior-to = 2026-03-18

Crontab-Eintrag (aktualisiert das Datum taeglich auf "heute minus 7 Tage"):

0 * * * * /usr/local/bin/pip-dependency-cooldown ~/.config/pip/pip.conf 7

Das ist ein Hack, aber er funktioniert, bis pip native relative Dauer-Unterstuetzung bekommt.

Renovate

In renovate.json:

{
  "extends": ["config:best-practices"],
  "packageRules": [
    {
      "matchUpdateTypes": ["major"],
      "minimumReleaseAge": "14 days"
    },
    {
      "matchUpdateTypes": ["minor", "patch"],
      "minimumReleaseAge": "7 days"
    }
  ]
}

Dependabot

In .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7
      semver-major-days: 14

Lockfiles und Version-Pinning als Mindestmassnahme

Wer noch keinen Package-Manager mit Cooldown-Unterstuetzung nutzt, sollte zumindest:

  1. Lockfiles committen (requirements.txt mit gepinnten Versionen, uv.lock, package-lock.json)
  2. Versions-Ranges vermeiden: litellm>=1.80 ist gefaehrlich; litellm==1.82.5 ist es nicht
  3. Automatische Dependency-Updates deaktivieren oder verzoegern: Renovate und Dependabot koennen Updates auf einen Wochentag buendeln statt sofort zu mergen

Grenzen des Ansatzes

Cooldowns schliessen das Angriffsfenster nicht vollstaendig. Sie geben der Community mehr Zeit -- aber ein Angriff, der 8 Tage unentdeckt bleibt, wirkt trotzdem. Cooldowns ersetzen keine:

Quellen

Nach oben