Sicurezza #

EthicsPortal tratta dati sensibili dei segnalanti. Questa pagina documenta le specifiche misure tecniche e organizzative che abbiamo adottato. È redatta per i responsabili della compliance, i DPO e i team legali che valutano la piattaforma.

Ultimo aggiornamento: 2026-11-04.

Crittografia dei dati #

I campi sensibili del database elencati di seguito sono crittografati a riposo mediante Rails ActiveRecord Encryption con crittografia non deterministica (ogni crittografia produce un testo cifrato univoco, impedendo l’analisi dei pattern). La crittografia dei campi non copre i dump completi del database né gli allegati; questi sono crittografati separatamente, come descritto nelle sezioni allegati e backup.

La crittografia non deterministica significa che questi campi non possono essere interrogati per valore a livello di database. Anche con pieno accesso al database, un aggressore non può cercare uno specifico nome di segnalante tra i record.

Allegati #

I file allegati alle segnalazioni, ai messaggi e alle note interne, le registrazioni vocali e le esportazioni dei dati dei casi sono crittografati a riposo in Hetzner Object Storage con AES-256, con una chiave casuale distinta per ogni file (crittografia lato server con chiavi fornite dal cliente). La chiave viene inviata con ogni richiesta allo storage e Hetzner rifiuta qualsiasi lettura effettuata senza di essa. EthicsPortal la conserva nel database con la ActiveRecord Encryption descritta sopra, quindi le sole credenziali dello storage non consentono di leggere un file: servono anche il database e le chiavi di crittografia dell’applicazione. I file raggiungono gli utenti autorizzati in streaming attraverso l’applicazione, mai tramite un link diretto allo storage.

I file caricati prima del 6 ottobre 2026 sono stati ricrittografati in quella data e le loro copie non crittografate, comprese le versioni precedenti conservate, sono state eliminate. I file che non sono dati delle segnalazioni, come le immagini del profilo e le immagini di condivisione dell’organizzazione, non sono crittografati in questo modo. Nulla di tutto ciò protegge da una compromissione del server applicativo, che detiene insieme le credenziali dello storage, il database e le chiavi.

Tutte le connessioni a EthicsPortal utilizzano HTTPS/TLS. Le richieste HTTP non crittografate vengono reindirizzate.

Anonimato e privacy #

Indirizzi IP #

EthicsPortal non registra l’indirizzo IP di un segnalante con le segnalazioni, i messaggi o i record di audit, e i log dell’applicazione per il canale di segnalazione non contengono indirizzi IP.

La limitazione delle richieste sul canale di segnalazione (invio della segnalazione, consultazione del caso, messaggistica) si basa su un hash SHA-256 con chiave e troncato dell’IP della richiesta. L’hash è pseudonimo, non anonimo: non può essere riletto come indirizzo, ma chiunque disponga del segreto dell’applicazione potrebbe verificarvi indirizzi candidati. È utilizzato solo per la finestra di limitazione (al massimo 10 minuti) e un processo in background lo elimina dalla cache entro 5 minuti dalla fine della finestra.

Il proxy TLS posto davanti all’applicazione tiene un proprio log delle richieste: indirizzo IP, percorso della richiesta, user agent e stato della risposta. Il percorso della pagina in cui un segnalante consulta la propria segnalazione contiene l’ID del caso, quindi una voce per quella pagina può essere collegata alla segnalazione. Sono conservate in un unico file di log da 10 MB sovrascritto man mano che si riempie, attualmente dopo circa due giorni; gli snapshot del server a 7 giorni descritti nella sezione backup possono contenerne una copia.

Rimozione dei metadati dei file #

I file caricati vengono automaticamente ripuliti dai metadati identificativi prima dell’archiviazione:

La rimozione dei metadati viene eseguita lato server prima dell’archiviazione. Per i tipi di file gestiti da exiftool, ciò dipende dalla presenza degli strumenti di produzione standard.

All’interno di un PDF vengono conservati i nomi presenti nei commenti e i metadati delle foto incorporate, come la posizione GPS e il numero di serie della fotocamera. Il segnalante che desidera eliminarli dovrebbe caricare le foto come file immagine separati e rimuovere i commenti prima di caricare un PDF.

Scansione antivirus #

I file allegati alle segnalazioni, ai messaggi e alle note interne vengono automaticamente sottoposti a scansione antimalware mediante ClamAV, un motore antivirus open source. La scansione avviene lato server in un processo in background dopo il caricamento. I file che non hanno superato la scansione sono bloccati alla consegna e i file infetti vengono rimossi automaticamente.

I file vengono sottoposti a scansione sull’infrastruttura di EthicsPortal — nessun dato dei file viene inviato a servizi di scansione di terze parti.

Segnalazioni via email #

Ogni canale di segnalazione ha un proprio indirizzo email su report.ethicsportal.eu. Un’email inviata a questo indirizzo diventa un caso in quel canale di segnalazione, come una segnalazione inviata tramite il modulo di segnalazione online. Le segnalazioni via email sono attive per impostazione predefinita. Un’organizzazione può disattivarle nelle impostazioni del canale; l’indirizzo rifiuta quindi le nuove email entro un minuto.

• Server di posta proprio. La posta per questi indirizzi è ricevuta dal server di posta di EthicsPortal, sulla stessa infrastruttura in Germania, e non da un fornitore di posta terzo. Accetta posta solo per gli indirizzi dei canali, rifiuta qualsiasi altro indirizzo e non inoltra nulla.
• Crittografia del trasporto. Il server offre TLS 1.2 o superiore con un certificato Let’s Encrypt. Il TLS è opportunistico: un server mittente che non lo supporta consegna il messaggio senza crittografia.
• Indirizzo del mittente nascosto ai gestori. L’indirizzo del mittente è memorizzato in forma crittografata e non viene mai mostrato ai gestori del caso, né nel caso, né nel relativo PDF, né nelle esportazioni. EthicsPortal lo usa solo per inviare al segnalante la ricevuta e gli avvisi di nuovi messaggi.
• Accesso senza email. La ricevuta contiene l’ID del caso e una password monouso per la posta sicura, sostituita al primo accesso. Domande e risposte successive restano nella posta sicura, non nell’email. Se il dominio del mittente rifiuta l’indirizzo nella propria policy DMARC, la segnalazione viene conservata ma non viene inviata alcuna password. Oltre 10 segnalazioni via email a un’organizzazione, o 50 su tutto EthicsPortal, nell’arco di 24 ore, le segnalazioni successive vengono conservate ma non viene inviata alcuna email: né la ricevuta al segnalante né l’avviso via email agli amministratori, che vedono comunque il caso nell’applicazione.
• Allegati. I file ricevono la stessa rimozione dei metadati e la stessa scansione antivirus dei file caricati tramite il modulo. I file che non possono essere accettati (di altro tipo, troppo grandi o impossibili da ripulire) vengono esclusi e il segnalante viene informato di quanti sono.
• Copie. Un messaggio resta nella coda del server di posta, sullo stesso server, solo finché l’applicazione non lo accetta. L’applicazione conserva l’email originale crittografata fino al salvataggio del caso, poi la elimina. I log del server di posta registrano gli indirizzi dei canali, mai l’indirizzo del mittente.
• Controlli sul mittente. SPF, DKIM e DMARC vengono verificati sull’infrastruttura di EthicsPortal. Nessun dato dei messaggi viene inviato a un servizio esterno antispam o di reputazione.

L’email non è anonima: il fornitore di posta del segnalante e, se scrive da un account di lavoro, i sistemi di posta dell’organizzazione possono conservare copie e registrazioni del messaggio. La ricevuta lo indica e rimanda al modulo di segnalazione online per i segnalanti che vogliono restare anonimi.

Email per gli aggiornamenti #

Il modulo di segnalazione online ha un campo email facoltativo per gli aggiornamenti. L’indirizzo riceve la ricevuta e un avviso quando un gestore scrive, mai il contenuto della segnalazione. È memorizzato in forma crittografata e, come l’indirizzo del mittente di una segnalazione via email, non viene mostrato in nessuna pagina dei gestori, in nessun PDF né in nessuna esportazione. Resta disponibile quando il segnalante invia in forma anonima. Solo un segnalante che disattiva l’invio anonimo e spunta “mostra il mio indirizzo email anche ai gestori del caso” lo trasforma in un indirizzo di contatto visibile ai gestori.

Anonimato del gestore #

I segnalanti non vedono mai i nomi reali o gli indirizzi email delle persone che gestiscono la loro segnalazione. Tutti i messaggi dei gestori sono visualizzati come “Gestore del caso”. Ciò protegge l’identità del gestore e previene l’ingegneria sociale.

Nessun tracciamento #

EthicsPortal non utilizza cookie di tracciamento di terze parti, pixel pubblicitari o script di fingerprinting. Utilizziamo Plausible Analytics solo sul sito di marketing, servito tramite il nostro dominio. Non imposta cookie e non conserva gli indirizzi IP. Cloudflare, che distribuisce il sito di marketing, tratta metadati della richiesta, inclusi gli indirizzi IP, come descritto nell’Informativa sulla privacy. Il canale di segnalazione non contiene strumenti di analisi.

Stato attuale delle garanzie #

EthicsPortal attualmente non dichiara su questo sito una certificazione ISO 27001 accreditata. Non pubblica inoltre attualmente un audit indipendente di terze parti dell’architettura di anonimato. Qualora ciò cambi, l’ambito e la data saranno pubblicati qui.

Materiali per la verifica di sicurezza #

I clienti che necessitano di materiali per la verifica in fase di approvvigionamento o legale possono richiederli durante l’approvvigionamento. I materiali disponibili possono includere un DPA firmato, evidenze di registro e fiscali, un questionario di sicurezza compilato e risposte scritte relative alle procedure di backup e ripristino, all’accesso privilegiato in produzione e alla gestione della risposta agli incidenti.

Controllo di accesso #

L’autorizzazione è applicata a livello applicativo mediante le policy di Pundit.

• I gestori non possono vedere le segnalazioni a cui non sono né assegnati né partecipanti. I partecipanti sono aggiunti esplicitamente da un amministratore o dall’assegnatario principale (ad esempio, coinvolgendo l’ufficio legale o le risorse umane).
• I segnalanti non hanno un account utente — aprono la propria segnalazione con un ID del caso (WB-XXXX-XXXX) e una password che il sistema genera al momento dell’invio della segnalazione.
• Ogni azione del controller verifica l’autorizzazione. I tentativi di accesso non autorizzati vengono bloccati e registrati.

Autenticazione a due fattori #

Gli account dei gestori e degli amministratori possono abilitare l’autenticazione a due fattori basata su TOTP tramite qualsiasi app di autenticazione standard (Google Authenticator, 1Password, Authy e alternative compatibili). Una volta abilitata, l’accesso richiede sia la credenziale primaria sia un codice rotante di 6 cifre.

Accesso dei segnalanti #

I segnalanti accedono con l’ID del caso e una password. L’ID del caso identifica il caso e non è segreto. La password è composta da 16 cifre casuali, generate dal sistema al momento dell’invio della segnalazione; il segnalante non la sceglie. È memorizzata solo come digest bcrypt, quindi nessuno può recuperarla, ed EthicsPortal non ha alcuna funzione che permetta al segnalante, al gestore del caso o all’operatore di reimpostarla. Il segnalante che la perde invia una nuova segnalazione e indica l’ID del caso. Le segnalazioni inviate prima del 18 ottobre 2026 mantengono la password di 6 cifre scelta allora dal segnalante, che continua a funzionare. La casella di seguito e l’invio di messaggi sono protetti dalla sessione dietro questo controllo, così che un ID del caso trapelato da solo non possa leggere la segnalazione né impersonare il segnalante.

Subito dopo l’invio, una pagina di ricevuta mostra l’indirizzo della posta sicura, l’ID del caso e la password. Resta disponibile in quel browser solo finché il caso è sbloccato e scompare quando la posta si blocca dopo 30 minuti di inattività o quando il segnalante esce. Nella pagina di accesso il campo della password è un campo di testo visibile con il completamento automatico disattivato, anziché un campo password mascherato, così che i browser non propongano di salvare la password: un browser gestito dall’azienda potrebbe altrimenti sincronizzarla con l’account del datore di lavoro. Si può incollare la password e gli spazi vengono ignorati.

Quando il personale registra una segnalazione ricevuta per telefono, in un incontro di persona, per lettera o per email e il segnalante vuole seguire il caso online, il sistema genera una password monouso che il gestore gli comunica. Funziona una sola volta: al primo accesso del segnalante viene sostituita, sul server, da una nuova password che vede solo il segnalante.

L’accesso del segnalante termina quando seleziona «Esci» oppure dopo 30 minuti senza attività. Circa due minuti prima del blocco, un avviso offre di mantenere aperta la posta; se nessuno risponde, il caso scompare dallo schermo. L’accesso è conservato in un cookie cifrato nel browser del segnalante e il server non conserva alcuna sessione del segnalante.

Ciclo di vita delle sessioni #

Ogni sessione autenticata registra last_seen_at a ogni richiesta (con debounce). Gli utenti possono esaminare le proprie sessioni attive, vedere quando ciascuna è stata attiva l’ultima volta, revocare singolarmente qualsiasi sessione o disconnettersi da tutte le altre sessioni contemporaneamente dalle impostazioni dell’account.

Le sessioni scadono automaticamente dopo 14 giorni di inattività. La richiesta successiva da una sessione inattiva distrugge il record lato server, cancella il cookie e impone una nuova autenticazione tramite un nuovo magic link. Un processo notturno ripulisce le sessioni abbandonate sulla stessa scadenza, così che user_agent e ip_address non siano conservati oltre la finestra di inattività anche quando l’utente non ritorna mai.

L’autenticazione tramite magic link limita l’impatto delle sessioni di lunga durata: un cookie di sessione rubato non fornisce una credenziale riutilizzabile e la nuova autenticazione richiede l’accesso all’email.

Accesso dei membri e dismissione #

L’accesso all’organizzazione è applicato al confine della richiesta. Quando un membro viene disattivato:

• L’accesso all’organizzazione è rifiutato immediatamente, anche per gli URL salvati in precedenza.
• Le assegnazioni di segnalazioni aperte vengono annullate.
• Le partecipazioni vengono rimosse.
• La cronologia del registro delle attività attribuibile al membro è preservata.
• Il membro disattivato viene avvisato.
• La riattivazione non ripristina automaticamente l’accesso ai casi precedenti.

Il proprietario dell’organizzazione, l’ultimo amministratore attivo e il responsabile della compliance designato per il canale di segnalazione non possono essere disattivati. Tutti gli eventi di disattivazione e riattivazione sono scritti nel registro delle attività in sola aggiunta.

La rimozione di un membro disattiva l’appartenenza anziché eliminarla, così che il registro delle attività e la cronologia delle segnalazioni restino risolvibili. Un’appartenenza viene eliminata definitivamente solo quando viene cancellato l’account del membro stesso o l’organizzazione.

Cancellazione dell’account #

Quando un membro chiude il proprio account, l’indirizzo email viene sostituito con un segnaposto non instradabile e l’immagine del profilo, le credenziali a due fattori, le sessioni, i token API e le preferenze vengono eliminati definitivamente; l’account non può più autenticarsi né essere contattato. Se l’account non ha mai agito in un’organizzazione, il record viene eliminato del tutto. In caso contrario, il nome del membro resta, mentre le sue appartenenze vengono disattivate affinché le note dei casi, i messaggi e le voci del registro delle attività conservati restino attribuibili. Il Titolare determina il periodo di conservazione secondo le proprie istruzioni documentate e la legge applicabile; i diritti di cancellazione previsti dal GDPR restano soggetti alle eventuali eccezioni applicabili per obblighi legali o azioni legali.

Un account ripulito non può autenticarsi per alcuna via: magic link, asserzione SSO o token API.

Limitazione delle richieste #

Gli endpoint pubblici del canale di segnalazione sono soggetti a limitazione delle richieste per prevenire abusi e attacchi di enumerazione:

La limitazione delle richieste utilizza l’hash IP con chiave descritto sopra — nessun indirizzo IP viene memorizzato a tale scopo. Il limite per ID del caso usa come chiave l’ID del caso stesso, che viene eliminato dalla stessa cache entro 15 minuti.

Audit e conformità #

Registro delle attività in sola aggiunta #

Gli eventi definiti relativi alle segnalazioni e agli account sono registrati con:

• Marca temporale (UTC)
• Attore (quale utente o processo di sistema ha eseguito l’azione)
• Tipo di azione (ad esempio, segnalazione creata, stato modificato, messaggio inviato, gestore assegnato, segnalazione esportata o segnalazione eliminata). Ogni visualizzazione di una determinata segnalazione da parte di un gestore è registrata, deduplicata a una voce per gestore per segnalazione ogni 24 ore, e le visualizzazioni di follow-up da parte del segnalante sono registrate allo stesso modo. Le letture di altre risorse non sono registrate.

Le voci del registro delle attività sono in sola aggiunta. Nessun utente, inclusi gli amministratori dell’organizzazione, può modificare una voce o eliminarne una singolarmente: i trigger PostgreSQL rifiutano modifica e truncate a livello di database. Le voci sono rimosse solo dal ciclo di conservazione o quando l’organizzazione stessa viene eliminata, e l’intervento privilegiato sul database resta un rischio residuo documentato (registro dei rischi R-08). Il registro delle attività completo è incluso nelle esportazioni dei casi in PDF per la verifica delle autorità.

Conservazione dei dati #

Le organizzazioni configurano il proprio periodo di conservazione: 12, 24, 36, 48 o 60 mesi dopo la chiusura di una segnalazione. Alla scadenza del periodo di conservazione, un processo in background elimina la segnalazione e i dati associati dalla produzione; le copie di backup scadono secondo un ciclo di vita distinto e documentato.

Le email inviate a un segnalante non lasciano alcun registro nello storico di invio di EthicsPortal, quindi nessun indirizzo di un segnalante resta dopo l’eliminazione della segnalazione.

Il Titolare resta responsabile della scelta di un periodo che rispetti il principio di limitazione della conservazione del GDPR e le norme nazionali applicabili in materia di conservazione dei registri.

Protezione CSRF #

Tutti gli invii di moduli sono protetti contro il cross-site request forgery mediante i token CSRF integrati di Rails.

Ciclo di vita di sviluppo sicuro #

EthicsPortal segue un ciclo di vita di sviluppo documentato per le modifiche che toccano il Servizio. Le fasi sono indicate qui affinché un addetto all’approvvigionamento possa mapparle ai controlli A.8.25-A.8.29 della ISO/IEC 27001:2022 (vedi la mappa dei controlli per la mappatura completa).

Gestione delle dipendenze e delle patch #

EthicsPortal non distribuisce componenti software a fine vita. L’applicazione gira su versioni attivamente supportate di Rails, Ruby, PostgreSQL e del sistema operativo sottostante; le release di sicurezza a monte vengono applicate su base continuativa.

Le dipendenze sono sottoposte a scansione continua in continuous integration:

• Brakeman segnala le vulnerabilità specifiche di Rails a ogni modifica.
• bundler-audit verifica il Gemfile rispetto al Ruby Advisory Database a ogni modifica e nuovamente su base giornaliera, così che i nuovi avvisi pubblicati vengano intercettati anche quando il codice non è cambiato.
• importmap audit esegue la scansione delle importazioni JavaScript alla ricerca di vulnerabilità note a ogni modifica e nuovamente su base giornaliera.
• Dependabot apre pull request settimanali per le gemme Ruby e le GitHub Actions obsolete, raggruppate per aggiornamenti minor/patch.

I controlli sulla catena di fornitura limitano ciò che una release compromessa di una dipendenza può raggiungere:

• Periodo di attesa. Le nuove versioni delle gem vengono adottate solo dopo tre giorni dalla pubblicazione; gli aggiornamenti di versione di Dependabot attendono 3, 7 o 14 giorni per le release patch, minor e major. Le release dirottate vengono di solito ritirate entro questo intervallo.
• Azioni CI fissate. Ogni passaggio di GitHub Actions è fissato a uno SHA di commit completo, così un tag spostato non può cambiare ciò che viene eseguito.
• Download verificati. I binari scaricati durante la build dell’immagine del container vengono verificati rispetto a un checksum SHA-256 fissato.
• Aggiornamenti automatici vincolati. Le pull request di Dependabot vengono unite automaticamente solo dopo il superamento dell’intera suite di test e dell’analisi statica.

I componenti che raggiungono il fine vita a monte vengono sostituiti o aggiornati prima della chiusura della loro finestra di supporto.

Infrastruttura #

• L’archiviazione principale delle segnalazioni e dei dati dei casi avviene nell’Unione europea. La consegna delle email e la telemetria dell’applicazione hanno catene di fornitori a valle distinte; vedi il DPA.
• Nessun numero di carta di credito o credenziale di pagamento è memorizzato sui server di EthicsPortal. Tutti i dati di pagamento sono gestiti da Stripe.
• Mailjet invia le notifiche ai gestori e, facoltativamente, le ricevute e gli avvisi di nuovi messaggi ai segnalanti. Gli avvisi ai segnalanti contengono l’indirizzo email del destinatario, l’ID del caso e il link, ma non il contenuto della segnalazione. La ricevuta di una segnalazione inviata via email contiene anche una password monouso per la casella sicura, sostituita al primo accesso del segnalante. La catena di supporto a valle di Mailjet può comportare accessi al di fuori del SEE; vedi il DPA.
• Il sito di marketing è erogato tramite Cloudflare (CDN, Stati Uniti); il canale di segnalazione e il pannello di gestione no. Questo trattamento separato del sito pubblico e le relative garanzie di trasferimento sono descritti nell’Informativa sulla privacy, non nell’elenco dei sub-responsabili del DPA con il cliente.

Backup e ripristino #

EthicsPortal opera tre livelli di backup complementari, tutti conservati all’interno dell’UE:

Obiettivi di ripristino. L’obiettivo del punto di ripristino (RPO) è di 24 ore. L’obiettivo del tempo di ripristino (RTO) è di 4 ore. Questi obiettivi figurano anche nell’accordo sul livello di servizio.

Test di ripristino. Un’esercitazione di ripristino viene eseguita automaticamente ogni mese tramite un workflow CI, e su richiesta, ripristinando l’ultimo dump in un ambiente usa e getta. Decifra il dump, lo ripristina, confronta ogni tabella con la produzione e poi avvia l’applicazione sul database ripristinato per confermare che una colonna cifrata si decifri ancora, che un allegato cifrato si apra con la chiave contenuta nel dump ripristinato e che ogni allegato più vecchio di un’ora abbia una copia nella posizione di backup, con una di queste copie aperta e verificata rispetto al relativo checksum — il solo conteggio delle righe non può distinguere un backup utilizzabile da un testo cifrato la cui chiave non corrisponde più. La freschezza dei backup è monitorata continuamente (avviso se il dump più recente è più vecchio di 36 ore).

Crittografia. Hetzner dichiara che Object Storage non cifra gli oggetti a riposo per impostazione predefinita, quindi i dump del database sono cifrati prima di lasciare l’host: GnuPG simmetrico AES-256, con la passphrase detenuta solo dal processo di backup e depositata fuori dalla macchina. I campi cifrati a livello applicativo con Rails ActiveRecord Encryption restano cifrati separatamente all’interno di ogni dump. Gli allegati sono cifrati a riposo con una chiave per ogni file (vedi allegati). Tali chiavi esistono solo nel database, quindi ogni dump cifrato le contiene. I file stessi non sono copiati nel dump. Ciascuno è archiviato a Norimberga e copiato, con la stessa chiave, in un secondo bucket a Falkenstein; entrambi mantengono le versioni precedenti per 28 giorni.

Esame operativo #

Alcuni materiali operativi sono condivisi durante la verifica in fase di approvvigionamento anziché pubblicati per intero sul web aperto, perché contengono dettagli infrastrutturali e di risposta più appropriati per una divulgazione controllata.

Tra gli argomenti disponibili su richiesta durante l’approvvigionamento figurano:

• Riepilogo dell’accesso privilegiato in produzione
• Flusso di lavoro di risposta agli incidenti e contatti per l’escalation
• Risposte su continuità operativa e dismissione/esportazione dei dati dei clienti

Divulgazione responsabile #

Se scopri una vulnerabilità di sicurezza in EthicsPortal, ti preghiamo di segnalarla a security@ethicsportal.eu. Ti chiediamo di:

1. Non divulgare pubblicamente la vulnerabilità prima che abbiamo avuto la possibilità di affrontarla.
2. Fornire dettagli sufficienti affinché possiamo riprodurre e correggere il problema.
3. Non accedere né modificare i dati di altri clienti.
4. Non eseguire attacchi denial-of-service né scansioni automatizzate massive, non tentare attacchi di social engineering contro il nostro personale e non inviare segnalazioni tramite il canale di segnalazione di un cliente.

Daremo avviso di ricevimento della tua segnalazione entro 2 giorni lavorativi e ci impegneremo a risolvere prontamente le vulnerabilità confermate.

Nessun bug bounty retribuito. La divulgazione non è ricompensata: non remuneriamo le segnalazioni di vulnerabilità e non firmiamo accordi di riservatezza, non accettiamo condizioni commerciali né teniamo chiamate come presupposto per ricevere una segnalazione. Invia l’asset interessato, i passaggi di riproduzione e l’impatto che hai accertato all’indirizzo indicato.

Ultimo aggiornamento: 8 novembre 2026