Anthropic hat gerade Claude Code Security vorgestellt. Darum sind das großartige Neuigkeiten für die Branche
Artikel von
0 Min. Lesezeit
TL;DR: Keine Panik – das neue Produkt Claude Code Security bestätigt eindeutig die Richtung, in die sich die Branche entwickelt. Es ist ein starkes Signal, das die Bedeutung von Application Security unterstreicht. Wenn Sie einen umfassenderen Überblick möchten, sehen Sie sich den Beitrag meines Kollegen an. Dieser Beitrag geht etwas mehr in die Tiefe.
Anthropic hat Claude Code Security angekündigt, eine neue, in Claude Code integrierte Funktion, die KI nutzt, um Codebasen auf Sicherheitslücken zu untersuchen und Patches vorzuschlagen. Wenn Sie die Entwicklungen in der Security-Branche in letzter Zeit verfolgt haben, kennen Sie die Reaktionen wahrscheinlich bereits. Cybersecurity-Aktien stürzen ab. Kommentatoren erklären, dies sei der Anfang vom Ende für Security-Anbieter. Ein besonders viral gegangener Tweet behauptete, Anthropic habe gerade der gesamten AppSec-Branche das Mittagessen weggegessen.
Und verstehen Sie mich nicht falsch: Ich kann die Begeisterung nachvollziehen. Die Demo ist beeindruckend. Opus 4.6 hat in Open-Source-Codebasen mehr als 500 bisher unbekannte Zero-Day-Schwachstellen gefunden – darunter Fehler, die trotz Expertenprüfungen jahrzehntelang unentdeckt geblieben waren. Allein in der CGIF-Bibliothek entdeckte Claude einen Heap-Buffer-Overflow, indem es den LZW-Kompressionsalgorithmus analysierte. Das hätte herkömmliches, Coverage-gesteuertes Fuzzing selbst bei 100 % Codeabdeckung nicht aufgespürt. Das ist eine beachtliche Fähigkeit.
Doch genau das ist der Punkt: Bei den zugespitzten Reaktionen wird der Wald vor lauter Bäumen nicht gesehen. Die eigentliche Geschichte ist vielschichtiger und interessanter als „KI ersetzt Security-Tools“.
Was in den Reaktionen übersehen wurde – und was die Architektur bestätigt
Die vorherrschende Erzählung scheint zu lauten: „Anthropic hat eine KI entwickelt, die Sicherheitslücken findet, also sind herkömmliche Security-Tools überflüssig.“ Das ist ungefähr so, als würde man sagen: „Wir haben einen richtig guten Rauchmelder entwickelt, also sind Feuerwehren überflüssig.“
Sicherheitslücken zu finden, ist wichtig. Aber das ist nicht der schwierige Teil.
Ich sage es noch einmal für alle, die weiter hinten sitzen: Sicherheitslücken zu finden, war noch nie der schwierige Teil.
Der schwierige Teil – der Teil, der AppSec-Teams nachts wach hält, mehrjährige Rückstände verursacht und zu Gesprächen wie „Das nehmen wir im nächsten Sprint in Angriff“ führt – ist, die Lücken zu beheben. Und zwar in großem Umfang. Über Hunderte von Repositories hinweg. Ohne etwas kaputt zu machen. Während Entwicklerinnen und Entwickler in rasantem Tempo neue Funktionen veröffentlichen. In Code, den sie nicht selbst geschrieben haben, mit Bibliotheken, die sie nicht ausgewählt haben, und in Programmiersprachen, mit denen sie möglicherweise nicht vertraut sind.
Wenn Sie schon einmal in einem Security-Team gearbeitet haben, wissen Sie genau, was ich meine. Der Ablauf sieht ungefähr so aus:
Security-Tool findet eine Sicherheitslücke
Security-Team bewertet und priorisiert den Fund
Security-Team erstellt ein Ticket und weist es einer Entwicklerin oder einem Entwickler zu
Entwicklerin oder Entwickler sieht sich das Ticket drei Sprints später an
Entwicklerin oder Entwickler versucht, die Sicherheitslücke und ihren Kontext zu verstehen
Entwicklerin oder Entwickler versucht, das Problem zu beheben, und verursacht dabei möglicherweise ein neues
Security-Team scannt erneut – und der Kreislauf beginnt von vorn
Dieser Kreislauf führt zum Burnout bei AppSec-Fachleuten und frustriert Entwicklerinnen und Entwickler. Und noch so viel besseres Scanning – ob KI-gestützt oder nicht – durchbricht diesen grundlegenden Kreislauf nicht. Die Arbeit landet letztendlich weiterhin auf dem Schreibtisch eines Entwicklers oder einer Entwicklerin.
Claude Code Security scheint eine ziemlich coole Technologie zu sein. Doch es ist ein Scan- und Erkennungstool – es findet Probleme und schlägt Patches vor. Das ist zweifellos wertvoll. Aber die Frage, die sich alle Senior Engineers und AppSec-Fachleute stellen sollten, lautet: Was passiert nach dem Scan?
Die Ironie, über die niemand spricht
Ein Teil der Diskussion fehlt in den zugespitzten Reaktionen auffallend oft: Dieselben KI-Modelle, die Sicherheitslücken finden, verursachen sie auch.
Die Daten dazu sind ernüchternd. BaxBench, ein Benchmark von ETH Zürich, UC Berkeley und INSAIT, der LLMs anhand sicherheitskritischer Backend-Programmieraufgaben bewertet, ergab, dass 62 % der von selbst den besten Modellen generierten Lösungen entweder fehlerhaft sind oder Sicherheitslücken enthalten. Anthropics eigenes Claude Opus 4.5, das leistungsstärkste Modell, erzeugte nur in 56 % der Fälle sicheren und korrekten Code – und das ohne gezielte Security-Prompts.
Eine Analyse von CodeRabbit zeichnet ein ähnliches Bild: Von KI generierter Code führt 2,74-mal häufiger zu XSS-Schwachstellen, 1,91-mal häufiger zu unsicheren Objektreferenzen und weist insgesamt 1,57-mal häufiger Sicherheitsprobleme auf als von Menschen geschriebener Code.
Denken wir kurz darüber nach. KI-Modelle können 500 Zero-Day-Schwachstellen in Open-Source-Code finden. Gleichzeitig verursachen KI-Modelle in fast der Hälfte des von ihnen generierten Codes Sicherheitslücken. Dieselbe Technologie ist sowohl Teil des Problems als auch Teil der Lösung. Das ist kein Widerspruch, sondern schlicht die Realität, in der wir uns befinden. Und das bedeutet, dass jede ernst zu nehmende Security-Strategie beide Seiten dieser Gleichung berücksichtigen muss.
Sie können sich nicht einfach aus einem Problem herausscannen, das Ihre Tools gleichzeitig selbst verursachen. Sie brauchen ein System, das Sicherheitslücken bereits bei ihrer Entstehung verhindert, durchgerutschte Lücken erkennt, sie automatisch behebt und den gesamten Prozess unternehmensweit steuert. Das ist kein Scanner. Das ist eine Plattform.
Wie die Architektur tatsächlich aussehen muss
Sehen wir uns an, wie Security-Tools in moderne Entwicklungsabläufe passen, denn bei der Architektur liegt die eigentliche Erkenntnis.
In einer typischen Unternehmensumgebung sieht Ihre Security-Infrastruktur heute ungefähr so aus:
Der Engpass lag schon immer ab Schritt 6. Hier geht die Geschwindigkeit verloren. Hier steigt die mittlere Zeit bis zur Behebung (MTTR) von Stunden auf Wochen und schließlich Monate. Und da KI-gestütztes Programmieren die Zahl der Pull Requests pro Autor um 20 % erhöht (Engineering-Benchmark 2026 von Cortex), wächst der Rückstand schneller als je zuvor. Mehr Code bedeutet mehr Fehler. Mehr Fehler bei gleich vielen (oder weniger) Security Engineers bedeuten eine immer längere Warteschlange.
Doch hier liegt Anthropics Ankündigung richtig, auch wenn die Reaktion des Marktes das übersieht: KI gehört in den Behebungsprozess, nicht nur in den Erkennungsprozess. Der Durchbruch besteht nicht darin, dass „KI Sicherheitslücken finden kann“ – gute Scanner tun das schon seit Jahren. Der Durchbruch ist: „KI kann Code so gut analysieren, dass sie Sicherheitslücken beheben kann.“ Genau auf dieser These bauen wir bei Snyk auf.
Die beste Security verbindet KI mit deterministischer Analyse
Bevor ich darauf eingehe, was wir entwickelt haben, möchte ich eines klarstellen: Hier geht es nicht um ein „Entweder deterministisch oder KI“. Diese Gegenüberstellung verfehlt den eigentlichen Punkt völlig.
KI-gestütztes, umfassendes Schlussfolgern ist bei bestimmten Aufgaben unglaublich leistungsfähig. Die Zero-Day-Entdeckungen mit Opus 4.6 beweisen das. Einen Heap-Buffer-Overflow aufzuspüren, indem man die LZW-Kompression auf konzeptioneller Ebene versteht? Dafür braucht es ein ganzheitliches Verständnis von Code, das kein herkömmlicher Scanner erreichen kann. Komplexe Fehler in der Geschäftslogik, mangelhafte Zugriffskontrollen und Authentifizierungsumgehungen, die mehrere Dateien umfassen – in diesen Bereichen spielt KI-gestütztes Schlussfolgern seine Stärken tatsächlich aus.
Doch KI-gestütztes Schlussfolgern hat auch gut dokumentierte Grenzen. Es kann halluzinieren und mit großer Überzeugung eine „kritische SQL-Injection“ in einer parametrisierten Abfrage melden, die völlig sicher ist, weil das Modell den Datenfluss falsch interpretiert hat. Es kann offensichtliche Probleme übersehen, weil die Aufmerksamkeit bei einer großen Codebasis nachlässt oder das Kontextfenster während der Analyse ausgeschöpft ist. Im Security-Kontext sind beide Fehlerarten kostspielig: Falschmeldungen untergraben das Vertrauen der Entwicklerinnen und Entwickler, bis diese die Funde ignorieren, und übersehene Sicherheitslücken gelangen in die Produktion.
Bei der deterministischen Analyse – Datenflussanalyse, Taint-Tracking, symbolischer Ausführung und Musterabgleich mit kuratierten Schwachstellendatenbanken – ist es genau umgekehrt. Damit werden keine neuartigen Zero-Day-Schwachstellen entdeckt. Wenn die Analyse jedoch eine SQL-Injection in Zeile 47 Ihrer UserController.java meldet, ist dieser Fund durch einen konkreten Datenfluss vom Ursprung bis zur Senke belegt. Er ist reproduzierbar, nachvollziehbar und überprüfbar. Die hohe Verlässlichkeit ergibt sich daraus, dass die Analyse mechanisch statt probabilistisch erfolgt.
Und hier ist etwas, das vielen nicht klar ist: Bei Snyk verfolgen diese beiden Ansätze keine getrennten Wege. Unsere Security-Research-Teams setzen generative KI aktiv ein, um neue Schwachstellenmuster zu entdecken. Wenn sie etwas Reales finden, wandeln sie den Fund in eine deterministische Erkennungsregel um, die auf der gesamten Plattform ausgerollt wird. So wird die neuartige, kreative Entdeckungskraft der KI in schnelle, zuverlässige und kostengünstige Erkennungsverfahren übertragen, von denen alle Snyk-Kunden automatisch profitieren. Sie erhalten die Erkenntnisse aus der KI-Forschung, ohne bei jedem einzelnen Scan für Rechenleistung aufkommen oder das Risiko von Halluzinationen eingehen zu müssen. Das Beste aus beiden Welten: KI übernimmt einmalig die schwierige Entdeckungsarbeit, und die deterministische Analyse erfasst dasselbe Muster von da an zuverlässig und in großem Umfang in jeder Codebasis, die wir schützen.
Die richtige Antwort ist nicht, sich für einen der beiden Ansätze zu entscheiden. Die richtige Antwort ist, sie miteinander zu kombinieren. Nutzen Sie KI-gestütztes Schlussfolgern dort, wo es besonders leistungsfähig ist: bei der Entdeckung neuartiger Sicherheitslücken, komplexen Logikfehlern und dateiübergreifenden Analysen. Nutzen Sie deterministische Analyse dort, wo sie ihre Stärken hat: bei bekannten Schwachstellenmustern, Supply-Chain-Risiken und Compliance-kritischen Funden, für die ein prüfbarer Nachweis erforderlich ist. Und setzen Sie anschließend erneut KI für die Behebung ein, denn einen Fix auf Grundlage eines gut verstandenen, verlässlichen Fundes zu erstellen, ist genau die Art von Aufgabe, bei der LLMs glänzen.
Und hier schließt sich der Kreis: Die Kombination ist nicht nur für die Erkennung wichtig. Sie ist auch für die Behebung entscheidend. Wenn Claude Code Security einen Patch generiert, handelt es sich um KI-generierten Code. Und wir haben bereits gesehen, was bei KI-generiertem Code passiert: BaxBench beziffert die Unsicherheitsrate auf 62 %, Veracode auf 45 %. Eine KI findet also eine Sicherheitslücke und generiert anschließend einen Fix, der selbst mit einer Wahrscheinlichkeit von eins zu zwei eine neue Sicherheitslücke verursacht. Ohne einen deterministischen Validierungsschritt, der den vorgeschlagenen Fix vor dem Merge erneut scannt, spielen Sie in Ihrer eigenen Behebungspipeline ein endloses Katz-und-Maus-Spiel. Der mehrschichtige Ansatz – KI-gestütztes Schlussfolgern + deterministische Validierung + KI-gestützte Behebung + erneute deterministische Validierung – ist nicht bloß ein hübsches Architekturdiagramm. Nur so geht die Rechnung tatsächlich auf.
Diese Architektur funktioniert auch auf Unternehmensebene. Und genau das entwickeln wir.
Genau das macht Snyk (das Beste aus beiden Welten)
Wenn Sie verfolgt haben, was wir mit Snyk Studio entwickeln, wird Ihnen etwas auffallen: Die Architekturvision hinter Claude Code Security ähnelt stark dem, was wir bereits bereitstellen. Der Unterschied: Wir konzentrieren uns auf die gesamte Pipeline, nicht nur auf den Scan-Teil, und bauen auf einer Plattform auf, die deutlich mehr abdeckt als nur die Codeanalyse.
Snyk Studio: Security ohne Unterbrechungen
Snyk Studio integriert Security-Intelligenz direkt in die KI-Coding-Tools, die Entwicklerinnen und Entwickler bereits verwenden, darunter Claude Code, Cursor, Gemini CLI, Cline und weitere. Damit werden zwei wichtige Anwendungsfälle möglich:
Von Anfang an sicher – Wenn Entwicklerinnen und Entwickler mit einem KI-Coding-Assistenten Code schreiben, fangen die Guardrail-Anweisungen von Snyk Studio unsicheren Code automatisch ab, bevor die Entwicklerin oder der Entwickler den Vorschlag überhaupt annimmt. Der KI-Assistent führt für neuen Code snyk_code_scan aus und behebt alle gefundenen Sicherheitsprobleme direkt im Arbeitsablauf. Kein Ticket. Kein Kontextwechsel. Keine Verzögerung von drei Sprints. Angesichts dessen, was die BaxBench-Daten über die Sicherheit von KI-generiertem Code aussagen, ist das keine Option, sondern unverzichtbar.
Behebung in großem Maßstab – Für den Rückstand an bestehenden Sicherheitslücken bietet Snyk Studio Remediation Directives wie /snyk-fix. Damit wird der gesamte Ablauf aus Scannen, Triage, Beheben und Verifizieren zu einem einzigen Befehl:
Die Erkennung übernimmt hier Snyks deterministische Analyse-Engine: Sie liefert Ergebnisse mit hoher Konfidenz, auf deren Grundlage die KI-Behebung handeln kann, ohne sie erst hinterfragen zu müssen. Die Korrekturen generiert das LLM. So profitieren Sie von den Stärken beider Ansätze.
Über den Code hinaus: die gesamte Plattform
Der Vergleich mit Claude Code Security macht deutlich, dass das Scannen von Quellcode nur ein Teil eines viel größeren Puzzles ist. Ein Sicherheitsprogramm für Unternehmen mit einem Scanner zu betreiben, der nur ein Signal berücksichtigt – egal, wie intelligent er ist –, ist, als würde man einen Patienten nur mit einem Thermometer diagnostizieren.
Stellen Sie sich vor, Sie erhalten auf derselben Plattform Ergebnisse aus mehreren Scan-Typen. Ihre SAST-Engine meldet eine mögliche SQL-Injection in einer Controller-Methode. Ihre DAST-Engine bestätigt unabhängig davon, dass derselbe Endpunkt zur Laufzeit ausnutzbar ist. Ihre SCA-Engine erkennt, dass die von Ihnen verwendete ORM-Bibliothek eine bekannte CVE aufweist, die in bestimmten Ausnahmefällen ihre Parametrisierung umgeht. Jedes dieser Ergebnisse liefert für sich genommen eine Information. Werden sie auf derselben Plattform miteinander korreliert, zeigen sie Ihnen genau, was passiert, warum es passiert und was zuerst behoben werden sollte.
Das meinen wir, wenn wir von der AI Security Fabric sprechen: Sie ist kein einzelnes Tool und kein einzelner Scan-Typ, sondern ein adaptives System, das alle Sicherheitssignale entlang Ihrer gesamten Software-Lieferkette miteinander verknüpft. Snyk korreliert automatisch SAST- und DAST-Ergebnisse und verbindet ein auf Code-Ebene von Snyk Code erkanntes Problem mit einer von Snyk API & Web entdeckten Laufzeit-Sicherheitslücke. So lässt sich die genaue Codezeile ermitteln, die für eine ausnutzbare Schwachstelle verantwortlich ist. Das erreichen Sie nicht, indem Sie einzelne Tools zusammenfügen. Es ist ein architektonischer Vorteil, der daraus entsteht, dass SAST, SCA, Container-Scanning, Infrastructure-as-Code-Analyse, DAST und API-Sicherheit in dieselbe Fabric sowie dieselbe Priorisierungs- und Behebungs-Engine einfließen.
Hinzu kommt die Unternehmensebene, auf der Sicherheitsteams ihre Programme tatsächlich betreiben: zentrale Dashboards, die Risiken über Tausende von Repositories hinweg zusammenfassen, Policy-as-Code-Governance, CI/CD-Pipeline-Integration und Berichte, mit denen Ihr CISO die Frage „Wie hoch ist unser Risiko?“ und Ihr VP of Engineering die Frage „Entwickelt sich unsere MTTR in die richtige Richtung?“ beantworten kann – ohne sechs verschiedene Anbieter-Dashboards zusammenführen zu müssen. Ein Code-Scanner, selbst ein brillanter, beantwortet diese Fragen nicht. Eine Security Fabric schon.
Evo: Absicherung des KI-Stacks selbst
Und dann gibt es noch eine Sicherheitsdimension, die Claude Code Security überhaupt nicht abdeckt: die Absicherung Ihrer KI-Infrastruktur.
Evo by Snyk ist unser agentisches System zur Sicherheitsorchestrierung, das speziell für die KI-native Entwicklungslandschaft konzipiert wurde. Es umfasst KI-Bedrohungsmodellierung, die automatisch dynamische Bedrohungsmodelle auf Basis Ihres Codes erstellt und Risiken wie Prompt-Injection aufzeigt. Hinzu kommt AI Red Teaming, das Ihre Modelle und Agenten kontinuierlich adversarial testet, adaptive Angreifer simuliert und überprüfbare Nachweise erfolgreicher Exploits liefert. Außerdem umfasst es AI-SPM (Software-Posture-Management), damit Sie genau wissen, welche KI-Modelle, Datensätze, Frameworks und Tools in Ihrem Unternehmen eingesetzt werden – einschließlich der „Shadow AI“, von der Ihre Sicherheitsteams womöglich gar nichts wissen. Und Agent Scanning sorgt für Transparenz über alle Toolchains hinweg, etwa bei MCP-Servern und Skills in Entwicklungsumgebungen, mit Leitplanken in Echtzeit.
Im Januar 2026 entdeckte unser Forschungsteam Hunderte bösartige Skills auf ClawHub – den ersten großen Supply-Chain-Angriff auf Ökosysteme von KI-Agenten. Gegen eine solche Bedrohung hilft ein Scanner auf Code-Ebene nicht, egal, wie ausgefeilt er ist. Sie betrifft eine ganz andere Angriffsfläche und erfordert speziell dafür entwickelte Tools.
Das ist eine Bestätigung, keine Disruption
Hier ist meine ehrliche Einschätzung dazu, was die heutige Ankündigung für die Sicherheitsbranche bedeutet: Sie ist eine Bestätigung.
Anthropic, eines der am besten finanzierten und technisch versiertesten KI-Unternehmen der Welt, hat sich angesehen, was sich mit seinen Spitzenmodellen entwickeln lässt, und sich für ein Tool zum Scannen und Beheben von Sicherheitslücken entschieden. Das ist kein Zufall. Es zeigt, wohin sich die Branche entwickelt: hin zu KI-nativen, agentischen Sicherheits-Workflows, die direkt in Entwicklertools integriert sind.
Das ist dieselbe Grundidee, auf der Snyk Studio und die umfassendere Snyk-Plattform beruhen. Das Ziel ist nicht, ein besseres Dashboard für die Triage von Sicherheitslücken zu entwickeln. Es geht auch nicht darum, ansprechendere Berichte oder detailliertere Schweregrade zu erstellen. Das Ziel ist, so viele Sicherheitslücken wie möglich automatisch zu beheben, so früh wie möglich – direkt dort, wo sie entstehen, und ohne den Arbeitsfluss der Entwickler zu unterbrechen.
Nicht jeder Fehler lässt sich automatisch beheben. Manche erfordern Architekturänderungen, andere menschliches Urteilsvermögen bei Abwägungen zur Geschäftslogik. Aber die große Mehrheit der gängigen Sicherheitslücken, denen Ihr Team täglich begegnet? Für sie sollte es niemals ein Jira-Ticket und drei Sprints Wartezeit brauchen.
Das ist die ganze Vision.
Dass Anthropic in diesen Bereich investiert, bestätigt mir, dass wir am Richtigen arbeiten. Diese Tools ergänzen sich: Claude Code Security für die tiefgehende Erkennung neuartiger Zero-Day-Schwachstellen und Snyks Plattform für die umfassende Pipeline von der Prävention bis zur Behebung – mit deterministischer Analyse und KI, die Unternehmen für Sicherheitsprogramme in großem Maßstab benötigen.
Die Frage war nie: „Sollte KI in der Sicherheit zum Einsatz kommen?“ Die Frage lautete schon immer: „Wie lässt sich das zuverlässig, umfassend und für Unternehmen geeignet umsetzen?“ Die Antwort kombiniert KI-gestütztes Schlussfolgern und deterministische Analyse, integriert beides in Entwicklertools und stützt sich auf eine Plattform, die die gesamte Software-Lieferkette abdeckt – einschließlich der KI-Lieferkette selbst.
Was das für Sie bedeutet
Wenn Sie Senior Engineer oder AppSec-Fachkraft sind, hier mein praktischer Rat:
Der Ausverkauf von Cybersicherheitsaktien ist übertrieben. Der Markt reagiert auf Schlagzeilen, nicht auf die Architektur. Sicherheitslücken zu finden, ist ein notwendiger, aber nicht ausreichender Bestandteil eines Sicherheitsprogramms. Der eigentliche Mehrwert liegt im Behebungsprozess. Dafür braucht es eine tiefe Integration in Ihre vorhandenen Tools, eine vertrauenswürdige, mehrschichtige Erkennung und die Fähigkeit, im Unternehmensmaßstab zu arbeiten.
Probieren Sie Claude Code Security aus. Im Ernst: Wenn Sie Open-Source-Code betreuen oder an einem Projekt arbeiten, bei dem die Erkennung neuartiger Zero-Day-Schwachstellen wichtig ist, lohnt sich ein Blick auf die Research Preview. Was Opus 4.6 mit GhostScript und CGIF erreicht hat, ist wirklich innovativ.
Bauen Sie Ihr Sicherheitsprogramm aber auf einer Plattform auf, nicht auf einem einzelnen Tool. Für Ihre täglichen AppSec-Aufgaben benötigen Sie den gesamten Stack, um die Hunderte bekannter Muster von Sicherheitslücken, Supply-Chain-Risiken, Container-Fehlkonfigurationen, IaC-Abweichungen und die Governance von KI-Modellen abzudecken. Sie brauchen deterministische Erkennung und KI-gestütztes Schlussfolgern. Sie brauchen Prävention von Anfang an und automatisierte Behebung in großem Maßstab. Außerdem brauchen Sie Sicherheitsüberwachung, Dashboards und Enterprise-Governance. Und immer häufiger müssen Sie auch die KI-Tools selbst absichern.
Genau das leistet Snyk. Die Plattform nutzt dieselben KI-Coding-Assistenten, die Ihre Entwickler bereits verwenden, darunter Claude Code, und macht daraus sicherheitsbewusste Agenten, die Sicherheitslücken von Anfang an verhindern und bestehende in großem Maßstab beheben können. Und das alles auf einer Plattform, die Code, Abhängigkeiten, Container, Infrastruktur, APIs und den KI-Stack abdeckt.
Probieren Sie es selbst aus
Am einfachsten können Sie diese These prüfen, indem Sie es selbst ausprobieren. Snyk Studio ist kostenlos und in wenigen Minuten eingerichtet. So können Sie loslegen:
Wenn Sie Claude Code bereits verwenden (und nach der jüngsten Veröffentlichung von Anthropic ist das gut möglich), zeigt Ihnen die Integrationsanleitung für Claude Code, wie Sie Snyk Studio in Ihren bestehenden Workflow einbinden. In etwa fünf Minuten haben Sie deterministische Scans und den Behebungsbefehl /snyk-fix in Ihrem Terminal eingerichtet.
Wenn Sie wissen möchten, wie das Directive-System funktioniert, einschließlich der Secure-at-Inception-Leitplanken und der Remediation Directives, finden Sie in der Dokumentation zu Directives alle Einzelheiten. Die Directives sind anpassbar, sodass Sie sie auf den spezifischen Tech-Stack und die Risikotoleranz Ihres Teams abstimmen können.
Wenn Sie sich einen Gesamtüberblick über die Plattform verschaffen möchten, ist die Produktseite von Snyk Studio ein guter Ausgangspunkt. Für den Aspekt der KI-Sicherheit bietet Evo weitere Informationen.
Bei der Zukunft von AppSec geht es nicht darum, bessere Scanner zu entwickeln. Es geht darum, die Lücke zwischen Erkennung und Behebung automatisch und in großem Maßstab zu schließen, ohne Entwickler auszubremsen – und zwar über die gesamte Angriffsfläche hinweg, einschließlich des KI-Stacks. Dass Anthropic jetzt massiv in genau diese Richtung investiert, zeigt mir, dass die Branche erkannt hat, wo der größte Hebel liegt. Mit Snyk können Sie diesen Hebel schon heute nutzen.
E-Book
Von Shift Left zu Secure at Inception: Die Evolution von AppSec im Zeitalter der KI
Erfahren Sie, warum Sicherheit bereits beim Entstehen des Codes beginnen muss. Entdecken Sie, wie Snyk Studio die Intelligenz, Automatisierung und Leitplanken bereitstellt, um KI-gestütztes Coding zu steuern und Schutz zu einem selbstverständlichen Bestandteil von Innovation zu machen.