Worauf Security-Teams 2026 bei einer Code-Security-Plattform achten sollten

Mit dem Wurm Shai-Hulud hat das npm-Ökosystem im September 2025 einen Vorfall erlebt, der vorher nur theoretisch beschrieben worden war: Schadcode, der sich autonom durch eine Paket-Registry fortpflanzt. Über 500 Paket-Versionen waren binnen weniger Tage betroffen. Wenige Wochen davor hatten Angreifer schon die Maintainer-Konten der populären Pakete chalk und debug übernommen. Für die Auswahl einer Code-Security-Plattform haben sich die Kriterien damit verschoben.

axios-Vorfall mit einer falschen Slack-Einladung

Der Sonatype-Bericht zum Stand der Software-Lieferkette führt 2025 als das bislang schwerste Jahr für npm. Im März 2026 ging es weiter. Der axios-Maintainer Jason Saayman beschrieb nach dem Angriff auf seinen Account, wie der Angreifer ihn über eine täuschend echte Slack-Einladung in ein Microsoft-Teams-Meeting gelockt habe. Dort sei er gebeten worden, ein vermeintliches Update zu installieren. Sicherheitsforscher von Google verbinden den Vorfall mit einem nordkoreanischen Akteur.

Diese Vorfälle zielen nicht mehr nur auf die Software, sondern auf die Menschen dahinter. Werkzeuge, die nur Repositories scannen, sehen davon wenig.

Wie solche Angriffe im Detail aussehen und woran man sie erkennt, zeigen u.a. unsere Phishing-Warnungen.

Drei Architektur-Linien im Markt

Der Markt lässt sich 2026 grob in drei Architektur-Linien aufteilen. Die erste sind Developer-First-Werkzeuge wie Snyk oder Aikido. Sie setzen am Pull-Request an und versuchen, die False-Positive-Quote niedrig zu halten, damit Entwickler das Feedback ernst nehmen. ASPM-Plattformen bilden die zweite Linie. Cycode, ArmorCode oder Apiiro scannen meist nicht selbst, sondern aggregieren Befunde aus mehreren bestehenden Scannern und priorisieren sie nach Geschäftsrisiko. Bleiben die Cloud-native CNAPP-Suiten wie Wiz Code, Cortex Cloud oder Checkmarx One, die Code-Security in eine breitere Plattform für Cloud, Identity und Runtime einbetten.

In der Praxis sind die drei Familien nicht austauschbar. Cycode oder ArmorCode aggregieren Befunde, scannen aber nicht von sich aus. Snyk und Aikido scannen schnell, decken aber den Runtime- und Cloud-Kontext nicht ab. Prüfst du gerade Wiz Alternativen, dreh die Frage um: Klär zuerst, was in deinem Stack schon vorhanden ist. Eine CNAPP-Telemetrie aus einer anderen Cloud-Plattform willst du selten in einem dritten Werkzeug duplizieren.

Was nie aufgerufen wird, ist auch nicht verwundbar

Statische Scanner (SAST) markieren jeden Code-Pfad, der theoretisch verwundbar sein könnte. In einer großen Codebasis sind das schnell tausende Warnungen pro Sprint. Viele zeigen auf Funktionen, die in der laufenden Anwendung nie aufgerufen werden. Entwickler lernen, diese Hinweise zu überfliegen. Die wenigen wirklich kritischen Befunde gehen so im Strom unter.

Reachability-Analyse setzt eine Ebene tiefer an. Sie verfolgt den tatsächlichen Aufrufgraphen einer Anwendung und blendet Funde aus, die in der Praxis nicht erreichbar sind. Endor Labs hat das Verfahren früh zur Kernfunktion gemacht, Semgrep und Aikido sind nachgezogen. Eine Plattform, die 2026 nur nach CVE-Severity sortiert und den Ausführungspfad nicht prüft, lässt einen Großteil der Triage-Arbeit beim Security-Team.

JetBrains und Copilot

Generative Coding-Assistenten haben den Anteil maschinell erzeugten Codes in Produktiv-Codebasen rasch hochgetrieben. Eine Analyse öffentlicher GitHub-Repositories vom Oktober 2025 zeigt, dass Python-Code aus Copilot und ChatGPT in 16 bis 18 Prozent der Fälle bekannte Schwachstellen-Muster enthält. JavaScript und TypeScript liegen darunter, fehlerfrei sind sie nicht.

Die Plattformhersteller haben darauf reagiert, indem sie die Prüfung an den Ort verlegen, an dem der Code entsteht. Wiz hat im Januar 2026 ein Plugin für JetBrains-IDEs veröffentlicht, das bei jedem Speichervorgang scannt. GitHub Advanced Security ergänzt Copilot um Inline-Hinweise vor dem Commit, Snyk und Cycode bieten ähnliche Editor-Erweiterungen.

Was eine IDE-Erweiterung tatsächlich an KI-generiertem Code erkennt, hängt aber davon ab, ob die genutzten Assistenten diese Codeblöcke als solche markieren. Bei manchen Tools passiert das, bei anderen nicht durchgängig. Eine zuverlässige Erkennung von KI-Code in beliebigen Repositories ist 2026 noch kein gelöstes Problem.

Die Korrelation entscheidet

Ein SAST-Befund allein sagt nichts darüber aus, ob die betroffene Funktion in einer öffentlich erreichbaren Komponente läuft oder im internen Build-Skript. Eine verwundbare Bibliothek in einem Container ohne Internetzugang ist ein anderes Problem als die gleiche Bibliothek in einer öffentlich exponierten API mit Zugriff auf die Produktionsdatenbank. Plattformen, die diesen Bezug auflösen, priorisieren nach Geschäftsrisiko statt nach abstrakter CVSS-Punktzahl.

Cycode nennt diese Korrelation Context Intelligence Graph, Apiiro spricht von Software-Architecture-Mapping. Beide Begriffe meinen, dass Code-Findings mit dem realen Lauf-Kontext verbunden werden, von der Cloud-Konfiguration bis zur Identity. Ohne diese Verknüpfung bleibt die Triage-Arbeit beim Security-Team.

SBOM wird zur Pflichtbeilage

Mit dem Cyber Resilience Act hat die EU 2024 Regeln verabschiedet, deren wichtigste Pflichten ab Ende 2027 vollständig greifen. Hersteller müssen für jedes Produkt mit digitalen Elementen eine Software Bill of Materials führen, also eine vollständige Auflistung aller Komponenten, kontinuierlich auf Schwachstellen prüfen und sicherheitsrelevante Vorfälle melden. Verstöße können mit bis zu 15 Millionen Euro oder 2,5 Prozent des globalen Jahresumsatzes geahndet werden.

SBOM-Erzeugung wird damit zum Standardumfang einer Code-Security-Plattform, nicht zum optionalen Zusatzmodul. Wer eine Lösung wählt, die SBOMs nur über externe Werkzeuge generiert, muss diesen Compliance-Teil ohnehin nachbauen.

Probephase mit dem komplexesten Repository entscheidet

Welche Plattform am Ende zu deinem Team passt, lässt sich aus einem Featurevergleich nicht zuverlässig ableiten. Eine zeitlich begrenzte Probephase mit dem kompliziertesten Repository deiner Codebasis liefert konkretere Daten: wie viele Treffer sind echt, wie viele Befunde landen im Entwickler-Workflow tatsächlich auf der Backlog-Liste, wie sie sich in deinen bestehenden Toolchain-Aufbau einfügt. Die meisten Hersteller bieten dafür Demo-Zeiträume an.