Un’affermazione è una frase. Una prova è qualcosa che una seconda persona può verificare senza chiedertelo. Cosa deve contenere una traccia di audit, cosa prova davvero un hash, e cosa pretendere da qualsiasi strumento che sostiene di produrne una.
Aggiornato · 6 min di lettura
La dashboard è stata revisionata. Questa è un’affermazione.
Questa cartella di lavoro, in questa versione, differiva dalla versione precedente in ventiquattro modi, tre dei quali falliti; revisionata da questa persona con un nome in questa data; esportata come un pacchetto sigillato con questo hash. Questa è una prova.
Il test tra le due è una sola domanda. Una seconda persona può arrivare alla stessa conclusione senza chiedere nulla alla prima. Se deve chiedere, quello che hai è una conversazione, e le conversazioni non sopravvivono alle persone che le hanno avute.
Due cose non devono mai starci: i segreti, e una copia dei dati che la verifica ha letto per caso. Un log di audit che accumula silenziosamente dati di business è una nuova responsabilità con addosso un badge di conformità, e verrà scoperta da qualcuno che non è dalla tua parte.
Questo sito fa qualcosa che un sito di marketing di solito non fa. Le affermazioni portano un percorso nel repository o una superficie del prodotto, e ogni articolo finisce con fonti che puoi aprire e leggere da solo.
La ragione è il pubblico. Un prodotto di governance viene comprato da persone la cui professione non è prendere le affermazioni sulla fiducia, e un’affermazione con un percorso allegato invita alla verifica. Invitare alla verifica è il segnale più forte disponibile che la verifica non sarà imbarazzante.
Disciplina anche la scrittura, in un modo scomodo e utile. Cinque capacità sono state proposte per questo sito come elementi distintivi e sono state verificate contro il codice sorgente prima che qualcosa venisse stampato. Nessuna è sopravvissuta alla verifica, e due sono state smentite apertamente dal codice in produzione. Ora sono vietate su ogni pagina da un test, non da buone intenzioni, e il registro del perché è conservato nel repository. La disciplina si è rivelata molto più importante delle cinque frasi.
Un sigillo SHA-256 su un pacchetto esportato prova esattamente una cosa: i byte che hai in mano sono i byte che sono stati sigillati. Non prova che il contenuto sia vero. Uno strumento che lascia intendere altro ti sta vendendo qualcosa.
Ciò che elimina è un argomento specifico: se il file è stato modificato tra l’esportazione e la revisione. Eliminare quell’argomento vale moltissimo in un audit, e non vale niente in una discussione sul fatto che la verifica fosse quella giusta.
La forma più forte è una catena. Ogni voce fa l’hash del proprio contenuto insieme all’hash della voce precedente. Una riga cancellata o alterata rompe la catena da quel punto in avanti, e la verifica nomina la prima riga sbagliata. Usare SHA-256 semplice senza chiave segreta è la parte che conta per un auditor: può ricontrollare l’export con i propri strumenti invece di usare i nostri.
Un pacchetto di prove dovrebbe essere riproducibile byte per byte. Eseguilo due volte sullo stesso input e ottieni gli stessi byte. Sembra accademico finché qualcuno non ti chiede di rieseguire un rapporto di sei mesi fa e confrontarlo.
Vincola anche la progettazione in modi utili. Esclude marche temporali sparse nel contenuto, ordinamenti instabili, e qualsiasi cosa derivi da un modello che domani potrebbe rispondere diversamente.
Che è un altro modo per enunciare una regola che vale la pena tenere: il motore deterministico è quello che può produrre prove. Un passaggio assistito dall’IA produce una bozza, e una bozza è una bella cosa da avere, purché nessuno la archivi come prova.
Una prova che esiste solo dentro il prodotto che l’ha prodotta non è una prova, è uno schermo. La domanda da fare è cosa esporta, e in che forma.
Sul lato sicurezza l’etichettatura deve viaggiare con il rilievo. Un rilievo mappato a un safeguard CIS Controls v8.1 e a una funzione NIST CSF 2.0 dovrebbe portare quella mappatura identica nel CSV, nell’export SARIF, nel PDF e nell’interfaccia. Una mappatura che compare solo in una pagina web non raggiunge mai lo scanner che l’avrebbe usata. Era decorazione.
Le prove di audit mappate sono una cosa utile da produrre, e non sono una certificazione di conformità. Qualsiasi strumento che confonde le due ti fa del male nel momento esatto in cui hai più bisogno di chiarezza.
La quarta seleziona i prodotti in fretta. Se il registro se ne va con lo strumento, allora ciò che è stato comprato era una dashboard sulla governance, non la governance stessa.
La riga più utile nella maggior parte dei rapporti è quella che descrive cosa non è stato coperto. Ciò che non è stato misurato dovrebbe essere riportato come non misurato, mai riempito in silenzio con un numero plausibile.
Un rapporto con lacune che puoi vedere vale più di un rapporto dall’aria completa che non puoi verificare, perché sul primo puoi agire questa settimana.
E un elenco di rilievi vuoto è un buon risultato, il che è vero solo quando lo stesso strumento ti avrebbe detto chiaramente se la verifica non fosse girata affatto. Una prova è ciò che resta utile quando la persona che l’ha prodotta non è disponibile.
Quattro cose vengono chiamate governance: certificazione, proprietà, contenuti obsoleti e controllo delle modifiche. Qui ognuna è scritta come una verifica che puoi eseguire, non come un obiettivo che puoi dichiarare. Si parla anche dell’unica modifica che supera una revisione visiva ed è comunque sbagliata.
La regola approva per eseguire, in parole semplici. L’assistente legge, spiega e propone, e una persona possiede il percorso di scrittura. Cosa costa, cosa rende, e tre domande da fare a qualsiasi funzione di IA.
Un livello semantico dà a una metrica una sola casa. Ogni strumento che calcola la metrica legge quell’unica casa. Tutti ottengono lo stesso numero. Ecco cosa significa in pratica, e cosa cambia quando gestisci più di un warehouse.