--- title: "Audit di sicurezza che verifica di nuovo | BionicAdri" description: "Ogni rilievo passa da sospetto a verificato, corretto e chiuso con un nuovo test. Una matrice per ruoli mostra cosa vede ogni profilo del tuo sito." url: https://bionicadri.com/it/blog/auditoria-seguridad-retest-roles.html markdown: https://bionicadri.com/it/md/blog-auditoria-seguridad-retest-roles.md language: it updated: 2026-10-29 index: https://bionicadri.com/it/llms.txt publisher: "BIONICADRI SOLUTIONS S.L. · info@bionicadri.com · +34 604 87 17 35" translations: es: https://bionicadri.com/md/blog-auditoria-seguridad-retest-roles.md en: https://bionicadri.com/en/md/blog-auditoria-seguridad-retest-roles.md ro: https://bionicadri.com/ro/md/blog-auditoria-seguridad-retest-roles.md fr: https://bionicadri.com/fr/md/blog-auditoria-seguridad-retest-roles.md de: https://bionicadri.com/de/md/blog-auditoria-seguridad-retest-roles.md it: https://bionicadri.com/it/md/blog-auditoria-seguridad-retest-roles.md pt: https://bionicadri.com/pt/md/blog-auditoria-seguridad-retest-roles.md --- # Un audit di sicurezza che ricontrolla ciò che è stato corretto e chi vede cosa Un report di sicurezza che dice «ci sono 23 problemi» e finisce in un cassetto non protegge nulla. Ciò che protegge è sapere quali sono stati davvero corretti, quali sono ancora lì e quali sono tornati. ADRI tiene il conto di ogni rilevamento e lo verifica di nuovo. Di [Liviu Diaconu](https://bionicadri.com/it/nosotros.html#fundador) 29 ott 2026 7 min di lettura 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à](https://bionicadri.com/it/seguridad.html) e su [pentesting automatico con agenti IA](https://bionicadri.com/it/blog/seguridad-empresas-agentes-ia.html). Se ti interessa come ADRI chiede il permesso prima di agire, ne parliamo in [quando ADRI ti chiede il permesso](https://bionicadri.com/it/blog/cuando-adri-pide-permiso.html), oppure [richiedi una demo](https://bionicadri.com/it/contacto.html#formulario). ## 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 ## Articoli correlati ### [Sicurezza aziendale con agenti IA: pentesting automatico](https://bionicadri.com/it/blog/seguridad-empresas-agentes-ia.html) ### [La Sentinella di ADRI: cosa vigila sui tuoi server, come decide e cosa lascia a una persona](https://bionicadri.com/it/blog/centinela-seguridad-adri.html) ### [Quando ADRI ti chiede il permesso e quando no: una pausa che protegge senza intralciare](https://bionicadri.com/it/blog/cuando-adri-pide-permiso.html) ## Guardalo con i dati della tua azienda Ti mostriamo ADRI al lavoro su un tuo compito reale, in circa 15 minuti. [Richiedi una demo](https://bionicadri.com/it/contacto.html#formulario) [info@bionicadri.com](mailto:info@bionicadri.com) · [+34 604 87 17 35](tel:+34604871735)