MHC-09 AI-gestütztes Security-Testing in der Pipeline

Auf einen Blick

Operativer Nutzen

Findet Schwachstellen schon vor der Auslieferung — automatisch bei jeder Änderung — und entzieht dem Angreifer das Zeitfenster zwischen Bekanntwerden einer Lücke und ihrem Schließen.

Betroffene Richtlinie

Richtlinie zur sicheren Softwareentwicklung.

Abhängigkeiten

setzt eine automatisierte Build-/CI-Pipeline voraus; nutzt die Stücklisten aus MHC-02 für den Komponenten-Abgleich.

Aufwandstreiber

hängt von Zahl und Aufbau der Pipelines und der Menge des erzeugten Codes ab. Der konkrete Aufwand richtet sich nach den Ressourcen der Organisation.

Primäre Kennzahl

Zeit vom Verfügbarwerden einer belastbaren Behebung für eine aktiv ausgenutzte Schwachstelle (KEV) bis zur nachgewiesenen Behebung oder wirksamen Kompensation. Ergänzende Wirksamkeitskennzahlen: Anteil der Pipelines mit Sicherheitsprüfung und Pre-Merge-Block, Anteil der Funde, die trotz Pipeline-Prüfung in die Produktion gelangen (Escape Rate), Anteil geeigneter Anwendungen mit produktivem AI-gestütztem Testverfahren.

Berührte Standards (ohne Erfüllungsanspruch)

ISO/IEC 27002 A.8.28/A.8.29; NIST SP 800-218 (SSDF) und SP 800-218A (AI); OWASP ASVS; C5:2026 OPS-25; CRA Annex I.

Control-Statement

Sicherheitsprüfungen laufen automatisch in der Entwicklungs-Pipeline: Code, Abhängigkeiten und laufende Anwendung werden bei jeder Änderung geprüft; schwerwiegende Funde blockieren die Übernahme. Für geeignete Anwendungen werden darüber hinaus AI-gestützte Testverfahren ergänzend eingesetzt — insbesondere zur dynamischen Erzeugung von Testfällen, zur Erkennung mehrstufiger Schwachstellenketten, zur hypothesenbasierten Prüfung von Angriffspfaden oder zur agentischen Sicherheitsanalyse. AI-generierter Code wird als eigene Risikokategorie zusätzlich geprüft.

Zweck und Bedrohungsbezug

Früher blieb zwischen dem Bekanntwerden einer Schwachstelle und einem funktionierenden Angriff Zeit zum Patchen. AI verkürzt dieses Fenster drastisch — teils auf Stunden. Wer Schwachstellen erst spät findet, ist zu langsam. Hinzu kommt: AI-Programmierhilfen erzeugen regelmäßig unsichere Muster (fest eingebaute Zugangsdaten, fehlende Prüfungen von Eingaben, unsichere Voreinstellungen, veraltete Bausteine). Schutzziel ist, Schwachstellen so früh wie möglich — schon bei jeder Änderung — automatisch zu finden und zu beheben, bevor sie in den Betrieb gelangen.

Wirkung in den Regelwerken

Auf diese Controls und Anforderungen wirkt das MHC. Die Einstufung zeigt, wie stark das jeweilige Control unter KI-gestützten Angriffen an Wirkung verliert.

Alle 93 Controls in der Analysematrix · Alle 45 Controls in der Befundmatrix · Alle 23 Anforderungen der Bausteinfamilie

Reifegrad-Pfad

Initial

SAST/DAST/SCA in der Pipeline.

Defined

zusätzliche Prüfung AI-generierten Codes; Blockieren bei schwerwiegenden Funden; mindestens ein AI-gestütztes Testverfahren ist für geeignete Anwendungen nachweislich produktiv im Einsatz.

Managed

tägliche Schwachstellen-Scans der laufenden Systeme; gesonderte Auswertung des AI-Codes; beschleunigter Weg für aktiv ausgenutzte Schwachstellen (KEV).

Messung und Audit-Nachweis

Kennzahl

Behebungslatenz für aktiv ausgenutzte Schwachstellen (KEV) — Zeit von der Verfügbarkeit einer belastbaren Behebung oder wirksamen Kompensationsmöglichkeit bis zu deren verifizierter Umsetzung; als Behebung zählen Patch, Workaround, kompensierendes Control, Isolierung oder Ablösung (Richtwert: möglichst unter 24 Stunden im Mittel); ergänzend Anteil der Pipelines mit Sicherheitsprüfung und Pre-Merge-Block, Escape Rate sowie Anteil geeigneter Anwendungen mit produktivem AI-gestütztem Testverfahren.

Nachweis

Pipeline-Konfiguration, Prüf- und Blockier-Protokolle, Auswertung der AI-Code-Funde, Berichte der Penetrationstests.

Nachweislogik (in Anlehnung an ISO/IEC 27001, Clause 9)

dokumentiert? — Entwicklungsrichtlinie, Pipeline-Konfiguration; verantwortlich? — Entwicklungs-/Produktverantwortliche; Häufigkeit? — bei jeder Änderung, Scans täglich; Toleranz? — keine Auslieferung mit offenen schwerwiegenden Funden.

Typische Fehler

• Die Prüfungen laufen zwar, blockieren aber nicht; schwerwiegende Funde werden gemeldet und trotzdem ausgeliefert.
• Es wird nur der neue Code geprüft, nicht die bereits laufenden Systeme; dort bekannt gewordene Schwachstellen bleiben offen.
• AI-generierter Code wird wie handgeschriebener behandelt; seine typischen Schwächen werden nicht gezielt gesucht.
• Die Schwellen sind so streng gesetzt, dass die Pipeline ständig blockiert; in der Folge werden Prüfungen umgangen statt behoben.

Abgrenzung und Restrisiko

Abgrenzung

betrifft das automatisierte Prüfen während der Entwicklung; die Transparenz der Komponenten behandelt MHC-02, das Erkennen aktiver Angriffe MHC-05.

Restrisiko

automatisierte Prüfungen finden bekannte Muster, nicht jede neuartige oder logische Schwachstelle; Penetrationstests und manuelle Prüfungen bleiben ergänzend nötig.

ISO/IEC 27002:2022

A.8.8 Handhabung von technischen Schwachstellen; A.8.25 Lebenszyklus einer sicheren Entwicklung; A.8.26 Anforderungen an die Anwendungssicherheit; A.8.28 Sichere Codierung; A.8.29 Sicherheitsprüfung bei Entwicklung und Abnahme; A.8.32 Änderungssteuerung.

Framework

C5:2026 OPS-25 (mit Verschärfung OPS-25.01AS, tägliche Scans); NIST SP 800-218 (SSDF v1.1; Revision 1.2 im Entwurf) und SP 800-218A (sichere Entwicklung für generative AI); OWASP ASVS; CRA Annex I Teil II.

Umsetzung im Detail

Organisatorische und technische Umsetzung, Umsetzungsbeispiele und die Priorisierung im Gesamtprogramm beschreibt der Implementation Guide.

Implementation Guide (PDF)Zum MHC-Katalog

Quelle: MRIS Implementation Guide (ISO/IEC 27001), Fassung 2.0. Lizenz CC BY-SA 4.0. © 2026 Richard Peddi.