Quando si tratta la conformità come qualcosa che risiede nel codice, sorge una domanda: quali modifiche violano effettivamente un controllo? Non in teoria, ma nel diff. Non abbiamo ancora telemetria di produzione per rispondere, quindi non si tratta di un grafico di ciò che abbiamo osservato in pratica. È la tassonomia che abbiamo creato per heygrc: cinque pattern di pull request che, per costruzione, violano un controllo nel modo più diretto.
Cosa li unisce è scomodo. Nessuno sembra una modifica di conformità. Ogni modifica è un edit ragionevole, una pulizia, uno sblocco, una comodità, che per caso rimuove l'elemento su cui un framework contava. Ecco quali sono.
1. Una chiave segreta nella configurazione
Il modo più veloce per far funzionare un'integrazione è inserire la chiave dove il codice può leggerla direttamente. Funziona al primo tentativo e scrive una credenziale attiva nel repository, nella sua cronologia e in ogni clone e cache CI che la scarica. Una chiave segreta committata è una chiave segreta esposta, e l'unica risposta sicura è ruotarla.
- const key = process.env.PAYMENTS_SECRET_KEY+ const key = "<the live key, pasted inline>"const client = new Payments(key)La credenziale ora risiede nel controllo versione, accessibile a chiunque abbia accesso al repository, ora o in futuro. Leggila da un archivio segreto gestito e ruota quella che è stata committata.
2. Autorizzazione allentata
Un controllo di autorizzazione ostacola una modifica, quindi viene rimosso o ampliato con un wildcard per sbloccare un chiamante. La funzionalità funziona per tutti dopo, incluse le persone che il controllo esisteva per escludere.
export async function getReport(user, id) {- if (!user.can("reports:read")) return forbidden() return reports.find(id)}Rimuovendo il controllo, qualsiasi chiamante autenticato può leggere qualsiasi report, non solo quelli a cui ha diritto. Ripristina il controllo di autorizzazione invece di aggirarlo.
3. Registrazione disabilitata
Una riga di log è rumorosa, quindi viene rimossa durante una pulizia. Il sistema funziona ancora, ma smette di registrare l'evento di sicurezza che un revisore campionerà in seguito e che vorresti avere dopo un incidente.
async function onLogin(userId, ip) {- await audit.log("auth.login", { userId, ip }) return startSession(userId)}L'evento di accesso non viene più registrato, quindi non può essere monitorato o ricostruito in seguito. Mantieni il log; se è troppo rumoroso, cambia il suo livello o la destinazione invece di eliminarlo.
4. Regole di rete ampliate
Un servizio non riesce a raggiungere un database, quindi una regola del gruppo di sicurezza viene aperta per far funzionare la connessione. Funziona, e ora funziona anche ogni altra connessione nell'intervallo, incluse quelle provenienti da internet aperto.
ingress { from_port = 5432- cidr_blocks = ["10.0.0.0/16"]+ cidr_blocks = ["0.0.0.0/0"]}Aprire la regola a 0.0.0.0/0 espone la porta del database a tutto internet, non solo al servizio che ne aveva bisogno. Limita la regola alla sorgente che richiede l'accesso.
5. Crittografia disabilitata
La crittografia non funziona in staging, quindi la soluzione più rapida è smettere di verificarla, e la modifica viene distribuita. I dati che dovrebbero viaggiare autenticati e crittati ora viaggiano in un modo che può essere letto o manomesso durante il transito.
const agent = new https.Agent({+ rejectUnauthorized: false,})Disabilitare la verifica del certificato significa che la connessione non è più autenticata, quindi può essere intercettata da un attacco man-in-the-middle. Mantieni la verifica attiva e sistema il certificato di staging invece.
Perché questi cinque
Lo schema comune a tutti e cinque è lo stesso: una modifica che migliora una cosa, un'integrazione funzionante, un chiamante sbloccato, un output più pulito, un database raggiungibile, un test di staging superato, rimuove silenziosamente una salvaguardia su cui un framework fa affidamento. Il danno alla conformità è un effetto collaterale di un obiettivo ragionevole, ed è esattamente per questo che né l'autore né una revisione ordinaria lo rileva. Nessuno intendeva indebolire un controllo.
Questo è il motivo per cui è necessario rivedere il diff rispetto ai controlli, nel momento in cui la modifica viene effettuata. Abbiamo iniziato con questi cinque perché sono i più diretti: ognuno si mappa chiaramente a una clausola e ognuno è visibile nella modifica stessa. Impareremo la distribuzione reale quando heygrc sarà in esecuzione su pull request reali. Fino ad allora, questa è la mappa, non il territorio, e preferiamo ammetterlo.