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.
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.
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.
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.
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.
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.
Wir haben das DevSecOps-Modell, dem Sie bereits vertrauen, um drei Frameworks erweitert, die gut zusammenarbeiten:
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.
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.
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.
Angenommen, Sie entwickeln ein KI-System zur Betrugserkennung. Was passiert, wenn Sicherheitsmechanismen nicht von Anfang an integriert sind?
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».
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.
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.
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.
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.
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.
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.
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.
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.
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