Prima di tutto: ADRI verifica solo ciò che è tuo o ciò che è autorizzato. Prima di lanciare un audit attivo contro un sito web, ti chiede un sì esplicito nella chat con una dichiarazione: che sei titolare di quell'obiettivo o che hai l'autorizzazione scritta del suo titolare. La richiesta e la tua risposta vengono registrate. Per impostazione predefinita possono richiedere audit la direzione, l'amministrazione e il super-amministratore, e ogni richiesta, anche quelle negate, resta nella schermata di audit delle scansioni.
Che cos'è un retest delle vulnerabilità?
È riprovare un difetto dopo che qualcuno dice di averlo corretto. Sembra ovvio, ma è qui che le cose si complicano di più: la patch è stata applicata su un server e non su un altro, si è corretta una rotta e quella accanto è rimasta uguale, oppure un aggiornamento successivo l'ha riaperta.
Con ADRI, il «re-test» è semplice come chiedere un altro audit dello stesso obiettivo. La differenza è che ora ricorda cosa è stato deciso per ogni rilevamento.
Ogni rilevamento ha la sua scheda e il suo stato
Ogni rilevamento riceve un identificativo stabile, del tipo H-1a2b3c4d, che resta lo stesso da un audit all'altro. E passa attraverso questi stati:
- Sospetto. L'ha trovato la scansione e non è ancora confermato.
- Verificato. C'è prova che è reale: ADRI la annota con la sua nota, oppure la scansione stessa lo ha dimostrato.
- Corretto. Lo dice una persona, con l'identificativo del rilevamento nel suo messaggio. ADRI non può darlo per corretto di sua iniziativa.
- Chiuso. Nell'audit successivo non compare più e il test che lo rilevava è stato eseguito correttamente.
- Riaperto. Lo avevi dato per corretto e continua a comparire.
Ci sono anche due decisioni che prende solo una persona: falso positivo (non è un problema reale) e accettato (è reale, ma ti assumi il rischio). Entrambe restano con la loro nota.
Quando si può considerare chiusa una vulnerabilità?
Solo quando il nuovo test lo dimostra. Le regole sono volutamente severe:
- Se il test che avrebbe dovuto rilevarlo non è stato eseguito o è fallito, il re-test viene contrassegnato come non conclusivo, e te lo dice. Non si chiude nulla solo perché non lo si è controllato.
- Se un finding aperto semplicemente non compare, non si chiude da solo: può darsi che quella volta non sia stata controllata quella parte.
- Se qualcosa di chiuso ricompare, viene contrassegnato come regressione, che è proprio ciò che interessa di più vedere.
Il riepilogo di queste modifiche va in cima al report: cosa è stato chiuso, cosa è stato riaperto e cosa è tornato.
Che cos'è una matrice di accesso per ruoli?
Molti difetti gravi non si vedono dall'esterno. Una scansione anonima non rileva che un dipendente può aprire la scheda di un altro, o che un cliente del portale vede fatture che non sono sue. A questo serve la matrice di accesso per ruoli.
Funziona così: tu dichiari in un file i ruoli della tua applicazione, con account di test del tuo ambiente di test, e quali ruoli dovrebbero poter vedere ogni percorso. ADRI ti prepara il modello di partenza se gli dai il codice. Poi richiede ogni percorso con ogni ruolo e confronta:
- 🔴 Accesso indebito: un ruolo che non dovrebbe vedere il percorso, lo vede.
- ⚠️ Blocco imprevisto: un ruolo che dovrebbe poterlo vedere, non può.
- ❔ Indeterminato: un errore del server o una risposta ambigua da controllare manualmente.
Per non causare danni, fa solo letture, non segue reindirizzamenti, non esce dal dominio che gli hai indicato e ha un limite di percorsi e di ruoli, con pause tra le richieste. Nel report non compaiono né il contenuto delle pagine né i cookie di test: solo lo stato, la dimensione e un'impronta per confrontare. Gli account di test li metti tu; ADRI non li inventa né te li chiede via chat.
Se hai il codice, l'audit punta alla riga
Se gli dai il percorso del codice della tua applicazione, ADRI crea prima una mappa statica: quali percorsi esistono, quali richiedono il login e quali arrivano a operazioni delicate. Incrociandola con la scansione, un finding confermato dal codice viene riportato con la sua causa: il file e la riga. Ciò che il codice segnala ma la scansione non ha toccato resta un indizio, mai un finding.
Valuta, non ripara
L'audit segnala e dà priorità; non applica patch per conto proprio. Se c'è qualcosa da correggere nel codice, ADRI lo prepara e si procede con la tua approvazione. Poi, un altro audit chiude il cerchio.
Maggiori informazioni su sicurezza e conformità e su pentesting automatico con agenti IA. Se ti interessa come ADRI chiede il permesso prima di agire, ne parliamo in quando ADRI ti chiede il permesso, oppure richiedi una demo.
Domande frequenti
Posso fare l'audit del sito web di un'altra azienda?
Solo se ne sei il titolare o hai un'autorizzazione scritta. Prima di un audit attivo, ADRI ti chiede un sì con quella dichiarazione e resta registrato.
Chi decide che un finding è risolto?
Una persona, inserendo l'identificativo del finding. Poi, l'audit successivo lo chiude solo se il test è stato eseguito e non lo trova più.
La matrice per ruoli può modificare i dati della mia applicazione?
No. Fa solo letture, senza seguire reindirizzamenti e senza uscire dal dominio che gli hai indicato, con un limite di percorsi e pause tra le richieste.
- Sicurezza
- Audit
- Ruoli
- ADRI