Deine Software-Fabrik sichern

Der GitLab Security
Standard

Unternehmen bewegen sich auf eine Welt zu, in der Agenten Software entwickeln, ohne dass bei jedem Schritt ein Mensch beteiligt ist. Der GitLab Security Standard zeigt, wie du sicher dorthin gelangst: mit Sicherheitsgrundlagen, die die Software-Fabrik härten, und Stufen, in denen Agenten sich Autonomie verdienen.

v1.0Veröffentlicht am 6. Oktober 2026

Die Wirtschaftlichkeit hat sich verändert

Code ist im Überfluss vorhanden. Vertrauen ist knapp. Dieselben KI-Modelle, mit denen Agenten Code in Maschinengeschwindigkeit schreiben und ausliefern, machen es auch schneller und günstiger, bestehende Schwachstellen zu entdecken, zu verknüpfen und auszunutzen. Die Zahl der Funde steigt inzwischen schneller, als Teams das Wichtige überprüfen, priorisieren und beheben können.

Vertraue deinen Agenten

Pyramide aus fünf Stufen – Autorisieren, Isolieren, Verifizieren, Freigeben und Reagieren – auf einem Fundament aus Richtlinien, Audit und Verantwortung, mit Autonomie an der Spitze und einem Kreislauf aus Finden, Beheben und Lernen, der Fehler an das Fundament zurückführt.

Unser Ansatz, Vertrauen in eine Flotte von Agenten aufzubauen, beginnt bei der Software-Fabrik, in der sie arbeiten. Sicherheit ist in jede Stufe eingebettet, sodass Agenten unter Kontrollen arbeiten, die sie nicht umgehen können. Autonomie wird nicht gewährt, sondern verdient – Stufe für Stufe.

Fünf Stufen auf einem Fundament aus Richtlinien, Audit und Verantwortung legen fest, was jeder Agent nachweisen muss. Je mehr ein Agent nachweist, desto mehr Autonomie erhält er.

Fundament · Wo Vertrauen beginnt

Richtlinien, Audit, Verantwortung

Regeln, die durchgesetzt werden, eine Aufzeichnung des Geschehenen und ein namentlich benannter Mensch, der verantwortlich ist, wenn etwas schiefgeht. Ohne das Fundament lässt sich keine Stufe nachweisen.

  • Richtlinien

    Menschen legen fest, was Agenten dürfen und was nicht: welche Tools sie verwenden, worauf sie zugreifen dürfen und welche Aktionen eine Genehmigung erfordern. Diese Richtlinien werden definiert und genehmigt, bevor Code geschrieben wird, und anschließend automatisch durchgesetzt.

  • Audit

    Ein unveränderlicher Audit-Trail jedes Agenten und Modells – bis hin zu jedem Prompt, jedem Denkschritt, jedem Tool-Aufruf und jeder Aktion, verknüpft von der Aufgabe bis zum Deployment.

  • Verantwortung

    Jeder Agent, jedes Dienstkonto und jede Kontrolle ist einem namentlich benannten Menschen zugeordnet.

  1. 01Autorisieren

    Zweck

    Wer und was darf handeln – und in welchem Rahmen?

    Jede Person, jeder Agent und jeder Dienst hat eine bekannte oder zusammengesetzte Identität, einen benannten Owner und Zugriff, der auf die jeweilige Aufgabe beschränkt ist.

    Beispielkontrollen

    1. AgenteninventarJeder Agent, jede Integration und jedes Dienstkonto ist bekannt und hat einen OwnerAI Catalog
    2. AgentenidentitätJede Agentenaktion lässt sich auf den Agenten und den Menschen zurückführen, der sie ausgelöst hatComposite Identity
    3. Secrets-VerwaltungZentralisiert, nach dem Least-Privilege-Prinzip, rotiert und widerrufbar – mit festgelegtem Geltungsbereich und festgelegter Lebensdauer für jede AnmeldeinformationGitLab Secrets Manager

  2. 02Isolieren

    Zweck

    Kann eine kompromittierte Eingabe oder ein kompromittiertes Tool über die Aufgabe hinaus wirken?

    Die Arbeit läuft in einer abgeschotteten Umgebung, deren Grenzen auch dann halten, wenn der Agent einer schädlichen Anweisung folgt.

    Beispielkontrollen

    1. Isolierte AusführungKurzlebiger Arbeitsbereich mit eingeschränktem Speicher und NetzwerkAusführungsumgebung der Duo Agent Platform
    2. Vertrauenswürdige AbhängigkeitenPakete werden über einen kontrollierten Proxy bezogen und geprüft, bevor sie in den Build gelangenDependency FirewallGeschlossene Beta
    3. Freigegebene Tools und ZugriffswegeAgenten verwenden nur genehmigte Tools, Verbindungen und MCP-ServerKI-GovernanceBeta

  3. 03Verifizieren

    Zweck

    Ist die Änderung sicher – geprüft durch Kontrollen, die der Akteur nicht verändern kann?

    Jede Änderung, ob von Mensch oder Agent, durchläuft Sicherheitsprüfungen, die zentral durchgesetzt werden und weder geändert noch ausgesetzt werden können.

    Beispielkontrollen

    1. Richtlinien im AusführungspfadScans, Genehmigungen und Deployment-Kontrollen werden zentral durchgesetzt, nicht pro ProjektPipeline-Ausführungsrichtlinien
    2. Geschützte PrüfungenDer Akteur kann die Pipeline oder Richtlinie, die ihn bewertet, nicht bearbeitenGeschützte Branches
    3. AufgabentrennungDer Autor bzw. die Autorin, ob Mensch oder Agent, kann nicht die einzige genehmigende Instanz seinMerge-Request-Genehmigungsrichtlinien

  4. 04Freigeben

    Zweck

    Erhält die Produktion genau das, was verifiziert wurde?

    Deployment-Entscheidungen sind an genau das Artefakt gebunden, das die Verifizierung bestanden hat – identifiziert über Digest und Herkunft, nicht über Namen oder Versionslabel.

    Beispielkontrollen

    1. Herkunft und SignierungJedes Artefakt enthält signierte Nachweise über Quelle, Eingaben und BuildSLSA-Provenance-Generierung
    2. Vor dem Deployment verifizierenDer bereitgestellte Digest muss mit dem genehmigten übereinstimmenVerifizierung von Artefakt-Attestierungen
    3. Unveränderliche ReferenzenTags und Images können nach der Genehmigung nicht überschrieben werdenGeschützte Container-Tags

  5. 05Reagieren

    Zweck

    Können wir es stoppen, nachverfolgen und wiederherstellen?

    Verdächtige Aktivitäten und anfällige Ergebnisse sind mit einer Reaktion verknüpft, die die Aufgabe stoppen, nachverfolgen kann, worauf sie zugegriffen hat, und den Fix verifiziert.

    Beispielkontrollen

    1. Getesteter NotausschalterAufgabe stoppen, Zugriff widerrufen, Releases pausierenSperren von Dienstkonten
    2. Auswirkungen nachverfolgenJede Änderung und jedes Release identifizieren, das ein Agent berührt hatAudit-Ereignisse
    3. Folgenreiche Aktionen überwachenTool-Nutzung, Zugriffe auf Anmeldeinformationen, Berechtigungsänderungen und Deployments sind sichtbarAudit-Ereignis-Streaming

Der Feedback-Kreislauf

Finden, beheben, lernen

Wenn etwas fehlschlägt, lerne daraus und aktualisiere die Richtlinie, damit die Regeln besser werden, bevor die Autonomie wiederhergestellt wird.

Gleichzeitig erkennen, triagieren und beheben Sicherheitsagenten kontinuierlich Schwachstellen.

Automatisierte Behebung

Was wir messen

  • Zeit bis zur Eindämmung
  • Zeit bis zur verifizierten Behebung

Abgleich mit Frameworks

Der Standard lässt sich den Frameworks zuordnen, an die deine Sicherheits- und Compliance-Teams bereits berichten.

StufeOWASP SAMMOWASP Top 10 for Agentic ApplicationsMITRE ATLASNIST SSDF & SP 800-53
FundamentRichtlinien, Audit, Verantwortung
  • Least Agency (Grundprinzip)
  • SSDF PO.1, PO.2, PO.3
  • SP 800-53 AU
01Autorisieren
  • ASI03 Identity and Privilege Abuse
  • ASI07 Insecure Inter-Agent Communication
  • ASI10 Rogue Agents
  • SSDF PS.1
  • SP 800-53 AC-2, AC-5, AC-6, CM-3, CM-5, IA, SA-11
02Isolieren
  • ASI01 Agent Goal Hijack
  • ASI02 Tool Misuse and Exploitation
  • ASI04 Agentic Supply Chain Vulnerabilities
  • ASI05 Unexpected Code Execution
  • ASI06 Memory and Context Poisoning
  • ASI08 Cascading Failures
  • SSDF PO.5, PW.4
  • SP 800-53 SC-7, SC-39, SR
03Verifizieren
  • ASI05 Unexpected Code Execution
  • ASI09 Human-Agent Trust Exploitation
  • SSDF PO.4, PW.7, PW.8
04Freigeben
  • ASI04 Agentic Supply Chain Vulnerabilities
  • SSDF PS.2, PS.3
  • SP 800-53 SI-7, SR-4
05Reagieren
  • ASI10 Rogue Agents
  • SSDF RV.1 bis RV.3
  • SP 800-53 IR, AU

MITRE ATLAS katalogisiert Angriffstechniken gegen KI-Systeme, daher gibt es nicht für jede Stufe eine direkte Entsprechung.

Verdiente Autonomie

Autonomie wird pro Workflow gewährt, und jeder Workflow muss die Tests jeder Stufe bestehen, bevor er sich mehr verdient. Verschiedene Workflows können gleichzeitig mit unterschiedlichen Autonomiestufen arbeiten.

  • Was der Agent tun darf
    Empfehlen; Menschen nehmen die Änderung vor
    Beispiel-Workflow
    Pipeline- und Richtlinienkonfiguration (Änderungen an den Kontrollen selbst)

Haben sich deine Agenten Autonomie verdient?

Fordere dein kostenloses Assessment an und erfahre, wie du in deiner Umgebung die nächste Autonomiestufe erreichst.

Alle Felder sind Pflichtfelder.

GitLab wendet diesen Standard auf die eigene Software-Fabrik an. Er ist öffentlich, frei zugänglich und entwickelt sich ständig weiter. Wenn sich Bedrohungen, Modelle und unsere eigenen Möglichkeiten ändern, aktualisieren wir ihn weiter und zeigen, was sich geändert hat.