Dependency Firewall: riskante Pakete vor dem Build stoppen

Angreifer tarnen schädliche Pakete als vertrauenswürdige. Im Juni 2026 entdeckten GitLab-Forscher(innen) fünf schädliche PyPI-Pakete, vier davon Typosquats von Flask, Requests und NumPy, die beim Installieren ausgeführt werden und CI/CD-Zugangsdaten stehlen. Hinzu kommt, dass KI-Coding-Agenten Open-Source-Abhängigkeiten inzwischen selbstständig hinzufügen – oft ohne Prüfung –, sodass Entwickler(innen) keinen Überblick darüber haben, welche Pakete den Build verunreinigen könnten.

Ist ein schädliches oder anfälliges Paket erst einmal in deinen Build gelangt, läuft sein Code womöglich mit denselben Zugriffsrechten in deiner CI-Pipeline – und erreicht damit jedes System, mit dem deine Pipelines verbunden sind.

GitLab Dependency Firewall, heute auf der Transcend als Early Access vorgestellt, blockiert Pakete, die gegen deine Richtlinie verstoßen – darunter schädliche, anfällige und nicht konforme Pakete –, bevor sie deinen Build erreichen. Die integrierte Governance stoppt Risiken vor der Installation, sodass dein Team nicht nachverfolgen, entfernen oder neu bauen muss, was eine Richtlinie blockiert. Entwickler(innen) und ihre Agenten beziehen weiterhin die Abhängigkeiten, die sie brauchen, ohne auf eine manuelle Sicherheitsprüfung zu warten. Pakete, die deine Richtlinien erfüllen, werden Teil des offiziellen Builds.

Sieh dir die Aufzeichnung unseres Transcend-Events an – mit Demos der neuen Plattformfunktionen und der Frage, wie sich agentische KI über den gesamten Software-Lebenszyklus hinweg einsetzen lässt.

Schädliche Pakete blockieren, ohne den Build lahmzulegen

Ohne Richtlinie zum Zeitpunkt der Installation gelangt ein problematisches Paket zuerst in den Build und wird erst später entdeckt. Die Analyse der Softwarezusammensetzung (SCA) prüft, was bereits eingebunden ist. Meldet sie ein schädliches Paket, eine Sicherheitslücke mit hohem Schweregrad oder eine Lizenz, die deine Rechtsabteilung nicht akzeptiert, ist die Abhängigkeit bereits installiert und womöglich schon in einem Artefakt ausgeliefert. Nachzuverfolgen, wohin sie gelangt ist, sie zu entfernen und neu zu bauen, macht aus einem routinemäßigen Pipeline-Durchlauf ungeplante Arbeit für dein Engineering-Team.

Mit Dependency Firewall legst du fest, was in deine Builds gelangen darf, bevor es installiert wird. Dazu definierst du Richtlinien für:

1. Schadstatus: Pakete, die in der Malware-Advisory-Datenbank von GitLab gekennzeichnet sind
2. Schweregrad von Sicherheitslücken: der von dir festgelegte Schweregrad (kritisch, hoch, mittel oder niedrig) und die Anzahl der Funde, die du auf dieser Stufe zulässt – auch null
3. Lizenztyp: die zugelassenen oder abgelehnten Lizenzen, jeweils mit vollem Namen, sowie der Umgang mit Paketen, deren Lizenz sich nicht bestimmen lässt
4. Paketalter: das Mindestalter, das ein Paket erreicht haben muss, bevor es in einen Build darf – so gelangt eine gerade erst veröffentlichte Version nicht direkt in den Build, bevor jemand sie geprüft hat

Die Einführung der Durchsetzung muss die Auslieferung nicht gefährden. Starte im Warnmodus: Die Firewall protokolliert, was eine Richtlinie erfassen würde, lässt den Build aber weiterlaufen. Dabei entstehen ein Audit-Ereignis, ein Eintrag im Dashboard und eine Zeile in der CI-Zusammenfassung, sodass du auswerten kannst, ob der Build blockiert werden sollte.

Sobald du den Richtlinien vertraust, wechselst du in den Blockiermodus. Er stoppt die Pipeline bei einem Treffer und nennt den Grund. Gibt es einen begründeten Bedarf, ein freigegebenes Paket dennoch durchzulassen, ermöglicht ein protokollierter Bypass einer festgelegten Person oder einem Token, fortzufahren – nachvollziehbar dokumentiert.

Richtlinien einmal festlegen oder pro Team anpassen

Eine Firewall, die nur auf Registry-Ebene greift, gibt allen dieselbe Richtlinie vor – das passt selten zur tatsächlichen Arbeitsweise von Teams. Ein Zahlungsdienst und ein interner Prototyp tragen sehr unterschiedliche Risiken, und deine Richtlinie sollte sie entsprechend unterschiedlich behandeln.

Mit Dependency Firewall legst du eine Richtlinie für die Gruppe der obersten Ebene fest, und alle darunterliegenden Projekte übernehmen dieselben Regeln. Braucht ein Team etwas anderes, kannst du eine eigene Richtlinie für diese Gruppe oder dieses Projekt festlegen.

Du kannst die Durchsetzung auch auf Registry-Ebene verankern, sodass jeder Pull geprüft wird – nicht nur Pulls aus einer Pipeline. Die Regeln liegen als Code in einem Sicherheitsrichtlinienprojekt. Sie werden also wie der Rest deiner Konfiguration per Merge Request geprüft und geändert. Sie vererben sich von der Gruppe der obersten Ebene bis in jedes Projekt; überschneiden sich Regeln, gilt die strengste. Ein kritischer Service lässt sich über den Mindeststandard der Organisation hinaus absichern, und kein Projekt fällt darunter.

Pakete prüfen, bevor du sie einbindest

Entwickler(innen) – oder Agenten, die in ihrem Auftrag arbeiten – erfahren meist erst dann, dass ein Paket nicht zulässig ist, wenn die Pipeline fehlschlägt. Das kostet einen Build-Durchlauf und unterbricht die Konzentration, genau dann, wenn die Arbeit gut vorankommt.

Mit GitLab Dependency Firewall erhältst du die Antwort, bevor du eine Abhängigkeit hinzufügst, und zwar dort, wo du ohnehin arbeitest. So wählst du ein Paket, das die Prüfung beim ersten Versuch besteht.

Über die GitLab CLI im Terminal oder in einem Skript prüft ein Befehl, ob ein Paket deine Richtlinie erfüllt oder blockiert wird – ohne dass Entwickler(innen) eine separate Konsole öffnen müssen. Unterstützt werden gängige Paketmanager wie npm, pip, Poetry, Maven, Gradle und Bundler; weitere folgen.

Jede Entscheidung sichtbar und nachweisbar

Sicherheitsverantwortliche müssen bei einem Audit nachweisen können, was eine Kontrolle tatsächlich tut. Eine Kontrolle, die stillschweigend blockiert und nichts protokolliert, beantwortet die Frage der Prüfer(innen) nicht und schafft kein Vertrauen bei den Teams, für die sie gilt.

Du erhältst eine zentrale Übersicht darüber, was die Firewall zugelassen, mit einer Warnung versehen und blockiert hat – mit einem unveränderlichen Protokoll jeder Entscheidung, das du an Prüfer(innen) weitergeben kannst.

Ein Dependency-Firewall-Dashboard zeigt Aktivitäten und Ergebnisse über alle einbezogenen Projekte hinweg. Jede Warnung, jede Blockierung und jeder Bypass erzeugt ein Audit-Ereignis mit der zutreffenden Regel, der zugrunde liegenden Richtlinie und dem betroffenen Paket.

Early Access für GitLab Dependency Firewall

Mit Dependency Firewall stoppst du schädliche, anfällige und nicht konforme Pakete, bevor sie einen Build erreichen. Die Lösung ist mit GitLab Artifact Central sowie mit externen Registrys von Sonatype Nexus Repository und JFrog Artifactory kompatibel und erfordert kein separates Tool neben deiner GitLab-Installation. Dependency Firewall ist jetzt als Early Access für Kund(inn)en von GitLab.com und GitLab Self-Managed im Tarif Premium oder Ultimate verfügbar. Jetzt Early Access anfordern