# Cosa serve per i bandi (il salto di qualità) ## Vulnerability Assessment e Certificazione di crittografia Per bandi di **livello elevato** (es. Difesa, Sanità, PA sensibile) le stazioni appaltanti possono richiedere, **in alternativa o in aggiunta** alla consegna del codice sorgente, due elementi con **valore legale e contrattuale**: 1. **Vulnerability Assessment (VA)** – documento rilasciato da soggetto terzo certificato. 2. **Dichiarazione / Certificazione di crittografia** – assenza di backdoor e conformità a **Privacy by Design e by Default** (es. GDPR, bandi europei). Di seguito: cosa sono, cosa chiedere e come strutturarli. --- ## 1. Vulnerability Assessment (VA) ### 1.1 Cosa è Un **Vulnerability Assessment** è un’attività condotta da una **società esterna e qualificata** (es. penetration test, security assessment) che: - prova ad attaccare il sistema (es. intercettare traffico, leggere dati in transito, sfruttare vulnerabilità note); - documenta metodologia, scope, risultati e conclusioni; - attesta in forma scritta (e firmata) che, nell’ambito del perimetro e delle tecniche adottate, **non è stato possibile** leggere le push in transito o violare la confidenzialità E2EE nel modo richiesto dal mandante. Ha **valore probatorio in sede di gara** perché è un **documento di terza parte**, indipendente dal fornitore. ### 1.2 Cosa deve contenere il documento (checklist per la commessa) Quando si incarica una società per il VA, il **deliverable** dovrebbe includere almeno: | Voce | Descrizione | |------|-------------| | **Scope** | Perimetro oggetto di assessment (es. “sistema di push E2EE Willy Push: API, client web, flusso FCM”). | | **Obiettivi** | Cosa si intende dimostrare (es. “impossibilità di leggere il contenuto delle push in transito senza la chiave privata sul dispositivo”). | | **Metodologia** | Standard o framework usati (es. OWASP, NIST, o metodologia interna documentata). | | **Attività svolte** | Es. analisi traffico, tentativi di decifratura senza chiave, test su API, verifica gestione chiavi. | | **Risultati** | Cosa è stato trovato (vulnerabilità) e cosa no (es. “non è stato possibile recuperare il plaintext delle push in transito”). | | **Conclusioni** | Dichiarazione sintetica utilizzabile in gara (es. “Nel perimetro definito, il contenuto delle notifiche push cifrate non risulta accessibile senza la chiave privata custodita sul dispositivo”). | | **Limitazioni** | Limitazioni di scope, tempo, tecniche (per correttezza e trasparenza). | | **Riferimento al fornitore** | Nome progetto/prodotto e, se utile, riferimento al Whitepaper o alla documentazione tecnica (es. WHITEPAPER_E2EE_Willy.md). | ### 1.3 Come usarlo in gara - Allegare il **report VA** (o un estratto “per la stazione appaltante” senza dettagli sensibili) come **documentazione a supporto** della soluzione. - Nel **capitolo tecnico / sicurezza** della risposta al bando: citare il VA (“È stato condotto un Vulnerability Assessment da [società certificata] in data … con esito …”) e indicare che il documento completo (o sintesi) è allegato. --- ## 2. Certificazione di crittografia e assenza di backdoor ### 2.1 Cosa richiedono i bandi Molti bandi (soprattutto post-GDPR e in ambito europeo) chiedono: - una **dichiarazione** che il software **non contiene backdoor** (nessuna via occulta per accedere ai dati senza consenso/legittimo titolo); - l’attestazione di conformità ai principi di **Privacy by Design** e **Privacy by Default** (progettazione e impostazioni predefinite rispettose della privacy). Queste dichiarazioni possono essere: - **autocertificazioni** del fornitore (sottoscritte da legale rappresentante o responsabile tecnico), oppure - **certificazioni / audit** di terza parte, se il bando lo richiede esplicitamente. ### 2.2 Template di dichiarazione (da adattare) Di seguito un **modello di dichiarazione** che l’azienda può adattare e sottoscrivere (o far integrare in una relazione tecnica / documento di conformità). --- **DICHIARAZIONE – Crittografia e Privacy by Design (E2EE Willy Push)** Il sottoscritto ____________________, in qualità di ____________________ della società ____________________, **dichiara** quanto segue, con riferimento al sistema di notifiche push con crittografia end-to-end (E2EE) denominato “Willy Push E2EE”: 1. **Assenza di backdoor** Il software non implementa backdoor, canali nascosti o meccanismi che consentano a soggetti terzi (inclusi il fornitore e gli operatori di infrastruttura) di decifrare il contenuto delle notifiche push senza il possesso della chiave privata custodita sul dispositivo dell’utente. La decifratura avviene esclusivamente sul dispositivo dell’utente, utilizzando chiavi generate e memorizzate localmente (es. IndexedDB in ambito web; Keystore/Secure Enclave in ambito nativo). 2. **Privacy by Design** Il sistema è progettato in modo che: - il contenuto delle notifiche (titolo, corpo, URL, ecc.) sia cifrato end-to-end prima dell’invio verso qualsiasi servizio di trasporto (es. FCM); - solo il destinatario designato (dispositivo in possesso della chiave privata) possa decifrare tale contenuto; - il fornitore e i gestori dell’infrastruttura di invio non abbiano la possibilità tecnica di leggere il contenuto in chiaro delle notifiche E2EE. 3. **Privacy by Default** Le impostazioni predefinite del sistema sono orientate alla massima protezione dei dati: l’uso della crittografia end-to-end per le notifiche è previsto come modalità di funzionamento quando l’utente aderisce al relativo flusso (generazione chiavi e registrazione); non sono previste modalità “degradate” che espongano il contenuto in chiaro al di fuori del dispositivo dell’utente senza suo consenso esplicito. 4. **Riferimento documentale** La descrizione del protocollo crittografico, del ciclo di vita delle chiavi e dell’architettura logica è documentata nel Whitepaper tecnico (WHITEPAPER_E2EE_Willy.md) e può essere verificata da esperti di sicurezza senza necessità di analisi del codice sorgente. La presente dichiarazione è resa in conformità ai principi di cui al Regolamento (UE) 2016/679 (GDPR), in particolare agli artt. 25 (Privacy by Design e by Default) e 32 (sicurezza del trattamento), e alle eventuali specifiche richieste dal bando di riferimento. Luogo e data ____________________ Firma ____________________ --- ### 2.3 Come usarla in gara - Inserire la **dichiarazione firmata** tra gli allegati della risposta (es. “Dichiarazione crittografia e Privacy by Design”). - Nel **capitolo sicurezza / privacy / conformità**: citare esplicitamente “Privacy by Design”, “Privacy by Default”, “assenza di backdoor” e rinviare al Whitepaper e alla dichiarazione allegata. --- ## 3. Riepilogo per la risposta al bando | Richiesta tipica | Documento / azione | |------------------|-------------------| | **Dimostrazione pratica (PoC)** | Sessione di **Live Debug** secondo la guida **POC_Live_Debug_Guida.md**: cloud con messaggio illeggibile + dispositivo con testo in chiaro. | | **Vulnerability Assessment** | Incarico a **società esterna certificata**; deliverable = report VA con scope, metodologia, risultati, conclusioni; allegato alla documentazione di gara. | | **Certificazione / dichiarazione crittografia** | **Dichiarazione** firmata (template sopra) su assenza di backdoor e conformità a Privacy by Design e by Default; riferimento al Whitepaper; allegata alla documentazione di gara. | Questi elementi **non sostituiscono** eventuali obblighi di consegna del codice o di audit del codice se il bando li richiede; li **affiancano** per dare alle stazioni appaltanti garanzie di sicurezza e privacy in forma documentata e, ove previsto, legalmente rilevante. --- *Documento di supporto per la preparazione delle offerte in bandi che richiedono VA, certificazione di crittografia e Privacy by Design / by Default.*