Correggere una vulnerabilità nel codice sorgente costa 10 volte meno che correggerla in produzione. Analizziamo il codice come lo farebbe un attaccante con SAST e DAST, configuriamo la pipeline CI/CD con security gate automatici e produciamo evidenze per la conformità NIS2 e ISO 27001.
Il SAST (Static Application Security Testing) analizza il codice sorgente senza eseguirlo — trova vulnerabilità nella logica, nell'uso delle API crittografiche, nelle query al database. Il DAST (Dynamic Application Security Testing) attacca l'applicazione mentre gira — trova vulnerabilità che esistono solo a runtime: sessioni mal gestite, header HTTP mancanti, comportamenti inattesi degli endpoint. Usarli insieme è l'unico modo per avere una copertura reale. La revisione manuale di un esperto completa il quadro identificando vulnerabilità nella business logic che nessuno strumento automatico può rilevare.
Leggiamo il codice sorgente come un revisore esperto: cerchiamo pattern insicuri, uso errato delle librerie crittografiche, vulnerabilità di injection, logica di autorizzazione difettosa. Ogni segnalazione dello scanner viene verificata manualmente per eliminare i falsi positivi e confermare la reale sfruttabilità.
Testiamo l'applicazione mentre è in esecuzione su un ambiente di staging o pre-produzione. Simuliamo attacchi reali sugli endpoint API e sulle interfacce web per trovare vulnerabilità che il codice sorgente non mostra: comportamenti del server, gestione degli errori, sicurezza dei cookie, header HTTP, risposte non attese.
SQL injection, XSS, XXE, SSRF, command injection, path traversal, insecure deserialization, algoritmi crittografici deboli. Il SAST identifica i pattern nel codice; il DAST li verifica sull'applicazione in esecuzione. Ogni finding viene classificato per severità reale ed exploitability, eliminando i falsi positivi prima del report.
Implementazione dell'autenticazione, gestione dei token JWT (algoritmi deboli, mancata verifica della firma), reset password insicuro, gestione delle sessioni, hashing delle password, hardcoded credentials. Il DAST verifica i flussi di autenticazione sull'applicazione live per rilevare bypass che il solo SAST non può scoprire.
Verifica che ogni endpoint controlli correttamente i permessi dell'utente. Accesso a risorse altrui (IDOR), escalation dei privilegi attraverso la modifica di parametri, funzioni admin accessibili senza verifica del ruolo, broken object level authorization nelle API REST e GraphQL.
Dati personali memorizzati in chiaro, log che includono dati sensibili, chiavi API e segreti nel codice, trasmissione non cifrata di informazioni riservate, data retention non conforme al GDPR. Analisi orientata ai requisiti NIS2 e alle aspettative del DPO aziendale.
Analisi delle dipendenze (npm, pip, composer, maven, go modules) per vulnerabilità note (CVE). Librerie obsolete o abbandonate, dipendenze con permessi eccessivi, typosquatting nei nomi dei pacchetti, integrità dei build artifacts e delle immagini container. Il Software Composition Analysis è incluso in ogni engagement.
Analisi della superficie di attacco delle API REST, GraphQL e SOAP: autenticazione, rate limiting, esposizione di dati eccessivi (over-fetching), verifica dei webhook e sicurezza delle integrazioni con servizi terzi. Il DAST testa gli endpoint con payload personalizzati su ambiente di staging, producendo evidenze concrete per il report.
Una Secure Code Review è un momento nel tempo. Uno Secure SDLC è un processo continuativo che protegge ogni release. Configuriamo la tua pipeline di sviluppo con security gate automatici che intercettano vulnerabilità a ogni commit, pull request e build — prima che il codice insicuro raggiunga anche solo il branch di staging. Questo è esattamente il requisito che NIS2 Art. 21 e ISO 27001 Annex A.8 descrivono quando parlano di "sicurezza nel ciclo di sviluppo del software".
Blocca il commit se contiene API key, token o credenziali hardcoded. Nessun segreto entra nel repository.
Semgrep, CodeQL o SonarQube analizzano il diff. I finding vengono postati come commenti in linea alla PR. Merge bloccato oltre soglia di rischio configurata.
Controllo CVE su tutte le dipendenze (npm audit, pip-audit, Trivy per le immagini Docker). Build fallisce se trovate vulnerabilità critiche senza eccezione approvata.
OWASP ZAP o Burp Suite Enterprise in modalità passiva sull'ambiente di staging. Rileva header mancanti, endpoint non protetti, misconfigurazioni TLS.
Scansione DAST completa prima del rilascio in produzione. Il deploy viene bloccato automaticamente se il security gate non è superato. Evidence prodotte per audit di compliance.
Ogni engagement segue un processo strutturato che massimizza la copertura delle vulnerabilità e minimizza il tempo necessario. Il codice non lascia mai i tuoi ambienti senza il tuo consenso esplicito: firmiamo l'NDA prima di ricevere qualunque file. I risultati vengono discussi in una call di debriefing dedicata con il tuo team tecnico e, se richiesto, con la direzione.
Definiamo il perimetro: moduli critici, linguaggi, environment di staging per il DAST, pipeline CI/CD da configurare. Firma dell'NDA prima di ricevere qualunque accesso al codice.
Scanner automatici sul codice sorgente, poi revisione manuale di ogni finding. Eliminazione dei falsi positivi, identificazione delle vulnerabilità di business logic, analisi SCA di tutte le dipendenze per CVE attivi.
Scansione attiva sull'applicazione in esecuzione su staging. Test degli endpoint API, verifica dei flussi di autenticazione a runtime, fuzzing degli input, controllo degli header HTTP. Evidenze catturate per il report.
Report bilingue con vulnerabilità classificate per severità (CVSS), proof-of-concept, remediation specifica per il tuo stack e la tua versione. Call di debriefing con il team tecnico inclusa. Verifica post-fix disponibile.
Meglio scoprirlo adesso che dopo che qualcuno lo ha già sfruttato in produzione — e dopo che l'auditor NIS2 lo ha già trovato nel report di ispezione.