Le vulnerabilità del software scoperte in ambiente di produzione costano alle organizzazioni in media quattro volte di più da risolvere rispetto alle vulnerabilità individuate durante la fase di sviluppo. Il rapporto IBM "Cost of a Data Breach Report" del 2025 stima il costo medio di una violazione a 4.88 milioni di dollari, e le violazioni che hanno origine da vulnerabilità non rilevate nel codice sorgente sono tra le più costose da risolvere, poiché la loro causa principale richiede non solo la risposta all'incidente, ma anche la correzione del codice sorgente. Gli strumenti di scansione del codice esistono per anticipare l'individuazione delle vulnerabilità, consentendo di intervenire già nell'ambiente di sviluppo e non solo dopo la violazione.
La scansione del codice è l'analisi automatizzata del codice sorgente, dei binari compilati o delle applicazioni in esecuzione per identificare vulnerabilità di sicurezza, difetti di qualità, violazioni di conformità e debito tecnico prima che il software raggiunga la produzione. Rappresenta il livello fondamentale della sicurezza delle applicazioni, non un sostituto del penetration testing o della modellazione delle minacce, ma la base sistematica che individua le classi di errori prevedibili e ripetibili che nessun revisore umano è in grado di rilevare in modo coerente su larga scala.
Scansiona tutte le lingue in cui il tuo team è impegnato
SMART TS XL Esegue contemporaneamente la scansione statica del codice in COBOL, Java, Python, JavaScript e nell'intero portfolio.
SCOPRI DI PIÙ…Cos'è la scansione del codice?
La scansione del codice è l'esame automatizzato di artefatti software, codice sorgente, bytecode, file binari o applicazioni in esecuzione, per identificare difetti senza richiedere la revisione manuale di ogni singola riga da parte di un essere umano. Gli strumenti di scansione applicano set di regole, corrispondenza di pattern, analisi del flusso di dati e, negli strumenti più sofisticati, tracciamento delle interconnessioni tra procedure per individuare problemi che altrimenti arriverebbero in produzione senza essere rilevati.
Cosa non è la scansione del codice: non sostituisce la revisione del codice, l'analisi architetturale, i test di penetrazione o il monitoraggio in fase di esecuzione. È un primo filtro rapido, sistematico e scalabile che individua in modo affidabile e coerente i pattern noti nell'intera codebase, comprese le parti che i revisori del codice non esaminano attentamente perché appaiono di routine.
Cosa si intende per verifica del codice in questo contesto: la verifica del codice conferma che il codice si comporti in conformità alle sue specifiche. La scansione è una componente della verifica, la componente automatizzata che si occupa del rilevamento di pattern e dell'analisi del flusso di dati. La revisione manuale, i test e la verifica formale sono le altre componenti. Insieme, costituiscono un programma di verifica; la sola scansione non è sufficiente.
Scansione statica vs. dinamica del codice: la differenza fondamentale
La scelta più importante nella creazione di un programma di scansione è capire quando viene eseguito ciascun approccio e cosa è in grado di rilevare:
| Dimensioni | Statico (SAST) | Dinamico (DAST) |
|---|---|---|
| Quando funziona | Sul codice sorgente non è richiesta alcuna esecuzione | Contro un'applicazione in esecuzione |
| Ciò che vede | Struttura del codice, flusso dei dati, violazioni degli schemi | Comportamento in fase di esecuzione, configurazione del server, risposte API |
| reperti | Schemi di iniezione SQL, segreti hardcoded, crittografia insicura, code smell | Bypass dell'autenticazione, iniezione in fase di esecuzione, difetti nella gestione delle sessioni, errata configurazione del server |
| Misses | Vulnerabilità che si verificano solo in fase di esecuzione, problemi di configurazione | Pattern a livello di codice non attivati durante i test |
| Velocità | Veloce, si esegue in pochi secondi o minuti. | Lento, richiede un ambiente di esecuzione |
| Feedback degli sviluppatori | Immediato, IDE o pre-commit | Ritardato, richiede l'applicazione distribuita |
| Tasso di falsi positivi | Più alto, manca il contesto di runtime | Inferiore, conferma la sfruttabilità |
| Migliore integrazione a | IDE, pre-commit, CI/CD su ogni PR | Ambiente di staging, fase di pre-rilascio |
La risposta pratica per la maggior parte dei team è: eseguirle entrambe . La scansione statica nell'IDE e nella pipeline CI fornisce un feedback rapido e tempestivo sui modelli di codice. La scansione dinamica sull'ambiente di staging conferma la sfruttabilità e individua problemi di configurazione che l'analisi statica non è in grado di rilevare.
I quattro tipi di scansione del codice
SAST, Test di sicurezza statica delle applicazioni
SAST analizza il codice sorgente, il bytecode o il binario senza eseguirlo. È la forma più comune di scansione del codice, integrata negli IDE e nelle pipeline CI/CD. SAST individua le vulnerabilità di injection tramite l'analisi di taint (tracciando input non attendibili verso destinazioni pericolose), l'uso improprio della crittografia tramite il pattern matching, le credenziali hardcoded tramite l'analisi delle stringhe e i problemi di qualità strutturale tramite metriche e regole basate su pattern.
Strumenti migliori: Semgrep, SonarQube, Checkmarx, CodeQL, Veracode, Snyk Code, SMART TS XL.
DAST, Test dinamico di sicurezza delle applicazioni
DAST viene eseguito su un'applicazione in tempo reale, inviando input appositamente creati e osservando le risposte. Non può accedere al codice sorgente, ma interagisce con l'applicazione dall'esterno, proprio come farebbe un attaccante. DAST individua vulnerabilità di autenticazione, difetti nella logica di business, falsificazioni di richieste lato server e vulnerabilità di configurazione che SAST non è in grado di rilevare perché richiedono il contesto di runtime.
Strumenti migliori: OWASP ZAP, Burp Suite, Invicti, Acunetix, HCL AppScan.
SCA, Analisi della composizione del software
Scansioni SCA dei manifesti di dipendenza (package.json, pom.xml, requirements.txt, go.mod) contro i database delle vulnerabilità per identificare CVE noti nelle librerie di terze parti. Ogni applicazione moderna utilizza dipendenze open source. SCA è il livello di scansione che garantisce che tali dipendenze non introducano vulnerabilità note.
Strumenti migliori: Snyk, OWASP Dependency-Check, Mend (precedentemente WhiteSource), GitHub Dependabot, npm audit.
IAST, Test interattivo di sicurezza delle applicazioni
IAST strumenta l'applicazione in fase di esecuzione utilizzando agenti o sensori integrati nel server applicativo. Osserva la gestione effettiva delle richieste dall'interno dell'applicazione, combinando la precisione in fase di esecuzione di DAST con l'analisi a livello di codice di SAST. IAST presenta il tasso di falsi positivi più basso tra i quattro tipi, ma richiede ambienti di implementazione strumentati.
Strumenti migliori: Contrast Security, Seeker (Synopsys), HCL IAST.
Come combinarli: Esegui SAST a ogni commit per un feedback rapido da parte degli sviluppatori. Esegui SCA a ogni modifica delle dipendenze. Esegui DAST sull'ambiente di staging prima di ogni rilascio. Aggiungi IAST per le applicazioni critiche in cui il tasso di falsi positivi deve essere ridotto al minimo.
Cosa rileva effettivamente la scansione del codice
Le diverse tipologie di scansione individuano diverse classi di vulnerabilità. Questa mappatura aiuta i team a capire quale scanner scegliere in base al proprio profilo di rischio specifico:
| Categoria di vulnerabilità | SAST | DAST | SCA | IAST |
|---|---|---|---|---|
| SQL Injection | Forte (analisi della contaminazione) | Forte (test attivo) | Non | Forte |
| XSS | Moderato | Forte | Non | Forte |
| Segreti/credenziali codificati in modo rigido | Forte (riconoscimento di modelli) | Non | Parziale | Non |
| Autenticazione non funzionante | Parziale (solo il modello) | Forte | Non | Forte |
| Dipendenze vulnerabili (CVE) | Non | Non | Forte | Non |
| Uso improprio della crittografia | Forte (API notoriamente inefficienti) | Non | Parziale | Parziale |
| Errata configurazione della sicurezza | Parziale (configurazione nel codice) | Forte | Non | Parziale |
| SSRF | Forte (analisi della contaminazione) | Forte | Non | Forte |
| Attraversamento del percorso | Forte | Moderato | Non | Forte |
| Iniezione di comando | Forte (analisi della contaminazione) | Forte | Non | Forte |
| Qualità del codice / debito tecnico | Forte | Non | Non | Non |
| Codice morto | Forte | Non | Non | Non |
Analisi del codice nel ciclo di vita dello sviluppo del software: quando eseguire cosa
Il principio "shift-left" nella sicurezza, che prevede di anticipare il rilevamento delle vulnerabilità il più possibile nelle fasi iniziali del ciclo di sviluppo, è il motivo per cui la scansione del codice è diventata una pratica standard. Trovare una vulnerabilità di SQL injection nell'IDE dello sviluppatore richiede pochi minuti per essere corretta. Trovarla in produzione dopo una violazione richiede settimane di intervento, attività di correzione e adempimenti burocratici.
Nell'IDE: SonarLint, le estensioni Snyk e i plugin Semgrep evidenziano le vulnerabilità direttamente nel codice mentre gli sviluppatori lo scrivono. Un flag di SQL injection che compare quando viene scritta la riga vulnerabile richiede solo pochi secondi per essere corretto.
Hook pre-commit: Esegui rapidamente le regole SAST e il rilevamento dei segreti prima che il codice raggiunga il repository. Gli hook pre-commit devono essere veloci, meno di dieci secondi, altrimenti gli sviluppatori li disabiliteranno.
Per ogni pull request: scansione SAST completa e controllo SCA. È in questa fase che la maggior parte dei team applica i controlli di qualità, bloccando le fusioni quando vengono introdotte nuove criticità.
Ogni notte o settimanalmente: analisi interprocedurale approfondita, scansioni DAST complete, audit SCA completi. Queste operazioni sono troppo lente per essere eseguite a ogni commit, ma vengono eseguite regolarmente sul ramo principale.
Una configurazione completa per la scansione CI/CD:
YAML
# GitHub Actions: layered scanning at the right pipeline stage
name: Code Scanning Pipeline
on:
push:
branches: [main, develop]
pull_request:
jobs:
sast:
name: Static Analysis
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Semgrep SAST scan
uses: semgrep/semgrep-action@v1
with:
config: >-
p/owasp-top-ten
p/security-audit
p/secrets
- name: SonarCloud quality gate
uses: SonarSource/sonarcloud-github-action@master
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
sca:
name: Dependency Scan
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Snyk dependency check
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high
secrets:
name: Secret Detection
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: TruffleHog secret scan
uses: trufflesecurity/trufflehog@main
with:
extra_args: --only-verifiedStrumenti di analisi del codice: una panoramica pratica
| Chiavetta | Tipo | Ideale per | Open Source |
|---|---|---|---|
| Segrep | SAST | Regole personalizzate, scansioni rapide, multilingue | Sì (regole della community) |
| SonarQube / SonarCloud | SAST | Qualità + sicurezza, integrazione CI/CD, monitoraggio delle tendenze | Edizione comunitaria |
| CodiceQL | SAST | Analisi semantica approfondita, nativa di GitHub | Si |
| Check Marx | SAST | Programmi di sicurezza delle applicazioni aziendali, conformità | Non |
| Codice Snyk | SAST | Sicurezza pensata per gli sviluppatori e con un approccio IDE prioritario. | Freemium |
| OWASP ZAP | DAST | DAST gratuito, compatibile con CI/CD | Si |
| Suite Rutto | DAST | Test di sicurezza delle applicazioni web manuali e automatizzati | Edizione comunitaria |
| Snyk / Riparare | SCA | Gestione della vulnerabilità delle dipendenze | Freemium |
| Controllo delle dipendenze OWASP | SCA | Scansione CVE delle dipendenze open-source | Si |
| Sicurezza a contrasto | IAST | Precisione in fase di esecuzione, basso numero di falsi positivi | Non |
| SMART TS XL | SAST + strutturale | Multilingua, COBOL, aziendale, legacy | Non |
Migliori pratiche per una scansione efficace del codice
Iniziate con regole affidabili e a basso rumore. Eseguire ogni set di regole disponibile fin dal primo giorno produce migliaia di risultati, sovraccarica gli sviluppatori e ostacola l'adozione. Iniziate con un set selezionato di regole ad alta severità e affidabilità, pattern OWASP Top 10, rilevamento di segreti e chiamate di funzioni note per essere pericolose. Aggiungete regole gradualmente man mano che il team acquisisce familiarità con gli strumenti.
Applicare i controlli solo al nuovo codice. Per le codebase legacy con vulnerabilità preesistenti, configurare i controlli di qualità in modo che blocchino solo le vulnerabilità introdotte nella pull request corrente (e non l'intera codebase) consente di integrare i controlli di sicurezza nel flusso di lavoro senza creare un accumulo di vulnerabilità preesistenti che bloccherebbe tutto lo sviluppo.
YAML
# SonarQube: new-code quality gate configuration
# Block merges on new critical security hotspots only
sonar.qualitygate.wait=true
sonar.newCode.referenceBranch=main
# Existing findings in main don't block PRs
# Only new findings in the PR diff are gatedGestisci i falsi positivi in modo sistematico. Un falso positivo che uno sviluppatore esamina e scarta una sola volta è solo un fastidio. Un falso positivo che si verifica a ogni pull request per sei mesi abitua gli sviluppatori a ignorare completamente i risultati. Stabilisci un processo di revisione delle richieste di soppressione: ogni richiesta di soppressione deve essere giustificata e documentata, e le richieste vengono riesaminate trimestralmente.
Mappa i risultati in base ai livelli di gravità. Non tutti i risultati richiedono un intervento immediato. Una risposta a livelli:
- critico (CVSS 9+, vulnerabilità confermata): bloccare l'implementazione, risolvere entro 24 ore
- Alto (CVSS 7-8): blocco unione PR, correzione entro lo sprint
- Medio: aggiungere al backlog, risolvere entro il trimestre
- Basso / Informativo: tracciare, indirizzare durante il refactoring
Misura ciò che conta. Monitora il tempo medio di risoluzione (MTTR) per livello di gravità, il rapporto tra problemi risolti e problemi rilevati per sprint e il tasso di falsi positivi nel tempo. Queste metriche ti dicono se il programma di scansione funziona, non solo se lo scanner è in esecuzione.
Come la scansione del codice previene il debito tecnico
Il debito tecnico si accumula quando i problemi di qualità vengono rimandati, quando una vulnerabilità di SQL injection che potrebbe essere rilevata da una regola SAST in fase di sviluppo raggiunge invece l'ambiente di produzione e richiede una patch di sicurezza, test di regressione e coordinamento del deployment per essere risolta. Gli strumenti di analisi del codice intercettano questo accumulo alla fonte.
Tre meccanismi collegano direttamente l'analisi del codice alla riduzione del debito tecnico:
Rilevamento della complessità. La complessità ciclomica al di sopra di una determinata soglia, le condizioni annidate in profondità e le funzioni lunghe sono "code smell" (cattive pratiche di programmazione) che gli strumenti di scansione segnalano. Se non affrontati, questi schemi si accumulano in codebase che diventano progressivamente più difficili e costose da modificare. La scansione fornisce un allarme precoce basato su metriche che sollecita il refactoring prima che la complessità diventi strutturale.
Rilevamento delle duplicazioni. Il codice duplicato è una delle forme più costose di debito tecnico: ogni correzione di bug e ogni modifica alle funzionalità devono essere applicate in più punti e le copie inevitabilmente divergono. Il rilevamento delle duplicazioni di SonarQube e regole simili mettono in evidenza questo schema nell'intera codebase, consentendo il consolidamento prima che la divergenza crei incoerenze.
Identificazione del codice morto. Il codice morto, ovvero funzioni e moduli che non vengono mai richiamati da alcun percorso di esecuzione in produzione, aumenta le dimensioni del codebase, confonde gli sviluppatori e complica l'analisi di migrazione. Gli strumenti di scansione che eseguono l'analisi di raggiungibilità identificano sistematicamente il codice morto, consentendone la rimozione prima che si accumuli ulteriormente.
L'effetto cumulativo: una codebase soggetta a scansione continua presenta una minore densità di difetti, una minore complessità ciclomica, un minore tasso di duplicazione e una minore percentuale di codice morto rispetto a una codebase comparabile non sottoposta a scansione. Questi parametri si traducono direttamente in uno sviluppo più rapido delle funzionalità, minori costi di manutenzione e un rischio ridotto di incidenti in produzione.
Come SMART TS XL Offre funzionalità di scansione del codice su scala aziendale.
Gli strumenti standard di analisi del codice operano all'interno di un singolo linguaggio. Negli ambienti aziendali in cui coesistono servizi Java, pipeline Python, programmi batch COBOL, flussi di lavoro JCL e moduli RPG, ognuno dei quali richiede il proprio scanner con la propria configurazione e la propria dashboard dei risultati, il quadro dell'analisi del codice risulta frammentato.
SMART TS XL'S analisi statica del codice Esegue la scansione simultanea di tutti i linguaggi presenti nell'ambiente, tra cui COBOL, JCL, Java, Python, RPG, PL/I, SQL e stack moderni, producendo metriche di qualità unificate, risultati di sicurezza e dati strutturali sull'intero portfolio in un'unica fase di analisi. Per le organizzazioni che dispongono di applicazioni mainframe legacy accanto a moderni servizi cloud, questa copertura multi-linguaggio rappresenta la differenza tra un programma di scansione che copre lo stack moderno e uno che copre l'intero sistema.
La funzionalità di mappatura delle dipendenze dell'applicazione estende la scansione oltre i singoli file, arrivando all'analisi architetturale: quali componenti presentano il più alto grado di accoppiamento, dove esistono dipendenze circolari, quali programmi condividono dati tramite interfacce di file implicite anziché API esplicite. Questi risultati strutturali rappresentano i problemi di sicurezza e qualità architetturale che gli strumenti di corrispondenza di pattern su singoli file non sono in grado di rilevare.
La funzionalità di analisi dell'impatto rende i risultati delle scansioni utilizzabili su larga scala: quando viene rilevata una vulnerabilità in un componente ad alto impatto da cui dipendono 150 programmi, l'analisi dell'impatto definisce l'ambito dell'intervento di correzione, quali programmi devono essere testati, quali utenti devono essere aggiornati e qual è la portata completa della correzione. In questo modo, i risultati delle scansioni, inizialmente un semplice elenco di problemi, si trasformano in un programma di correzione strutturato e con un ambito ben definito.
La funzionalità di ricerca aziendale consente di interrogare i risultati della scansione sull'intero portfolio: trova ogni programma che utilizza una specifica API non sicura, ogni file che contiene credenziali hardcoded, ogni componente che supera una soglia di complessità, in pochi secondi, tra milioni di righe di codice e in qualsiasi combinazione di linguaggi.
Per i team di gestione modernizzazione dell'eredità programmi, SMART TS XLLa scansione fornisce la baseline di qualità pre-migrazione: il codice obsoleto escluso dall'ambito della migrazione, la distribuzione della complessità che determina la sequenza di migrazione e i risultati di sicurezza che devono essere corretti prima che il codice convertito venga distribuito nell'infrastruttura cloud.
Scansiona presto, scansiona continuamente, scansiona tutto
Le organizzazioni con il tempo medio di risoluzione delle vulnerabilità di sicurezza più basso non sono quelle con i programmi di penetration testing più aggressivi. Sono invece quelle che individuano il maggior numero di vulnerabilità prima che raggiungano la fase di revisione del codice, nell'IDE dello sviluppatore, nell'hook pre-commit, nella pipeline CI/CD. La scansione del codice è il modo in cui ciò avviene su larga scala.
Costruire un programma di scansione significa scegliere la giusta combinazione di SAST, DAST, SCA e IAST per il proprio profilo di rischio, integrarli nei punti opportuni del ciclo di sviluppo, ottimizzarli per minimizzare il rumore senza sacrificare la copertura e misurare l'efficacia del programma nel tempo, anziché dare per scontato che lo scanner sia in funzione. L'avvio dello scanner è solo l'inizio. Il funzionamento del programma è l'obiettivo.
