Neue Features und Updates

Teams können keine Parameter für einzelne manuelle Jobs innerhalb von Pipelines festlegen, was teure vollständige Pipeline-Wiederholungen für einfache Parameteränderungen erzwingt. Einige Eingabeparameter sind unbekannt, bis frühere Jobs abgeschlossen sind, was Echtzeitentscheidungen basierend auf dem Pipeline-Kontext erfordert. Job-Level-Eingaben ermöglichen dynamische Parameterfestlegung, wenn sich Parameter während der Ausführung ändern. Daran arbeiten wir:

Container-Image-Management über mehrere Upstream-Registries hinweg schafft Komplexität und Inkonsistenzen. Die virtuelle Docker-Registry aggregiert Images aus mehreren Quellen – einschließlich Docker Hub, Harbor und Quay – über eine einzige Schnittstelle mit intelligenten Caching- und Verwaltungsfunktionen. Geplant:

JavaScript/Node.js-Teams, die Abhängigkeiten über mehrere npm-Quellen verwalten, stehen vor inkonsistenter Auflösung und Konfigurationsaufwand. Die virtuelle npm-Registry bietet eine einzige Quelle der Wahrheit für Paketabhängigkeiten – kritische Funktionalität für Organisationen, die von JFrog Artifactory zu GitLab migrieren. Geplant:

Wiki-Diskussionen finden abseits relevanter Inhalte statt, was die Effektivität reduziert und Kontextwechsel erhöht. Inline-Kontextkommentare ermöglichen Thread-Diskussionen, die direkt mit hervorgehobenem Text verknüpft sind – Gespräche bleiben mit dem Inhalt verbunden, auf den sie sich beziehen. Daran arbeiten wir:

Supply-Chain-Angriffe durch bösartige Pakete stellen ein unmittelbares Risiko dar – im Gegensatz zu CVEs, die monatelang unentdeckt bleiben können, verursacht ein bösartiges Paket Schäden in dem Moment, in dem es aufgenommen wird. GitLab zeigt bösartige Pakete jetzt direkt in den Ergebnissen der Abhängigkeitssuche an und ermöglicht Teams, aktive Bedrohungen zu identifizieren und darauf zu reagieren, bevor sie Produktionssysteme kompromittieren. Für kommende Releases geplant:

Sicherheitsteams müssen Secret-Push-Schutz im großen Maßstab bereitstellen, ohne manuelle Projekt-für-Projekt-Konfiguration. Scan-Konfigurationsprofile führen Massenaktivierung über das Security Inventory Interface ein und schützen Projekte, ohne YAML-Änderungen oder Entwicklereingriffe zu erfordern. Daran arbeiten wir:

Während Secret-Push-Schutz Commits in Echtzeit blockiert, bietet Pipeline-Scanning ergänzende Abdeckung durch Erkennung von Secrets in der Repository-Historie und Pipeline-Artefakten. Dieses Profil ermöglicht Sicherheitsteams, umfassende Secret-Erkennung über Projekte hinweg über denselben profilbasierten Ansatz zu aktivieren – wodurch mehrschichtige Verteidigung ohne Konfigurationsaufwand geschaffen wird. Daran arbeiten wir:

SAST bleibt grundlegend für die Anwendungssicherheit, aber CI/CD-Konfigurationsanforderungen schaffen Adoptionsbarrieren. Das SAST-Scan-Profil ermöglicht Sicherheitsteams, statische Analyse über Projekte hinweg über das Security Inventory bereitzustellen – mit automatischer Spracherkennung und Advanced-SAST-Aktivierung für unterstützte Sprachen im Ultimate-Tarif. Für kommende Releases geplant:

Sicherheitsteams führen derzeit regelmäßige Überprüfungen durch, um sicherzustellen, dass Secret-Push-Schutz für neue Projekte aktiviert ist – ein manueller Prozess, der Abdeckungslücken schafft. Nach Fertigstellung haben neue private Ultimate-Projekte Secret-Push-Schutz standardmäßig aktiviert, mit Opt-out während der Projekterstellung für Teams mit spezifischen Anforderungen. Daran arbeiten wir:

Teams, die falsch positive Ergebnisse bei der Secret-Erkennung erleben, benötigen die Möglichkeit, spezifische Pfade und Werte auszuschließen, ohne den Schutz vollständig zu deaktivieren. Konfigurationsprofile unterstützen Ausschlüsse – Teams können die Erkennung abstimmen und gleichzeitig umfassende Abdeckung beibehalten. Daran arbeiten wir:

Standard-Schwachstellen-Schweregrade spiegeln nicht immer organisatorische Risikoprioritäten wider. Sicherheitsteams können Schweregrad-Überschreibungen basierend auf Regeln automatisieren, einschließlich KEV/EPSS, CVSS, Erreichbarkeit, CVE, CWE und Scan-Typ – Risiko auf Geschäftsbedürfnisse abbilden und gleichzeitig Triage-Prozesse automatisieren, die zuvor manuelle Eingriffe erforderten. Für kommende Releases geplant:

Musterbasierte Secret-Erkennung übersieht generische Passwörter wie admin_password=Password123!, denen erkennbare Formate fehlen. Kontextbewusste Erkennung identifiziert generische Passwörter durch Analyse umgebender Code-Muster und Variablen-Namenskonventionen – schließt eine bedeutende Lücke in der Secret-Erkennungsabdeckung. Geplant:

Breite PAT-Scopes wie read_api und api schaffen übermäßigen Schadensumfang, wenn Tokens kompromittiert werden. Feingliedrige Berechtigungen ermöglichen Tokens mit spezifischem Zugriff nur auf erforderliche Ressourcen und Operationen – beschränkt auf spezifische Projekte und Gruppen mit präzisen Kombinationen von Lese- und Schreibzugriff für verschiedene Ressourcentypen. Geplant:

Teams, die CI-Variablen für Secrets verwenden, fehlen ordnungsgemäße Lifecycle-Verwaltung, Rotationserinnerungen und granulare Zugriffskontrolle. GitLab Secrets Manager bietet zweckgebundene Secret-Speicherung mit Ablaufverwaltung, Umgebungs-/Branch-Scoping und rollenbasierten Berechtigungen – reduziert die Abhängigkeit von Drittanbieter-Secret-Managern für CI-Workflows. Daran arbeiten wir:

Organisationen, die SLSA-Attestierungen produzieren, benötigen Distributions- und Verifizierungsfunktionen. Attestierungs-APIs, UI-Integration und glab-Verifizierungsunterstützung ermöglichen Teams, Artefakte zu verifizieren – vervollständigt den Supply-Chain-Sicherheits-Workflow von der Attestierungsgenerierung bis zur Verifizierung. Geplant:

Organisationen fehlt nach Geschäftskontext segmentierte Transparenz – Anwendung, Geschäftsbereich oder Entwicklungsteam. Sicherheitsattribut-Filterung ermöglicht Schwachstellen- und Abhängigkeitsfilterung nach geschäftslogischen Entitäten, mit URL-Unterstützung für das Bookmarking gefilterter Ansichten und Dashboard-Click-Through-Unterstützung. Geplant:

Erweitert von LOW-Schweregrad-Schwachstellen unterstützt Auto-Remediation jetzt konfigurierbare Schweregrade und Versionsziele. Teams können gruppierte oder individuelle Merge Requests (MRs) für Dependency-Bumps wählen, mit UI-Indikatoren, die auto-remediierte Schwachstellen hervorheben. Für kommende Releases geplant:

Dart/Flutter-Lizenzinformationen werden derzeit als UNKNOWN angezeigt und zwingen Teams zu externen Datenquellen. Lizenz-Scanning-Unterstützung für den pub-Paketmanager ermöglicht genaue Lizenztransparenz für Dart- und Flutter-Abhängigkeiten. Geplant:

Advanced-SAST-Analyse in großen Repositories kann Pipeline-Job-Zeitlimits überschreiten. Inkrementelles Scanning cached Ergebnisse aus vorherigen Scans und analysiert nur geänderten Code – reduziert Scan-Zeit erheblich und produziert gleichzeitig genaue Ergebnisse. Geplant:

Sicherheitsdashboards benötigen exportierbare Formate für Stakeholder-Kommunikation und Compliance-Dokumentation. PDF-Export repliziert Dashboard-Panels mit angewendeten Filtern und Gruppierungskonfigurationen für Offline-Sharing und Archivierung. Daran arbeiten wir:

Erweiterte Schwachstellen-Intelligence durch zusätzliche Datensignale einschließlich Exploit-Verfügbarkeit, Threat-Actor-Aktivität und CVSS-Verbesserungen – erhöht das Wertversprechen der Advisory Database als Premium-Lösung. Geplant:

Sicherheitsteams verbringen erhebliche Zeit mit der Triage von Secret-Detection-Ergebnissen, die sich als Test-Credentials oder Dummy-Werte herausstellen. KI-gestützte Falsch-Positiv-Erkennung analysiert Ergebnisse, bevor Teams sie sehen, identifiziert Test-Credentials, Beispielwerte und Platzhalter-Secrets mit klaren Erklärungen und Vertrauens-Scores – verbessert das Signal-zu-Rauschen-Verhältnis erheblich. Daran arbeiten wir:

Wenn dasselbe Schwachstellenmuster über eine Codebase hinweg erscheint, erzeugt das Erstellen individueller Merge Requests für jede Instanz Review-Müdigkeit und verlangsamt die Remediation. GitLab Duo gruppiert intelligent verwandte SAST-Ergebnisse nach geteilten Grundursachen und generiert einzelne Merge Requests, die verwandte Schwachstellen adressieren – transformiert verstreute Fixes in koordinierte Remediation. Geplant:

Automatisierte Dependency-Bumps scheitern oft in CI/CD-Pipelines aufgrund von Breaking Changes und erfordern manuelle Eingriffe, die Sicherheits-Remediation verzögern. Wenn Dependency-Bump-MRs scheitern, analysiert KI Pipeline-Fehler und Dependency-Changelogs, um automatisch Code-Fixes zu generieren, die Kompatibilitätsprobleme lösen – reduziert den manuellen Aufwand zur Remediation von Schwachstellen erheblich. Daran arbeiten wir: