Fortify vs Checkmarx One vs Veracode vs Snyk vs GitHub Code Security vs Semgrep: Welche Enterprise-AppSec-Plattform ist 2026 die richtige?

• ob der eigene Code Schwachstellen enthält,
• ob Open-Source-Abhängigkeiten bekannte CVE oder Lizenzprobleme aufweisen,
• ob sich im Repository Secrets befinden,
• ob Terraform, Kubernetes oder CloudFormation fehlerhaft konfiguriert sind,
• ob ein Container-Image verwundbare Pakete enthält,
• ob die laufende Anwendung und API aus Sicht eines Angreifers angreifbar sind,
• ob sich die Ergebnisse Eigentümern zuordnen, priorisieren und in Tausenden von Repositories durchsetzen lassen.

Kein einzelnes Wort „Scanner“ deckt automatisch alle diese Schichten ab.

Im Jahr 2026 gehören zu den am häufigsten in Betracht gezogenen Enterprise-Plattformen unter anderem:

• OpenText Fortify,
• Checkmarx One,
• Veracode,
• Snyk,
• GitHub Code Security und GitHub Secret Protection, historisch unter dem gemeinsamen Namen GitHub Advanced Security beschrieben,
• Semgrep.

Hinzu kommen ergänzende Lösungen wie:

• SonarQube Advanced Security,
• Burp Suite DAST,
• Invicti.

Dieser Artikel vergibt keine fiktiven Bewertungen wie „9,8/10“, wiederholt keine Herstellerangaben zur prozentualen Wirksamkeit und kürt keinen Sieger auf Basis der Anzahl von Posten in der Preisliste.

Das beste AppSec-Werkzeug ist nicht das Produkt mit der größten Funktionstabelle. Es ist das Produkt oder die Produktkombination, die relevante Probleme im tatsächlichen Stack der Organisation erkennt, in ihr Deployment-Modell passt und zu Behebungen führt, statt einen unbearbeiteten Backlog zu erzeugen.

Produktumfang und Dokumentation wurden am 23. Juli 2026 überprüft.

TL;DR

Szenario	Natürlichster Ausgangspunkt
Große regulierte Organisation, Legacy, Deployment-Anforderungen und umfangreiches SAST/DAST	Fortify
Eine breite Plattform, die Code, Dependencies, IaC, Secrets, API, Container und DAST abdeckt	Checkmarx One
Verwaltetes AppSec-Programm mit zentralen Richtlinien, SAST, SCA und DAST	Veracode
Developer-first für Code, Open Source, Container, IaC und inzwischen auch DAST/API	Snyk
Organisation, die überwiegend in GitHub arbeitet und Security in Pull Requests möchte	GitHub Code Security + Secret Protection
Schnelles, konfigurierbares SAST/SCA/Secrets und eigene Regeln	Semgrep
Unternehmen, das SonarQube bereits als Quality Gate nutzt	SonarQube Advanced Security als Erweiterung
Dediziertes Enterprise-DAST für Web und API	Burp Suite DAST oder Invicti, in einem separaten POC bewertet

Dies ist keine Tabelle bedingungsloser Sieger. Es ist eine Karte der Produkte, deren Architektur am besten zum jeweiligen Problem passt.

1. Trennen Sie zuerst die Testarten

OWASP ASVS bildet eine offene Grundlage zur Definition von Anforderungen und des Rigorositätsniveaus bei der Überprüfung der Anwendungssicherheit. Er setzt nicht voraus, dass ein einzelnes automatisches Werkzeug alle Anforderungen verifiziert.

SAST

Static Application Security Testing analysiert Code oder Artefakte, ohne die Anwendung auszuführen.

Es kann unter anderem erkennen:

• den Fluss nicht vertrauenswürdiger Daten in einen gefährlichen Sink,
• Validierungsfehler,
• hardcoded Credentials,
• kryptografische Probleme,
• unsichere API,
• ausgewählte Autorisierungs- und Logikfehler.

SAST bestätigt nicht automatisch, dass sich eine Schwachstelle in einer konkreten Runtime-Umgebung ausnutzen lässt.

SCA

Software Composition Analysis analysiert Abhängigkeiten, Pakete, Versionen, Schwachstellen und Open-Source-Lizenzen.

SCA beantwortet eine andere Frage als SAST:

SAST: czy nasz kod zawiera niebezpieczny wzorzec lub przepływ?
SCA: czy używany komponent ma znaną podatność albo ryzyko licencyjne?

Secrets scanning

Erkennt Schlüssel, Tokens, Passwörter und andere Anmeldedaten im aktuellen Code, im Git-Verlauf und manchmal vor dem Ausführen eines Push.

IaC scanning

Analysiert Terraform, Kubernetes, Helm, CloudFormation, ARM und andere Infrastrukturdeklarationen.

Container scanning

Analysiert Images, das Basissystem, Systempakete, Anwendungsabhängigkeiten und manchmal die Workload-Konfiguration.

DAST

Dynamic Application Security Testing testet die laufende Anwendung von außen. OWASP definiert DAST als Black-Box-Test, der über die Weboberfläche mit der Anwendung kommuniziert.

DAST kann Folgendes finden:

• Probleme der Serverkonfiguration,
• Schwachstellen, die erst zur Runtime sichtbar werden,
• einen Teil der Authentifizierungs- und Sitzungsfehler,
• SQL injection,
• XSS,
• Schwachstellen von API-Endpunkten,
• Probleme, die vom realen Deployment abhängen.

Es sieht den Quellcode nicht und ersetzt kein Code Review.

ASPM und Governance

Application Security Posture Management aggregiert Ergebnisse, ordnet Anwendungen Eigentümern zu, korreliert Findings und hilft, Richtlinien im Maßstab der Organisation anzuwenden.

Eine Plattform kann ein breites Dashboard besitzen und dennoch Engines unterschiedlicher Tiefe nutzen. Allein das Vorhandensein einer gemeinsamen UI beweist keine gleichwertige Qualität aller Module.

2. Wie ist dieser Vergleich entstanden?

Eine Funktion wurde nur dann in die Tabelle aufgenommen, wenn sie in der aktuellen offiziellen Dokumentation des Anbieters bestätigt war.

Als Beleg verwenden wir nicht:

• gesponserte Rankings,
• Einträge von Vertriebspartnern,
• „accuracy“-Zahlen ohne unabhängige Methodik,
• Erklärungen „zero false positives“,
• allgemeine Marketingauszeichnungen,
• ein einzelnes, vom Hersteller angegebenes OWASP-Benchmark-Ergebnis.

Symbole in der Matrix

Symbol	Bedeutung
●	bestätigter, nativer Bestandteil des aktuellen Angebots
◐	Funktion verfügbar über ein separates Modul, ein Add-on oder in deutlich engerem Umfang
-	kein bestätigtes natives Modul im analysierten Angebot
POC	ohne Test am Stack der Organisation nicht fair bewertbar

3. Matrix des Produktumfangs

Plattform	SAST	SCA	Secrets	IaC	Containers	DAST / API runtime	Zentrale Governance
Fortify	●	●	◐	-	-	●	●
Checkmarx One	●	●	●	●	●	●	●
Veracode	●	●	●	●	●	●	●
Snyk	●	●	◐	●	●	●	●
GitHub Code Security + Secret Protection	●	●	●	-	-	-	●
Semgrep	●	●	●	-	-	-	●
SonarQube Advanced Security	●	●	●	-	-	-	●
Burp Suite DAST	-	-	-	-	-	●	●
Invicti	-	-	-	-	-	●	●

Die Tabelle zeigt den Umfang, nicht die Wirksamkeit.

Beispiel: Ein Produkt mit nativem SAST und DAST muss nicht gegen die Kombination aus dem besten Repository-Werkzeug und einem separaten DAST gewinnen. Umgekehrt können zwei separate Produkte die Integrationskosten, die Anzahl der Dashboards und die Schwierigkeit der Ergebnis-Deduplizierung erhöhen.

4. OpenText Fortify

Das aktuelle Angebot von Fortify umfasst separate Lösungen für:

• SAST,
• DAST,
• Software Composition Analysis,
• das verwaltete Fortify on Demand.

OpenText beschreibt Fortify SAST als Enterprise-Lösung mit flexiblen Deployment-Modellen. Fortify DAST testet laufende Anwendungen, API und Dienste. Fortify Software Composition Analysis ist ein separates Produkt, das Open-Source-Komponenten analysiert. Fortify on Demand stellt im Servicemodell unter anderem SAST, DAST und MAST bereit.

Die wichtigste begriffliche Unterscheidung

Der historische Name Fortify Static Code Analyzer wurde oft zu „Fortify SCA“ verkürzt.

Im neuen Kontext bedeutet SCA jedoch Software Composition Analysis.

Deshalb sollte man in Dokumentation und Bestellung genau unterscheiden:

Fortify SAST / Static Code Analyzer
Fortify Software Composition Analysis

Das sind nicht dieselben Tests.

Stärken von Fortify

• umfangreiches SAST und DAST in einer Produktfamilie,
• Möglichkeit von Deployments, die mehr Kontrolle über die Infrastruktur erfordern,
• SaaS-Angebot über Fortify on Demand,
• Unterstützung für traditionelle Enterprise-Umgebungen und ältere Stacks,
• zentrale Verwaltung des AppSec-Programms.

OpenText kündigte in der Version SAST 26.2 unter anderem Erweiterungen für COBOL, Fortran, C++23, PHP 8.5, Kotlin 2.3 und Swift 6.3 an. Das ist wichtig für Organisationen mit einer Mischung aus modernen und älteren Systemen.

Einschränkungen, die zu prüfen sind

• Dauer des vollständigen und inkrementellen Scans auf den eigenen Monorepositories,
• Anforderungen an Builds und die Vorbereitung von Artefakten,
• Qualität der Integration mit Pull Requests,
• Betriebskosten der self-managed Infrastruktur,
• Umgang mit IaC und Containern, falls erforderlich,
• Triage-Ergonomie für Entwickler.

Für wen?

Fortify ist ein natürlicher Kandidat für:

• Banken,
• Telekommunikationsunternehmen,
• öffentliche Verwaltung,
• große Organisationen mit Anforderungen an Deployment und Daten,
• Umgebungen mit Java, .NET, C/C++, COBOL und anderen langlebigen Technologien.

Das bedeutet keinen automatischen Sieg in einem neuen, cloud-nativen Startup. Es bedeutet eine gute Passung des Produktmodells zu einem komplexen Enterprise.

5. Checkmarx One

Checkmarx One wird als breite Application-Security-Plattform positioniert, die die Phasen von der Codeerstellung bis zur Runtime abdeckt.

Offizielle Materialien bestätigen unter anderem:

• SAST,
• SCA,
• secrets detection,
• IaC security,
• API Security,
• Container Security,
• DAST,
• software supply chain security.

Der größte Vorteil

Checkmarx One ist einer der natürlichsten Kandidaten, wenn das Ziel der Beschaffung die Reduzierung der Anzahl an Anbietern ist.

In einer Architektur lassen sich abdecken:

kod własny
+ zależności
+ sekrety
+ IaC
+ kontenery
+ API
+ działającą aplikację

Was muss im POC überprüft werden?

Die Breite des Portfolios beantwortet nicht die Frage nach der Tiefe.

Man sollte separat messen:

• SAST für die für das Unternehmen wichtigsten Sprachen,
• Qualität der Reachability in SCA,
• IaC-Abdeckung,
• Umgang mit privaten Registries und Basis-Images,
• authentifiziertes DAST-Scanning,
• Import von OpenAPI, GraphQL und realen Workflows,
• Art der Ergebniskorrelation zwischen Modulen,
• Data Residency und die Verarbeitung des Codes.

Für wen?

Checkmarx One sollte man weit oben auf die Liste setzen, wenn:

• das Unternehmen einen strategischen AppSec-Anbieter möchte,
• es mehr als SAST und SCA benötigt,
• es viele Teams, Sprachen, Clouds und Repositories hat,
• ein zentrales Sicherheitsteam Governance über den gesamten SDLC möchte.

Ein ehrliches Fazit

Der breiteste bestätigte Umfang bedeutet nicht „die beste Engine in allem“. Checkmarx One sollte erst dann gewinnen, wenn nachgewiesen ist, dass die zwei oder drei für die Organisation wichtigsten Module gut genug sind.

6. Veracode

Veracode bietet die Plattform Application Risk Management und bestätigte Produkte für:

• SAST,
• SCA,
• DAST,
• Container Security,
• IaC-Scanning,
• Erkennung von Secrets,
• Scan-Workflows und die zentrale Verwaltung der Ergebnisse.

Veracode SAST analysiert Anwendungen statisch, DAST testet laufende Anwendungen und API, und Veracode Container Security scannt Container, IaC-Dateien sowie offengelegte Secrets.

Stärken

• ein kohärentes, verwaltetes Plattformmodell,
• SAST, SCA und DAST in einem Programm,
• zentrale Richtlinien und Reporting,
• weniger Bedarf, eine schwere Scanner-Infrastruktur zu betreiben,
• ein Ansatz, der für Organisationen mit SaaS-Präferenz geeignet ist.

Ein wichtiges Architekturmerkmal

Veracode wird seit Jahren mit der Analyse vorbereiteter Binär- oder Bytecode-Artefakte in einem Teil der statischen Workflows in Verbindung gebracht. Die aktuelle Konfiguration hängt von der Sprache und dem Scantyp ab, weshalb ein POC den tatsächlichen Build-Prozess der Organisation nachbilden muss und nicht nur ein kleines Demonstrationsprojekt.

Zu prüfende Einschränkungen

• wie schnell ein Entwickler nach einer Änderung ein Ergebnis erhält,
• wie viel Aufwand die Vorbereitung eines Artefakts erfordert,
• wie sich der Pipeline Scan im Vergleich zum vollständigen Policy Scan verhält,
• Umgang mit Monorepo,
• Integration mit self-hosted SCM und CI,
• Anforderungen an das Übermitteln von Artefakten,
• Qualität und Umfang von Container Security, IaC und Secrets an den tatsächlichen Artefakten der Organisation.

Für wen?

Veracode ist ein starker Kandidat für Organisationen, die Folgendes möchten:

• verwaltetes, zentrales AppSec,
• eine Kombination aus SAST, SCA und DAST,
• Richtlinien und Berichte, ohne eine eigene Scanning-Plattform aufzubauen,
• ein einheitliches Modell für viele Teams.

7. Snyk

Das aktuelle Angebot von Snyk ist breiter als die frühere Assoziation ausschließlich mit Dependency Scanning.

Zu den offiziellen Produkten gehören:

• Snyk Code - SAST,
• Snyk Open Source - SCA und License Compliance,
• Snyk Container,
• Snyk IaC,
• Snyk API & Web - cloud-based DAST für Anwendungen und API.

Snyk verfügt außerdem über eine Schicht zur Verwaltung und Priorisierung des Anwendungsrisikos.

Stärken

• Integration mit IDE, CLI, SCM und CI/CD,
• Fokus auf den Workflow des Entwicklers,
• eine Produktfamilie für Code, Dependencies, Container, IaC und Runtime-DAST,
• Remediation Guidance,
• Kontext zu Reachability, Exploit und Deployment in ausgewählten Modulen,
• gute Passung zu Cloud-native und Platform Engineering.

Eine wichtige Aktualisierung gegenüber älteren Vergleichen

Die Aussage „Snyk hat kein DAST“ ist im Jahr 2026 überholt.

Snyk API & Web wird offiziell als cloudbasierte DAST-Lösung für laufende Webanwendungen und API beschrieben.

Deshalb muss ein aktueller Vergleich seine reale Abdeckung gegenüber den dedizierten Produkten Burp Suite DAST, Invicti, Fortify DAST, Checkmarx DAST und Veracode DAST bewerten.

Was ist zu prüfen?

• Sprachabdeckung in SAST,
• Genauigkeit und Scandauer auf einem echten Repository,
• Qualität der Fix Suggestions,
• SCA für Transitive Dependencies und Monorepo,
• eigene Basis-Images und private Registries,
• Terraform, Kubernetes, Helm und CloudFormation,
• DAST für authentifizierte Anwendungen und komplexe API,
• Datenmodell und Hosting-Region,
• Gesamtkosten mehrerer Module.

Für wen?

Snyk ist ein natürlicher Kandidat für:

• cloud-native Unternehmen,
• Teams, die Container und IaC nutzen,
• Organisationen, die Sicherheit nah am Entwickler möchten,
• Teams, die eine breite Plattform benötigen, aber nicht mit einem schweren, traditionellen SAST beginnen möchten.

8. GitHub Code Security und GitHub Secret Protection

Im aktuellen Modell teilt GitHub die kostenpflichtigen Funktionen auf in:

• GitHub Code Security,
• GitHub Secret Protection.

Die Dokumentation beschreibt sie weiterhin als Produkte von GitHub Advanced Security.

GitHub Code Security umfasst unter anderem:

• code scanning,
• CodeQL,
• Premium-Funktionen von Dependabot,
• dependency review.

GitHub Secret Protection umfasst unter anderem:

• secret scanning,
• push protection,
• custom patterns,
• Erkennung ausgewählter unstrukturierter Credentials.

CodeQL ist eine von GitHub entwickelte Code-Analyse-Engine. Dependabot kann Pull Requests erstellen, die verwundbare Abhängigkeiten aktualisieren.

Der größte Vorteil

Die Ergebnisse sind an dem Ort verfügbar, an dem der Entwickler:

• einen Pull Request öffnet,
• den Diff prüft,
• Branch Protection anwendet,
• Code Review durchführt,
• Actions ausführt,
• die Eigentümer des Repositories verwaltet.

Das reduziert organisatorische Reibung.

Was ersetzt GitHub nicht?

Das native Angebot ist kein vollständiges Äquivalent zu:

• Enterprise-DAST,
• dem Scannen laufender Anwendungsworkflows,
• einer dedizierten IaC-Security-Suite,
• einer vollständigen Container-Security-Plattform,
• einem manuellen Pentest.

GitHub code scanning kann Ergebnisse externer Werkzeuge übernehmen, aber das Aggregieren von SARIF bedeutet nicht, dass GitHub diese Tests selbst durchgeführt hat.

Für wen?

Die stärkste Passung besteht, wenn:

• GitHub der Standard der gesamten Organisation ist,
• Security in Pull Requests funktionieren soll,
• CodeQL die wichtigsten Sprachen unterstützt,
• das Team die Ergänzung um ein separates DAST und gegebenenfalls einen IaC-/Container-Scanner akzeptiert.

Eine mögliche Kombination

GitHub Code Security
+ GitHub Secret Protection
+ dedykowany DAST
+ opcjonalny IaC/container scanner

Sie kann besser sein als eine breite Plattform für ein Unternehmen, das das vorhandene GitHub-Ökosystem maximal nutzen möchte.

9. Semgrep

Die Semgrep AppSec Platform bestätigt drei Hauptprodukte:

• Semgrep Code - SAST,
• Semgrep Supply Chain - SCA,
• Semgrep Secrets.

Die Plattform integriert sich mit SCM und CI, ermöglicht die Verwaltung von Richtlinien sowie das Blockieren ausgewählter Probleme in Pull Requests.

Der größte Vorteil

Semgrep ermöglicht das Erstellen eigener Regeln, die angepasst sind an:

• interne Frameworks,
• Sicherheits-Wrapper,
• unternehmensspezifische Anti-Patterns,
• Architekturregeln,
• gefährliche Funktionen,
• Autorisierungsprozesse.

Eine beispielhafte, vereinfachte Regel:

rules:
  - id: internal-unsafe-query
    message: Use the approved parameterized database wrapper.
    severity: ERROR
    languages: [javascript]
    patterns:
      - pattern: db.raw($QUERY)

Die Leichtigkeit, Regeln zu schreiben, kann wichtiger sein als weitere tausend allgemeine Checks.

Stärken

• schnelle Rückmeldung im Workflow des Entwicklers,
• konfigurierbare Regeln,
• SAST, SCA und Secrets in einer Plattform,
• sinnvoller Einsatz in Monorepo und modernen Stacks,
• Möglichkeit, organisationsspezifische Guardrails einzuführen.

Einschränkungen

Semgrep ist kein natives Enterprise-DAST und ersetzt nicht:

• das Testen einer laufenden Anwendung,
• authentifiziertes Crawling,
• Runtime-API-Attacks,
• vollständige Container Security,
• eine dedizierte IaC-Security-Suite.

Für wen?

Semgrep lohnt sich, wenn:

• das Security-Team schnell eigene Regeln erstellen möchte,
• die Developer Experience Priorität hat,
• die Organisation einen zusammengesetzten Werkzeugsatz akzeptiert,
• ein separates DAST und ein Container-/IaC-Scanner Teil des Plans sind.

10. SonarQube Advanced Security

SonarQube wurde über Jahre vor allem mit Code Quality und statischer Analyse in Verbindung gebracht.

Im Jahr 2026 erweitert SonarQube Advanced Security das Enterprise-Angebot um:

• Advanced SAST,
• Software Composition Analysis,
• zusätzliche Sicherheits- und Compliance-Funktionen.

Die Dokumentation und die Release Notes bestätigen außerdem weiterentwickelte Regeln für Secrets Detection.

Wann ist das sinnvoll?

Wenn eine Organisation SonarQube bereits als verpflichtendes Quality Gate nutzt, kann die Erweiterung der vorhandenen Plattform operativ einfacher sein als die Einführung eines neuen Dashboards für jedes Repository.

Was sollte man nicht annehmen?

SonarQube Advanced Security wird dadurch nicht automatisch zu:

• einem DAST,
• einer Plattform für authentifizierte Webtests,
• einem vollständigen Container-Scanner,
• einer kompletten IaC-Plattform.

Die Rolle im Vergleich

SonarQube ist eine starke Konsolidierungsalternative für Unternehmen, die Quality und Security in einem bestehenden Prozess verbinden möchten. Es ist jedoch nicht dieselbe Kategorie wie breite Plattformen, die die Runtime abdecken.

11. Burp Suite DAST und Invicti

DAST sollte separat bewertet werden, da die Qualität eines dynamischen Scans abhängt von:

• der Crawl Coverage,
• der Unterstützung von SPA,
• der Authentifizierung,
• der Aufrechterhaltung der Sitzung,
• dem Aufzeichnen komplexer Workflows,
• API Discovery,
• dem Import von OpenAPI, GraphQL oder SOAP,
• der Steuerung der Scan-Intensität,
• der Verifizierung von Findings,
• dem Betrieb im internen Netzwerk.

Burp Suite DAST

PortSwigger dokumentiert:

• die Integration von CI-driven scans mit Plattformen, die Container unterstützen,
• eine Cloud- sowie eine self-hosted Variante,
• GraphQL API und REST API zur Integration.

Ein natürlicher Vorteil ist die Verbindung zum Burp-Ökosystem, das von Pentestern genutzt wird.

Invicti

Invicti ist eine dedizierte DAST-Plattform für Web und API. Die offizielle Dokumentation beschreibt Discovery, Stateful API Scanning und Proof-based Validation.

Herstellerangaben zur prozentualen Genauigkeit sollten ohne einen unabhängigen Test nicht in eine Kaufentscheidung übernommen werden.

Welcher ist besser?

Eine ehrliche Antwort auf Basis der Produktseite ist nicht möglich.

Der POC muss Folgendes umfassen:

• Anmeldung über SSO,
• MFA,
• Token-Aktualisierung,
• Benutzerrollen,
• mehrstufigen Workflow,
• SPA,
• REST,
• GraphQL,
• Upload,
• Webhooks,
• interne Endpunkte,
• das Risiko einer Datenbeschädigung.

12. Vergleich der organisatorischen Passung

Kriterium	Fortify	Checkmarx One	Veracode	Snyk	GitHub	Semgrep
Reguliertes Enterprise und Legacy	sehr natürlich	natürlich	natürlich	vom Stack abhängig	als Repo-Schicht	als Repo-Schicht
Eine breite Plattform	breit	sehr breit	SAST/SCA/DAST	sehr breit	nein	nein
Developer-first	POC	POC	POC	starkes Profil	sehr stark in GitHub	sehr stark
Self-managed / Infrastrukturkontrolle	starker Kandidat	Modell prüfen	überwiegend verwaltetes Modell	Modul prüfen	GHES für einen Teil der Funktionen	Enterprise-Optionen
Legacy languages	starkes Profil	POC	POC	POC	abhängig von CodeQL	abhängig von der Sprache
IaC und Container	zusätzliche Werkzeuge	native Module	natives Modul Container Security	native Module	zusätzliche Werkzeuge	zusätzliche Werkzeuge
Natives DAST	ja	ja	ja	ja	nein	nein
Eigene SAST-Regeln	möglich, Kosten prüfen	möglich, POC	POC	POC	CodeQL queries	zentraler Vorteil

„Starkes Profil“ erfordert weiterhin einen POC.

13. Lässt sich ein einziger Sieger benennen?

Nicht auf verantwortungsvolle Weise.

Man kann jedoch die logischsten Shortlists benennen.

Shortlist A: eine Plattform mit breitem Umfang

Checkmarx One
Snyk
Fortify
Veracode

Man sollte den Modulen ein Gewicht zuweisen. Beispiel:

SAST              25%
SCA               15%
DAST i API        20%
IaC i containers  15%
developer UX      10%
governance        10%
deployment/data    5%

Wenn ein Unternehmen weder IaC noch Container benötigt, sollte deren Gewicht null betragen. Es dürfen keine Punkte für ein Modul vergeben werden, das kein Problem der Organisation löst.

Shortlist B: GitHub-native

GitHub Code Security
GitHub Secret Protection
+ Burp Suite DAST lub Invicti
+ Snyk IaC/Container albo inny wyspecjalizowany scanner

Shortlist C: Custom Rules und Developer-first

Semgrep Code + Supply Chain + Secrets
+ dedykowany DAST
+ osobne IaC/container security

Shortlist D: Legacy und Deployment-Kontrolle

Fortify SAST + DAST + Software Composition Analysis

Man sollte prüfen, ob die übrigen Schichten von den vorhandenen Infrastrukturwerkzeugen abgedeckt werden.

Shortlist E: vorhandenes SonarQube

SonarQube Advanced Security
+ dedykowany DAST
+ osobne IaC/container security, jeżeli potrzebne

14. Wie führt man einen fairen POC durch?

OWASP Benchmark enthält Testsuiten und Werkzeuge zur Bewertung von Accuracy, Coverage und Geschwindigkeit automatischer Scanner.

Er sollte jedoch nicht die alleinige Entscheidungsgrundlage sein:

• ein Teil der Tests ist synthetisch,
• der Java Benchmark wird seit vielen Jahren ohne wesentliche Änderung der Fälle gepflegt,
• der neue Benchmark für Python hat einen anderen Reifegrad,
• das Ergebnis misst nicht den Workflow des Entwicklers,
• es misst keine Governance,
• es bildet keine unternehmensspezifischen Frameworks nach.

OWASP Juice Shop ist eine absichtlich verwundbare Anwendung aus Node.js, Express und Angular, nützlich für Übungen sowie das Testen von Werkzeugen an einem JavaScript-Frontend und einer REST API.

Ein minimaler Testsatz

1. OWASP Benchmark für eine unterstützte Sprache.
2. OWASP Juice Shop für DAST.
3. Eine eigene Anwendung, die den Produktions-Stack repräsentiert.
4. Ein Monorepo realer Größe.
5. Ein Repository mit:
   • verwundbaren Dependencies,
   • einem Secret in der aktuellen Version,
   • einem Secret im Git-Verlauf,
   • Dockerfile,
   • Terraform,
   • Kubernetes,
   • generiertem Code.
6. Eine laufende Umgebung mit:
   • SSO,
   • mehreren Rollen,
   • REST und GraphQL,
   • einer Upload-Funktion,
   • einem mehrstufigen Prozess.

15. POC-Metriken

Erkennungsleistung

• true positives,
• false positives,
• false negatives,
• Duplikate,
• Findings ohne realen Ausführungspfad,
• tatsächlich erreichbare Schwachstellen in Abhängigkeiten.

Leistung

• Dauer des ersten vollständigen Scans,
• Scandauer eines Pull Requests,
• Dauer nach Änderung einer einzelnen Zeile,
• Auslastung von CPU und RAM,
• Verhalten auf einem Monorepo,
• Parallelität.

Remediation

• ob das Ergebnis Source und Sink angibt,
• ob es den vollständigen Data Flow zeigt,
• ob die Behebung mit dem Framework kompatibel ist,
• ob ein Entwickler das Ergebnis ohne das AppSec-Team verifizieren kann,
• ob ein automatischer Fix die Tests besteht,
• wie viele Ergebnisse als „won’t fix“ geschlossen werden.

Governance

• RBAC,
• SSO und SCIM,
• audit log,
• Richtlinien pro Business Unit,
• Ausnahmen mit Ablaufdatum,
• SLA,
• Anwendungen und Eigentümer,
• Integration mit Jira oder einem anderen System,
• Datenexport,
• API,
• Compliance-Berichte.

Deployment und Daten

• SaaS, self-hosted oder hybrid,
• Datenregion,
• ob der Code die Organisation verlässt,
• Art der Speicherung von Artefakten,
• private Registries,
• interne Anwendungen,
• Proxy,
• air-gapped environment,
• Verschlüsselung,
• Retention.

Gesamtkosten

Nicht nur der Lizenzpreis:

TCO =
licencja
+ infrastruktura
+ onboarding
+ tuning
+ triage
+ integracje
+ utrzymanie reguł
+ wsparcie
+ czas developerów

Ein günstiges Werkzeug mit Tausenden unbearbeiteter Findings kann teurer sein als eine Plattform mit höherem Lizenzpreis.

16. Typische Fehler bei der Beschaffung

Kauf auf Basis der Anzahl an Sprachen

„Sprachunterstützung“ kann bedeuten:

• einen Syntax-Parser,
• grundlegende Regeln,
• vollständigen interprozeduralen Data Flow,
• die Unterstützung konkreter Frameworks.

Der POC muss die Frameworks der Organisation verwenden.

Vermischen von SAST und SCA

Das sind eigenständige Techniken. Die ähnliche Abkürzung im historischen Namen von Fortify erhöht zusätzlich das Verwechslungsrisiko.

Jedes Modul gleich gewichten

Wenn ein Unternehmen Terraform nicht verwendet, sollte das IaC-Modul die Bewertung nicht verbessern.

Nur die öffentliche Demo-Anwendung testen

Ein kleiner Benchmark bildet Folgendes nicht nach:

• Monorepo,
• Custom Framework,
• einen internen Package Manager,
• Build System,
• SSO,
• ein privates Netzwerk.

Fehlender Test der Developer Experience

Ein Werkzeug kann gute Probleme finden, aber bei der Einführung scheitern durch:

• Ergebnisse erst nach einigen Stunden,
• fehlenden Kommentar im PR,
• unverständliche Remediation,
• komplizierte Suppressions,
• instabile Builds.

Glaube an eine Marketing-Zahl zu false positives

Ohne einen öffentlichen Datensatz, Konfiguration, Version und Definition des Ergebnisses eignet sich die Zahl nicht für einen Vergleich.

Kauf eines DAST ohne gelöste Authentifizierung

Ein Scanner, der die Anmeldung nicht durchläuft, kann nur einen kleinen öffentlichen Teil der Anwendung testen.

17. Empfehlungen nach Unternehmenstyp

Bank, Versicherung, öffentliche Verwaltung

Shortlist:

• Fortify,
• Checkmarx One,
• Veracode.

Prioritäten:

• Deployment und Daten,
• legacy languages,
• Audit,
• Compliance,
• SAST und DAST,
• langfristiger Support.

SaaS-Unternehmen, das GitHub nutzt

Shortlist:

• GitHub Code Security + Secret Protection,
• Snyk,
• Semgrep,
• ein separates Burp Suite DAST oder Invicti.

Prioritäten:

• PR feedback,
• Scandauer,
• dependency updates,
• secrets,
• API und DAST,
• minimale Reibung für Entwickler.

Cloud-native mit Kubernetes und Terraform

Shortlist:

• Snyk,
• Checkmarx One,
• alternativ eine Kombination aus GitHub/Semgrep plus spezialisiertem IaC- und Container-Security.

Prioritäten:

• SCA,
• Container,
• IaC,
• private registries,
• runtime context,
• DAST/API.

Organisation mit vorhandenem SonarQube

Shortlist:

• SonarQube Advanced Security,
• GitHub Code Security,
• Semgrep,
• ein dediziertes DAST.

Die Entscheidung sollte beantworten, ob die Konsolidierung von Qualität und Sicherheit wichtiger ist als das breitere Portfolio eines einzelnen Anbieters.

18. Das abschließende Fazit

Bester Kandidat für eine breite Single-Vendor-Plattform

Checkmarx One hat einen sehr breiten, offiziell bestätigten Umfang, der Code, Open Source, Secrets, IaC, Container, API und DAST umfasst.

Das qualifiziert ihn für einen POC, garantiert aber keinen automatischen Sieg.

Am natürlichsten für Legacy und kontrolliertes Enterprise

Fortify bleibt ein starker Kandidat für große, regulierte und technologisch heterogene Organisationen.

Am natürlichsten als verwaltetes Programm, das Code und Runtime abdeckt

Veracode ist die logische Wahl für ein Unternehmen, das eine zentrale Service-Plattform mit SAST, SCA, DAST sowie einem separaten Container-Security-Modul mit IaC und Secrets bevorzugt, statt viele Scanner zu betreiben.

Am natürlichsten als cloud-native Developer-first

Snyk hat bestätigte Module Code, Open Source, Container, IaC sowie API & Web DAST. Ältere Vergleiche, die DAST auslassen, sind überholt.

Geringste Reibung in einer GitHub-Umgebung

GitHub Code Security und Secret Protection bieten die engste Integration mit Repositories und Pull Requests, erfordern aber eine separate Runtime-DAST-Schicht.

Bester Kandidat für eigene Guardrails

Semgrep ist besonders attraktiv, wenn eine Organisation schnell eigene Regeln für SAST, SCA und Secrets nah am Entwickler aufbauen und pflegen möchte.

DAST

Burp Suite DAST und Invicti sollten an der eigenen Anwendung verglichen werden. Es gibt keine belastbare Grundlage, um ohne einen Test von Authentifizierung, API, Workflow und Abdeckung einen bedingungslosen Sieger zu benennen.

Meist wird die beste Enterprise-Lösung kein einzelner Scanner sein, sondern ein bewusst gestalteter Satz: Repository-Schicht + Supply Chain + Runtime-DAST + Governance.

19. Checkliste für die Auswahl

Umfang

• Die benötigten Testarten sind definiert.
• SAST und SCA werden separat bewertet.
• Es ist festgelegt, ob DAST benötigt wird.
• Es ist festgelegt, ob Secrets benötigt werden.
• Es ist festgelegt, ob IaC und Container benötigt werden.
• Die Anforderungen an API Security sind festgelegt.
• Kritische Anwendungen und Sprachen sind definiert.

POC

• Jedes Produkt scannt denselben Code.
• Es werden dieselben Versionen und Konfigurationen verwendet.
• Der Test umfasst die eigene Anwendung.
• Der Test umfasst ein Monorepo.
• Der Test umfasst einen Pull Request.
• DAST durchläuft die Authentifizierung.
• Rollen und Workflow werden getestet.
• Die false positives wurden gemessen.
• Die false negatives wurden manuell geprüft.
• Die Zeit bis zur Behebung wurde gemessen.

Enterprise

• SSO, SCIM und RBAC wurden bestätigt.
• Der audit log wurde bestätigt.
• Datenmodell und Region wurden bestätigt.
• Die Integration mit SCM und CI wurde bestätigt.
• Der Zugriff auf private Anwendungen wurde bestätigt.
• Die Unterstützung von Proxy und Registry wurde bestätigt.
• Die Datenretention wurde bestätigt.
• API und Export wurden bestätigt.
• Das Modell für Ausnahmen wurde bestätigt.
• Die TCO wurden berechnet, nicht nur die Lizenz.

Einführung

• Die Eigentümer der Findings sind definiert.
• Die SLA nach Risiko sind definiert.
• Neuer Code ist vom Backlog getrennt.
• Das Quality Gate blockiert ausschließlich belastbare Probleme.
• Es gibt einen Prozess zum Tuning der Regeln.
• Ausnahmen haben ein Ablaufdatum.
• Die DAST-Ergebnisse werden mit SAST dedupliziert.
• Der Entwickler erhält Kontext und eine Anleitung zur Behebung.
• Das Team misst die Fix Rate, nicht die Anzahl der Alerts.

20. POLPROG-Werkzeuge und -Materialien

Automatische Scanner sollten durch eine Prüfung der öffentlichen Schicht ergänzt werden:

• Website-Zustand hilft, technische, SEO-, Performance- und Accessibility-Probleme zu erkennen.
• Inspektor für Sicherheits-Header prüft CSP, HSTS und andere Schutzmaßnahmen der HTTP-Antwort.
• DNS- und SSL-Inspektor analysiert die Domain-Schicht sowie TLS.
• FlowTrace hilft, den Ablauf einer Anfrage durch DNS, TLS, CDN, Backend und Rendering zu visualisieren.
• In der POLPROG-Wissensdatenbank finden sich Materialien zur Sicherheit von Anwendungen und Infrastruktur.