Eine Ansicht für alle Schwachstellen, von Scanner-Abdeckung bis KI-Governance

Die meisten Unternehmen setzen eine Handvoll unterschiedlicher Sicherheitsscanner ein, jeweils einzeln konfiguriert und projektweise durchgesetzt. Ohne zentrale Übersicht darüber, welche Scanner wo laufen, driften Richtlinien auseinander, blinde Flecken bleiben unentdeckt, und wichtige Projekte könnten unbemerkt ungeschützt bleiben. Mit GitLab 19.1 lassen sich die bereits genutzten Sicherheitsscanner integrieren, was eine einzige Ansicht der Scanner-Abdeckung ergibt. GitLab setzt Drittanbieter-Scanner im großen Maßstab über alle Projekte hinweg durch, und die dabei erkannten Schwachstellen werden automatisch behoben. Auf der Governance-Seite starten wir die Beta von AI Audit Event Streaming, mit der sich nachvollziehen lässt, ob Agenten sicher handeln.

Drittanbieter-Scanner im großen Maßstab auf jedem Projekt durchsetzen

Für die meisten Sicherheitsteams ist die Scanner-Abdeckung der schwierigste Teil der Anwendungssicherheit. Verschiedene Scanner werden projektweise eingerichtet, sodass es vom jeweiligen Team abhängt, ob ein Scanner überhaupt läuft. Neue Projekte bleiben mitunter unbemerkt und werden womöglich wochenlang ausgeliefert, bevor auffällt, dass sie nicht gescannt werden. Hängt die Abdeckung von implizitem Wissen statt von Richtlinien ab, gelangt ungescannter Code in die Auslieferung, Schwachstellen erreichen die Produktion, und Audits legen die Lücken offen.

Drittanbieter-Scanner lassen sich nun im großen Maßstab über alle GitLab-Projekte hinweg durchsetzen. Jeder Scanner, der SARIF ausgibt, läuft unter den definierten Richtlinien, und die identifizierten Schwachstellen fließen nativ in GitLab ein. Jeder Fund landet in einer einzigen Schwachstellenansicht, die denselben Regeln unterliegt. So wird die Abdeckung nachweisbar, statt auf gut Glück zu beruhen.

Von dort durchlaufen die Funde von Drittanbieter-Scannern denselben automatischen Behebungs-Workflow der GitLab Duo Agent Platform wie die Funde nativer GitLab-Scanner. SAST False Positive Detection priorisiert Funde nach tatsächlichem Risiko, und Agentic SAST Vulnerability Resolution erstellt einen merge-fertigen Fix, um Funde automatisch zu beheben, bevor sie in die Produktion gelangen. So erhält das Team eine nachweisbare Abdeckung mit einer einzigen, geregelten Ansicht über alle Scanner hinweg, dazu die automatische Behebung von Drittanbieter-Funden.

Geheimnisse früher erkennen und False Positives reduzieren

Die Erkennung von Geheimnissen läuft in den Pipelines, um durchgesickerte Zugangsdaten aufzuspüren. Bisher hatten Teams jedoch mit zwei Problemen zu kämpfen: übersehenen Geheimnissen und verrauschten Funden. Bei einem neuen Branch wird nur der jüngste Commit gescannt, sodass ein zuvor eingebrachtes Geheimnis unbemerkt ausgeliefert werden kann. Die erkannten Funde vermischen sich mit Test-Zugangsdaten, Platzhalterwerten und Beispiel-Tokens, sodass Entwicklungsteams Aufwand in das Aussortieren von Rauschen stecken, statt echte Risiken zu beheben.

Secret Detection scannt jetzt jeden Commit eines neuen Branch statt nur den jüngsten, und Secret False Positive Detection, jetzt allgemein verfügbar, ergänzt jeden Fund um einen Konfidenzwert und eine Erklärung, die im Schwachstellenbericht erscheinen. So erkennt das Team Geheimnisse unabhängig davon, wo sie eingebracht wurden, und konzentriert sich auf das Verringern echter Risiken statt auf False Positives.

Festlegen, was KI-Agenten tun dürfen, und es nachweisen

Unternehmen haben KI-Agenten für die Programmierung eingeführt. Agenten öffnen Merge Requests, rufen Tools auf und committen Code an der Seite der Teams, für die sie arbeiten. Sobald ein Agent jedoch für ein Projekt freigegeben ist, kann er schreiben, löschen und pushen, ohne dass jemand die Aktion zuvor prüft. Verantwortlich für Änderungen an der Codebase bleibt das Unternehmen, unabhängig davon, ob ein Agent oder ein Mensch sie vornimmt. Unternehmen müssen festlegen, was ein Agent darf, bevor er handelt, und im Nachhinein genau belegen können, was er getan hat.

GitLab 19.1 schließt diese Governance-Lücke. Mit AI Audit Event Streaming, jetzt in der Beta, wird jede Aktion eines Agenten als Audit Event aufgezeichnet und zusammen mit dem übrigen Audit-Trail an die Audit-Log-Ziele gestreamt. Das Release bringt zudem Kontrolle darüber, was Agenten auf der Plattform tun dürfen. Agent Tool Approval Guardrails, ebenfalls in der Beta, erlauben es der Administration, jedes Agenten-Tool so einzustellen, dass es eigenständig läuft, auf eine menschliche Freigabe wartet oder blockiert bleibt. So wartet eine sensible Aktion wie das Schreiben einer Datei oder das Löschen einer Ressource auf die Freigabe durch ein Teammitglied, bevor sie ausgeführt wird. Jede Freigabeentscheidung wird als Audit Event aufgezeichnet, sodass Teams sie nachträglich prüfen können.

Das Ergebnis ist geregelte Autonomie. Agenten können von Anfang bis Ende laufen, innerhalb der gesetzten Leitlinien, und eine riskante Aktion erreicht die Codebase nicht, solange niemand sie abgezeichnet hat. Fragt später jemand aus dem Audit oder der Incident Response, was ein Agent getan hat, liegt die Antwort bereits im Audit-Trail, den das Team führt.

Audit-Trail der Agentenaktivität mit einer Warnung, weil ein Agent einen Fund mit hohem Schweregrad ohne menschliche Freigabe verworfen hat

Geregelte Autonomie für Agenten

GitLab 19.1 bringt Governance zu den Agenten in der Codebase, mit vollständiger Sicherheits-Scanner-Abdeckung über alle Projekte hinweg und automatischer Behebung bei Drittanbieter-Scannern. Festlegen lässt sich für jeden Agenten, was er darf, bevor er handelt, und jede Aktion landet im Audit-Trail.

Um zu sehen, was Agenten innerhalb der gesetzten Leitlinien tun können, und um zu belegen, was sie getan haben: jetzt eine kostenlose Testversion der GitLab Duo Agent Platform starten.