GitLab Dependency Firewall stoppt riskante Pakete, bevor sie in den Build gelangen

Warum GitLab die Prüfung auf den Zeitpunkt der Installation verlegt

GitLab argumentiert, das Risiko wachse, weil Entwicklerinnen und Entwickler Abhängigkeiten oft nicht mehr selbst auswählen. Laut dem Unternehmen fügen KI-Coding-Agenten inzwischen eigenständig Open-Source-Abhängigkeiten hinzu, häufig ohne dass jemand prüft oder auch nur sieht, was im Build gelandet ist. Ein schädliches oder anfälliges Paket kann so in einen Build gelangen, ohne dass jemand es freigegeben hat, und sein Code läuft womöglich mit denselben Zugriffsrechten wie die Pipeline.

Software Composition Analysis (SCA) scanne, so GitLab, nur das, was bereits eingebunden wurde. Bis sie ein schädliches Paket, eine Schwachstelle mit hohem Schweregrad oder eine unzulässige Lizenz meldet, sei die Abhängigkeit bereits installiert und möglicherweise in einem Artefakt ausgeliefert worden. Sie aufzuspüren, zu entfernen und neu zu bauen, bedeutet dann ungeplanten Aufwand für die Engineering-Teams. Die Dependency Firewall wendet die Richtlinie stattdessen vor der Installation an.

Was die Richtlinien abdecken und wie die Durchsetzung funktioniert

Teams können Richtlinien für vier Bereiche festlegen:

• Schädlicher Status: Pakete, die in GitLabs Malware-Advisory-Datenbank markiert sind.
• Schweregrad von Schwachstellen: die Stufe (kritisch, hoch, mittel oder niedrig) und die Zahl der auf dieser Stufe erlaubten Funde, auch null.
• Lizenztyp: die erlaubten oder verbotenen Lizenzen, aufgeführt mit vollständigem Namen, sowie der Umgang mit Paketen, deren Lizenz sich nicht ermitteln lässt.
• Alter des Pakets: ein Mindestalter, bevor ein Paket in einen Build aufgenommen werden darf, sodass eine Version, die erst vor wenigen Minuten veröffentlicht wurde, nicht ungeprüft direkt hineingelangt.

GitLab empfiehlt eine schrittweise Einführung. Im Warnmodus protokolliert die Firewall, was eine Richtlinie erfassen würde, lässt den Build aber weiterlaufen und hinterlässt ein Audit-Ereignis, einen Dashboard-Eintrag und eine Zeile in der CI-Zusammenfassung. Sobald Teams ihren Richtlinien vertrauen, können sie in den Blockmodus wechseln, der die Pipeline bei einem Treffer stoppt und den Grund nennt. Eine protokollierte Ausnahme erlaubt es einem bestimmten Nutzer oder Token, bei echtem Bedarf fortzufahren, nachvollziehbar dokumentiert.

Richtlinien auf Gruppenebene, CLI-Prüfungen und Audit-Protokolle

Eine Richtlinie lässt sich einmal auf oberster Gruppenebene festlegen, und jedes darunterliegende Projekt übernimmt die Regeln. Teams können für eine Gruppe oder ein Projekt eine abweichende Richtlinie definieren. Die Regeln liegen als Code in einem Security-Policy-Projekt und werden daher per Merge Request geprüft und geändert. Wo sich Regeln überschneiden, gilt die strengste, sodass ein kritischer Dienst über dem Basisniveau der Organisation gehalten werden kann und kein Projekt darunter fällt.

Auch Entwickler und Agenten können ein Paket prüfen, bevor sie es hinzufügen. Über die GitLab CLI im Terminal oder in einem Skript zeigt eine Prüfung auf der Kommandozeile, ob ein Paket die Richtlinie besteht oder blockiert wird, ohne dass eine separate Konsole geöffnet werden muss. Laut GitLab werden npm, pip, Poetry, Maven, Gradle und Bundler unterstützt, weitere sollen bald folgen.

Für Audits zeigt ein Dashboard Aktivitäten und Ergebnisse über alle Projekte im jeweiligen Geltungsbereich. Jede Warnung, jede Blockade und jede Ausnahme erzeugt ein Audit-Ereignis, das die zutreffende Regel, die zugrunde liegende Richtlinie und das betroffene Paket festhält. GitLab beschreibt jede Entscheidung als unveränderlichen Nachweis, der einer Prüferin oder einem Prüfer vorgelegt werden kann.

Verfügbarkeit und Bedeutung für Teams

Die Dependency Firewall ist kompatibel mit GitLab Artifact Central sowie mit externen Registries von Sonatype Nexus Repository und JFrog Artifactory. Laut GitLab ist neben einer bestehenden GitLab-Installation kein separates Tool nötig. Sie steht im Early Access für Kunden von GitLab.com und GitLab Self-Managed im Premium- oder Ultimate-Tarif bereit, Interessenten können den Zugang anfragen.

Für Organisationen, in denen KI-Agenten automatisch Abhängigkeiten hinzufügen, soll die Funktion dieses Tempo erhalten und zugleich die Richtlinie am Punkt der Installation durchsetzen. Laut GitLab werden Pakete, die die Richtlinienvorgaben erfüllen, Teil des offiziellen Builds, und Entwickler wie Agenten müssen nicht auf eine manuelle Sicherheitsprüfung warten. Das Unternehmen behauptet außerdem, dass die Suche nach Risiken für die Behebung dank integrierter Governance von Wochen auf Minuten schrumpfe.