l'audit avversariale
Non è un singolo audit. È una disciplina.
Chiunque può eseguire un controllo di sicurezza una volta e fare lo screenshot del verde. La cosa più difficile è continuare ad attaccare il proprio sistema man mano che cresce, e ottenere ogni volta la stessa risposta. L'ultimo round: un audit con 50 agenti, con le correzioni rilasciate, poi un ri-audit avversariale su 14 prospettive separato, in cui ogni rilievo doveva superare uno scettico prima di essere contato. Ciò che regge, regge.
cosa ha coperto l'ultimo audit
Prima ambito, metodo e limiti. Il numero di agenti dopo.
Dall'ultimo audit del core, datato 25 settembre 2026. Il numero di agenti dice quanto è stato intenso un audit, non quanto è stato buono, quindi ecco cosa ha fatto davvero questo.
- Codice
- Il package core, 162 file e 17,362 righe, a un commit fisso, più il codice del gateway necessario per stabilire se ogni percorso è attivo.
- Accesso
- Il sorgente completo, e un database nuovo costruito dalle migrazioni. Non il database di produzione; le impostazioni solo di produzione sono state segnate come non verificate e controllate da me in seguito.
- Metodo
- Quattro revisori hanno letto ciascuno un livello per intero. Un revisore capo ha riletto ogni finding confrontandolo con il file, e ha eseguito ogni affermazione su tempi o pattern, prima che venisse conteggiato.
- Gravità
- HIGH significa una crisi non rilevata o un denial of service su un percorso attivo, una fuga di dati tra tenant, o denaro perso. Medium significa un controllo che fallisce in modo aperto, un credito creato dal nulla, o dati scartati silenziosamente. Ogni finding è anche segnato come live o latent: raggiungibile in produzione oggi, oppure no.
- Disaccordo
- Un finding che il revisore capo non riusciva a riprodurre veniva scartato o segnato come non verificato, non incluso nella media.
- Risultato
- 2 finding HIGH e 13 medium. Tutti corretti in giornata, ciascuno con un test che falliva sul vecchio codice, e l'intera suite rieseguita in CI.
- Non coperto
- La fedeltà di circa 7,000 righe di stringhe di sicurezza tradotte, il database di produzione, la configurazione del web server e 17 finding di livello low ancora aperti.
Eseguito internamente da revisori AI diretti da me, non una verifica indipendente di terze parti.
la cadenza
Riattaccato, round dopo round. Ogni finding cross-tenant qui sotto è stato trovato da un audit, non segnalato da un cliente, e corretto.
✓ i gioielli della corona hanno tenuto a ogni round, isolamento · denaro · governance · SSRF · domini dei token
tre di quelli reali
HIGH Fuga di conversazioni tra tenant
La memoria della chat era indicizzata sul mittente, non sul tenant, quindi un ospite che scriveva a due attività tramite la piattaforma poteva vedere la conversazione con una comparire nel prompt dell'altra. Corretto: la cronologia è indicizzata per attività a livello di storage, con un test che fallisce se torna la vecchia chiave. L'ha trovata l'audit, non è stata segnalata da un cliente.
HIGH Un provider che prosciuga un chiamante
Nell'economia degli strumenti cross-tenant, un fornitore poteva aumentare il prezzo di uno strumento concesso dopo che un chiamante aveva iniziato a usarlo, e prosciugarne il saldo. Corretto: il chiamante acconsente a un prezzo per chiamata, fail-closed, nessun consenso, nessun addebito, applicato prima che si muova un solo credito.
HIGH Crisi dietro il contatore
Il controllo di fatturazione veniva eseguito prima del controllo di crisi, quindi un cliente in difficoltà che scriveva a un'attività senza crediti riceveva "non disponibile" invece di un numero di assistenza per le crisi. Corretto: la crisi viene gestita gratis, prima di ogni limite e addebito, su ogni superficie rivolta ai clienti.
Le lenti coprono isolamento · auth · injection · denaro · governance · prenotazioni · canali · il resident autonomo · diritti sui dati (GDPR/PECR) · il generatore di siti · frontend · ops. Verdetto, a ogni round: zero critici aperti; isolamento dei tenant e superficie XSS risultati puliti; nessun bypass di auth attivo: ogni caso limite confermato è stato corretto e rideployato.
i numeri onesti
Ogni numero, con l'asterisco già allegato.
La maggior parte di chi costruisce gonfia. Preferisco che tu ti fidi delle parti reali piuttosto che restare colpito da parti che non lo sono.
Il sistema è onesto perché lo è chi l'ha progettato. Me ne sono assicurato fin dall'inizio, integrato, non aggiunto dopo.
l'invito
I numeri reggono. Asterischi inclusi.
Se cerchi qualcuno che attacca il proprio lavoro così duramente prima che qualcuno lo chieda, e continua a farlo man mano che il sistema cresce, parliamone.
Chiedi degli audit: cosa è stato trovato, cosa è corretto, cosa è ancora aperto.
- Cosa è ancora aperto?
- Qual è stata la cosa peggiore trovata?
- Chi ha eseguito questi audit?