- se il codice proprietario contiene vulnerabilità,
- se le dipendenze open source hanno CVE noti o problemi di licenza,
- se nel repository sono presenti secret,
- se Terraform, Kubernetes o CloudFormation sono configurati in modo errato,
- se l'immagine del container contiene pacchetti vulnerabili,
- se l'applicazione in esecuzione e le API sono vulnerabili dal punto di vista di un attaccante,
- se i risultati possono essere assegnati ai proprietari, prioritizzati ed applicati in migliaia di repository.
Nessuna singola parola "scanner" copre automaticamente tutti questi livelli.
Nel 2026 le piattaforme enterprise più frequentemente prese in considerazione includono tra le altre:
- OpenText Fortify,
- Checkmarx One,
- Veracode,
- Snyk,
- GitHub Code Security e GitHub Secret Protection, storicamente descritti con il nome comune GitHub Advanced Security,
- Semgrep.
A questi si aggiungono soluzioni complementari, come:
- SonarQube Advanced Security,
- Burp Suite DAST,
- Invicti.
Questo articolo non assegna valutazioni fittizie del tipo "9,8/10", non ripete le dichiarazioni dei fornitori relative all'efficacia percentuale e non crea un vincitore in base al numero di voci nel listino prezzi.
Il miglior strumento AppSec non è il prodotto con la tabella di funzionalità più ampia. È il prodotto o l'insieme di prodotti che rileva i problemi rilevanti nello stack reale dell'organizzazione, rientra nel suo modello di deployment e porta alle correzioni, invece di generare un backlog ingestibile.
La gamma dei prodotti e la documentazione sono state verificate il 23 luglio 2026.
TL;DR
| Scenario | Punto di partenza più naturale |
|---|---|
| Grande organizzazione regolamentata, legacy, requisiti di deployment e SAST/DAST completi | Fortify |
| Un'unica piattaforma ampia che copre codice, dipendenze, IaC, secret, API, container e DAST | Checkmarx One |
| Programma AppSec gestito con policy centralizzate, SAST, SCA e DAST | Veracode |
| Developer-first per codice, open source, container, IaC e ora anche DAST/API | Snyk |
| Organizzazione che lavora principalmente in GitHub e vuole la sicurezza nelle pull request | GitHub Code Security + Secret Protection |
| SAST/SCA/secrets rapido e configurabile e regole personalizzate | Semgrep |
| Azienda che utilizza già SonarQube come quality gate | SonarQube Advanced Security come estensione |
| DAST enterprise dedicato per web e API | Burp Suite DAST o Invicti, valutati in un POC separato |
Non è una tabella di vincitori assoluti. È una mappa dei prodotti la cui architettura risponde meglio a un determinato problema.
1. Prima separa i tipi di test
OWASP ASVS costituisce una base aperta per definire i requisiti e il livello di rigore della verifica della sicurezza delle applicazioni. Non presuppone che un unico strumento automatico verifichi tutti i requisiti.
SAST
Lo Static Application Security Testing analizza il codice o gli artefatti senza eseguire l'applicazione.
Può rilevare tra l'altro:
- il flusso di dati non attendibili verso un sink pericoloso,
- errori di validazione,
- hardcoded credentials,
- problemi crittografici,
- API non sicure,
- alcuni errori di autorizzazione e di logica.
Il SAST non conferma automaticamente che una vulnerabilità sia sfruttabile in uno specifico ambiente runtime.
SCA
La Software Composition Analysis analizza dipendenze, pacchetti, versioni, vulnerabilità e licenze open source.
La SCA risponde a una domanda diversa rispetto al SAST:
SAST: czy nasz kod zawiera niebezpieczny wzorzec lub przepływ?
SCA: czy używany komponent ma znaną podatność albo ryzyko licencyjne?
Secrets scanning
Rileva chiavi, token, password e altre credenziali nel codice attuale, nella cronologia Git e talvolta prima dell'esecuzione del push.
IaC scanning
Analizza Terraform, Kubernetes, Helm, CloudFormation, ARM e altre dichiarazioni di infrastruttura.
Container scanning
Analizza le immagini, il sistema di base, i pacchetti di sistema, le dipendenze applicative e talvolta la configurazione del workload.
DAST
Il Dynamic Application Security Testing testa l'applicazione in esecuzione dall'esterno. OWASP definisce il DAST come un test black-box che comunica con l'applicazione attraverso la sua interfaccia web.
Il DAST può trovare:
- problemi di configurazione del server,
- vulnerabilità visibili solo in runtime,
- alcuni errori di autenticazione e di sessione,
- SQL injection,
- XSS,
- vulnerabilità degli endpoint API,
- problemi dipendenti dal deployment reale.
Non vede il codice sorgente e non sostituisce la code review.
ASPM e governance
L'Application Security Posture Management aggrega i risultati, assegna le applicazioni ai proprietari, correla i findings e aiuta ad applicare le policy su scala dell'organizzazione.
Una piattaforma può avere un'ampia dashboard, ma utilizzare comunque motori di profondità diversa. La sola presenza di una UI comune non dimostra una qualità uguale di tutti i moduli.
2. Come è nato il confronto?
Una funzionalità è finita nella tabella solo quando è stata confermata nella documentazione ufficiale attuale del fornitore.
Non utilizziamo come prova:
- classifiche sponsorizzate,
- contributi di partner commerciali,
- cifre di "accuracy" senza una metodologia indipendente,
- dichiarazioni "zero false positives",
- premi di marketing generici,
- un singolo risultato OWASP Benchmark fornito dal produttore.
Simboli nella matrice
| Simbolo | Significato |
|---|---|
| ● | parte confermata e nativa dell'offerta attuale |
| ◐ | funzionalità disponibile tramite un modulo separato, un componente aggiuntivo o con un ambito nettamente più ristretto |
| - | nessun modulo nativo confermato nell'offerta analizzata |
| POC | non è possibile valutare in modo corretto senza un test sullo stack dell'organizzazione |
3. Matrice della gamma dei prodotti
| Piattaforma | SAST | SCA | Secrets | IaC | Containers | DAST / API runtime | Governance centralizzata |
|---|---|---|---|---|---|---|---|
| Fortify | ● | ● | ◐ | - | - | ● | ● |
| Checkmarx One | ● | ● | ● | ● | ● | ● | ● |
| Veracode | ● | ● | ● | ● | ● | ● | ● |
| Snyk | ● | ● | ◐ | ● | ● | ● | ● |
| GitHub Code Security + Secret Protection | ● | ● | ● | - | - | - | ● |
| Semgrep | ● | ● | ● | - | - | - | ● |
| SonarQube Advanced Security | ● | ● | ● | - | - | - | ● |
| Burp Suite DAST | - | - | - | - | - | ● | ● |
| Invicti | - | - | - | - | - | ● | ● |
La tabella mostra la copertura, non l'efficacia.
Esempio: un prodotto dotato di SAST e DAST nativi non deve necessariamente battere la combinazione del miglior strumento a livello di repository e di un DAST separato. D'altro canto, due prodotti separati possono aumentare il costo di integrazione, il numero di dashboard e la difficoltà di deduplicazione dei risultati.
4. OpenText Fortify
L'offerta attuale di Fortify comprende soluzioni separate per:
- SAST,
- DAST,
- Software Composition Analysis,
- il Fortify on Demand gestito.
OpenText descrive Fortify SAST come una soluzione enterprise con modelli di deployment flessibili. Fortify DAST testa applicazioni, API e servizi in esecuzione. Fortify Software Composition Analysis è un prodotto separato che analizza i componenti open source. Fortify on Demand mette a disposizione in modalità servizio, tra l'altro, SAST, DAST e MAST.
La distinzione terminologica più importante
Il nome storico Fortify Static Code Analyzer veniva spesso abbreviato in "Fortify SCA".
Nel nuovo contesto, tuttavia, SCA indica Software Composition Analysis.
Per questo, nella documentazione e nell'ordine, occorre distinguere con precisione:
Fortify SAST / Static Code Analyzer
Fortify Software Composition Analysis
Non si tratta degli stessi test.
Punti di forza di Fortify
- SAST e DAST completi in un'unica famiglia di prodotti,
- possibilità di deployment che richiedono un maggiore controllo dell'infrastruttura,
- offerta SaaS tramite Fortify on Demand,
- supporto per ambienti enterprise tradizionali e stack più datati,
- gestione centralizzata del programma AppSec.
OpenText, nella release SAST 26.2, ha annunciato tra l'altro estensioni relative a COBOL, Fortran, C++23, PHP 8.5, Kotlin 2.3 e Swift 6.3. Questo è rilevante per le organizzazioni che hanno un mix di sistemi moderni e più datati.
Limiti da verificare
- il tempo di scansione completa e incrementale sui propri monorepository,
- i requisiti relativi alle build e alla preparazione degli artefatti,
- la qualità dell'integrazione con le pull request,
- il costo operativo dell'infrastruttura self-managed,
- il modo di gestire IaC e container, se necessari,
- l'ergonomia del triage per gli sviluppatori.
Per chi?
Fortify è un candidato naturale per:
- banche,
- aziende di telecomunicazioni,
- pubblica amministrazione,
- grandi organizzazioni con requisiti relativi al deployment e ai dati,
- ambienti con Java, .NET, C/C++, COBOL e altre tecnologie longeve.
Questo non significa una vittoria automatica in una nuova startup cloud-native. Significa un buon adattamento del modello di prodotto a un enterprise complesso.
5. Checkmarx One
Checkmarx One è posizionato come un'ampia piattaforma di Application Security che copre le fasi dalla scrittura del codice fino al runtime.
I materiali ufficiali confermano tra l'altro:
- SAST,
- SCA,
- secrets detection,
- IaC security,
- API Security,
- Container Security,
- DAST,
- software supply chain security.
Il vantaggio maggiore
Checkmarx One è uno dei candidati più naturali quando l'obiettivo del procurement è ridurre il numero di fornitori.
In un'unica architettura è possibile coprire:
kod własny
+ zależności
+ sekrety
+ IaC
+ kontenery
+ API
+ działającą aplikację
Cosa occorre verificare nel POC?
L'ampiezza del portfolio non risponde alla domanda sulla profondità.
Occorre misurare separatamente:
- il SAST sui linguaggi chiave per l'azienda,
- la qualità della reachability nella SCA,
- la copertura IaC,
- il supporto per i registry privati e le immagini di base,
- la scansione DAST autenticata,
- l'importazione di OpenAPI, GraphQL e i workflow reali,
- il modo di correlazione dei risultati tra i moduli,
- la data residency e l'elaborazione del codice.
Per chi?
Vale la pena collocare Checkmarx One in alto nella lista quando:
- l'azienda vuole un unico fornitore AppSec strategico,
- ha bisogno di più di SAST e SCA,
- dispone di molti team, linguaggi, cloud e repository,
- il team di sicurezza centrale vuole la governance sull'intero SDLC.
Verdetto onesto
La gamma confermata più ampia non significa "il miglior motore in tutto". Checkmarx One dovrebbe vincere solo dopo aver dimostrato che i due o tre moduli più importanti per l'organizzazione sono sufficientemente buoni.
6. Veracode
Veracode offre la piattaforma Application Risk Management e prodotti confermati per:
- SAST,
- SCA,
- DAST,
- Container Security,
- scansione IaC,
- rilevamento dei secret,
- workflow di scansione e gestione centralizzata dei risultati.
Veracode SAST analizza le applicazioni in modo statico, il DAST testa le applicazioni e le API in esecuzione, e Veracode Container Security esegue la scansione di container, file IaC e secret esposti.
Punti di forza
- un modello di piattaforma coerente e gestito,
- SAST, SCA e DAST in un unico programma,
- policy e reporting centralizzati,
- riduzione della necessità di mantenere una pesante infrastruttura di scanner,
- un approccio adatto a un'organizzazione che preferisce il SaaS.
Una caratteristica architetturale importante
Veracode è associato da anni all'analisi di artefatti binari o bytecode già preparati in una parte dei workflow statici. La configurazione attuale dipende dal linguaggio e dal tipo di scansione, quindi il POC deve riprodurre il processo di build reale dell'organizzazione, e non soltanto un piccolo progetto dimostrativo.
Limiti da verificare
- quanto rapidamente lo sviluppatore riceve il risultato dopo una modifica,
- quanto lavoro richiede la preparazione dell'artefatto,
- come si comporta il Pipeline Scan rispetto al policy scan completo,
- il supporto per il monorepo,
- l'integrazione con SCM e CI self-hosted,
- i requisiti relativi all'invio degli artefatti,
- la qualità e la copertura di Container Security, IaC e secrets sugli artefatti reali dell'organizzazione.
Per chi?
Veracode è un candidato forte per un'organizzazione che vuole:
- un AppSec gestito e centralizzato,
- la combinazione di SAST, SCA e DAST,
- policy e report senza costruire una propria piattaforma di scansione,
- un modello coerente per più team.
7. Snyk
L'offerta attuale di Snyk è più ampia rispetto alla precedente associazione esclusiva con il dependency scanning.
I prodotti ufficiali comprendono:
- Snyk Code - SAST,
- Snyk Open Source - SCA e license compliance,
- Snyk Container,
- Snyk IaC,
- Snyk API & Web - DAST cloud-based per applicazioni e API.
Snyk dispone anche di un livello di gestione e prioritizzazione del rischio applicativo.
Punti di forza
- integrazione con IDE, CLI, SCM e CI/CD,
- attenzione al workflow dello sviluppatore,
- un'unica famiglia di prodotti per codice, dependencies, container, IaC e DAST runtime,
- remediation guidance,
- contesto relativo a reachability, exploit e deployment in alcuni moduli,
- buon adattamento al cloud-native e al platform engineering.
Un aggiornamento importante rispetto ai confronti più datati
L'affermazione "Snyk non ha il DAST" nel 2026 non è più attuale.
Snyk API & Web è descritto ufficialmente come una soluzione DAST cloud per applicazioni web e API in esecuzione.
Per questo un confronto attuale deve valutare la sua copertura reale rispetto ai prodotti dedicati Burp Suite DAST, Invicti, Fortify DAST, Checkmarx DAST e Veracode DAST.
Cosa verificare?
- la copertura dei linguaggi nel SAST,
- la precisione e il tempo di scansione su un repository reale,
- la qualità dei fix suggestions,
- la SCA per transitive dependencies e monorepo,
- immagini di base personalizzate e registry privati,
- Terraform, Kubernetes, Helm e CloudFormation,
- il DAST per applicazioni autenticate e API complesse,
- il modello dei dati e la regione di hosting,
- il costo totale di più moduli.
Per chi?
Snyk è un candidato naturale per:
- aziende cloud-native,
- team che utilizzano container e IaC,
- organizzazioni che vogliono la sicurezza vicino allo sviluppatore,
- team che necessitano di un'ampia piattaforma ma non vogliono partire da un SAST tradizionale e pesante.
8. GitHub Code Security e GitHub Secret Protection
Nel modello attuale GitHub suddivide le funzionalità a pagamento in:
- GitHub Code Security,
- GitHub Secret Protection.
La documentazione continua a descriverli come prodotti GitHub Advanced Security.
GitHub Code Security comprende tra l'altro:
- code scanning,
- CodeQL,
- funzionalità premium di Dependabot,
- dependency review.
GitHub Secret Protection comprende tra l'altro:
- secret scanning,
- push protection,
- custom patterns,
- il rilevamento di alcune credentials non strutturate.
CodeQL è un motore di analisi del codice sviluppato da GitHub. Dependabot può creare pull request che aggiornano le dipendenze vulnerabili.
Il vantaggio maggiore
I risultati sono disponibili nel punto in cui lo sviluppatore:
- apre una pull request,
- esamina il diff,
- applica la branch protection,
- conduce la code review,
- esegue le Actions,
- gestisce i proprietari del repository.
Questo riduce l'attrito organizzativo.
Cosa non sostituisce GitHub?
L'offerta nativa non è un equivalente completo di:
- un DAST enterprise,
- la scansione dei workflow applicativi in esecuzione,
- una suite di IaC security dedicata,
- una piattaforma completa di container security,
- un pentest manuale.
GitHub code scanning può accettare i risultati di strumenti esterni, ma l'aggregazione di SARIF non significa che GitHub abbia eseguito personalmente quei test.
Per chi?
L'adattamento più forte si verifica quando:
- GitHub è lo standard dell'intera organizzazione,
- la sicurezza deve operare nelle pull request,
- CodeQL supporta i linguaggi chiave,
- il team accetta l'aggiunta di un DAST separato e, eventualmente, di uno scanner IaC/container.
Un possibile set
GitHub Code Security
+ GitHub Secret Protection
+ dedykowany DAST
+ opcjonalny IaC/container scanner
Può essere migliore di un'ampia piattaforma per un'azienda che vuole sfruttare al massimo l'ecosistema GitHub esistente.
9. Semgrep
Semgrep AppSec Platform conferma tre prodotti principali:
- Semgrep Code - SAST,
- Semgrep Supply Chain - SCA,
- Semgrep Secrets.
La piattaforma si integra con SCM e CI, consente la gestione delle policy e il blocco di alcuni problemi nelle pull request.
Il vantaggio maggiore
Semgrep consente di creare regole personalizzate adatte a:
- framework interni,
- wrapper di sicurezza,
- anti-pattern aziendali,
- principi architetturali,
- funzioni pericolose,
- processi di autorizzazione.
Un esempio di regola semplificata:
rules:
- id: internal-unsafe-query
message: Use the approved parameterized database wrapper.
severity: ERROR
languages: [javascript]
patterns:
- pattern: db.raw($QUERY)
La facilità di scrivere regole può essere più importante di altri mille check generici.
Punti di forza
- informazioni rapide nel workflow dello sviluppatore,
- regole configurabili,
- SAST, SCA e secrets in un'unica piattaforma,
- un utilizzo sensato in monorepo e stack moderni,
- la possibilità di implementare guardrails specifici per l'organizzazione.
Limiti
Semgrep non è un DAST enterprise nativo e non sostituisce:
- il test di un'applicazione in esecuzione,
- il crawling autenticato,
- runtime API attacks,
- un container security completo,
- una suite di IaC security dedicata.
Per chi?
Vale la pena scegliere Semgrep quando:
- la sicurezza vuole creare rapidamente regole personalizzate,
- la developer experience è una priorità,
- l'organizzazione accetta un set componibile di strumenti,
- un DAST separato e uno scanner container/IaC fanno parte del piano.
10. SonarQube Advanced Security
Per anni SonarQube è stato associato soprattutto alla code quality e all'analisi statica.
Nel 2026 SonarQube Advanced Security amplia l'offerta enterprise con:
- Advanced SAST,
- Software Composition Analysis,
- funzionalità aggiuntive di sicurezza e compliance.
La documentazione e le release notes confermano anche le regole di secrets detection in fase di sviluppo.
Quando ha senso?
Quando un'organizzazione utilizza già SonarQube come quality gate obbligatorio, ampliare la piattaforma esistente può essere operativamente più semplice rispetto all'introduzione di una nuova dashboard per ogni repository.
Cosa non presupporre?
SonarQube Advanced Security non diventa automaticamente per questo:
- un DAST,
- una piattaforma per test web autenticati,
- un container scanner completo,
- una piattaforma IaC completa.
Il ruolo nel confronto
SonarQube è una forte alternativa di consolidamento per le aziende che vogliono unire quality e security nel processo esistente. Non è però la stessa categoria delle ampie piattaforme che coprono il runtime.
11. Burp Suite DAST e Invicti
Il DAST va valutato separatamente, perché la qualità della scansione dinamica dipende da:
- crawl coverage,
- il supporto per le SPA,
- l'autenticazione,
- il mantenimento della sessione,
- la registrazione di workflow complessi,
- API discovery,
- l'importazione di OpenAPI, GraphQL o SOAP,
- il controllo dell'intensità della scansione,
- la verifica dei findings,
- il funzionamento nella rete interna.
Burp Suite DAST
PortSwigger documenta:
- l'integrazione delle CI-driven scans con piattaforme che supportano i container,
- la variante cloud e self-hosted,
- GraphQL API e REST API per l'integrazione.
Un vantaggio naturale è il legame con l'ecosistema Burp utilizzato dai pentester.
Invicti
Invicti è una piattaforma DAST dedicata per web e API. La documentazione ufficiale descrive discovery, stateful API scanning e proof-based validation.
Le dichiarazioni del produttore relative alla precisione percentuale non dovrebbero essere trasferite alla decisione di acquisto senza un test indipendente.
Quale è migliore?
Non è possibile rispondere in modo corretto basandosi sulla pagina di prodotto.
Il POC deve comprendere:
- il login tramite SSO,
- MFA,
- il refresh del token,
- i ruoli degli utenti,
- un workflow a più fasi,
- SPA,
- REST,
- GraphQL,
- upload,
- webhook,
- endpoint interni,
- il rischio di danneggiamento dei dati.
12. Confronto dell'adattamento organizzativo
| Criterio | Fortify | Checkmarx One | Veracode | Snyk | GitHub | Semgrep |
|---|---|---|---|---|---|---|
| Enterprise regolamentato e legacy | molto naturale | naturale | naturale | dipende dallo stack | come livello repo | come livello repo |
| Un'unica piattaforma ampia | ampia | molto ampia | SAST/SCA/DAST | molto ampia | no | no |
| Developer-first | POC | POC | POC | profilo forte | molto forte in GitHub | molto forte |
| Self-managed / controllo dell'infrastruttura | candidato forte | verificare il modello | modello principalmente gestito | verificare il modulo | GHES per alcune funzionalità | opzioni enterprise |
| Legacy languages | profilo forte | POC | POC | POC | dipende da CodeQL | dipende dal linguaggio |
| IaC e container | strumenti aggiuntivi | moduli nativi | modulo nativo Container Security | moduli nativi | strumenti aggiuntivi | strumenti aggiuntivi |
| DAST nativo | sì | sì | sì | sì | no | no |
| Regole SAST personalizzate | possibile, verificare il costo | possibile, POC | POC | POC | CodeQL queries | vantaggio chiave |
Un "profilo forte" richiede comunque un POC.
13. È possibile indicare un unico vincitore?
Non in modo responsabile.
Si possono però indicare le shortlist più logiche.
Shortlist A: un'unica piattaforma ad ampia copertura
Checkmarx One
Snyk
Fortify
Veracode
Occorre assegnare un peso ai moduli. Esempio:
SAST 25%
SCA 15%
DAST i API 20%
IaC i containers 15%
developer UX 10%
governance 10%
deployment/data 5%
Se l'azienda non ha bisogno di IaC né di container, il loro peso dovrebbe essere pari a zero. Non si devono assegnare punti a un modulo che non risolve alcun problema dell'organizzazione.
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 e developer-first
Semgrep Code + Supply Chain + Secrets
+ dedykowany DAST
+ osobne IaC/container security
Shortlist D: legacy e controllo del deployment
Fortify SAST + DAST + Software Composition Analysis
Occorre verificare se gli altri livelli saranno gestiti dagli strumenti infrastrutturali esistenti.
Shortlist E: SonarQube esistente
SonarQube Advanced Security
+ dedykowany DAST
+ osobne IaC/container security, jeżeli potrzebne
14. Come condurre un POC corretto?
OWASP Benchmark contiene suite di test e strumenti per valutare accuracy, coverage e velocità degli scanner automatici.
Non dovrebbe però essere l'unica base della decisione:
- una parte dei test è sintetica,
- il Java Benchmark viene mantenuto senza modifiche sostanziali dei casi da molti anni,
- il nuovo Benchmark per Python ha un livello di maturità diverso,
- il risultato non misura il workflow dello sviluppatore,
- non misura la governance,
- non riproduce i framework aziendali.
OWASP Juice Shop è un'applicazione deliberatamente vulnerabile in Node.js, Express e Angular, utile per esercitazioni e per testare gli strumenti su frontend JavaScript e REST API.
Set di test minimo
- OWASP Benchmark per un linguaggio supportato.
- OWASP Juice Shop per il DAST.
- Un'applicazione propria che rappresenti lo stack di produzione.
- Un monorepo di dimensioni reali.
- Un repository con:
- dependencies vulnerabili,
- un secret nella versione corrente,
- un secret nella cronologia Git,
- Dockerfile,
- Terraform,
- Kubernetes,
- codice generato.
- Un ambiente in esecuzione con:
- SSO,
- alcuni ruoli,
- REST e GraphQL,
- funzione di upload,
- un processo a più fasi.
15. Metriche del POC
Efficacia del rilevamento
- true positives,
- false positives,
- false negatives,
- duplicati,
- findings senza un reale percorso di esecuzione,
- vulnerabilità delle dipendenze effettivamente raggiungibili.
Prestazioni
- il tempo della prima scansione completa,
- il tempo di scansione di una pull request,
- il tempo dopo la modifica di una singola riga,
- l'utilizzo di CPU e RAM,
- il comportamento su monorepo,
- il parallelismo.
Remediation
- se il risultato indica source e sink,
- se mostra il data flow completo,
- se la correzione è conforme al framework,
- se lo sviluppatore può verificare il risultato senza il team AppSec,
- se la correzione automatica supera i test,
- quanti risultati vengono chiusi come "won't fix".
Governance
- RBAC,
- SSO e SCIM,
- audit log,
- policy per business unit,
- eccezioni con data di scadenza,
- SLA,
- applicazioni e proprietari,
- integrazione con Jira o un altro sistema,
- esportazione dei dati,
- API,
- report di compliance.
Deployment e dati
- SaaS, self-hosted o ibrido,
- la regione dei dati,
- se il codice esce dall'organizzazione,
- il modo di archiviazione degli artefatti,
- registry privati,
- applicazioni interne,
- proxy,
- air-gapped environment,
- cifratura,
- retention.
Costo totale
Non solo il prezzo della licenza:
TCO =
licencja
+ infrastruktura
+ onboarding
+ tuning
+ triage
+ integracje
+ utrzymanie reguł
+ wsparcie
+ czas developerów
Uno strumento economico con migliaia di findings non gestiti può risultare più costoso di una piattaforma con un prezzo di licenza più alto.
16. Errori comuni nel procurement
Acquistare in base al numero di linguaggi
Il "supporto di un linguaggio" può significare:
- parser della sintassi,
- regole di base,
- un interprocedural data flow completo,
- il supporto di framework specifici.
Il POC deve utilizzare i framework dell'organizzazione.
Confondere SAST e SCA
Sono tecniche distinte. L'acronimo simile nel nome storico di Fortify aumenta ulteriormente il rischio di confusione.
Contare ogni modulo allo stesso modo
Se l'azienda non utilizza Terraform, il modulo IaC non dovrebbe migliorare la valutazione.
Testare solo un'applicazione demo pubblica
Un piccolo benchmark non riproduce:
- monorepo,
- custom framework,
- un package manager interno,
- build system,
- SSO,
- una rete privata.
Assenza di un test della developer experience
Uno strumento può individuare problemi validi, ma perdere l'adozione a causa di:
- risultati dopo diverse ore,
- l'assenza di un commento nella PR,
- remediation incomprensibili,
- suppressions complicate,
- build instabili.
Credere alla cifra di marketing sui false positives
Senza un dataset pubblico, la configurazione, la versione e la definizione del risultato, la cifra non è adatta al confronto.
Acquistare un DAST senza risolvere l'autenticazione
Uno scanner che non supera il login può testare solo un piccolo frammento pubblico dell'applicazione.
17. Raccomandazioni per tipo di azienda
Banche, assicurazioni, pubblica amministrazione
Shortlist:
- Fortify,
- Checkmarx One,
- Veracode.
Priorità:
- deployment e dati,
- legacy languages,
- audit,
- compliance,
- SAST e DAST,
- supporto a lungo termine.
Azienda SaaS che utilizza GitHub
Shortlist:
- GitHub Code Security + Secret Protection,
- Snyk,
- Semgrep,
- Burp Suite DAST separato o Invicti.
Priorità:
- PR feedback,
- tempo di scansione,
- dependency updates,
- secrets,
- API e DAST,
- attrito minimo per lo sviluppatore.
Cloud-native con Kubernetes e Terraform
Shortlist:
- Snyk,
- Checkmarx One,
- in alternativa un set GitHub/Semgrep più IaC e container security specializzati.
Priorità:
- SCA,
- containers,
- IaC,
- private registries,
- runtime context,
- DAST/API.
Organizzazione con SonarQube esistente
Shortlist:
- SonarQube Advanced Security,
- GitHub Code Security,
- Semgrep,
- un DAST dedicato.
La decisione deve rispondere se il consolidamento di qualità e sicurezza sia più importante di un portfolio più ampio di un unico fornitore.
18. Verdetto finale
Il miglior candidato come ampia piattaforma di un unico fornitore
Checkmarx One ha una gamma molto ampia e ufficialmente confermata che copre codice, open source, secret, IaC, container, API e DAST.
Questo lo qualifica per un POC, ma non gli garantisce una vittoria automatica.
Il più naturale per legacy ed enterprise controllato
Fortify resta un candidato forte per organizzazioni grandi, regolamentate e tecnologicamente eterogenee.
Il programma gestito più naturale che copre codice e runtime
Veracode è la scelta logica per un'azienda che preferisce una piattaforma di servizio centralizzata che copre SAST, SCA, DAST e un modulo separato Container Security con IaC e secrets, invece di mantenere più scanner.
Il più naturale cloud-native developer-first
Snyk dispone di moduli confermati Code, Open Source, Container, IaC e API & Web DAST. I confronti più datati che omettono il DAST non sono più attuali.
Il minimo attrito nell'ambiente GitHub
GitHub Code Security e Secret Protection garantiscono l'integrazione più stretta con i repository e le pull request, ma richiedono un livello separato di DAST runtime.
Il miglior candidato per guardrails personalizzati
Semgrep è particolarmente interessante quando l'organizzazione vuole costruire e mantenere rapidamente regole personalizzate SAST, SCA e secrets vicino allo sviluppatore.
DAST
Burp Suite DAST e Invicti vanno confrontati sulla propria applicazione. Non esiste una base attendibile per indicare un vincitore assoluto senza un test di autenticazione, API, workflow e copertura.
Il più delle volte la migliore soluzione enterprise non sarà un unico scanner, ma un set progettato in modo consapevole: livello repository + supply chain + DAST runtime + governance.
19. Checklist di scelta
Ambito
- Sono stati definiti i tipi di test necessari.
- SAST e SCA vengono valutati separatamente.
- È stato stabilito se serve il DAST.
- È stato stabilito se servono i secrets.
- È stato stabilito se servono IaC e container.
- Sono stati stabiliti i requisiti di API Security.
- Sono stati definiti le applicazioni e i linguaggi critici.
POC
- Ogni prodotto scansiona lo stesso codice.
- Vengono usate le stesse versioni e configurazioni.
- Il test comprende un'applicazione propria.
- Il test comprende un monorepo.
- Il test comprende una pull request.
- Il DAST supera l'autenticazione.
- Vengono testati ruoli e workflow.
- Sono stati misurati i false positives.
- I false negatives sono stati verificati manualmente.
- È stato misurato il tempo fino alla correzione.
Enterprise
- Sono stati confermati SSO, SCIM e RBAC.
- È stato confermato l'audit log.
- Sono stati confermati il modello dei dati e la regione.
- È stata confermata l'integrazione con SCM e CI.
- È stato confermato l'accesso alle applicazioni private.
- È stato confermato il supporto per proxy e registry.
- È stata confermata la retention dei dati.
- Sono stati confermati API ed esportazione.
- È stato confermato il modello delle eccezioni.
- È stato calcolato il TCO, non solo la licenza.
Adozione
- Sono stati definiti i proprietari dei findings.
- Sono stati definiti gli SLA in base al rischio.
- Il nuovo codice è separato dal backlog.
- Il quality gate blocca esclusivamente problemi attendibili.
- Esiste un processo di tuning delle regole.
- Le eccezioni hanno una data di scadenza.
- I risultati del DAST vengono deduplicati con quelli del SAST.
- Lo sviluppatore riceve il contesto e le istruzioni di correzione.
- Il team misura il fix rate, e non il numero di alert.
20. Strumenti e materiali POLPROG
Vale la pena integrare gli scanner automatici con un controllo del livello pubblico:
- Stato di salute del sito aiuta a rilevare problemi tecnici, SEO, di prestazioni e di accessibilità.
- Ispettore delle intestazioni di sicurezza verifica CSP, HSTS e altre protezioni delle risposte HTTP.
- Ispettore DNS e SSL analizza il livello del dominio e il TLS.
- FlowTrace aiuta a visualizzare il flusso di una richiesta attraverso DNS, TLS, CDN, backend e rendering.
- Nella base di conoscenza POLPROG sono presenti materiali sulla sicurezza delle applicazioni e dell'infrastruttura.
