DevSecOps: 3 Frameworks und ein 4-Stufen-Plan beenden jeden Cyber-Blindflug

DevSecOps hat Entwicklungsprozesse über Jahre hinweg robuster gemacht: CI/CD-Pipelines sind abgesichert, Infrastrukturen stabiler, Sicherheitsprüfungen fest integriert. Doch mit dem Einsatz von Künstlicher Intelligenz verschiebt sich die Ausgangslage jetzt grundlegend.

Entwickler:innen integrieren LLMs in bestehende Applikationen, Data Analysts trainieren Machine-Learning-Modelle, KI-Tools werden unternehmensweit produktiv eingesetzt – und die Angriffsfläche wächst schneller, als bestehende Sicherheitsmodelle nachziehen können. Plötzlich zeigen sich Lücken dort, wo Prozesse als bewährt galten.

Warum Scanner, Firewalls und Pentests bei KI versagen

Die harte Wahrheit ist: KI-Systeme sind mit herkömmlichen Sicherheitsmassnahmen nur unzureichend geschützt. Schwachstellenscanner übersehen sogenannt vergiftete, manipulierte Trainingsdaten, klassische Firewalls greifen bei Prompt-Injection-Angriffen auf KI-Lösungen ins Leere, und selbst Penetrationstests erfassen keine Schwachstellenrisiken in der Modellextraktion. KI ohne spezialisierte Sicherheitsmassnahmen bedeutet Kontrollverlust. Wer sie dennoch ohne KI-spezifische Schutzmassnahmen einsetzt, operiert im Blindflug.

KI-Sicherheit beginnt nicht im Code, sondern im Management

Sie kennen die DevSecOps-Philosophie: Sicherheit gehört von Anfang in jeden Prozess, wird konsequent automatisiert und als gemeinsame Verantwortung verankert. Mit KI entstehen völlig neue Angriffsmuster, die ausserhalb der bisherigen Erfahrungswerte und Schutzmechanismen liegen.

Die neuen Cyberrisiken zeigen sich auf folgenden drei Ebenen: in der Data Science, im operativen Betrieb von KI-Systemen und in strategischen Entscheidungsprozessen.

Data Science und KI: Wie Machine-Learning-Modelle neue Angriffsflächen schaffen

Im Bereich «Data Analysts & Scientists» können unbeabsichtigt folgende, neue Sicherheitsrisiken entstehen:

• Einsatz nicht verifizierter Trainingsdaten, potenziell manipuliert von Angreifern oder Wettbewerbern.

• Verwendung von vorab trainierten Modellen aus öffentlichen Repositories ohne Überprüfung ihrer Sicherheit oder Urheberschutz.

• Offenlegung von Modell-APIs ohne Rate Limitation oder Extraktionsschutz.

• Bereitstellung von Modellen ohne Rücksicht auf Angriffe durch böswillige Akteure.

MLOps: Deshalb versagt ein klassischer Schutz bei ML-Systemen

Der Betrieb von ML-Systemen folgt einer anderen Sicherheitslogik als klassische Applikationen mit konkreten Auswirkungen auf Architektur, Lieferkette und Monitoring:

• Anwendungscode und ML-Pipelines erfordern unterschiedliche Arten von Sicherheit.

• Die Infrastruktur für die Bereitstellung von Modellen benötigt besonderen Schutz.

• Kontinuierliches Training von KI-Modellen birgt neue Risiken für die Lieferkette.

• Bei der Drift-Erkennung (Überwachen von Daten- oder Modellveränderungen) geht es nicht nur um Leistung, sondern auch um Sicherheit.

Wenn fehlende Risikoanalyse zum Business-Risiko wird

Fehlende Transparenz über KI-Risiken kann dazu führen, dass strategische Entscheidungen auf unsicherer Basis getroffen werden:

• Welche KI-Systeme sind für Ihr Unternehmen am gefährlichsten?

• Halten wir die neuen KI-Vorschriften (https://www.infoguard.ch/en/blog/ai-and-cybersecurity-part-1-fine-tuning-between-potential-and-risk) ein (z. B. EU-KI-Gesetz, Vorschriften für bestimmte Branchen)?

• Wie wahrscheinlich ist es, dass unsere Modelle gestohlen werden, unsere Daten nach aussen geleakt werden oder unsere Algorithmen voreingenommen sind?

• Wie viel Geld sollten wir für KI-Sicherheit ausgeben und wo?

Eine KI-Sicherheitsbewertung hilft Ihnen alle diese Fragen zu beantworten, bevor sie zu Problemen werden.

Das Drei-Framework-Modell: Was macht es so erfolgreich?

Wir haben das DevSecOps-Modell, dem Sie bereits vertrauen, um drei Frameworks erweitert, die gut zusammenarbeiten:

Strategische Ebene: NIST AI Risk Management Framework

Was das NIST AI Risk Management Framework leistet:

Das NIST AI Risk Management Framework übersetzt KI-Risiken in eine für Führungskräfte verständliche Governance-Sprache; wie Sicherheit, Datenschutz, Fairness, Transparenz und Einhaltung von regulatorische Anforderungen. Es unterstützt dabei, das KI-Portfolio systematisch zu klassifizieren und Prioritäten anhand von Risikostufen zu setzen.

Warum Sie es brauchen:

Verwaltungsräte interessieren sich zunehmend dafür, wie KI im Unternehmen eingesetzt wird. Regulierungsbehörden beobachten deren Anwendung genau, und auch Kunden erwarten Transparenz. Das NIST AI RMF schafft die notwendige Governance-Struktur, um diese Anforderungen systematisch und nachvollziehbar zu adressieren.

Taktische Ebene: MITRE ATLAS Threat Intelligence

Was MITRE ATLAS Threat Intelligence für Sie leistet:

Das MITRE ATLAS Threat Intelligence zeigt genau, wie KI-Systeme angegriffen werden,¬ mit realen Techniken, die Wettbewerber, Staaten und Cyberkriminelle in der Vergangenheit eingesetzt haben. Nicht nur hypothetische, sondern auch reale und verifizierte Angriffe: Vom Modell-Diebstahl durch API-Abfragen bis hin zur Vergiftung von Trainingsdaten über Monate hinweg.

Warum Sie es brauchen:

Ein Red Team kennt die Methoden, in klassische Apps einzudringen. Es weiss jedoch noch nicht, wie man Modelle extrahiert oder ML-Pipelines vergiftet. ATLAS füllt diese Wissenslücke mit Angriffsmustern, die speziell für KI entwickelt wurden.

Operative Ebene: CRISP-ML(Q) Development Lifecycle

Was das CRISP-ML(Q) Development Lifecycle leistet:

Das CRISP-ML(Q) Development Lifecycle fügt Sicherheitskontrollen in jedem Schritt der ML-Entwicklung hinzu, von der Datenerfassung über die Bereitstellung bis hin zur Überwachung. Es überträgt das aus DevSecOps bekannte «Shift Left»-Prinzip auf den Entwicklungszyklus von KI-Systemen.

Warum Sie es brauchen:

Die Kompetenz zur sicheren Softwareentwicklung ist etabliert, während der sichere Aufbau von ML-Systemen häufig noch nicht vergleichbar verankert ist. CRISP-ML(Q) schliesst diese Lücke mit einem strukturierten Prozess, der Sicherheit nicht nur in der Theorie, sondern auch in der Praxis gewährleistet.

Praktische Umsetzung: Do’s und Dont’s beim Aufspüren von Betrugsfällen mit KI

Angenommen, Sie entwickeln ein KI-System zur Betrugserkennung. Was passiert, wenn Sicherheitsmechanismen nicht von Anfang an integriert sind?

Ohne integrierte DevSecOps-Frameworks (Worst-case-Szenario)

Fehlen integrierte Frameworks, entfaltet sich das Risiko entlang der gesamten Wertschöpfungskette:

• Datenwissenschaftler trainieren mit den verfügbaren Daten, wodurch sie mit höherer Wahrscheinlichkeit «vergiftet» sein werden.

• Ein DevOps-Team stellt es wie jede andere App bereit, was bedeutet, dass es keine KI-spezifischen Kontrollen gibt.

• Das Sicherheitsteam testet es wie normale Software, was bedeutet, dass es keine Betrachtung von KI-Angriffsvektoren gibt.

• Sechs Monate später stehlen Wettbewerber das Modell durch API-Abfragen, Aufsichtsbehörden verhängen Geldstrafen wegen Voreingenommenheit und Führungskräfte fragen sich, warum die Sicherheit «das nicht bemerkt hat».

KI mit integrierter KI-Sicherheitsbewertung

Basierend auf den Kriterien des NIST AI RMF wird dies als ein System mit hohem Risiko eingestuft, das strengen Kontrollen unterliegt, da es die Finanzen der Kunden betrifft und unter behördlicher Aufsicht steht.

Die Bedrohungsmodellierung nach MITRE ATLAS zeigt, dass die grössten Bedrohungen die Modell-Extraktion (durch Wettbewerber), Datenvergiftung (durch Gegner, die eine Entdeckung vermeiden wollen) und «Bias Incidents» (durch Aufsichtsbehörden) sind.

Die Integration von CRISP-ML(Q) stellt sicher, dass die Datenvalidierung das Verfälschen verhindert, Fairness-Tests entsprechende Verzerrungen aufdecken und die kontinuierliche Überwachung Angriffe in der Produktion erkennt.

Das Ergebnis? Die Betrugserkennung geht planmässig live, besteht die behördliche Überprüfung und funktioniert sicher, da die Sicherheitsmechanismen von Anfang an integriert war und Schwachstellen nicht erst bei der Einführung sichtbar werden.

«Mehr KI, mehr Risiko. Wer Sicherheit nicht entlang des ML-Lebenszyklus denkt, verliert die Kontrolle.» 

Eine KI-Sicherheitsbewertung beantwortet die brennendsten Governance-Fragen, bevor sie Ihre Innovation ausbremsen.

Von der Analyse zur Umsetzung: Der 4-Stufen-Plan für sichere KI

Unsere KI-Sicherheitsbewertung schafft für DevSecOps-Teams Klarheit darüber, welche Massnahmen prioritär umzusetzen sind und worauf der Fokus beim Einsatz von KI liegen sollte.

Schritt 1: Finden Sie heraus, wie hoch Ihr KI-Risiko ist

Wir erstellen eine Karte aller KI-Systeme, einschliesslich derjenigen, die der IT bekannt sind, und derjenigen, die «Schatten-KI» sind. Durch die systematische Risikoklassifizierung wird transparent, welche KI-Projekte ein erhöhtes Sicherheitsrisiko darstellen und welche weniger kritisch sind.

Was Sie potenziell sehen werden: «Das Data-Science-Team verwendet 12 verschiedene KI-Tools. Drei davon verarbeiten personenbezogene Daten von Kunden. Eines ist mit der Datenbank verbunden, in der der Betrieb Produktionsdaten speichert. Zwei davon sind gemäss dem EU-KI-Gesetz mit einem hohen Risiko behaftet.» Jetzt wissen Sie, wo Sie ansetzen müssen.

Schritt 2: Wissen, wie Angreifer vorgehen werden

Wir verwenden MITRE ATLAS, um dem Sicherheitsteam genau zu zeigen, wie Angreifer die KI-Systeme angreifen werden. Dabei handelt es sich nicht um allgemeine Bedrohungen, sondern um spezifische Angriffsszenarien, die auf dokumentierten Methoden aus der Praxis basieren.

Was Sie potenziell sehen werden: «Prompt-Injection-Angriffe können in den Kundenservice-Chatbot eindringen und Kundendaten stehlen. Durch eine Vielzahl von API-Abfragen lässt sich die Funktionsweise eines Betrugserkennungsmodells rekonstruieren. Eine KI-gestützte Lösung im Bereich Personalbeschaffung kann zudem ins Visier von Aufsichtsbehörden geraten, wenn Anzeichen für Voreingenommenheit bestehen.» Jetzt weiss Ihr Sicherheitsteam, worauf es achten muss.

Schritt 3: Suchen Sie nach Lücken in Ihrer Sicherheit

Wir vergleichen die aktuelle KI-Sicherheitslage mit den Branchenstandards. Welche Kontrollmechanismen sind etabliert? Wo gibt es Lücken? Wie hoch ist die Risikobewertung für jede Lücke?

Was Sie potenziell sehen werden: «Die API-Sicherheit ist robust, jedoch fehlt ein wirksamer Schutz gegen Modellextraktion. Für Trainingsdaten bestehen Qualitätsprüfungen, aber keine Abwehrmassnahmen gegen Datenvergiftung (Poisoning). Die Überwachung identifiziert Probleme mit der Leistung, aber erkennt keine sicherheitsrelevanten Angriffe.» Jetzt wissen Sie genau, was Sie verbessern können.

Schritt 4: Etablieren Sie Ihren Aktionsplan als prioritär

Wir geben Ihnen einen Plan mit drei Implementierungsphasen: Kritisch (Monate 1–2), Hohe Priorität (Monate 3–4) und Mittlere Priorität (Monate 5–6). Jede Phase hat ihre eigenen Kontrollen sowie Schätzungen zum Arbeitsaufwand für die Umsetzung.

Was Sie potenziell sehen werden: «In Phase 1 arbeiten Sie an fünf wichtigen Kontrollen, die Ihre grössten Risiken innerhalb acht Wochen Arbeit senken. Für zusätzliche Einsatz von Experten über acht Wochen fügt Phase 2 eine tiefgreifende Verteidigung hinzu. Phase 3 erreicht einen hohen Reifegrad.» Jetzt können Sie Ihre Pläne erstellen, budgetieren und umsetzen.

Eine KI-Sicherheitsbewertung deckt Schatten-Ki sowie Angriffsszenarien auf und liefert in einem 4-Stufen-Plan die fünf entscheidenden Kontrollmechanismen für sofortige Risikosenkung.

KI-Security-Assessment abgeschlossen: Vom Bericht zur operativen Umsetzung

Die Bewertung ist nicht nur ein Bericht, sondern die Grundlage dafür, wie Teams KI-Modelle künftig sicher entwickeln können:

Sofort zu ergreifende Massnahmen (erste 90 Tage)

• Einrichtung zentraler Kontrollen zur Reduktion der kritischsten Schwachstellen

• Implementierung von Abwehrmassnahmen gegen Datenvergiftung (Poisoning)

• Begrenzung und Überwachung von API-Aufrufen zum Schutz vor Modellextraktion

• Prüfung und Sicherstellung der Modellintegrität

• Schliessen identifizierter Sicherheitslücken mit unmittelbarem Schadenspotenzial.

Grundlagen schaffen (3–6 Monate)

• Integration von KI-spezifischen Sicherheitskontrollen in bestehende DevSecOps-Pipelines

• Automatisierte Tests zur Erkennung potenziell schädlicher Eingaben

• Überprüfung von Modellartefakten und -integrität innerhalb der CI/CD-Prozesse

• Monitoring zur Identifikation ungewöhnlicher oder sicherheitsrelevanter Abfragen

• Verankerung von KI-Sicherheit als kontinuierlicher Bestandteil des operativen Betriebs statt als reaktive Massnahme im Vorfallfall.

Reifephase (6–12 Monate)

• Aufbau organisationaler Kompetenz zum Schutz von KI-Systemen

• Etablierung sicherer Entwicklungspraktiken im Bereich Machine Learning

• Souveräner und kontrollierter Einsatz von KI im operativen Betrieb

• Spezifische Abwehrmechanismen gegen KI-bezogene Bedrohungen

• Verankerung von KI-Sicherheit als Bestandteil der Unternehmenskultur

Kontinuierliche Optimierung

Mit entsprechenden Frameworks lässt sich flexibel auf veränderte Bedrohungen reagieren. Neue MITRE-ATLAS-Methoden werden in bestehende Abwehrmassnahmen integriert. Anpassungen gemäss NIST AI RMF stärken die Governance-Strukturen, während Weiterentwicklungen im CRISP-ML(Q)-Prozess die sichere KI-Entwicklung kontinuierlich verbessern. Sicherheit bleibt damit anpassungsfähig, ohne die Sicherheitsstrategie jeweils von Grund auf neu definieren zu müssen.

Von DevSecOps zu MLSecOps: Warum sichere KI ein Wettbewerbsvorteil ist

DevSecOps hat dieses Problem gelöst, indem es Sicherheit von Anfang an zu einem Teil des Prozesses gemacht hat. Dank Automatisierung konnte es wachsen. Es hat sich eine Kultur entwickelt, in der jeder Verantwortung trägt.

KI ist dasselbe, nur mit anderen Werkzeugen. Die Teams, welche heute DevSecOps-Ideen auf KI anwenden, werden sich durchsetzen. Wenn Sie KI-Sicherheit als «etwas, um das wir uns später kümmern werden» betrachten, werden Unternehmen gegenüber Wettbewerbern, Aufsichtsbehörden oder Angreifern den Kürzeren ziehen.

Jetzt handeln: DevSecOps um KI-Governance und ML-Security erweitern

KI erweitert die Angriffsfläche – und verlangt nach einer Sicherheitslogik, die über klassische DevSecOps-Modelle hinausgeht. Entscheidend ist nicht die Anzahl einzelner Kontrollen, sondern eine strukturierte Bewertung der Risiken, eine klare Priorisierung und die konsequente Integration von Sicherheitsmechanismen entlang des gesamten ML-Lebenszyklus. Nur so wird KI steuerbar, auditierbar und nachhaltig resilient. Ist Ihre Innovation nicht zu wertvoll, um sie Cyberangriffen schutzlos auszusetzen?

Lassen Sie uns gemeinsam für die Sicherheit Ihrer Kronjuwelen sorgen und eine fundierte, nachvollziehbare Einschätzung erstellen.

• Analyse laufender KI-Initiativen

• Identifikation konkreter Risikotreiber

• Definition einer gezielten Erweiterung von DevSecOps um KI-spezifische Sicherheitsmechanismen

Gemeinsam ordnen wir Ihre KI-Sicherheitsanforderungen ein und definieren die nächsten Schritte zu einem individuellen Massnahmenpaket.

Quellenverzeichnis
•    NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
•    MITRE ATLAS: https://atlas.mitre.org
•    CRISP-ML(Q): https://arxiv.org/pdf/2003.05155.pdf
•    Cloud Security Alliance AI Controls Matrix: https://cloudsecurityalliance.org/artifacts/ai-controls-matrix
•    EU AI Act: Regulation 2024/1689
•    ISO/IEC 23894:2023 - AI Risk Management
•    ISO/IEC 42001:2023 - AI Management Systems

Bildlegende: mit KI generiertes Bild