Vollständige Security-Scanner-Abdeckung der Codebase in Minuten

Die gesamte Branche steht vor derselben Herausforderung: Mit wachsenden Organisationen wird die manuelle Konfiguration von Scannern für jede Pipeline-Definitionsdatei nicht mehr skalierbar. KI beschleunigt das Tempo, mit dem Teams Code ausliefern – und damit entstehen mehr Projekte, mehr Pipelines und mehr Angriffsfläche, die abgesichert werden muss. Was als bewusste Sicherheitsentscheidung begann, wird zu geerbter Konfiguration, der niemand mehr gehört, nie nachgefüllter Abdeckung und Lücken, die unsichtbar bleiben, bis sie es nicht mehr sind.

Security-Teams müssen Scanner skaliert einsetzen, nicht Projekt für Projekt mit manuellen YAML-Dateien. Ein Security Configuration Profile ist eine zentrale Einstellung in der UI, über die Security-Teams festlegen, wie und wann Security-Scanner über Projekte hinweg laufen – ohne Scanner manuell in Pipeline-Definitionsdateien zu konfigurieren. Mit GitLab 19.0 lassen sich über Security Configuration Profiles Static Application Security Testing (SAST), Dependency Scanning und Secret Detection über alle Projekte hinweg vom ersten Tag an aktivieren.

Das folgende Video demonstriert Security Configuration Profiles:

Manuelle Aktivierung kann mit KI-getriebenem Code-Tempo nicht mithalten

Im kleinen Maßstab ist die manuelle Scanner-Konfiguration pro Projekt handhabbar. Ein Team, eine Handvoll Repositories, ein Security-Engineer, der weiß, wo alles liegt. Das Modell wird schwieriger zu pflegen, wenn Organisationen Teams und Projekte hinzufügen – und KI vergrößert die Lücke zwischen Code-Tempo und Security-Abdeckung täglich weiter.

Die Drift zeigt sich auf bekannte Weisen. Teams kopieren Scanner-Konfiguration aus der nächstbesten Quelle, sodass SAST im Backend-Service mit einem Regelwerk läuft und im Frontend mit einem anderen. Dependency Scanning wird neuen Projekten hinzugefügt, aber nie für ältere nachgerüstet. Jemand aktualisiert eine .gitlab-ci.yml-Datei, um ein Pipeline-Problem zu beheben, und ein Scanner fällt dabei heraus.

Ohne eine zentrale Übersicht ergeben individuelle Entscheidungen über Scanner-Abdeckung selten eine konsistente Security-Posture über eine Organisation hinweg.

Was sind Security Configuration Profiles?

Ein Security Configuration Profile ist eine zentrale Gruppe von Einstellungen, die festlegt, wie und wann ein Security-Scanner über Projekte hinweg läuft. Statt SAST, Secret Detection oder Dependency Scanning einzeln in der .gitlab-ci.yml jedes Projekts zu konfigurieren, wird ein Profil einmalig auf Group-Ebene definiert und in einer Aktion auf beliebig viele Projekte angewendet.

GitLab liefert Standardprofile für jeden Scanner: vorkonfigurierte Einstellungen, die Best Practices widerspiegeln – damit das Scanning über Projekte hinweg in Minuten läuft, ohne eine Zeile YAML zu schreiben. Alle technischen Details sind in der Security-Configuration-Profiles-Dokumentation zu finden.

Wie Profile funktionieren: Scan-Trigger und Abdeckung

Jedes Standardprofil aktiviert eine Reihe von Scan-Triggern, die festlegen, wann das Scanning läuft. Für SAST und Dependency Scanning gelten zwei Trigger.

Merge-Request-Pipelines. Ein Scan läuft automatisch, wenn neue Commits in einen Branch mit einem offenen Merge Request gepusht werden. Ergebnisse sind auf Schwachstellen beschränkt, die durch diesen Merge Request eingeführt wurden – Entwicklungsteams erhalten fokussiertes, umsetzbares Feedback ohne Rauschen durch bereits bestehende Probleme.

Branch-Pipelines (nur Default Branch). Ein Scan läuft automatisch, wenn Änderungen in den Default Branch gemergt oder gepusht werden – damit haben Security-Teams jederzeit ein vollständiges Bild der Security-Posture des Default Branch.

Secret Detection umfasst beide Trigger und fügt einen dritten hinzu: Push Protection. Statt auf eine Pipeline zu warten, fängt Push Protection Secrets in Echtzeit während des git push-Prozesses ab und blockiert den Push, bevor das Secret die Codebase erreicht. Da es ereignisbasiert und nicht pipeline-basiert ist, ist kein Scan-Datum im Security Inventory daran angehängt.

Anwendungsfälle

Vier Praxisszenarien, in denen Security Configuration Profiles Wirkung zeigen:

Abdeckung über eine große Group standardisieren
Ein Platform-Security-Team verwaltet Hunderte von Projekten über Dutzende von Subgroups. Das Security Inventory gibt ihnen eine einzige Übersicht über die Scanner-Abdeckung in allen Projekten – einschließlich welche SAST nutzen, welche nicht und welche fehlerhafte Scans haben. Über dieses Dashboard wählt das Team alle Projekte aus und wendet die Standardprofile in einer Bulk-Aktion an. Jedes Projekt läuft jetzt SAST, Secret Detection und Dependency Scanning auf Merge-Request- und Branch-Pipelines – ohne eine einzige .gitlab-ci.yml-Änderung.

Schwachstelle auf Code-Ebene abfangen, bevor sie ausgeliefert wird
Ein Entwickler in einem schnell agierenden Team führt ein unsicheres Deserialisierungsmuster ein, während er einen neuen API-Endpunkt baut. Kein Vorsatz – nur ein Fehler unter Zeitdruck. Mit angewendetem SAST-Profil läuft ein Scan automatisch, wenn das Team Commits in den Merge-Request-Branch pusht. Die Schwachstelle wird markiert, bevor der Merge Request genehmigt wird – zu einem Zeitpunkt, an dem ein Entwickler eine Stunde für den Fix braucht statt Tage Incident-Response danach.

Kompromittierte Abhängigkeit abfangen, bevor sie die Produktion erreicht
Ein Entwickler aktualisiert eine Abhängigkeit im Lockfile. Die neue Version eines weit verbreiteten Pakets wurde kompromittiert und enthält einen bösartigen Payload. Dependency Scanning läuft automatisch auf der Merge-Request-Pipeline und markiert die kompromittierte Version, bevor der Branch gemergt wird. Die Meldung erfolgt am Punkt der Änderung – nicht nachdem das Paket auf Build-Servern und in Produktionsumgebungen installiert wurde.

Secrets abfangen, bevor sie landen
Ein Entwickler fügt versehentlich einen API-Key in einen Commit ein, während er ein Pipeline-Problem debuggt. Ein häufiger Fehler, der in einem geschäftigen Team tagelang unbemerkt bleiben kann. Mit angewendetem Secret-Detection-Profil fängt Push Protection den Push in Echtzeit ab und blockiert ihn, bevor das Secret das Repository erreicht. Der Entwickler erhält sofortiges Feedback am Punkt des Fehlers – kein Security-Report, kein Incident-Ticket, keine Credential-Rotation erforderlich.

Erste Schritte: Von null zu vollständiger Abdeckung in Minuten

Security Configuration Profiles sind jetzt auf GitLab Ultimate für GitLab.com, GitLab Self-Managed und GitLab Dedicated verfügbar. So werden Standardprofile auf Projekte angewendet:

1. Für die Group zu Secure > Security Inventory navigieren.
2. Die gewünschten Projekte auswählen oder alle markieren.
3. Im Dropdown Bulk Action die Option Manage security scanners wählen.
4. Apply default profile to all auswählen.

Zum Überprüfen des Abdeckungsstatus nach der Profil-Anwendung zurück zum Security Inventory und die Spalte Tool Coverage prüfen. Ein durchgehend grüner Balken zeigt, dass der Scanner vollständig aktiv ist. Ein teilweise gefüllter Balken bedeutet, dass einige Trigger aktiv sind, andere nicht. Ein grauer Balken zeigt an, dass der Scanner noch nicht konfiguriert ist.

Für die vollständigen technischen Details eines Profils – einschließlich Scan-Triggern und aktuellem Status – den Profilnamen im Security Inventory auswählen.

Wenn Projekte bereits Scanner-Konfiguration in .gitlab-ci.yml haben: Profil- und Legacy-Konfiguration können nebeneinander existieren, aber der Security-Inventory-Tooltip spiegelt den kombinierten Status während des Übergangs möglicherweise nicht korrekt wider. Für die genaueste Ansicht des aktuellen Profilstatus die Security-Configuration-Seite des einzelnen Projekts prüfen. Weitere Details in der Security-Configuration-Profiles-Dokumentation.

Noch kein GitLab Ultimate? Kostenlose Testversion starten und SAST, Secret Detection und Dependency Scanning über alle Projekte in Minuten aktivieren.

FAQ

Was ist ein Security Configuration Profile?
Ein Security Configuration Profile ist eine zentrale Gruppe von Einstellungen, die festlegt, wie und wann ein Security-Scanner über Projekte hinweg läuft. Statt Scanner manuell in der .gitlab-ci.yml jedes Projekts zu konfigurieren, wird ein Profil einmalig angewendet und deckt jedes Projekt in der Group ab.

Welche Scanner haben Standardprofile in GitLab 19.0?
GitLab 19.0 vervollständigt den ersten Satz von Standardprofilen und fügt Dependency Scanning neben dem seit 18.9 ausgebauten Secret-Detection-Profil und dem in 18.11 eingeführten SAST-Profil hinzu. Jedes Profil aktiviert einen empfohlenen Satz von Scan-Triggern ohne manuelle Konfiguration.

Welche Scan-Trigger aktiviert jedes Profil?
Das Secret-Detection-Profil aktiviert drei Trigger: Push Protection, Merge-Request-Pipelines und Branch-Pipelines auf den Default Branch. Die SAST- und Dependency-Scanning-Profile aktivieren zwei Trigger: Merge-Request-Pipelines und Branch-Pipelines auf den Default Branch.

Ersetzen Profile die bestehende .gitlab-ci.yml-Scanner-Konfiguration?
Nicht automatisch. Profil- und Legacy-Konfigurationen können nebeneinander existieren. Wer ausschließlich profilbasierte Konfiguration nutzen möchte, entfernt die jeweilige Scanner-Konfiguration aus den .gitlab-ci.yml-Dateien. Die Seite Security Configuration des jeweiligen Projekts zeigt den jeweils aktuellsten Status während einer Umstellung.

Welches GitLab-Tier ist erforderlich?
Security Configuration Profiles sind auf GitLab Ultimate verfügbar – für GitLab.com, GitLab Self-Managed und GitLab Dedicated.

Lassen sich Profile auf einzelne Projekte statt auf eine gesamte Group anwenden?
Ja. Im Security Inventory kann die Scanner-Abdeckung für einzelne Projekte über das vertikale Dreipunktmenü neben dem Projekt und die Option Manage tool coverage verwaltet werden.

Weitere Informationen zu GitLab 19.0

• CI/CD-Credentials mit GitLab Secrets Manager verwalten
• MRs von manuellen Aufgaben zu automatisierten Workflows transformieren
• CI-Komponentennutzung in der Organisation nachverfolgen
• Mehr KI-Modelle für GitLab Duo Agent Platform Self-Hosted