Wenn IT- und Sicherheitsverantwortliche in Unternehmen die Einführung von KI-gestützten statischen Anwendungssicherheitstests (SAST) prüfen, verlagert sich der Diskurs rasch von der Scan-Geschwindigkeit auf den Schutz des geistigen Eigentums (IP). Chief Information Security Officers (CISOs), AppSec-Experten und Compliance-Beauftragte stellen dabei dieselben grundlegenden Fragen: Wird unser geschützter Quellcode beim Upload in eine Cloud-Engine zum Trainieren öffentlicher KI-Modelle verwendet? Könnte unsere unternehmenseigene Geschäftslogik in den Codevorschlägen von Wettbewerbern wieder auftauchen? Und wie lange verbleiben vertrauliche Codefragmente in der Cloud-Infrastruktur des Anbieters?
Snyk DeepCode AI begegnet diesen Risiken mit einer Sicherheits- und Datenschutzarchitektur, die statische Codeanalyse und KI-Modelltraining technisch strikt voneinander trennt. Snyk garantiert eine verbindliche Zero-Training-Richtlinie (Zero-Training Policy), flankiert von einer hybriden KI-Engine, ephemerem Caching mit minimalen Speicherzyklen, unternehmensweiter Mandantenisolierung und unabhängigen Zertifizierungen.
Die hybride KI-Architektur: Deterministische Logik versus generative Behebung
Ein verbreitetes Missverständnis besteht in der Annahme, Snyk DeepCode AI verhalte sich wie ein herkömmliches generatives Sprachmodell (LLM), das vollständige Repositories unkontrolliert in neuronale Netze einspeist. Tatsächlich nutzt DeepCode AI einen hybriden Ansatz, der die Entdeckung von Sicherheitslücken strikt von deren automatisierter Behebung trennt.
+-------------------------------------------------------------------------------+
| Proprietäre Codebasis des Kunden |
+-------------------------------------------------------------------------------+
|
[ TLS 1.2+ / Snyk Broker / Filterung via .dcignore ]
v
+-------------------------------------------------------------------------------+
| DeepCode AI Analyse-Pipeline |
| |
| +-----------------------------------------------------------------------+ |
| | 1. Symbolische KI-Engine (Deterministisches SAST) | |
| | - AST-Erzeugung, prozedurübergreifende Taint- und Datenflussanalyse| |
| | - Formale Datalog-Logikregeln zur Schwachstellenprüfung | |
| | - Kein neuronales Training; rein algorithmische Verifikation | |
| +-----------------------------------------------------------------------+ |
| | |
| Exakte Koordinaten |
| und CWE-Schwachstelle |
| v |
| +-----------------------------------------------------------------------+ |
| | 2. Generative Behebungs-Engine (Snyk Agent Fix) | |
| | - Dynamic Few-Shot Prompting (Über 35.000 kuratierte Experten-Fixes)| |
| | - Streng eingegrenzter Snippet-Kontext (Keine Repository-Freigabe) | |
| | - Anbindung über Enterprise-APIs mit Zero Data Retention (ZDR) | |
| +-----------------------------------------------------------------------+ |
| | |
| Vorgeschlagener Patch |
| v |
| +-----------------------------------------------------------------------+ |
| | 3. Verifikations- und Agenten-Wiederholungsschleife | |
| | - Symbolische Engine überprüft den generierten Code erneut | |
| | - Stellt sicher, dass der Fehler behoben ist und keine neuen Flaws | |
| | entstehen; bei Fehlschlag keine Ausspielung an den Entwickler | |
| +-----------------------------------------------------------------------+ |
+-------------------------------------------------------------------------------+
|
[ Cache-Ablauf: AWS 24–48 Std. / GCP 24 Std. ]
v
+-------------------------------------------------------------------------------+
| Dauerhaft gespeicherte Metadaten |
| Ausschließlich: Dateipfade, Zeilen-/Spaltenkoordinaten, IDs & CWE |
| (Quellcode vollständig aus Speicher, Netzwerk & Logs gelöscht) |
+-------------------------------------------------------------------------------+
1. Symbolische KI zur Schwachstellenerkennung
Der Kern von Snyk Code basiert auf symbolischer KI (Symbolic AI) und nicht auf generativen neuronalen Netzen. Symbolische KI nutzt formale Logik, abstrakte Syntaxbäume (AST) sowie Kontroll- und Datenflussgraphen, um Pfade von nicht vertrauenswürdigen Quellen (Sources) zu kritischen Senken (Sinks) mathematisch exakt zu berechnen.
Da symbolische KI auf deterministischen Regelsätzen und Logik-Solvern aufbaut, die von Snyks Sicherheitsforschern definiert wurden, muss das System nicht aus dem Kundencode "lernen". Die Engine führt reproduzierbare Prüfungen auf den Code-Strukturen durch, wodurch Halluzinationen ausgeschlossen sind, Falsch-Positiv-Raten minimiert werden und keine Kundendaten in Trainingsgewichte einfließen.
2. Generative KI für Snyk Agent Fix
Generative Modelle kommen erst ins Spiel, wenn Entwickler aktiv einen automatisierten Lösungsvorschlag über Snyk Agent Fix (vormals DeepCode AI Fix) anfordern. Statt Modelle auf privaten Repositories feinzutunen (Fine-Tuning), verwendet Snyk eine agentische Architektur mit dynamischem Few-Shot-Prompting:
- Kuratierte Wissensdatenbank: Das System greift auf eine proprietäre Datenbank mit über 35.000 verifizierten Fehlerbehebungen zurück, die aus permissiv lizenzierten Open-Source-Projekten stammen.
- Kontextminimierung: Es wird lediglich der unmittelbare Funktionsausschnitt rund um die Schwachstelle zusammen mit den relevanten CWE-Metadaten an das Modell übergeben.
- Symbolische Verifikationsschleife: Sobald das generative Modell einen Patch generiert, scannt die symbolische KI den modifizierten Code erneut. Ist die Schwachstelle nicht behoben oder entsteht ein neuer Fehler, wiederholt der Agent den Vorgang. Kann kein verifizierter Fix erzeugt werden, erhält der Entwickler keinen Vorschlag.
Die Zero-Training-Richtlinie und Grenzen des Pre-Trainings
Für Rechts- und Compliance-Abteilungen sind klare vertragliche und technische Grenzen essenziell. Die Richtlinie von Snyk ist eindeutig formuliert: Proprietärer Kundenquellcode wird unter keinen Umständen zum Trainieren, Verfeinern, Optimieren oder Evaluieren von KI-Modellen verwendet und dient niemals als Beispielfundus für andere Kunden.
Datenquellen für das Pre-Training von DeepCode AI
Um eine Kontamination durch fremdes geistiges Eigentum auszuschließen, setzt Snyk strikte Grenzen für den Trainingskorpus:
- Ausschließlich permissive Open-Source-Lizenzen: Modelle und Heuristiken werden ausschließlich anhand öffentlicher Repositories trainiert, die unter anerkannten permissiven Lizenzen stehen (z. B. MIT, Apache 2.0, BSD).
- Lizenzüberwachung und Ausschluss: Snyk überwacht Lizenzänderungen in Open-Source-Quellen kontinuierlich. Wechselt ein Projekt zu einer Copyleft- oder restriktiven Lizenz (wie der GPL-Familie), werden alle zugehörigen Daten unverzüglich aus den Trainingspipelines entfernt.
- Validierung durch Sicherheitsexperten: Alle Vorlagen und Regeln durchlaufen automatisierte Testverfahren sowie manuelle Prüfungen durch Snyk-Sicherheitsanalysten.
Code-Aufnahme und minimaler Lebenszyklus im ephemeren Cache
Sobald ein Scan über Git-Integrationen, CLI-Befehle oder IDE-Erweiterungen initiiert wird, muss der Quellcode analysiert werden. Der zeitliche Verbleib im Speicher ist ein entscheidender Faktor für die Sicherheitsbewertung.
Schutzmaßnahmen an der Zugriffsgrenze
Snyk lädt Codebestände nicht wahllos hoch:
- Ausschlüsse beachten: Snyk verarbeitet
.gitignore-,.dcignore- und.snyk-Dateien strikt. Nicht verfolgte Dateien und lokale Testdaten werden bereits am Client blockiert. - Größen- und Formatfilter: Snyk Code beschränkt sich auf unterstützte Programmiersprachen und verwirft Binärdateien sowie Dateien, die 4 MB überschreiten.
- Kurzlebige flache Klone: Bei SCM-Integrationen führt Snyk lediglich flache (shallow) Klone mit minimaler Tiefe durch. Diese werden unmittelbar nach Befüllung des Caches vom Dateisystem gelöscht.
Speicherfristen des ephemeren Caches
Um schnelle Deltascans bei aufeinanderfolgenden Commits zu ermöglichen, werden geparste Coderepräsentationen temporär im Cloud-Cache zwischengespeichert. Die Speicherdauer richtet sich nach den kürzestmöglichen Lifecycle-Richtlinien der Cloud-Infrastruktur-Provider:
| Cloud-Infrastruktur | Mandant und Region | Maximale Cache-Vorhaltezeit | Status nach Ablauf |
|---|---|---|---|
| Amazon Web Services (AWS) | EU / AU / Private Mandanten | 24 bis 48 Stunden (Kürzeste S3-Lifecycle-Regel) | Quellcode vollständig gelöscht |
| Google Cloud Platform (GCP) | USA (Standardmandant) | 24 Stunden (Kürzeste Cloud-Storage-Regel) | Quellcode vollständig gelöscht |
Welche Daten bleiben dauerhaft gespeichert?
Nach Ablauf des ephemeren Caches ist der eigentliche Quellcode vollständig aus den Speichersystemen, Netzwerken und Logs von Snyk getilgt. Persistent gespeichert werden ausschließlich strukturelle Positionsdaten, die für das Dashboard erforderlich sind:
- Relative Dateipfade, Zeilen- und Spaltennummern.
- Eindeutige Issue-IDs, Schweregrade und CWE-Klassifizierungen.
- Namen von Datenflussknoten (Funktions- und Variablennamen zur Visualisierung des Datenflusses).
Da der Quellcode nicht in der Snyk-Cloud verbleibt, lädt die Snyk-Weboberfläche den Code dynamisch über das angebundene Versionskontrollsystem des Kunden nach, sobald ein autorisierter Benutzer die Schwachstellendetails aufruft.
Governance externer LLM-Subprozessoren
Wenn Snyk Agent Fix externe Sprachmodelle (über AWS Bedrock, GCP Vertex oder Unternehmenskontrakte mit OpenAI und Anthropic) hinzuzieht, greifen zusätzliche Schutzmechanismen:
- Zero Data Retention (ZDR): Snyk schließt vertraglich bindende Vereinbarungen ab, die den Modellbetreibern das Logging, die persistente Speicherung auf Festplatten sowie die manuelle Überprüfung von Eingaben und Ausgaben untersagen.
- Modelltraining ausgeschlossen: Drittanbieter sind vertraglich verpflichtet, über die Snyk-Schnittstelle empfangene Daten nicht zum Trainieren oder Verbessern eigener Modelle zu nutzen.
- Minimale Nutzlasten: An externe Schnittstellen wird nur der konkrete Codeausschnitt der fehlerhaften Funktion übermittelt, niemals das gesamte Projekt.
Mandantenisolierung und Bereitstellungsmodelle für Unternehmen
Um unterschiedlichen regulatorischen Vorgaben gerecht zu werden, unterstützt Snyk drei Bereitstellungsarchitekturen:
[ Entwickler-Workstation / Lokale CI/CD ]
|
v
+--------------------------------------------------------------+
| Unternehmensperimeter |
| |
| +-----------------------+ +----------------------+ |
| | Internes SCM-System | <---> | Snyk Broker | |
| | (GitLab / GitHub Ent) | | (Verschlüsselter | |
| | | | Perimeter-Proxy) | |
| +-----------------------+ +----------------------+ |
+----------------------------------------------|---------------+
| Ausgehende TLS 1.2+ WebSocket-Verbindung
v (Über strikte Whitelist gefiltert)
+--------------------------------------------------------------+
| Snyk Cloud-Plattform |
| |
| +------------------------------------------------------+ |
| | Multi-Tenant oder Single-Tenant SaaS | |
| | - Logische Mandantentrennung (RBAC und Token-Schutz) | |
| | - Regionale Datenhaltung: USA / EU / Australien | |
| | - SOC 2 Typ II und ISO 27001/27017 zertifiziert | |
| +------------------------------------------------------+ |
+--------------------------------------------------------------+
1. Multi-Tenant-SaaS
Das Standardmodell bietet kontinuierliche Regelupdates und erlaubt die Wahl des Datenstandorts (USA, EU, Australien). Die Trennung der Mandanten erfolgt über mehrschichtige Softwarekontrollen:
- Authentifizierungs- und Zugriffsgrenzen: Rollenbasierte Zugriffskontrollen (RBAC) isolieren Projektmetadaten und Scanergebnisse auf Datenbankebene.
- Verschlüsselungsstandards: Verbindung über TLS 1.2+ bei der Übertragung und AES-256-Verschlüsselung im Ruhezustand.
2. Single-Tenant-SaaS (Private Cloud)
Für Organisationen mit hohen Isolationsanforderungen (z. B. im Finanz- oder Behördensektor) stellt Snyk dedizierte Private-Cloud-Instanzen bereit, in denen Rechner- und Speicherressourcen vollständig von anderen Mandanten getrennt sind.
3. Snyk Broker: Schutz interner Quellcode-Verwaltungen
Für Unternehmen mit internen Versionskontrollsystemen (wie GitHub Enterprise Server, GitLab Self-Managed oder Bitbucket Server) fungiert Snyk Broker als Sicherheitsbarriere:
- Einsatz in der DMZ: Ein schlanker Open-Source-Container wird innerhalb des internen Firmennetzwerks betrieben.
- Nur ausgehende Verbindungen: Der Broker baut verschlüsselte WebSocket-Verbindungen zu Snyk Cloud auf, sodass keine eingehenden Ports in der Firewall geöffnet werden müssen.
- Zugangsdaten verbleiben intern: SCM-Tokens und SSH-Schlüssel verbleiben auf dem lokalen Server und gelangen niemals zu Snyk.
- Whitelist-Inspektion: Der Broker filtert sämtliche von Snyk initiierten Aufrufe und erlaubt ausschließlich vorab freigegebene Code- und Testoperationen.
(Hinweis: Die frühere On-Premises-Engine Snyk Code Local Engine wird nicht mehr für Neukunden angeboten und befindet sich in der Auslaufphase. Die empfohlene moderne Architektur kombiniert Snyk Broker mit Cloud- oder Single-Tenant-Instanzen.)
Unabhängige Prüfungen, Zertifizierungen und rechtliche Absicherung
Die Sicherheitsversprechen von Snyk werden durch regelmäßige Audits unabhängiger Dritter belegt:
- SOC 2 Typ II: Jährliche Prüfberichte bestätigen die operative Wirksamkeit der Kontrollen hinsichtlich Sicherheit, Vertraulichkeit und Verfügbarkeit.
- ISO/IEC 27001:2022 und ISO/IEC 27017:2015: Zertifizierte Standards für Informationssicherheits-Managementsysteme und Cloud-Sicherheitskontrollen.
- Datenschutzkonformität: Vollständige Ausrichtung an den Vorgaben der Datenschutz-Grundverordnung (DSGVO) und des California Consumer Privacy Act (CCPA).
- Rechtsverbindliche Verträge: Das Master Services Agreement (MSA) und das Data Processing Addendum (DPA) fixieren die Zusicherung, Kundencode nicht für Modelltrainings zu verwenden, als einklagbare Vertragspflicht.
Praktische Checkliste für Sicherheitsteams
Für eine vorschriftsmäßige Implementierung von Snyk DeepCode AI empfiehlt sich folgender Leitfaden:
- Ausschlussdateien pflegen: Legen Sie
.dcignore- und.snyk-Dateien im Repository-Root an, um Testdaten, vertrauliche Mocks und interne Konfigurationsdateien vom Scan auszuschließen. - Datenresidenz festlegen: Wählen Sie bei der Einrichtung der Snyk-Organisation bewusst die passende Hosting-Region (USA, EU oder Australien).
- Snyk Broker für interne SCMs nutzen: Verbinden Sie interne Repositories grundsätzlich über Snyk Broker mit aktiver Whitelist-Prüfung, statt Server direkt extern exponieren zu lassen.
- Vier-Augen-Prinzip beibehalten: Nutzen Sie Snyk Agent Fix als Empfehlungswerkzeug, bei dem jeder Patch vor dem Merge einem regulären Code-Review unterzogen wird.
- Auditreports regelmäßig anfordern: Laden Sie aktuelle SOC 2 Typ II-Berichte und ISO-Zertifikate über das Snyk Trust Center für interne Compliance-Nachweise herunter.
Durch das Zusammenspiel aus symbolischer statischer Analyse, minimaler Cache-Speicherung und vertraglich zugesicherten Zero-Training-Garantien ermöglicht Snyk DeepCode AI eine verlässliche Schwachstellenbehebung bei absolutem Schutz des geschäftskritischen Quellcodes.