Software-Supply-Chain-Attacken abwenden: GitLab plant eine Dependency-Firewall

Eine erhöhte Sicherheit in der Supply Chain plant GitLab in der zweiten Jahreshälfte durch eine Dependency-Firewall. Neu erschienen ist GitLab 16.10.

In Pocket speichern vorlesen Druckansicht
Rechenzentrum-Alarm

Notfall im Rechenzentrum

(Bild: vchal/Shutterstock.com)

Lesezeit: 2 Min.

Das Team hinter der Entwicklungsplattform GitLab hat angekündigt, in der zweiten Jahreshälfte 2024 eine Dependency Firewall einführen zu wollen. Auf Basis der Policies-Funktion soll sie mehr Sicherheit für die Software Supply Chain bringen, indem sie eine erste Verteidigungslinie beim Herunterladen von Paketen aus dem Internet darstellt. Daneben liegt nun die neue GitLab-Version 16.10 mit über neunzig Änderungen vor.

Wie das GitLab-Team ausführt, hat das Einführen des Maven-Dependency-Proxy Anfang des Jahres in Version 16.8 nicht nur Vorteile gebracht: Er habe das Risiko von Angriffen auf die Software Supply Chain durch Typosquatting – das Verwenden eines leicht abgewandelten Paketnamens für Schadcode, der einem regulären Paketnamen ähnelt – oder weitere Dependency-Confusion-Angriffe erhöht.

Dort setzt nun die geplante Dependency-Firewall an: Sie soll solche Angriffe vermeiden, indem sie vor schadhaften Paketen warnt oder ihre Einführung in die Supply Chain verhindert, je nach Richtlinie eines Projekts. Bevor Pakete verfügbar gemacht werden soll die Firewall sie zur Review in Quarantäne schicken und dort verwalten können. Dahinter steht die Funktion GitLab Policies. Mit der Firewall soll jedes neue Paket gegen eine Policy geprüft werden. Das Verwenden von Policies ist GitLab-Usern in der Ultimate-Edition vorbehalten.

Die geplante Policy für die Dependency-Firewall soll die Funktionen warn und fail besitzen. GitLab-User werden eine Policy erstellen können, die unter festgelegten Bedingungen wahlweise eine Warnung auslöst oder dafür sorgt, Pakete in Quarantäne zu verschieben. Als Beispiel nennt das GitLab-Team, Pakete mit kritischen Sicherheitslücken für den Download zu sperren, während für weniger kritische Schwachstellen lediglich eine Warnung erscheint.

Details zum Einsatz der geplanten Firewall lassen sich dem GitLab-Blog und dem entsprechenden Epic entnehmen.

Bereits erschienen ist die neue GitLab-Version 16.10. Eine von mehr als neunzig enthaltenen Änderungen ist das Einführen semantischer Versionierung für Komponenten, die im CI/CD-Katalog veröffentlicht werden. Das gilt für GitLab-User aller Editionen und soll ein konsistentes Verhalten sicherstellen. Beim Veröffentlichen einer Komponente muss das Tag der semantischen Versionierung mit drei Stellen entsprechen, etwa 1.0.0.

Diese und weitere Neuerungen wie Wiki-Templates und Updates fĂĽr den KI-Dienst GitLab Duo sind im GitLab-Blog aufgefĂĽhrt.

(mai)