Come faccio questo senza violare un controllo?

Registra gli eventi rilevanti per la sicurezza (chi ha fatto cosa e quando), includi sempre l'attore, scrivili in un luogo durevole e non permettere che una pulizia successiva li elimini. SOC 2 (CC7.2) e ISO 27001 (A.8.15) si aspettano entrambi questo e lo verificano campionando gli eventi effettivamente registrati.

Non inserire mai la chiave nel codice sorgente. Leggila dall'ambiente o da un archivio gestito di secret a runtime, tieni fuori dal repository e dai log e ruota qualsiasi secret che sia stato committato. L'ISO 27001 A.8.24 (e la semplice prudenza) richiede che le chiavi siano gestite, non hardcodate.

Assicurati che il percorso di eliminazione raggiunga ogni sistema in cui risiedono i dati della persona: il database principale, le cache, gli indici di ricerca, gli analytics, i backup (con il proprio ciclo di vita documentato) e qualsiasi processore terzo a cui li hai inoltrati. Quando si applica il diritto all'oblio (GDPR Art. 17), una copia dimenticata è ciò che lo vanifica, quindi il percorso di eliminazione deve raggiungerle tutte.

Blocca la versione, verifica ciò che scarichi (con un lockfile e controlli di integrità), evita di eseguire script di installazione remoti e preferisci il tuo registry o mirror verificato. La NIS 2 (Art. 21(2)(d)) considera le dipendenze come parte della sicurezza della supply chain, e i controlli su di esse risiedono nel manifest e nel processo di build.

Attiva la crittografia a riposo per ogni archivio che contiene informazioni sanitarie protette in formato elettronico (database, bucket, volumi, backup) o documenta perché è in vigore una misura di protezione equivalente. La specifica di crittografia di HIPAA (164.312(a)(2)(iv)) è indirizzabile: implementala dove ragionevole, oppure registra un'alternativa equivalente, senza tralasciarla.

Concedi solo l'accesso necessario a ogni ruolo o servizio, nega per impostazione predefinita ed evita i wildcard. SOC 2 (CC6.1) verifica l'accesso logico, e il principio del privilegio minimo è ciò che un revisore campiona: ogni identità può fare solo ciò che il suo ruolo richiede, e nulla di più.

Registra riferimenti e codici minimi, non contenuti completi. Registra un ID di richiesta o un ID di ordine, oscura i campi personali prima che vengano scritti e non registrare mai l'intera richiesta o l'oggetto utente. Registrare meno dati, e meno dati identificativi, è proprio ciò che richiede il principio di minimizzazione dei dati del GDPR (Art. 5(1)(c)). Tratta un identificatore che punta a una persona come dato personale e limitati a ciò che serve effettivamente per l'indagine.

Valida il target prima di recuperarlo: richiedi https, risolvi l'host e rifiuta gli indirizzi privati, interni e link-local (inclusi gli endpoint dei metadati cloud). Preferisci una lista consentita quando le destinazioni sono note e non seguire reindirizzamenti in modo acritico. Il server-side request forgery è un problema di validazione dell'input (NIST 800-53 SI-10) e il controllo risiede nel codice che effettua la richiesta.

Un esportazione è una nuova copia di dati personali, quindi trattala come tale: assegnale una scadenza in modo che non superi il suo scopo, esporta solo i campi e le righe necessari allo scopo e non permettere che un esportazione ricorrente diventi un secondo archivio permanente e non governato. Questo è il principio del GDPR sulla limitazione della conservazione (Art. 5(1)(e)).

Utilizza la tokenizzazione del processore di pagamenti in modo che i dati grezzi della carta vengano inviati direttamente a loro, senza passare per i tuoi server. Memorizza il token restituito e le ultime quattro cifre per la visualizzazione e non conservare mai il numero completo della carta o il codice di verifica. In questo modo rimani conforme al Requisito 3 di PCI DSS e riduci la portata dell'ambito PCI applicabile alla tua organizzazione.

Se una decisione su una persona viene presa esclusivamente da un algoritmo e ha effetti giuridici o di simile importanza su di essa (ad esempio il diniego di un rimborso, un prestito o un account), l'Art. 22 del GDPR la limita: in linea di principio, la persona ha il diritto di non essere soggetta a una decisione completamente automatizzata di questo tipo. Nei casi in cui tale decisione è comunque consentita (ad esempio perché necessaria per un contratto o basata sul consenso esplicito della persona), l'Art. 22(3) richiede garanzie, tra cui la possibilità di ottenere l'intervento umano, esprimere un parere e contestare il risultato. In ogni caso, non lasciare che il percorso automatizzato sia l'ultima parola: indirizza queste decisioni verso un percorso in cui una persona possa rivederle.

Limitare chi può accedere a funzioni sensibili è l'obiettivo di SOC 2 CC6.1 (controlli di accesso logico), e per le azioni privilegiate una sessione valida di solito non è sufficiente da sola. Richiedi un secondo fattore al momento dell'azione privilegiata, blocca l'accesso se manca e registra il controllo, in modo che raggiungere un percorso admin richieda più di una sessione rubata o persistente.

Esistono tre tipi di revisori automatici che analizzano una pull request: i revisori del codice che cercano difetti, i revisori di sicurezza che cercano vulnerabilità e i revisori di conformità che analizzano la modifica rispetto ai framework che la tua azienda deve rispettare. heygrc è un revisore di conformità per le pull request: revisiona ogni PR rispetto ai framework selezionati e cita il controllo specifico interessato dalla modifica, ad esempio ISO 27001 A.8.15 o SOC 2 CC6.1. Per quanto ne sappiamo, è il primo revisore di conformità per pull request (luglio 2026).

La maggior parte delle piattaforme GRC e di automazione della conformità si integra con GitHub a livello di account e repository: leggono impostazioni come la protezione dei branch e le revisioni obbligatorie come prove che il controllo di gestione delle modifiche è operativo. Quell'integrazione legge la configurazione, non il codice. La revisione della pull request stessa, la lettura delle righe modificate e l'identificazione del controllo che mettono a rischio, è un compito diverso. heygrc svolge questo compito: un'app GitHub che esamina ogni pull request rispetto ai framework selezionati e pubblica il risultato come verifica sulla PR.

Un audit è un indicatore ritardato: campiona ciò che è stato distribuito mesi fa, quando la violazione è già in produzione e costosa. La code review è l'indicatore anticipato, l'ultimo momento in cui una violazione è a un click dal non esistere. Per rilevarla lì: sapete quali controlli risiedono effettivamente nel codice, fate della domanda di conformità parte della lettura di ogni diff, collegate ogni segnalazione alla clausola specifica e mantenete la traccia in modo che la revisione stessa diventi prova per l'audit.

Revisiona il codice generato dall'IA con lo stesso standard del codice umano: l'auditor non chiederà chi ha scritto una modifica, ma solo se il controllo è stato applicato. Ciò che cambia con gli agenti è il volume e il modello di errore. Un agente ottimizza per il compito visibile, quindi il codice di controllo che appare come un attrito (una riga di log, un controllo dei permessi, un limite di conservazione) è a rischio nelle sue diff. Inoltre, gli agenti aprono più pull request di quante un revisore umano possa gestire. Automatizza la prima verifica; riserva il giudizio umano alle decisioni critiche.

Sì. heygrc è un'app GitHub che esamina ogni pull request rispetto a ISO 27001:2022 e cita il controllo specifico dell'Allegato A che una modifica interessa, ad esempio A.8.15 per un log di audit silenziato o A.8.24 per una crittografia indebolita. La installi sui tuoi repository, selezioni ISO 27001 e altri framework applicabili, e pubblica i risultati come commenti di revisione più uno stato di controllo che non blocca il merge a meno che non lo richieda. Per quanto ne sappiamo, è il primo revisore di conformità per pull request (luglio 2026).

Solo se lo vuoi. Un controllo di conformità su una pull request dovrebbe predefinire uno stato neutro: pubblica i risultati e lo stato del controllo, mentre la decisione di merge rimane all'ingegnere. I team che vogliono un blocco rigido possono richiedere il controllo nella protezione del branch, il che trasforma lo stesso segnale in un blocco solo per i branch selezionati. heygrc fornisce lo stato neutro predefinito e supporta la configurazione del controllo richiesto.