Offensive Security · Penetration Test

Penetration test: dimostriamo l'impatto reale, non solo la lista delle falle.

Sfruttamento controllato delle vulnerabilità per provare cosa può fare davvero un attaccante. Metodologie riconosciute (OWASP, PTES, NIST SP 800-115), severità CVSS, PoC ed evidenze, remediation prioritizzata e retest dopo i fix.

Sfruttamento controllato (non solo scansione): proviamo l'impatto, non solo l'esistenza della falla.
Black-box, grey-box o white-box su web/API, network, cloud e identità.
Report con CVSS, PoC, remediation e retest, leggibile dal CISO del tuo cliente.

Richiedi un penetration test Vedi un report di esempio

Quando ti serve un penetration test

Auto-qualificazione rapida: ti riconosci in uno di questi?

Un deal enterprise è bloccato

Un cliente ti ha mandato un security questionnaire o chiede un pentest indipendente per firmare il contratto.

Vai al percorso

Evidenza per ISO 27001 / SOC 2

Ti serve un test indipendente come evidenza per l'audit di certificazione o per la sorveglianza annuale.

Vedi ISO 27001

Hai rilasciato qualcosa di nuovo

Nuova applicazione, nuova API, migrazione cloud o refactor importante: vuoi sapere cosa è esposto prima che lo scoprano altri.

Parlane con noi

Cos'è un penetration test (e cosa non è)

Un penetration test è uno sfruttamento controllato delle vulnerabilità per dimostrare l'impatto reale di una falla, non solo la sua esistenza. Un tester umano concatena debolezze, scala privilegi e raggiunge un obiettivo, esattamente come farebbe un attaccante, ma sotto regole d'ingaggio concordate.

Non è un vulnerability assessment: il VA identifica e classifica le vulnerabilità (scansione + verifica), senza sfruttarle. Non è un red team: il red team simula un avversario reale su obiettivi e in stealth, mettendo alla prova anche detection e risposta. Se non sei sicuro di cosa ti serve, scrivici e lo capiamo insieme, onestamente.

VA, penetration test e red team sono tre cose diverse. Il pentest è quello che chiedono di solito clienti enterprise, ISO 27001 e SOC 2.

Cosa testiamo e con quale approccio

Cosa (scope): applicazioni web e API, network esterno e interno, cloud (configuration review), identità e Active Directory, e, su richiesta, componenti mobile o scenari di social engineering. Lo scope lo definiamo insieme nello scoping.

Come (approccio): black-box (nessuna informazione preliminare), grey-box (credenziali o accessi parziali, lo scenario più realistico per la maggior parte dei SaaS), white-box (accesso completo a codice e architettura, massima copertura). Scegliamo in base a cosa vuoi davvero scoprire e al budget.

Cosa ricevi: il report

Executive summary leggibile da chi non è tecnico: cosa abbiamo trovato, quanto è grave, cosa fare.
Findings tecnici con severità calcolata in CVSS (v3.1 / v4.0), non valutazioni 'a sensazione'.
Proof of Concept ed evidenze che dimostrano l'impatto reale di ogni finding sfruttabile.
Mapping delle tecniche a MITRE ATT&CK dove utile per contestualizzare l'attacco.
Remediation guidance concreta e prioritizzata per rischio, non un copia-incolla generico.
Retest dopo i fix: verifichiamo che le correzioni reggano e chiudiamo il cerchio.
Lettera/attestazione del test che puoi condividere con clienti e auditor (anche via Trust Center).

Come funziona, fase per fase

Un processo trasparente con regole d'ingaggio concordate. L'esecuzione del test è guidata dal tester umano; l'AI ci aiuta sulla parte ripetitiva (triage, prima stesura), ma ogni finding è verificato manualmente.

1
Scoping & regole d'ingaggio
Definiamo perimetro, obiettivi, finestre temporali, approccio e autorizzazioni scritte.
2
Ricognizione & mapping
Raccolta informazioni, enumerazione della superficie d'attacco e dei servizi esposti.
3
Identificazione vulnerabilità
Scansione mirata e analisi manuale per individuare i punti deboli reali.
4
Sfruttamento controllato
Exploitation entro le regole, concatenazione delle falle, escalation verso l'obiettivo.
5
Reporting
Findings con CVSS, PoC, evidenze e remediation prioritizzata; executive summary incluso.
6
Retest
Dopo i fix riverifichiamo i finding e confermiamo la chiusura.

Stack & metodologie

Lavoriamo su metodologie di riferimento riconosciute. OWASP: Top 10, WSTG (Web Security Testing Guide), ASVS per le web app e MASTG per il mobile; PTES (Penetration Testing Execution Standard); NIST SP 800-115; OSSTMM. Le tecniche le mappiamo a MITRE ATT&CK dove aiuta a contestualizzare.

La severità di ogni finding è calcolata con CVSS (v3.1 / v4.0): una scala condivisa, difendibile e verificabile, non un giudizio soggettivo. È questo che fa reggere il report davanti a un compratore tecnico.

Modello e tempi

1
Modello a progetto : prezzo 'a partire da' + range
Il pentest è un progetto a perimetro definito. Il prezzo dipende dallo scope e dall'approccio: te lo fissiamo dopo lo scoping. Vedi la pagina prezzi.
2
Esecuzione : tipicamente 1-2 settimane di test
Variabile con l'ampiezza dello scope e l'approfondimento richiesto. Definito nello scoping, niente promesse a scatola chiusa.
3
Retest incluso : dopo i fix
Riverifichiamo i finding corretti entro una finestra concordata, così il report finale riflette lo stato reale.

Per chi ha bisogno di test ricorrenti, il pentest entra nel retainer di sicurezza continua a cadenza definita.

Nessun test 'garantisce' che tu sia sicuro: un pentest fotografa la postura nel suo scope e nel momento del test. Diffida di chi promette assoluti: la sicurezza si misura in riduzione del rischio.

Domande frequenti

Qual è la differenza tra penetration test e vulnerability assessment?

Il vulnerability assessment identifica e classifica le vulnerabilità (scansione + verifica manuale) con severità CVSS, senza sfruttarle. Il penetration test va oltre: sfrutta in modo controllato le falle per dimostrarne l'impatto reale. Spesso si parte da un VA e si approfondisce con un pentest dove conta.

E il red team? È la stessa cosa?

No. Il red team simula un avversario reale su obiettivi (non su uno scope predefinito), spesso in stealth, e mette alla prova anche detection e risposta. È avanzato: ha senso quando hai già una postura matura. Per la maggior parte dei clienti enterprise e per ISO/SOC 2 quello che serve è un pentest.

Black-box, grey-box o white-box: quale scelgo?

Black-box simula un attaccante esterno senza informazioni; grey-box parte da credenziali o accessi parziali ed è lo scenario più realistico per molti SaaS; white-box dà accesso a codice e architettura per la copertura massima. Te lo consigliamo in base a cosa vuoi scoprire e al budget.

Il pentest mi serve per ISO 27001 o SOC 2?

È un'evidenza molto comune sia per l'audit di certificazione sia per la sorveglianza annuale e i security questionnaire dei clienti. Non è un obbligo formale di per sé, ma è il modo più credibile per dimostrare che testi davvero i tuoi controlli tecnici.

Cosa ricevo alla fine?

Un report con executive summary, findings con severità CVSS, PoC ed evidenze, remediation prioritizzata e un retest dopo i fix. Più una lettera/attestazione del test condivisibile con clienti e auditor, anche tramite Trust Center.

Garantite che non resterà nessuna vulnerabilità?

No, e diffida di chi lo promette. Un pentest fotografa la postura nello scope e nel momento del test: riduce il rischio e dà priorità ai fix, ma 'rischio zero' non esiste. Per questo conta il testing periodico nel tempo.

Approfondisci

Audit & Pentest (hub)

La nostra linea di testing: VA, penetration test e red team spiegati insieme, con il modello di erogazione.

Vai all'hub

Report di esempio

Un report anonimizzato: executive summary, finding con CVSS, evidenze e remediation. Decidi prima di decidere.

Vedi il report

Vulnerability Assessment

Quando ti basta la fotografia ampia e ricorrente delle vulnerabilità, senza sfruttamento attivo.

Scopri

Vuoi un pentest che regge davanti a un tecnico?

Raccontaci scope e obiettivi: ti diciamo l'approccio giusto, i tempi onesti e un 'a partire da'.

Richiedi un penetration test