Versione 1.0 · 2026-08-19. Quattro domini: crittografia, custodia delle chiavi, isolamento tenant, requisiti giuridici. Ogni controllo riporta come verificarlo senza fidarsi di noi; i gap sono dichiarati, non nascosti.
Le prove sono verificabili da terzi senza fidarsi del server?
Manifest e sigilli di catena sono firmati con ECDSA su curva P-256 e digest SHA-256 tramite WebCrypto. La chiave privata non lascia mai il server.
Come verificarlo: src/lib/certified.server.ts (SIGNATURE_ALG) e verifica browser-side su /release-evidence/verify.
Il payload firmato è serializzato in forma canonica: due esecuzioni con gli stessi input producono lo stesso hash normalizzato.
Come verificarlo: Prova pubblica di determinismo su /release-evidence/determinism.
Ogni evento contiene prev_hash ed entry_hash: la rimozione o l'alterazione di un anello rompe la catena in modo rilevabile.
Come verificarlo: Verificatore offline HTML e /release-evidence/verify ricalcolano la catena localmente.
La firma simmetrica storica resta calcolata per compatibilità con i pacchetti emessi prima della migrazione. Non è sufficiente per la verifica pubblica e non deve essere presentata come tale.
Come verificarlo: Il verdetto pubblico si basa sulla firma asimmetrica; l'HMAC è solo un controllo interno.
Nessun laboratorio esterno ha ancora rivisto lo schema. È il prerequisito dichiarato prima di qualunque affermazione più forte.
Come verificarlo: Aperto: da assegnare a un revisore terzo.
Chi può firmare, con quale chiave, e cosa succede dopo una rotazione?
Ogni firma dichiara il key_id usato. Le chiavi ritirate restano pubblicate: le prove storiche restano verificabili dopo la rotazione.
Come verificarlo: Keyset pubblico esposto ai verificatori; console admin mostra stato ed età di ogni chiave.
Rotazione automatica alla scadenza configurata (default 90 giorni) e rotazione manuale amministrativa, entrambe tracciate come alert persistente.
Come verificarlo: ensureKeyRotation / rotateSigningKey, con evento di audit certified.key_rotated.
Prefissi di chiave distinti per PREPROD e produzione: un pacchetto di collaudo non può apparire come produttivo.
Come verificarlo: Prefissi bkc-test- e bkc-cert- nel keyset pubblico.
La chiave privata è oggi custodita nel database sovrano dell'applicazione, non in un HSM certificato. È il gap più rilevante dell'assessment.
Come verificarlo: KEY_CUSTODY riporta il custode effettivo; il valore attuale è dichiarato in console.
La revoca di una chiave è tecnicamente possibile, ma la procedura formale di risposta a compromissione (chi decide, in quanto tempo, come si comunica) non è ancora approvata.
Come verificarlo: Da formalizzare come runbook firmato.
Un utente autenticato può vedere o modificare dati di un altro?
Le tabelle applicative hanno RLS attiva e GRANT espliciti. Le server function autenticate operano con il client dell'utente: le policy si applicano come utente chiamante.
Come verificarlo: Policy ispezionabili; linter di piattaforma eseguito a ogni assessment.
Ogni server function non autenticata è elencata con motivazione ed esposizione. Un endpoint pubblico nuovo e non dichiarato fa fallire la CI.
Come verificarlo: src/lib/tenant-isolation.ts e src/lib/__tests__/tenant-isolation.test.ts.
La policy permissiva di auto-adesione è stata rimossa: l'appartenenza si ottiene solo tramite redeem di un invito valido in funzione SECURITY DEFINER.
Come verificarlo: space_members non ha alcuna policy INSERT lato client.
Tutte le operazioni sulla coda richiedono ruolo admin; la console non può leggere il payload degli elementi; ogni aggiornamento è scoped al singolo id e legato al run-id.
Come verificarlo: Test automatici sulle sei operazioni della coda e sulle colonne selezionabili.
Il client privilegiato è importato solo dentro gli handler, mai a livello di modulo di una server function, e mai per decidere se il chiamante è admin.
Come verificarlo: Controllo automatico sul module scope di ogni file *.functions.ts.
I controlli sono statici e di policy; manca una verifica dinamica condotta da un terzo con due tenant reali.
Come verificarlo: Aperto: da assegnare a un revisore terzo.
Cosa possiamo affermare pubblicamente, e cosa no?
Ogni pagina pubblica, report firmato e comunicazione riporta lo stesso testo: verificabilità tecnica sì, equivalenza PEC/eIDAS no.
Come verificarlo: LEGAL_DISCLAIMER in src/lib/trust-dossier.ts, riusato dalle pagine pubbliche.
Il sistema distingue i requisiti per giurisdizione e li mostra, ma la mappatura non è stata validata da un legale abilitato in ciascun ordinamento.
Come verificarlo: Motore giurisdizioni nel modulo Certified; validazione legale aperta.
I pacchetti conservano metadati e hash necessari alla prova; le politiche di retention per giurisdizione non sono ancora approvate formalmente.
Come verificarlo: Da formalizzare in una policy di conservazione approvata.
Nessuna qualificazione richiesta né ottenuta. Qualsiasi affermazione di equivalenza legale sarebbe scorretta finché un organismo competente non si esprime.
Come verificarlo: Nessuna evidenza esiste: lo stato è dichiarato come assente.