Il report di un pentest deve trasformare le evidenze in interventi. Scopri come leggere gravità, copertura e limitazioni e come verificare le correzioni. La relazione è il punto in cui una valutazione tecnica diventa lavoro per l'organizzazione. La guida ai penetration test introduce il servizio; questo articolo aiuta a capire se il risultato ricevuto consente di prendere decisioni. Due destinatari, una stessa base di evidenze Il responsabile del servizio deve comprendere impatto e priorità. Il team tecnico deve sapere dove intervenire e come riprodurre il comportamento nell'ambiente autorizzato. Le indicazioni OWASP sulla scrittura dei report distinguono la sintesi per i responsabili dai dettagli dei rilievi e includono perimetro, limitazioni ed evidenze. Una buona relazione permette di risalire dalla sintesi al singolo problema attraverso identificativi coerenti. Evita che "accessi non corretti" rimanga una formula generica: chi deve agire deve riconoscere applicazione, condizione e controllo coinvolto. Esempio di un rilievo comprensibile Immagina che un account cliente di prova abbia consultato un fascicolo fittizio assegnato a un altro. Una scheda utile distingue: ambiente, versione, ruoli, operazione osservata, risultato atteso, evidenza e proposta di correzione. Il titolo potrebbe descrivere "Separazione insufficiente fra fascicoli dei clienti". La conseguenza dimostrata è la lettura del fascicolo verificato. Se il tester non ha provato una modifica o un accesso più ampio, il report deve evitare di presentarli come fatti. Le possibili conseguenze ulteriori possono essere discusse come ipotesi, indicando su cosa si basano. Gravità tecnica e priorità di lavoro CVSS è un sistema per descrivere e valutare la severità delle vulnerabilità. La guida FIRST a CVSS v4.0 distingue metriche di base e informazioni aggiuntive su minaccia e ambiente. Un numero senza contesto non sostituisce la conoscenza del servizio. Per organizzare gli interventi, chiedi quali dati sono coinvolti, quanto è esposto il componente e quali condizioni rendono possibile il problema. Un difetto su un sistema pubblico usato tutti i giorni può richiedere una risposta diversa da un rilievo su un ambiente isolato. La motivazione della priorità deve essere leggibile e verificabile. Assegnare le correzioni Per ogni rilievo registra proprietario, azione, scadenza e modalità di verifica. Se serve una misura temporanea, distinguila dalla soluzione definitiva. Il patch management aiuta a governare aggiornamenti e finestre operative, ma non tutti i difetti si risolvono installando una patch: possono riguardare autorizzazioni, configurazioni o processi. Esempio: un team corregge il controllo sui fascicoli e prepara una prova automatica sui ruoli. Il referente applicativo approva il comportamento atteso; il tester verifica il difetto iniziale e i casi collegati previsti dall'accordo. Ogni soggetto ha una responsabilità distinta. Che cosa significa retest Il retest controlla le correzioni di rilievi specifici nelle condizioni concordate. Non copre automaticamente nuove funzionalità o l'intero sistema. Richiedi uno stato per ogni voce: risolta, ancora presente, mitigata o non verificabile, con evidenza e motivazione. Proteggi report e allegati come informazioni sensibili: le prove possono descrivere percorsi di accesso e dettagli dell'architettura. Consegna e conservazione devono seguire le regole d'ingaggio. Per risalire all'origine di un rilievo, consulta le fasi del pentest e le verifiche su web e API.