Gli ingegneri che si avvicinano per la prima volta a ISO 27001 spesso immaginano un'ampia revisione del codice, o un certificato che si supera come un test suite. Non è nessuna delle due. ISO/IEC 27001:2022 è uno standard di sistema di gestione. Si costruisce un sistema di gestione della sicurezza delle informazioni (politiche, trattamento del rischio, ruoli, fornitori, incidenti, e il resto). Un ente di certificazione accreditato audita quel sistema e, se conforme, emette un certificato. Il repository di GitHub non è la cosa che viene certificata.
Questa pagina tratta la piccola parte che risiede effettivamente nel repository: i controlli tecnologici dell'Allegato A che una pull request può indebolire silenziosamente. È il fratello ISO 27001 delle guide "cosa verifica effettivamente" di SOC 2 e HIPAA. Non è il catalogo dei controlli (quello è il hub del framework), e non è la domanda "c'è un'app di GitHub" (quella ha la sua risposta).
Il certificato non è una scansione del repository
Un rapporto SOC 2 Type II è un parere di una società di revisione indipendente sulla progettazione adeguata e sull'efficacia operativa dei tuoi controlli, come li hai descritti, durante un periodo. Un rapporto Type I si riferisce solo alla progettazione in un momento specifico. Un certificato ISO 27001 accreditato è diverso: un ente di certificazione accreditato attesta che il tuo sistema di gestione è conforme allo standard. Nessuno dei due è una scansione statica del codice sorgente. Nessuno dei due è emesso da un'app GitHub. Se un fornitore implica che l'installazione di un revisore "ti dà l'ISO 27001", sta descrivendo un prodotto diverso dallo standard.
L'allegato A della ISO/IEC 27001:2022 elenca 93 controlli in quattro temi (organizzativi, persone, fisici, tecnologici). Non implementi tutti e 93 come una checklist di codice. La Dichiarazione di Applicabilità registra i controlli che hai determinato essere necessari, perché sono inclusi, se sono implementati, e perché eventuali controlli dell'Allegato A sono esclusi. L'Allegato A è un set di riferimento a cui controlli le tue decisioni, non un menu di 93 voci da implementare come codice. La maggior parte dei 93 non appare mai in una diff: contratti con i fornitori, uffici fisici, screening del personale, documentazione di trattamento del rischio. Trattare i 93 come un audit del repository è la grana sbagliata.
La fetta dell'Allegato A che risiede nel codice
Il tema tecnologico (A.8) ha 34 controlli. Anche lì, solo una manciata compaiono regolarmente in una pull request: logging (A.8.15), monitoraggio (A.8.16), crittografia e gestione delle chiavi (A.8.24), restrizione dell'accesso (A.8.3), forza dell'autenticazione (A.8.5), configurazione che rimane abbinata a una baseline (A.8.9), codifica sicura (A.8.28), gestione dei cambiamenti (A.8.32) e backup delle informazioni (A.8.13). Se puoi ragionare su chi può raggiungere cosa, come provano chi sono, cosa viene registrato, come vengono tenuti i segreti e se un cambiamento è ancora passato attraverso il processo che hai scritto, stai ragionando sulla maggior parte della superficie rivolta al codice.
Il resto di A.8 (reti, capacità, malware, orologi, e così via) è reale, ma è solitamente deciso in architettura e operazioni, non in una PR di applicazione di due righe. Il hub del framework elenca i trigger. Questa pagina è il modello mentale: ISO 27001 in un repository sono quelle forme di A.8, non il certificato e non l'intera lista dell'Allegato A.
Un percorso privilegiato che elimina silenziosamente un secondo fattore
Un team di supporto non può generare un token API durante un incidente perché la strada amministrativa richiede MFA e il telefono di turno è in un armadietto. Una pull request rimuove il controllo del secondo fattore e lascia il cookie di sessione come unica porta. I test rimangono verdi. Il codice è più breve. I commenti di revisione riguardano lo sblocco dell'incidente. Dopo la fusione, chiunque possa ottenere una sessione valida può generare un token privilegiato senza il fattore aggiuntivo che il percorso usava per richiedere.
ISO 27001:2022 A.8.5 riguarda la forza dell'autenticazione. Un'azione privilegiata che richiedeva un secondo fattore e ora richiede solo una sessione è più debole dopo la fusione. Se ciò sia accettabile (un'eccezione documentata e temporizzata per incidenti rispetto a un buco permanente) è una decisione di rischio per il team. Il compito della revisione è nominare il controllo in modo che la decisione sia presa intenzionalmente. A.8.3 (restrizione dell'accesso) può sedere accanto ad esso se il token è come viene concesso l'accesso.
La modifica inversa, rimettere requireMfa sulla rotta o instradare la coniazione di token di incidente attraverso un percorso di emergenza che viene registrato e scade, è economica nella PR. Lasciare il percorso più debole in atto è la versione costosa: sei mesi dopo, un campionatore di un ente di certificazione può chiedere come vengono autenticate le azioni privilegiate, e il contesto è perso.
Dove si inserisce heygrc, e il confine di onestà
heygrc è un'app di GitHub che revisiona ogni pull request rispetto ai framework che hai selezionato e cita il controllo dell'Allegato A che una modifica tocca, ad esempio A.8.5 sul salto di MFA sopra, o A.8.15 quando un'azione privilegiata smette di essere registrata. Non ti certifica. Non esegue il tuo ISMS. Non scrive la Dichiarazione di Applicabilità, sceglie l'ente di certificazione o emette un certificato. Né heygrc né ISMS Copilot detengono una certificazione ISO 27001. Usalo come revisore del cambiamento, non come sistema di gestione.
Se la domanda che hai effettivamente digitato era "c'è un'app di GitHub per ISO 27001", la risposta breve è sì, e vive sulla sua pagina. Questa guida è l'altra metà: cosa quell'App starebbe effettivamente guardando, e perché la maggior parte di ISO 27001 non apparirà mai nella diff.