Fortify vs Checkmarx One vs Veracode vs Snyk vs GitHub Code Security vs Semgrep: które narzędzie AppSec dla enterprise wybrać w 2026 roku?

• czy kod własny zawiera podatności,
• czy zależności open source mają znane CVE lub problemy licencyjne,
• czy w repozytorium znajdują się sekrety,
• czy Terraform, Kubernetes lub CloudFormation są błędnie skonfigurowane,
• czy obraz kontenera zawiera podatne pakiety,
• czy działająca aplikacja i API są podatne z perspektywy atakującego,
• czy wyniki da się przypisać właścicielom, priorytetyzować i egzekwować w tysiącach repozytoriów.

Żadne pojedyncze słowo „scanner” nie obejmuje automatycznie wszystkich tych warstw.

W 2026 roku najczęściej rozważane platformy enterprise to między innymi:

• OpenText Fortify,
• Checkmarx One,
• Veracode,
• Snyk,
• GitHub Code Security i GitHub Secret Protection, historycznie opisywane wspólną nazwą GitHub Advanced Security,
• Semgrep.

Do tego dochodzą rozwiązania uzupełniające, takie jak:

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

Ten artykuł nie przyznaje fikcyjnych ocen typu „9,8/10”, nie powtarza deklaracji dostawców dotyczących procentowej skuteczności i nie tworzy zwycięzcy na podstawie liczby pozycji w cenniku.

Najlepsze narzędzie AppSec to nie produkt z największą tabelą funkcji. To produkt albo zestaw produktów, który wykrywa istotne problemy w rzeczywistym stosie organizacji, mieści się w jej modelu wdrożenia i prowadzi do napraw, zamiast generować nieobsługiwany backlog.

Zakres produktów i dokumentację zweryfikowano 23 lipca 2026 roku.

TL;DR

Scenariusz	Najbardziej naturalny punkt startowy
Duża organizacja regulowana, legacy, wymagania wdrożeniowe i rozbudowany SAST/DAST	Fortify
Jedna szeroka platforma obejmująca kod, dependencies, IaC, sekrety, API, kontenery i DAST	Checkmarx One
Zarządzany program AppSec z centralnymi politykami, SAST, SCA i DAST	Veracode
Developer-first dla kodu, open source, kontenerów, IaC oraz obecnie także DAST/API	Snyk
Organizacja pracująca głównie w GitHubie i chcąca security w pull requestach	GitHub Code Security + Secret Protection
Szybki, konfigurowalny SAST/SCA/secrets i własne reguły	Semgrep
Firma już wykorzystująca SonarQube jako quality gate	SonarQube Advanced Security jako rozszerzenie
Dedykowany enterprise DAST dla web i API	Burp Suite DAST lub Invicti, ocenione w osobnym POC

Nie jest to tabela bezwarunkowych zwycięzców. To mapa produktów, których architektura najlepiej odpowiada danemu problemowi.

1. Najpierw rozdziel rodzaje testów

OWASP ASVS stanowi otwartą podstawę do definiowania wymagań i poziomu rygoru weryfikacji bezpieczeństwa aplikacji. Nie zakłada, że jedno automatyczne narzędzie zweryfikuje wszystkie wymagania.

SAST

Static Application Security Testing analizuje kod lub artefakty bez uruchamiania aplikacji.

Może wykrywać między innymi:

• przepływ niezaufanych danych do niebezpiecznego sinka,
• błędy walidacji,
• hardcoded credentials,
• problemy kryptograficzne,
• niebezpieczne API,
• wybrane błędy autoryzacji i logiki.

SAST nie potwierdza automatycznie, że podatność da się wykorzystać w konkretnym środowisku runtime.

SCA

Software Composition Analysis analizuje zależności, pakiety, wersje, podatności i licencje open source.

SCA odpowiada na inne pytanie niż SAST:

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

Secrets scanning

Wykrywa klucze, tokeny, hasła i inne dane uwierzytelniające w aktualnym kodzie, historii Git oraz czasami przed wykonaniem push.

IaC scanning

Analizuje Terraform, Kubernetes, Helm, CloudFormation, ARM i inne deklaracje infrastruktury.

Container scanning

Analizuje obrazy, system bazowy, pakiety systemowe, zależności aplikacyjne i czasem konfigurację workloadu.

DAST

Dynamic Application Security Testing testuje działającą aplikację od zewnątrz. OWASP definiuje DAST jako test black-box komunikujący się z aplikacją przez jej interfejs webowy.

DAST może znaleźć:

• problemy konfiguracji serwera,
• podatności widoczne dopiero w runtime,
• część błędów uwierzytelnienia i sesji,
• SQL injection,
• XSS,
• podatności endpointów API,
• problemy zależne od realnego deploymentu.

Nie widzi kodu źródłowego i nie zastępuje code review.

ASPM i governance

Application Security Posture Management agreguje wyniki, przypisuje aplikacje do właścicieli, koreluje findings i pomaga stosować polityki w skali organizacji.

Platforma może mieć szeroki dashboard, ale nadal korzystać z silników o różnej głębokości. Sama obecność wspólnego UI nie dowodzi równej jakości wszystkich modułów.

2. Jak powstało porównanie?

Do tabeli trafiła funkcja tylko wtedy, gdy została potwierdzona w aktualnej oficjalnej dokumentacji dostawcy.

Nie wykorzystujemy jako dowodu:

• rankingów sponsorowanych,
• wpisów partnerów handlowych,
• liczb „accuracy” bez niezależnej metodologii,
• deklaracji „zero false positives”,
• ogólnych nagród marketingowych,
• pojedynczego wyniku OWASP Benchmark podanego przez producenta.

Symbole w macierzy

Symbol	Znaczenie
●	potwierdzona, natywna część aktualnej oferty
◐	funkcja dostępna przez oddzielny moduł, dodatek albo wyraźnie węższy zakres
-	brak potwierdzonego natywnego modułu w analizowanej ofercie
POC	nie da się uczciwie ocenić bez testu na stosie organizacji

3. Macierz zakresu produktów

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

Tabela pokazuje zakres, nie skuteczność.

Przykład: produkt posiadający natywne SAST i DAST nie musi wygrać z połączeniem najlepszego narzędzia repozytoryjnego oraz osobnego DAST. Z kolei dwa osobne produkty mogą zwiększyć koszt integracji, liczbę dashboardów i trudność deduplikacji wyników.

4. OpenText Fortify

Aktualna oferta Fortify obejmuje osobne rozwiązania dla:

• SAST,
• DAST,
• Software Composition Analysis,
• zarządzanego Fortify on Demand.

OpenText opisuje Fortify SAST jako rozwiązanie enterprise z elastycznymi modelami wdrożenia. Fortify DAST testuje działające aplikacje, API i usługi. Fortify Software Composition Analysis jest osobnym produktem analizującym komponenty open source. Fortify on Demand udostępnia w modelu usługowym między innymi SAST, DAST i MAST.

Najważniejsze rozróżnienie nazewnictwa

Historyczna nazwa Fortify Static Code Analyzer była często skracana do „Fortify SCA”.

W nowym kontekście SCA oznacza jednak Software Composition Analysis.

Dlatego w dokumentacji i zamówieniu należy precyzyjnie rozróżnić:

Fortify SAST / Static Code Analyzer
Fortify Software Composition Analysis

To nie są te same testy.

Mocne strony Fortify

• rozbudowany SAST i DAST w jednej rodzinie produktów,
• możliwość wdrożeń wymagających większej kontroli infrastruktury,
• oferta SaaS przez Fortify on Demand,
• wsparcie dla tradycyjnych środowisk enterprise i starszych stosów,
• centralne zarządzanie programem AppSec.

OpenText w wydaniu SAST 26.2 ogłosił między innymi rozszerzenia dotyczące COBOL, Fortran, C++23, PHP 8.5, Kotlin 2.3 i Swift 6.3. To istotne dla organizacji posiadających mieszankę nowoczesnych i starszych systemów.

Ograniczenia, które trzeba sprawdzić

• czas pełnego i przyrostowego skanu na własnych monorepozytoriach,
• wymagania dotyczące buildów i przygotowania artefaktów,
• jakość integracji z pull requestami,
• koszt operacyjny infrastruktury self-managed,
• sposób obsługi IaC i kontenerów, jeżeli są wymagane,
• ergonomia triage dla developerów.

Dla kogo?

Fortify jest naturalnym kandydatem dla:

• banków,
• telekomów,
• administracji,
• dużych organizacji z wymaganiami dotyczącymi deploymentu i danych,
• środowisk z Java, .NET, C/C++, COBOL i innymi długowiecznymi technologiami.

Nie oznacza to automatycznego zwycięstwa w nowym, cloud-native startupie. Oznacza dobre dopasowanie modelu produktu do złożonego enterprise.

5. Checkmarx One

Checkmarx One jest pozycjonowany jako szeroka platforma Application Security obejmująca etapy od tworzenia kodu do runtime.

Oficjalne materiały potwierdzają między innymi:

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

Największa zaleta

Checkmarx One jest jednym z najbardziej naturalnych kandydatów, gdy celem procurementu jest ograniczenie liczby dostawców.

W jednej architekturze można objąć:

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

Co trzeba zweryfikować w POC?

Szerokość portfolio nie odpowiada na pytanie o głębokość.

Należy osobno zmierzyć:

• SAST na językach kluczowych dla firmy,
• jakość reachability w SCA,
• pokrycie IaC,
• obsługę prywatnych registry i obrazów bazowych,
• uwierzytelnione skanowanie DAST,
• import OpenAPI, GraphQL i realne workflow,
• sposób korelacji wyników pomiędzy modułami,
• data residency oraz przetwarzanie kodu.

Dla kogo?

Checkmarx One warto umieścić wysoko na liście, gdy:

• firma chce jednego strategicznego dostawcę AppSec,
• potrzebuje więcej niż SAST i SCA,
• posiada wiele zespołów, języków, chmur i repozytoriów,
• centralny zespół bezpieczeństwa chce governance ponad całym SDLC.

Uczciwy werdykt

Najszerszy potwierdzony zakres nie oznacza „najlepszego silnika we wszystkim”. Checkmarx One powinien wygrać dopiero po udowodnieniu, że najważniejsze dla organizacji dwa albo trzy moduły są wystarczająco dobre.

6. Veracode

Veracode oferuje platformę Application Risk Management i potwierdzone produkty dla:

• SAST,
• SCA,
• DAST,
• Container Security,
• skanowania IaC,
• wykrywania sekretów,
• workflow skanowania i centralnego zarządzania wynikami.

Veracode SAST analizuje aplikacje statycznie, DAST testuje działające aplikacje i API, a Veracode Container Security skanuje kontenery, pliki IaC oraz ujawnione sekrety.

Mocne strony

• spójny, zarządzany model platformowy,
• SAST, SCA i DAST w jednym programie,
• centralne polityki i raportowanie,
• ograniczenie potrzeby utrzymywania ciężkiej infrastruktury skanerów,
• podejście odpowiednie dla organizacji preferującej SaaS.

Ważna cecha architektoniczna

Veracode od lat kojarzy się z analizą przygotowanych artefaktów binarnych lub bytecode w części statycznych workflow. Aktualna konfiguracja zależy od języka i typu skanu, dlatego POC musi odtworzyć rzeczywisty proces buildowania organizacji, a nie wyłącznie mały projekt demonstracyjny.

Ograniczenia do sprawdzenia

• jak szybko developer otrzymuje wynik po zmianie,
• ile pracy wymaga przygotowanie artefaktu,
• jak zachowuje się Pipeline Scan względem pełnego policy scan,
• obsługa monorepo,
• integracja z self-hosted SCM i CI,
• wymagania dotyczące wysyłania artefaktów,
• jakość i zakres Container Security, IaC oraz secrets na rzeczywistych artefaktach organizacji.

Dla kogo?

Veracode jest mocnym kandydatem dla organizacji, która chce:

• zarządzanego, centralnego AppSec,
• połączenia SAST, SCA i DAST,
• polityk i raportów bez budowania własnej platformy skanującej,
• spójnego modelu dla wielu zespołów.

7. Snyk

Aktualna oferta Snyk jest szersza niż wcześniejsze skojarzenie wyłącznie z dependency scanning.

Oficjalne produkty obejmują:

• Snyk Code - SAST,
• Snyk Open Source - SCA i license compliance,
• Snyk Container,
• Snyk IaC,
• Snyk API & Web - cloud-based DAST dla aplikacji i API.

Snyk posiada także warstwę zarządzania i priorytetyzacji ryzyka aplikacyjnego.

Mocne strony

• integracja z IDE, CLI, SCM i CI/CD,
• nacisk na workflow developera,
• jedna rodzina produktów dla kodu, dependencies, kontenerów, IaC i runtime DAST,
• remediation guidance,
• kontekst dotyczący reachability, exploita i deploymentu w wybranych modułach,
• dobre dopasowanie do cloud-native i platform engineering.

Ważna aktualizacja względem starszych porównań

Stwierdzenie „Snyk nie ma DAST” jest w 2026 roku nieaktualne.

Snyk API & Web jest oficjalnie opisany jako chmurowe rozwiązanie DAST dla działających aplikacji webowych i API.

Dlatego aktualne porównanie musi oceniać jego realne pokrycie względem dedykowanych produktów Burp Suite DAST, Invicti, Fortify DAST, Checkmarx DAST i Veracode DAST.

Co sprawdzić?

• pokrycie języków w SAST,
• dokładność i czas skanu na realnym repozytorium,
• jakość fix suggestions,
• SCA dla transitive dependencies i monorepo,
• własne obrazy bazowe i prywatne registry,
• Terraform, Kubernetes, Helm i CloudFormation,
• DAST dla uwierzytelnionych aplikacji i złożonych API,
• model danych i region hostingu,
• całkowity koszt kilku modułów.

Dla kogo?

Snyk jest naturalnym kandydatem dla:

• firm cloud-native,
• zespołów korzystających z kontenerów i IaC,
• organizacji chcących bezpieczeństwa blisko developera,
• zespołów, które potrzebują szerokiej platformy, ale nie chcą zaczynać od ciężkiego, tradycyjnego SAST.

8. GitHub Code Security i GitHub Secret Protection

W aktualnym modelu GitHub rozdziela płatne funkcje na:

• GitHub Code Security,
• GitHub Secret Protection.

Dokumentacja nadal opisuje je jako produkty GitHub Advanced Security.

GitHub Code Security obejmuje między innymi:

• code scanning,
• CodeQL,
• premium funkcje Dependabot,
• dependency review.

GitHub Secret Protection obejmuje między innymi:

• secret scanning,
• push protection,
• custom patterns,
• wykrywanie wybranych nieustrukturyzowanych credentials.

CodeQL jest silnikiem analizy kodu rozwijanym przez GitHub. Dependabot może tworzyć pull requesty aktualizujące podatne zależności.

Największa zaleta

Wyniki są dostępne w miejscu, w którym developer:

• otwiera pull request,
• przegląda diff,
• stosuje branch protection,
• prowadzi code review,
• uruchamia Actions,
• zarządza właścicielami repozytorium.

To redukuje tarcie organizacyjne.

Czego GitHub nie zastępuje?

Natywna oferta nie jest pełnym odpowiednikiem:

• enterprise DAST,
• skanowania działających workflow aplikacji,
• dedykowanego IaC security suite,
• pełnego container security platform,
• manualnego pentestu.

GitHub code scanning może przyjmować wyniki narzędzi zewnętrznych, ale agregowanie SARIF nie oznacza, że GitHub sam wykonał te testy.

Dla kogo?

Najmocniejsze dopasowanie występuje, gdy:

• GitHub jest standardem całej organizacji,
• security ma działać w pull requestach,
• CodeQL obsługuje kluczowe języki,
• zespół akceptuje dołożenie osobnego DAST oraz ewentualnie IaC/container scanner.

Potencjalny zestaw

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

Może być lepszy niż szeroka platforma dla firmy, która chce maksymalnie wykorzystać istniejący ekosystem GitHub.

9. Semgrep

Semgrep AppSec Platform potwierdza trzy główne produkty:

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

Platforma integruje się z SCM i CI, umożliwia zarządzanie politykami oraz blokowanie wybranych problemów w pull requestach.

Największa zaleta

Semgrep umożliwia tworzenie własnych reguł dopasowanych do:

• frameworków wewnętrznych,
• wrapperów bezpieczeństwa,
• firmowych anti-patternów,
• zasad architektonicznych,
• niebezpiecznych funkcji,
• procesów autoryzacji.

Przykładowa uproszczona reguła:

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

Łatwość pisania reguł może być ważniejsza niż kolejny tysiąc ogólnych checks.

Mocne strony

• szybka informacja w workflow developera,
• konfigurowalne reguły,
• SAST, SCA i secrets w jednej platformie,
• sensowne zastosowanie w monorepo i nowoczesnych stosach,
• możliwość wdrażania guardrails specyficznych dla organizacji.

Ograniczenia

Semgrep nie jest natywnym enterprise DAST i nie zastępuje:

• testowania działającej aplikacji,
• crawlingu uwierzytelnionego,
• runtime API attacks,
• pełnego container security,
• dedykowanego IaC security suite.

Dla kogo?

Semgrep warto wybrać, gdy:

• security chce szybko tworzyć własne reguły,
• developer experience jest priorytetem,
• organizacja akceptuje składany zestaw narzędzi,
• osobny DAST i container/IaC scanner są częścią planu.

10. SonarQube Advanced Security

SonarQube przez lata był kojarzony przede wszystkim z code quality i statyczną analizą.

W 2026 roku SonarQube Advanced Security rozszerza ofertę enterprise o:

• Advanced SAST,
• Software Composition Analysis,
• dodatkowe funkcje bezpieczeństwa i compliance.

Dokumentacja i release notes potwierdzają także rozwijane reguły secrets detection.

Kiedy ma sens?

Gdy organizacja już wykorzystuje SonarQube jako obowiązkowy quality gate, rozszerzenie istniejącej platformy może być operacyjnie prostsze niż wdrożenie nowego dashboardu dla każdego repozytorium.

Czego nie zakładać?

SonarQube Advanced Security nie staje się przez to automatycznie:

• DAST-em,
• platformą do uwierzytelnionych testów webowych,
• pełnym container scannerem,
• kompletną platformą IaC.

Rola w porównaniu

SonarQube jest silną alternatywą konsolidacyjną dla firm, które chcą łączyć quality i security w istniejącym procesie. Nie jest jednak identyczną kategorią jak szerokie platformy obejmujące runtime.

11. Burp Suite DAST i Invicti

DAST należy oceniać osobno, ponieważ jakość dynamicznego skanu zależy od:

• crawl coverage,
• obsługi SPA,
• uwierzytelnienia,
• utrzymania sesji,
• nagrywania złożonych workflow,
• API discovery,
• importu OpenAPI, GraphQL lub SOAP,
• kontroli intensywności skanu,
• weryfikacji findings,
• działania w sieci wewnętrznej.

Burp Suite DAST

PortSwigger dokumentuje:

• integrację CI-driven scans z platformami obsługującymi kontenery,
• wariant cloud oraz self-hosted,
• GraphQL API i REST API do integracji.

Naturalną zaletą jest powiązanie z ekosystemem Burp używanym przez pentesterów.

Invicti

Invicti jest dedykowaną platformą DAST dla web i API. Oficjalna dokumentacja opisuje discovery, stateful API scanning i proof-based validation.

Deklaracje producenta dotyczące procentowej dokładności nie powinny być przenoszone do decyzji zakupowej bez niezależnego testu.

Który jest lepszy?

Nie da się uczciwie odpowiedzieć na podstawie strony produktowej.

POC musi objąć:

• logowanie przez SSO,
• MFA,
• odświeżanie tokenu,
• role użytkowników,
• workflow wieloetapowy,
• SPA,
• REST,
• GraphQL,
• upload,
• webhooki,
• endpointy wewnętrzne,
• ryzyko uszkodzenia danych.

12. Porównanie dopasowania organizacyjnego

Kryterium	Fortify	Checkmarx One	Veracode	Snyk	GitHub	Semgrep
Regulowane enterprise i legacy	bardzo naturalne	naturalne	naturalne	zależne od stosu	jako warstwa repo	jako warstwa repo
Jedna szeroka platforma	szeroka	bardzo szeroka	SAST/SCA/DAST	bardzo szeroka	nie	nie
Developer-first	POC	POC	POC	mocny profil	bardzo mocny w GitHub	bardzo mocny
Self-managed / kontrola infrastruktury	mocny kandydat	sprawdzić model	głównie zarządzany model	sprawdzić moduł	GHES dla części funkcji	opcje enterprise
Legacy languages	mocny profil	POC	POC	POC	zależnie od CodeQL	zależnie od języka
IaC i containers	dodatkowe narzędzia	natywne moduły	natywny moduł Container Security	natywne moduły	dodatkowe narzędzia	dodatkowe narzędzia
Natywny DAST	tak	tak	tak	tak	nie	nie
Własne reguły SAST	możliwe, sprawdzić koszt	możliwe, POC	POC	POC	CodeQL queries	kluczowa zaleta

„Mocny profil” nadal wymaga POC.

13. Czy można wskazać jednego zwycięzcę?

Nie w sposób odpowiedzialny.

Można natomiast wskazać najbardziej logiczne shortlisty.

Shortlista A: jedna platforma o szerokim zakresie

Checkmarx One
Snyk
Fortify
Veracode

Należy nadać wagę modułom. Przykład:

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

Jeżeli firma nie potrzebuje IaC ani kontenerów, ich waga powinna wynosić zero. Nie wolno przyznawać punktów za moduł, który nie rozwiązuje żadnego problemu organizacji.

Shortlista B: GitHub-native

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

Shortlista C: custom rules i developer-first

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

Shortlista D: legacy i kontrola deploymentu

Fortify SAST + DAST + Software Composition Analysis

Należy sprawdzić, czy pozostałe warstwy będą obsługiwane przez istniejące narzędzia infrastrukturalne.

Shortlista E: istniejący SonarQube

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

14. Jak przeprowadzić uczciwy POC?

OWASP Benchmark zawiera zestawy testowe i narzędzia do oceny accuracy, coverage i szybkości automatycznych skanerów.

Nie powinien być jednak jedyną podstawą decyzji:

• część testów jest syntetyczna,
• Java Benchmark jest utrzymywany bez istotnej zmiany przypadków od wielu lat,
• nowy Benchmark dla Python ma inny poziom dojrzałości,
• wynik nie mierzy workflow developera,
• nie mierzy governance,
• nie odtwarza firmowych frameworków.

OWASP Juice Shop jest celowo podatną aplikacją Node.js, Express i Angular, przydatną do ćwiczeń oraz testowania narzędzi na JavaScriptowym frontendzie i REST API.

Minimalny zestaw testowy

1. OWASP Benchmark dla wspieranego języka.
2. OWASP Juice Shop dla DAST.
3. Własna aplikacja reprezentująca stack produkcyjny.
4. Monorepo o realnej wielkości.
5. Repozytorium z:
   • podatnymi dependencies,
   • sekretem w bieżącej wersji,
   • sekretem w historii Git,
   • Dockerfile,
   • Terraform,
   • Kubernetes,
   • wygenerowanym kodem.
6. Działające środowisko z:
   • SSO,
   • kilkoma rolami,
   • REST i GraphQL,
   • funkcją upload,
   • procesem wieloetapowym.

15. Metryki POC

Skuteczność wykrywania

• true positives,
• false positives,
• false negatives,
• duplikaty,
• findings bez realnej ścieżki wykonania,
• podatności zależności rzeczywiście osiągalne.

Wydajność

• czas pierwszego pełnego skanu,
• czas skanu pull requestu,
• czas po zmianie jednej linii,
• wykorzystanie CPU i RAM,
• zachowanie na monorepo,
• równoległość.

Remediation

• czy wynik wskazuje source i sink,
• czy pokazuje pełny data flow,
• czy naprawa jest zgodna z frameworkiem,
• czy developer może zweryfikować wynik bez zespołu AppSec,
• czy automatyczna poprawka przechodzi testy,
• ile wyników zostaje zamkniętych jako „won’t fix”.

Governance

• RBAC,
• SSO i SCIM,
• audit log,
• polityki per business unit,
• wyjątki z datą wygaśnięcia,
• SLA,
• aplikacje i właściciele,
• integracja z Jira lub innym systemem,
• eksport danych,
• API,
• raporty compliance.

Deployment i dane

• SaaS, self-hosted lub hybryda,
• region danych,
• czy kod opuszcza organizację,
• sposób przechowywania artefaktów,
• prywatne registry,
• wewnętrzne aplikacje,
• proxy,
• air-gapped environment,
• szyfrowanie,
• retencja.

Koszt całkowity

Nie tylko cena licencji:

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

Tanie narzędzie z tysiącami nieobsługiwanych findings może być droższe od platformy z wyższą ceną licencji.

16. Typowe błędy procurementu

Kupowanie na podstawie liczby języków

„Obsługa języka” może znaczyć:

• parser składni,
• podstawowe reguły,
• pełny interprocedural data flow,
• obsługę konkretnych frameworków.

POC musi używać frameworków organizacji.

Łączenie SAST i SCA

Są to odrębne techniki. Podobny skrót w historycznej nazwie Fortify dodatkowo zwiększa ryzyko pomyłki.

Liczenie każdego modułu tak samo

Jeżeli firma nie używa Terraform, moduł IaC nie powinien poprawiać oceny.

Testowanie tylko publicznej aplikacji demo

Mały benchmark nie odtwarza:

• monorepo,
• custom framework,
• wewnętrznego package managera,
• build system,
• SSO,
• prywatnej sieci.

Brak testu developer experience

Narzędzie może znajdować dobre problemy, ale przegrać wdrożenie przez:

• wyniki po kilku godzinach,
• brak komentarza w PR,
• niezrozumiałe remediation,
• skomplikowane suppressions,
• niestabilne buildy.

Wiara w marketingową liczbę false positives

Bez publicznego zbioru, konfiguracji, wersji i definicji wyniku liczba nie nadaje się do porównania.

Zakup DAST bez rozwiązania uwierzytelnienia

Scanner, który nie przechodzi logowania, może testować tylko mały publiczny fragment aplikacji.

17. Rekomendacje według typu firmy

Bank, ubezpieczenia, administracja

Shortlista:

• Fortify,
• Checkmarx One,
• Veracode.

Priorytety:

• deployment i dane,
• legacy languages,
• audit,
• compliance,
• SAST i DAST,
• długoterminowe wsparcie.

Firma SaaS używająca GitHub

Shortlista:

• GitHub Code Security + Secret Protection,
• Snyk,
• Semgrep,
• osobny Burp Suite DAST albo Invicti.

Priorytety:

• PR feedback,
• czas skanu,
• dependency updates,
• secrets,
• API i DAST,
• minimalne tarcie developera.

Cloud-native z Kubernetes i Terraform

Shortlista:

• Snyk,
• Checkmarx One,
• alternatywnie zestaw GitHub/Semgrep plus wyspecjalizowane IaC i container security.

Priorytety:

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

Organizacja z istniejącym SonarQube

Shortlista:

• SonarQube Advanced Security,
• GitHub Code Security,
• Semgrep,
• dedykowany DAST.

Decyzja powinna odpowiedzieć, czy konsolidacja jakości i bezpieczeństwa jest ważniejsza od szerszego portfolio jednego dostawcy.

18. Ostateczny werdykt

Najlepszy kandydat na szeroką platformę jednego dostawcy

Checkmarx One ma bardzo szeroki, oficjalnie potwierdzony zakres obejmujący kod, open source, sekrety, IaC, kontenery, API i DAST.

To kwalifikuje go do POC, ale nie daje automatycznej wygranej.

Najbardziej naturalny dla legacy i kontrolowanego enterprise

Fortify pozostaje mocnym kandydatem dla dużych, regulowanych i technologicznie zróżnicowanych organizacji.

Najbardziej naturalny zarządzany program obejmujący kod i runtime

Veracode jest logicznym wyborem dla firmy preferującej centralną platformę usługową obejmującą SAST, SCA, DAST oraz osobny moduł Container Security z IaC i secrets, zamiast utrzymywania wielu skanerów.

Najbardziej naturalny cloud-native developer-first

Snyk ma potwierdzone moduły Code, Open Source, Container, IaC oraz API & Web DAST. Starsze porównania pomijające DAST są nieaktualne.

Najmniejsze tarcie w środowisku GitHub

GitHub Code Security i Secret Protection zapewniają najściślejszą integrację z repozytoriami oraz pull requestami, ale wymagają osobnej warstwy runtime DAST.

Najlepszy kandydat do własnych guardrails

Semgrep jest szczególnie atrakcyjny, gdy organizacja chce szybko budować i utrzymywać własne reguły SAST, SCA i secrets blisko developera.

DAST

Burp Suite DAST i Invicti należy porównać na własnej aplikacji. Nie ma wiarygodnej podstawy, by wskazać bezwarunkowego zwycięzcę bez testu uwierzytelnienia, API, workflow oraz pokrycia.

Najczęściej najlepszym rozwiązaniem enterprise nie będzie jeden scanner, lecz świadomie zaprojektowany zestaw: warstwa repozytoryjna + supply chain + runtime DAST + governance.

19. Checklista wyboru

Zakres

• Zdefiniowano potrzebne rodzaje testów.
• SAST i SCA są oceniane osobno.
• Ustalono, czy potrzebny jest DAST.
• Ustalono, czy potrzebne są secrets.
• Ustalono, czy potrzebne są IaC i containers.
• Ustalono wymagania API Security.
• Zdefiniowano aplikacje i języki krytyczne.

POC

• Każdy produkt skanuje ten sam kod.
• Używane są te same wersje i konfiguracje.
• Test obejmuje aplikację własną.
• Test obejmuje monorepo.
• Test obejmuje pull request.
• DAST przechodzi uwierzytelnienie.
• Testowane są role i workflow.
• Zmierzono false positives.
• Ręcznie sprawdzono false negatives.
• Zmierzono czas do naprawy.

Enterprise

• Potwierdzono SSO, SCIM i RBAC.
• Potwierdzono audit log.
• Potwierdzono model danych i region.
• Potwierdzono integrację z SCM oraz CI.
• Potwierdzono dostęp do prywatnych aplikacji.
• Potwierdzono obsługę proxy i registry.
• Potwierdzono retencję danych.
• Potwierdzono API i eksport.
• Potwierdzono model wyjątków.
• Obliczono TCO, nie tylko licencję.

Wdrożenie

• Zdefiniowano właścicieli findings.
• Zdefiniowano SLA według ryzyka.
• Nowy kod jest oddzielony od backlogu.
• Quality gate blokuje wyłącznie wiarygodne problemy.
• Istnieje proces tuning reguł.
• Wyjątki mają datę wygaśnięcia.
• Wyniki DAST są deduplikowane z SAST.
• Developer otrzymuje kontekst i instrukcję naprawy.
• Zespół mierzy fix rate, a nie liczbę alertów.

20. Narzędzia i materiały POLPROG

Automatyczne skanery warto uzupełnić kontrolą warstwy publicznej:

• Kondycja witryny pomaga wykryć problemy techniczne, SEO, wydajnościowe i dostępnościowe.
• Inspektor nagłówków bezpieczeństwa sprawdza CSP, HSTS i inne zabezpieczenia odpowiedzi HTTP.
• Inspektor DNS i SSL analizuje warstwę domeny oraz TLS.
• FlowTrace pomaga wizualizować przepływ żądania przez DNS, TLS, CDN, backend i rendering.
• W bazie wiedzy POLPROG znajdują się materiały o bezpieczeństwie aplikacji i infrastruktury.