Managed CNAPP: Cloud-native Sicherheitsabläufe auslagern

Managed CNAPP lagert den Betrieb Ihrer cloud-native Application Protection Platform an einen Anbieter aus. Sehen Sie sich die Servicemodelle an, wann eine Auslagerung sinnvoll ist und wie Sie einen Anbieter auswählen.

Was ist Managed CNAPP?

Managed CNAPP ist ein Servicemodell, bei dem ein Anbieter Ihre Cloud-native Application Protection Platform (CNAPP) und die zugehörigen Sicherheitsabläufe in Ihrem Auftrag betreibt. Die Plattform bleibt Ihre. Ebenso die Verantwortung. Was sich ändert, ist, wer die Überwachung personell besetzt.

Die Anforderungen an diese Überwachung sind inzwischen in der Bundespolitik festgeschrieben. Im Dezember 2024 ordnete CISA mit der Binding Operational Directive 25-01 an, dass zivile Bundesbehörden Cloud-Fehlkonfigurationen identifizieren und beheben sowie eine kontinuierliche Überwachung über ihre Cloud-Tenants hinweg durchführen müssen, nachdem fehlkonfigurierte Kontrollen Angreifern einen Weg zur Datenexfiltration eröffnet hatten. Kontinuierlich ist hier das entscheidende Wort. Dieses Maß an Abdeckung über jedes von Ihnen betriebene Konto hinweg aufrechtzuerhalten, ist eine Aufgabe, die nur wenige schlanke Teams rund um die Uhr personell besetzen können, und genau diese Lücke soll das Managed-Modell schließen.

Wie Managed CNAPP mit Cybersicherheit zusammenhängt

Cloud-native Sicherheit umfasst Konfiguration, Identität, Workloads und Kubernetes, und jede Ebene erzeugt rund um die Uhr Findings. 

Ein CNAPP führt diese Ebenen in einer Plattform zusammen. Das Managed-Modell stellt ein personell besetztes Team dahinter, sodass die Abdeckung auch nachts und an Wochenenden bestehen bleibt, wenn ein offener Storage-Bucket oder eine übermäßig berechtigte Rolle für einen Angreifer genauso erreichbar ist wie mittags. Der Anbieter betreibt die Abläufe, und im Rahmen des Shared-Responsibility-Modells bleibt Ihre Organisation für ihre Cloud-Sicherheitslage und die regulatorische Compliance verantwortlich.

Kernkomponenten eines Managed-CNAPP-Service

Ein Managed-CNAPP-Service besteht aus zwei Ebenen: der Plattform, die die Findings erzeugt, und den Menschen und Prozessen, die darauf reagieren.

Was das zugrunde liegende CNAPP abdeckt

Die Plattform konsolidiert vier Funktionen, von denen jede eine Ebene darstellt, die der Managed-Anbieter betreibt, damit Ihr Team Cloud-Risiken an einer Stelle lesen kann – vom Build bis zur Runtime:

• Cloud Security Posture Management (CSPM) erkennt Fehlkonfigurationen und Compliance-Verstöße in der gesamten Cloud-Infrastruktur, von offenen Storage-Buckets bis hin zu freizügigen Firewall-Regeln.
• Cloud Workload Protection (CWP) sichert Container, virtuelle Maschinen, serverlose Funktionen und Server zur Laufzeit in öffentlichen, privaten und hybriden Umgebungen.
• Cloud Infrastructure Entitlement Management (CIEM) analysiert Berechtigungen für menschliche und nicht-menschliche Identitäten, kennzeichnet übermäßige Privilegien und setzt Least-Privilege-Richtlinien durch.
• Kubernetes Security Posture Management (KSPM) führt Prüfungen auf Fehlkonfigurationen für Kubernetes-Cluster durch und validiert die Übereinstimmung mit Compliance-Anforderungen.

Zusammen beantworten sie vier konkrete Fragen zu Ihrer Cloud: welche Konfigurationen und Compliance-Kontrollen abgewichen sind (CSPM), welche laufenden Workloads angegriffen werden (CWP), welche menschlichen und nicht-menschlichen Identitäten mehr Zugriff haben, als sie benötigen (CIEM), und welche Kubernetes-Cluster fehlkonfiguriert sind (KSPM).

Die Plattform meldet diese Findings kontinuierlich, triagiert sie jedoch nicht, stuft sie nicht nach Ausnutzbarkeit ein und weist sie keinem Verantwortlichen zu. Genau diese Arbeit übernimmt der Managed Service.

Was der Managed Service hinzufügt

Zusätzlich zur lizenzierten Plattform stellt der Anbieter eine personell besetzte operative Ebene bereit, die sie im Tagesgeschäft betreibt:

Operative Ebene	Was der Anbieter tut
Kontinuierliches Posture Management	Verfolgt Konfigurationen und Compliance, während die Infrastruktur über verbundene Konten hinweg abweicht.
Behebung von Fehlkonfigurationen	Findet und priorisiert Probleme, leitet sie an das verantwortliche Team weiter und verfolgt sie bis zum Abschluss.
Vulnerability- und Entitlement-Management	Agentenloses Scannen über Betriebssysteme und Workloads hinweg, mit CIEM-Analyse überprivilegierter Identitäten.
Runtime-Bedrohungsreaktion	Agenten- oder sensorbasierter Schutz, der Workloads überwacht und aktive Angriffe während der Ausführung stoppt.
Analystenabdeckung	Triage, Filterung von False Positives, Eskalation bestätigter Findings und Reporting in festgelegter Taktung.

Die personelle Besetzung des Anbieters und definierte Abdeckungszeiten sind das, was der Service einer Plattform hinzufügt, die Sie andernfalls allein betreiben könnten. Ob es die richtige Entscheidung ist, sie allein zu betreiben, ist die nächste Frage.

Wie Managed CNAPP funktioniert

Der Managed-CNAPP-Service läuft als kontinuierlicher Kreislauf über sechs Phasen. Der Anbieter verantwortet die operativen Schritte. Ihr Team tritt an der Stelle in den Kreislauf ein, an der aus einem Finding Arbeit wird, auf die Sie reagieren müssen, sodass Sie genau wissen, wo die Verantwortung wieder auf Sie übergeht.

1. Onboarding und Integration. Der Anbieter verbindet sich mit Ihren Cloud-Konten über AWS, Azure, GCP und alle weiteren von Ihnen genutzten Anbieter hinweg. Eine vollständige Bereitstellung über alle Konten hinweg, einschließlich Entwicklerkonten, schafft die Ausgangsbasis, bevor das Tuning beginnt.
2. Agentenloses Scannen und Runtime-Abdeckung. Der Anbieter aktiviert zwei Ebenen der Transparenz. Agentenloses Scannen fragt die APIs der Cloud-Anbieter ab, um Konfigurationen, Berechtigungen und Schwachstellen zu bewerten, ohne Software auf Workloads zu installieren. Agenten- oder sensorbasierte Abdeckung ergänzt dies um Runtime-Schutz in Echtzeit für Kubernetes-Cluster und Workloads in Containern oder virtuellen Maschinen (VMs).
3. Kontinuierliche Überwachung. Das Scannen läuft kontinuierlich, sodass neue Konten, Workloads und Konfigurationsänderungen in die Abdeckung aufgenommen werden, sobald sie erscheinen. Das Bild von Posture und Schwachstellen bleibt zwischen den Prüfzeitpunkten aktuell.
4. Alert-Triage und Priorisierung. Der Anbieter filtert False Positives und stuft bestätigte Findings nach Ausnutzbarkeit und Exponierung ein, wobei die geschäftlichen Auswirkungen in die Einstufung einfließen.
5. Übergabe von Behebung und Incident Response. Der Anbieter leitet priorisierte Findings mit dem erforderlichen Kontext an das verantwortliche Team weiter. Der Anbieter verantwortet Erkennung, Triage und Weiterleitung. Ihr Team verantwortet die Umsetzung der Behebung.
6. Reporting. Der Anbieter liefert Reporting in einer definierten Taktung, wobei Sicherheitsmetriken mit Geschäftsergebnissen verknüpft werden.

Der Kreislauf endet nie. Die einzige Frage ist, wer ihn betreiben sollte: Ihr eigenes Team oder ein Anbieter. 

Wann Cloud-native Sicherheitsabläufe ausgelagert werden sollten

Die Entscheidung zwischen dem internen Betrieb von CNAPP-Abläufen und der Übergabe an einen Anbieter hängt von der personellen Besetzung Ihres Teams, seiner Expertise, Ihren Abdeckungsanforderungen und Ihrem Kontrollbedarf ab.

Bedingung	Spricht für Outsourcing	Spricht für Inhouse-Betrieb
Personalstärke im Bereich Cloud-Sicherheit	Schlankes Team mit begrenztem dediziertem Cloud-Sicherheitspersonal	Ausgereiftes SOC mit dedizierten Cloud-Sicherheitsingenieuren
Abdeckungszeiten	Kontinuierliche Abdeckung erforderlich, aktuelles Team deckt nur Geschäftszeiten ab	Bestehendes Follow-the-Sun- oder Schichtmodell bereits personell besetzt
Time-to-Value	Operative Abdeckung wird schnell benötigt	Zeit vorhanden, um intern aufzubauen und zu optimieren
Multi-Cloud-Komplexität	Mehrere Cloud-Anbieter, Kontenwildwuchs über Geschäftsbereiche hinweg	Single-Cloud- oder eng kontrollierte Dual-Cloud-Umgebung
Cloud-native Expertise	Team ist stark On-Premises, aber mit begrenzter Tiefe bei Kubernetes, Containern oder IAM	Tiefgehende bestehende Expertise über CSPM-, CWPP- und CIEM-Abläufe hinweg
Kontrollanforderungen	Bereitschaft, mit einem Anbieter eine Shared-Responsibility-Grenze zu definieren	Strenge Vorgaben zur Datenresidenz, regulatorische Einschränkungen für Drittzugriffe oder Richtlinien gegen das Outsourcing von Sicherheitsabläufen
Tool-Reifegrad	CNAPP kürzlich gekauft oder noch nicht operationalisiert	CNAPP vollständig bereitgestellt und optimiert, Team betreibt es effektiv

Drei Servicemodelle liegen entlang des Outsourcing-Spektrums:

• Self-managed CNAPP bedeutet, dass Sie die Plattform lizenzieren und intern betreiben. Ihre Analysten besetzen die Überwachung, optimieren die Findings, triagieren die Alerts und steuern die Behebung.
• Co-managed CNAPP bedeutet, dass der Anbieter die Plattform und operative Expertise bereitstellt und Onboarding, Tuning, Alert-Priorisierung und Eskalationsunterstützung übernimmt. Sie behalten die primäre Verantwortung für Untersuchungen und Entscheidungen zur Behebung.
• Fully managed CNAPP bedeutet, dass der Anbieter die operative Verantwortung für Überwachung, Triage, Untersuchung und Koordination der Behebung übernimmt. Sie behalten die Governance-Verantwortung und die Umsetzung der Behebung bei weitergeleiteten Findings.

Wo Sie auf diesem Spektrum landen, bestimmt, wofür Sie bezahlen und was weiterhin in Ihrer Verantwortung bleibt. Die nächste Frage ist, ob ein bestimmter Anbieter dies über Ihre gesamte Cloud-Landschaft hinweg leisten kann.

Was bei einem Managed-CNAPP-Anbieter zu bewerten ist

Ein Managed CNAPP-Anbieter wird anhand von zwei Kategorien beurteilt: den Service-Level-Zusagen, die das Engagement regeln, und der technischen Integration, die bestimmt, ob er Ihre Cloud-Landschaft abdecken kann.

SLA-Überlegungen

Ein messbares Service-Level-Agreement (SLA) definiert spezifische, zeitgebundene Zusagen. Ein vages SLA verspricht „schnelle Reaktion“, ohne zu sagen, was schnell bedeutet. Die Analyse von Cloud-SLAs durch MITRE stellte erhebliche Unterschiede darin fest, wie Leistungsniveaus definiert werden und wie Risiken zwischen Anbieter und Kunde aufgeteilt werden. Lesen Sie die Definitionen, nicht die Adjektive.

Wenn Sie SLAs bewerten, konzentrieren Sie sich auf die Zusagen, die operativen Risiken zugeordnet werden können:

• Reaktionszeit für bestätigte Findings und das On-Call-Eskalationsmodell
• Abdeckungszeiten und Bearbeitungszeit für Alert-Triage
• Umgangsrate mit False Positives und Geschwindigkeit der Weiterleitung zur Behebung
• Reporting-Taktung

Fordern Sie vertraglich bindende SLAs. Prüfen Sie, ob der Anbieter die SLA-Leistung transparent berichtet und was geschieht, wenn SLAs verfehlt werden.

Anforderungen an die Multi-Cloud-Integration

Ihr Anbieter muss sich mit jeder von Ihnen betriebenen Cloud-Umgebung verbinden können. Bewerten Sie das agentenlose Onboarding: wie schnell der Anbieter Ihre AWS-, Azure- und GCP-Konten anbinden und mit dem Scannen beginnen kann. Prüfen Sie, ob sich die Abdeckung auf weitere von Ihnen genutzte Cloud-Anbieter erstreckt. SentinelOne's Singularity™ Cloud deckt beispielsweise AWS, Azure, GCP, Oracle Cloud Infrastructure (OCI) und Alibaba Cloud über eine einzige Konsole ab.

Bewerten Sie die Container- und Kubernetes-Abdeckung: Deckt das zugrunde liegende CNAPP des Anbieters Ihre Kubernetes-Cluster, Container-Registries und serverlosen Funktionen ab? Prüfen Sie, welche Daten Ihre Umgebung verlassen, wo sie gespeichert werden und ob die Architektur des Anbieters Ihre regulatorischen Anforderungen erfüllt.

CIEM sollte die Bewertung und Behebung von Fehlkonfigurationen in Richtlinien für Identity and Access Management (IAM) abdecken.

Herausforderungen und Einschränkungen von Managed CNAPP

Das Outsourcing Cloud-nativer Sicherheitsabläufe bringt strukturelle Einschränkungen mit sich, die selbst dann bestehen bleiben, wenn das Engagement gut geführt wird.

1. Reduzierte direkte Transparenz. Ein Anbieter, der Ihr CNAPP betreibt, sitzt zwischen Ihrem Team und den Roh-Findings. Das Software Engineering Institute (SEI) der Carnegie Mellon dokumentiert dieses Risiko beim Cloud-Outsourcing: Organisationen verlieren Transparenz und Kontrolle über die Assets und Abläufe, die sie auslagern, und deren Wiederherstellung erfordert Überwachung und Analyse, die früher durch On-Premises-Netzwerkprotokollierung bereitgestellt wurden.
2. Unklarheit an der Verantwortungsgrenze. Das Shared-Responsibility-Modell greift auch hier: Der Managed-Anbieter arbeitet innerhalb Ihrer Verantwortungsebene, und Ihre Organisation bleibt gegenüber dem Cloud-Anbieter und Regulierungsbehörden rechenschaftspflichtig.
3. Abhängigkeit vom Anbieter und Lock-in. Nicht standardisierte Datenformate, proprietäre APIs und die Abhängigkeit von anbieterspezifischen Tools machen die Kosten und den Aufwand eines Anbieterwechsels höher als ursprünglich erwartet.
4. Der Anbieter als Lieferkettenrisiko. Einer dritten Partei operativen Zugriff auf Ihre Cloud-Umgebung zu gewähren, ist selbst ein zu steuerndes Risiko. Das NCSC des Vereinigten Königreichs weist darauf hin, dass unkontrollierter und unbeobachteter Drittzugriff ein Anti-Pattern ist: Wenn Sie Administration oder operative Funktionen auslagern, sind Sie darauf angewiesen, dass eine andere Organisation Ihr System sicher hält. Begrenzen Sie diesen Zugriff. Definieren Sie Umfangsgrenzen, überwachen Sie die Aktivitäten des Anbieters und überprüfen Sie dessen Personal, Prozesse und Technologie fortlaufend.
5. Latenz bei der Übergabe von Alert zu Aktion. Jedes Finding, das eine Aktion Ihres Teams erfordert, durchläuft den Triage- und Weiterleitungsprozess des Anbieters. Diese Übergabe kann die Behebung verzögern.
6. Abdeckungsverzug in sich schnell verändernden Umgebungen. Neue Konten und Workloads oder Services erscheinen zwischen Onboarding-Zyklen, und die Abdeckung eines Anbieters spiegelt die Umgebung so wider, wie sie beim letzten Integrationsprüfpunkt konfiguriert war.

Jeder dieser Punkte ist ein bekannter Fehlermodus. Bekannte Fehlermodi lassen sich gestalten. Die folgenden Praktiken schließen sie, bevor sie Sie etwas kosten.

Best Practices für Managed CNAPP

Die Engagements, die Bestand haben, teilen einige operative Gewohnheiten. Jede davonschließt einen Fehlermodus, der ausgelagerte Sicherheitsarbeit sonst ins Stocken bringt.

Definieren Sie die Shared-Responsibility-Grenze schriftlich, bevor der Anbieter auch nur ein einziges Finding weiterleitet. Wenn die Verantwortung für den Abschluss nicht nach Finding-Klasse zugewiesen ist, bleiben Ergebnisse ungelöst liegen, während jede Seite davon ausgeht, dass die andere zuständig ist. Dieselbe Klarheit schützt auch Ihre eigene Rechenschaftspflicht: Der Anbieter betreibt die Abläufe, und Ihre Organisation bleibt weiterhin für ihre Cloud-Sicherheitslage, regulatorische Compliance und die Umsetzung der Behebung verantwortlich.

Binden Sie den Anbieter in die Workflows ein, die Sie bereits nutzen. Ordnen Sie jeden Eskalationstyp einem internen Verantwortlichen innerhalb Ihrer bestehenden IR-Runbooks zu, damit Findings des Anbieters als strukturierte Reaktionsarbeit eingehen, die sich in Ihren Prozess einfügt. 

Behalten Sie außerdem Ihren eigenen Zugriff auf die CNAPP-Konsole und die Reporting-Ausgaben des Anbieters, damit Sie die Leistung des Anbieters unabhängig anhand seiner eigenen Zahlen validieren können. Steuern Sie den Rest des Engagements anhand von Kennzahlen, die Sie in festgelegter Taktung prüfen:

• Verfolgen Sie die vertraglich vereinbarten SLAs und überprüfen Sie sie nach einem definierten Zeitplan. Ein SLA, das niemand misst, hat kein operatives Gewicht.
• Verknüpfen Sie Reporting mit Geschäftsergebnissen, damit jede Überprüfung Sicherheitsmetriken mit der Arbeit verbindet, die sie schützen.
• Führen Sie Abdeckungsprüfungen gegen Ihre Live-Umgebung durch, einschließlich Entwicklerkonten, Staging-Umgebungen und neu bereitgestellten Cloud-Konten.

Die Auswahl nach Preis vor Abdeckung ist eine teure Abkürzung: Ein kostengünstigerer Anbieter, der nur einen Teil Ihrer Umgebung überwacht, lässt den Rest unbeobachtet.

Managed CNAPP mit SentinelOne verbessern

Singularity Cloud Security ist SentinelOne's CNAPP. Es arbeitet von der Build-Zeit bis zur Runtime mit agentenlosem Posture Management und Workload-Schutz in Echtzeit über Cloud-Konten, Container, Kubernetes, KI-Services und serverlose Umgebungen hinweg. Eine Konsole deckt AWS, Azure, GCP, OCI und Alibaba Cloud über eine einzige Konsole ab. 

Die agentenlose Ebene, Singularity Cloud Native Security, bestätigt über Verified Exploit Paths, welche Findings tatsächlich ausnutzbar sind, sodass ein Anbieter hochwertige Findings an den richtigen Verantwortlichen weiterleitet und weniger Zeit mit Rauschen verbringt. Zur Runtime begrenzen automatische Reaktionsmaßnahmen, darunter das Beenden von Prozessen, Netzwerkisolierung, Dateiquarantäne und Pod-Trennung, Vorfälle, bevor ein Analyst eingreift. Die Singularity Platform vereinheitlicht Endpoint-, Cloud- und Identitätstelemetrie in einem Agenten, einer Konsole und einem Data Lake. Sie verzeichnete 88 % weniger Alerts in den 2024 MITRE ATT&CK® Evaluations bei 100 % Identifikation.

Mit Purple AI™ verkürzen Bedrohungssuche in natürlicher Sprache und agentische Untersuchungen die Zeit, die Analysten für das Sammeln von Belegen aufwenden. IDC's Snapshot vom April 2025 schreibt dem 63 % schnellere Bedrohungsidentifikation und 55 % schnellere Behebung zu. Ein Anbieter kann all dies in Ihrem Auftrag betreiben. Ein schlankes internes Team kann es direkt betreiben.

Buchen Sie eine SentinelOne-Demo, um zu sehen, was Singularity Cloud Ihrem Team abnimmt.

Wichtige Erkenntnisse

Managed CNAPP überträgt die operative Last des Betriebs einer Cloud-native Application Protection Platform an einen Anbieter, der Überwachung, Triage und Weiterleitung zur Behebung in Ihrem Auftrag personell besetzt. Die Entscheidung für Outsourcing hängt von der personellen Besetzung Ihres Teams, Ihrem Abdeckungsbedarf und der Komplexität Ihrer Cloud-Landschaft ab. 

Erfolgreiche Engagements beruhen auf einer klar definierten Verantwortungsgrenze, messbaren SLAs, Integration in Ihre Incident-Response-Workflows und fortlaufender Validierung der Abdeckung. Wenn diese vier Punkte stimmen, ist Outsourcing kein Kontrollverlust mehr. Sie setzen die Grenze, Sie behalten die Governance, und Sie sind nicht mehr die Person, die um 3 Uhr morgens Alerts triagiert.

FAQs

Was ist Managed CNAPP?

Managed CNAPP ist ein Servicemodell, bei dem ein Anbieter eine Cloud-native Application Protection Platform in Ihrem Auftrag betreibt. Der Anbieter übernimmt das kontinuierliche Posture Management, die Behebung von Fehlkonfigurationen, die Alarm-Triage und die Reaktion auf Laufzeitbedrohungen in Ihren Cloud-Umgebungen. 

Sie behalten die Governance-Befugnis über Eskalationsentscheidungen und die Verantwortung für die Umsetzung von Abhilfemaßnahmen. Das Modell verlagert den operativen Aufwand für den Betrieb der CNAPP, einschließlich der Besetzung mit Analysten und der fortlaufenden Arbeit zur Abstimmung von Findings, auf externe Cloud-Sicherheitsspezialisten.

Wie wird Managed CNAPP bepreist?

Die Preisgestaltung richtet sich in der Regel nach der Größe der abgedeckten Umgebung: der Anzahl der verbundenen Cloud-Konten, geschützten Workloads oder gescannten Assets, häufig im Rahmen eines gestaffelten Abonnements. 

Auch die Abdeckungszeiten und die Servicetiefe beeinflussen den Preis, da kontinuierliche Abdeckung und vollständige Untersuchungen mehr kosten als Triage während der Geschäftszeiten. Bitten Sie einen Anbieter, den Preis den spezifischen Konten und Workloads zuzuordnen, die er überwachen wird, damit das Angebot Ihre tatsächliche Umgebung widerspiegelt.

Wie lange dauert das Onboarding für Managed CNAPP?

Die agentenlose Verbindung zu Cloud-Konten über Provider-APIs stellt innerhalb weniger Stunden Transparenz über Sicherheitsstatus und Berechtigungen her, da keine Software auf Workloads installiert werden muss. Die Runtime-Abdeckung für Kubernetes sowie Container- oder VM-Workloads erfordert die Einführung eines Agenten oder Sensors. 

Der längere Aufwand liegt in der Feinabstimmung: dem Filtern von False Positives und dem Zuordnen von Eskalationen zu Ihren Verantwortlichen, was sich in den ersten Wochen einpendelt. Die vollständige Abdeckung hängt davon ab, dass jedes Konto angebunden wird, einschließlich Entwickler- und Staging-Umgebungen.

Wie gehen Managed CNAPP-Services mit Multi-Cloud-Umgebungen um?

Managed CNAPP-Anbieter verbinden sich über Cloud-Provider-APIs mit jeder Cloud-Umgebung. Der Managed CNAPP-Anbieter pflegt eine einheitliche Sicht auf Sicherheitsstatus, Berechtigungen und Workload-Schutz über alle verbundenen Konten hinweg. 

Die CIEM-Analyse erstreckt sich über Identitätsmodelle verschiedener Anbieter hinweg und kennzeichnet inkonsistente Vertrauensgrenzen sowie übermäßige Berechtigungen. Abdeckungsprüfungen sollten regelmäßig durchgeführt werden, um zu bestätigen, dass der Überwachungsumfang des Anbieters mit neuen Konten und Workloads in allen Regionen Schritt hält.

Ersetzt Managed CNAPP Ihr internes Sicherheitsteam?

Nein. Ein Managed CNAPP-Anbieter übernimmt den täglichen Betrieb Ihrer Cloud-Native Application Protection Platform, einschließlich Überwachung, Triage und Weiterleitung von Findings, während Ihre Organisation die Governance-Verantwortung behält und die Durchführung der Behebung verantwortet. Sie bleiben für Ihre Cloud-Sicherheit Sicherheitslage und die Einhaltung regulatorischer Anforderungen verantwortlich. 

Das Modell erweitert ein schlankes Team um operative Kapazität und Cloud-native Expertise und belässt die Verantwortung für Sicherheitsergebnisse innerhalb Ihrer Organisation.