Der Alarm sagt dir nicht, was in deiner Pipeline passiert ist
Dependabot hat gerade eine neue Warnung in deinem Repository abgelegt, abgeglichen gegen die GitHub Advisory Database. Vielleicht ein kompromittiertes Paket, vielleicht nur eine bekannte Schwachstelle in einer Version, die seit Monaten in deinem Lockfile steht. Die Meldung selbst beantwortet eine Frage nicht: was in deiner eigenen Pipeline mit diesem Paket tatsächlich passiert ist. Hat ein Build es installiert? Ist es in ein Artefakt gewandert, das du veröffentlicht hast? Lag im Job, der es gezogen hat, ein Token, auf das in diesem Moment jemand hätte zugreifen können? Diese Fragen stehen in keinem Alert. Du beantwortest sie in genau der Pipeline, die bei dir läuft, nicht in einer austauschbaren Checkliste.
Was aktuell in der Lieferkette passiert
Der Fall, der das Thema zuletzt verschärft hat, trägt den Namen Shai-Hulud: ein Wurm, der sich über kompromittierte npm-Pakete selbst weiterverbreitet, indem er Zugangsdaten von Paket-Maintainer:innen abgreift und damit weitere Pakete infiziert. Am 31.03.2026 kam eine Kompromittierung des Axios-Pakets dazu, bei der über das npm-Konto des Haupt-Maintainers manipulierte Versionen veröffentlicht wurden. Beide Fälle haben gemeinsam, dass der Schadcode nicht über eine offensichtliche Lücke eingeschleust wurde, sondern über die normale Update-Mechanik, die jede Pipeline täglich nutzt: ein npm install, ein automatischer Bump, ein Merge, der einer grünen CI vertraut. Wie stark die Zahl bösartiger Open-Source-Pakete im Jahresvergleich tatsächlich gestiegen ist, wird in verschiedenen Berichten unterschiedlich beziffert. Für deine eigene Pipeline zählt nicht die genaue Prozentzahl, sondern dass die Wahrscheinlichkeit eines echten Alarms in den letzten Monaten gestiegen ist, nicht nur die Wahrscheinlichkeit einer weiteren harmlosen Meldung.
Drei frühere Beiträge, eine andere Frage
Im Beitrag Dependabot vs. Renovate: welches Update-Tool wofür vom 06.07.2026 ging es um die Wahl des Werkzeugs selbst. Hier geht es nicht um das Werkzeug, sondern um das, was nach dessen Alarm in deiner eigenen Pipeline tatsächlich passiert ist, unabhängig davon, ob Dependabot oder ein anderes Werkzeug ihn ausgelöst hat.
Im Beitrag Dependabot cooldown: neue Paketversionen nicht sofort ziehen vom 28.09.2026 ging es um die Verzögerung, mit der neue Paketversionen überhaupt erst vorgeschlagen werden. Hier geht es um den Moment danach: der Alarm ist bereits da, und die Verzögerung spielt für die folgenden Schritte keine Rolle mehr.
Im Beitrag SBOM vom Lieferanten prüfen: vier Checks vor dem Ablegen vom 30.09.2026 ging es um den Input von außen, die Angaben eines Zulieferers vor der Übernahme seiner Software. Hier geht es um die eigene Pipeline, nachdem ein Paket bereits drin ist und ein Alarm genau darauf zeigt.
Was du in der ersten Stunde nach dem Alarm tatsächlich prüfst
Fünf Schritte, bezogen auf deine eigene Pipeline, nicht auf eine generische Checkliste:
Welche Builds das Paket tatsächlich gezogen haben. Durchsuche Build-Logs und Artefakt-Metadaten nach der genauen Versionsnummer, nicht nur nach dem Paketnamen. Beziehe transitive Abhängigkeiten mit ein: das betroffene Paket kann über ein anderes Paket mitgekommen sein, das in deinem eigenen Lockfile gar nicht direkt auftaucht.
Ob es in ein veröffentlichtes Artefakt oder Release gelangt ist. Gleiche Container-Image-Layer, veröffentlichte Pakete und Release-Tags gegen den Zeitraum ab, in dem die betroffene Version verfügbar war. Wenn ein Release betroffen ist, betrifft das jeden, der dieses Release bereits gezogen hat, nicht nur deine eigene Umgebung.
Die Lockfile-Historie. Prüfe per Git-Historie auf die Lockfile-Datei, wann genau die betroffene Version eingezogen ist, über welchen Commit und welchen Pull Request, und ob das automatisiert durch ein Update-Tool oder manuell geschah. Das zeigt dir, wie lange das Paket bereits in deiner Pipeline lag, bevor der Alarm kam.
Ob in den betroffenen Jobs Secrets oder Tokens zugänglich waren. Prüfe, welche Umgebungsvariablen und Zugangsdaten der Job-Definition zur Verfügung standen, in welchem Scope: nur lesend, mit Veröffentlichungsrechten, mit Zugriff auf weitere Repositories oder Registries. Ein Build-Script eines kompromittierten Pakets läuft mit denselben Rechten wie der Job, in dem es ausgeführt wird.
Rotation-Bedarf. Rotiere alles, das in einem betroffenen Job zugänglich war, nicht nur das, was offensichtlich benutzt wurde. Ein manipuliertes Installationsskript kann mehr auslesen, als für den eigentlichen Zweck des Pakets nötig wäre. Warum ein einmaliger Scan danach nicht reicht, beschreibt der Beitrag Secrets-Rotation: Warum ein einmaliger Scan nicht reicht.
Diese fünf Schritte beantworten zusammen die eine Frage, die der Alarm selbst offenlässt: ob aus einer Meldung über ein Paket tatsächlich ein Vorfall in deiner Pipeline geworden ist, oder ob er rechtzeitig draußen geblieben ist.
Eine strukturierte Checkliste für genau diese erste Stunde nach einem Alarm findest du hier: Supply-Chain-Sofortcheck.
Das Ergebnis zählt, nicht die Meldung
Ein Dependabot-Alarm ist ein Hinweis, keine Einordnung. Die Einordnung entsteht erst, wenn du weißt, welche Builds das Paket gezogen haben, ob es in einen Release gewandert ist, seit wann es im Lockfile steht und welche Zugangsdaten in den betroffenen Jobs offenlagen. Erst danach lässt sich sagen, ob Rotation nötig ist oder ob die Meldung ohne Folgen bleibt.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen