Guadagni:
- Capacità di utilizzare l'intelligenza artificiale come secondo occhio e contrassegnare le vulnerabilità della classe OWASP (iniezione, hard secret, controllo degli accessi) nel codice fornendo contesto
- Capacità di eliminare i falsi positivi prodotti dall'intelligenza artificiale contestualizzandoli ed evitare di trattare ogni reperto come una vera vulnerabilità senza validarlo
- Capacità di riconoscere che la correzione suggerita dall'intelligenza artificiale può introdurre nuove vulnerabilità/bug e passare ogni patch attraverso il gate di revisione e test
Le vulnerabilità all'interno del software sono tra le vulnerabilità più costose perché sono integrate nel prodotto fin dall'inizio e distribuite a milioni di utenti. La revisione sicura del codice è il processo di lettura del codice sorgente riga per riga e di individuazione delle vulnerabilità (SQL injection, vulnerabilità dell'autenticazione, password hardcoded, autorizzazione errata) prima che entrino in produzione. Se fatto a mano è lento e faticoso; È facile non notare una vulnerabilità in una base di codice di grandi dimensioni.
L’intelligenza artificiale è potente nella revisione del codice per due motivi: il codice è anche un linguaggio e l’intelligenza artificiale è brava nel riconoscimento dei modelli. L’intelligenza artificiale può segnalare rapidamente modelli pericolosi in una porzione di codice (inserimento dell’input dell’utente direttamente nella query, archiviazione di dati non crittografati, convalida dell’input mancante), spiegare perché ciascuno di essi è rischioso e suggerire una soluzione. Ma l'intelligenza artificiale non vede l'intero contesto operativo del codice (l'input potrebbe essere stato cancellato a un altro livello), potrebbe inventare una vulnerabilità che non esiste (falso positivo) o perdere una vulnerabilità reale (falso negativo) e, soprattutto, la "correzione" che propone potrebbe introdurre una nuova vulnerabilità o bug. L'intelligenza artificiale è un secondo occhio e puntatore nella revisione del codice; Lo sviluppatore e l'esperto di sicurezza decidono se una scoperta è una vera vulnerabilità e se la correzione è corretta e sicura.
Passaggi di revisione del codice
- Fornisci ambito e contesto. Quale linguaggio, quale framework, dove riceve input questo codice, dove fornisce output, a quale livello funziona? La revisione del codice senza contesto produce falsi positivi.
- Cerca schemi pericolosi. Cerca classi di vulnerabilità AI note (come OWASP Top 10): iniezione, autenticazione, divulgazione di dati sensibili, controllo degli accessi.
- Giustificare ogni scoperta. Per ogni flag: quale linea, quale classe di vulnerabilità, come può essere sfruttata, quali sono le prove. Una constatazione ingiustificata non viene presa sul serio.
- Elimina i falsi positivi. L'input viene effettivamente cancellato, il percorso è davvero accessibile: controlla con il contesto.
- Verificare la correzione. Confermare che la patch consigliata da AI chiuda effettivamente la vulnerabilità, non introduca nuove vulnerabilità/bug e abbia superato i test.
- Approvazione umana. Lo sviluppatore + l'esperto di sicurezza esamina la scoperta e la correzione; È così che entra nel repository del codice.
Termini: SAST (Static Application Security Testing: test di sicurezza statico che analizza il codice sorgente senza eseguirlo). DAST (Dynamic: test dinamico che testa esternamente l'applicazione in esecuzione). OWASP Top 10 è l'elenco standard delle vulnerabilità delle applicazioni web più comuni. L'iniezione è una vulnerabilità causata dall'interpretazione dell'input dell'utente come comando/query (ad esempio SQL injection). La query con parametri è il metodo corretto che impedisce l'inserimento separando l'input dal codice.
Tabella delle classi di vulnerabilità comuni
Classe di vulnerabilità
Sintomo (nel codice)
giusta soluzione
La trappola dell'IA
Iniezione SQL
Unione dell'input nella query
Interrogazione con parametri
Può ignorare la sanificazione
segreto codificato
Password/inserisci codice
Cassaforte segreta (caveau), env
Falso positivo (campione/test)
Autenticazione debole
Controllo mancante/errato
Controllo potente e centralizzato
manca il contesto
Controllo accessi difettoso
Nessun controllo di autorizzazione
Autorizzazione lato server
Non comprende il flusso complesso
Divulgazione dati sensibili
Archiviazione/registrazione senza password
Crittografia, mascheramento
Non posso conoscere la criticità
Serializzazione non sicura
Deserializzare i dati inaffidabili
Analisi sicura
Manca un modello raro
tre mini custodie
Caso 1: rilevamento dell'iniezione effettiva. Uno sviluppatore chiede all'intelligenza artificiale di esaminare una funzione di accesso ai dati. L'IA segna la riga in cui il valore userId dell'utente è concatenato direttamente nel testo SQL e dice "questa è la classica SQL injection, trasformala in una query parametrizzata"; Fornisce la correzione del campione. Lo sviluppatore conferma che l'input non è stato ripulito altrove, verifica che si tratti di una vulnerabilità reale, implementa la query parametrizzata suggerita e scrive un test. L’intelligenza artificiale ha evidenziato la vulnerabilità; i test di verifica e correzione provenivano dallo sviluppatore.
Caso 2: segreto fisso falso positivo. L'intelligenza artificiale vede la riga password = "test1234" in un file e dice "critica: password codificata". Lo sviluppatore controlla il contesto: si tratta di un file di unit test, dati di test fittizi, non rilasciati in produzione e non trasferiti su un sistema reale. Il risultato è un falso positivo. Lo sviluppatore lo documenta ma non prende provvedimenti perché non è un vero segreto. Lezione: il segno del "segreto difficile" dell'IA deve essere eliminato dal contesto; Non tutte le stringhe sono un segreto.
Caso 3: nuova correzione della vulnerabilità. L'intelligenza artificiale propone una correzione per una vulnerabilità XSS (cross-site scripting); ma il codice che suggerisce cancella l'input nel posto sbagliato e salta la codifica dell'output in un'altra area; Di conseguenza, il divario non si colma completamente. L'esperto di sicurezza esamina la correzione, nota la codifica mancante e la corregge al livello corretto. Lezione: la patch consigliata dall'intelligenza artificiale non è automaticamente sicura; Ogni correzione viene rivista e testata.
Prompt debole / Prompt forte
Suggerimento debole:
C'è una scappatoia in questo codice, correggila: [codice]
Questo suggerimento non fornisce contesto (linguaggio, struttura, fonte di input), non chiede giustificazione, non mette in dubbio il falso positivo ed è aperto ad accettare ciecamente la correzione prodotta dall'intelligenza artificiale. L’intelligenza artificiale mescola segnali di vulnerabilità reale e inesistente.
Suggerimento potente:
Il tuo ruolo: assistente che è il SECONDO OCCHIO dello sviluppatore nella revisione sicura del codice. Processo decisionale; considerare la correzione applicata direttamente. Codice: [specificare lingua/struttura].Contesto: questa funzione [fonte di input: es. riceve [richiesta HTTP esterna], scrive su [destinazione di output]. Il tuo compito: (1) contrassegnare possibili vulnerabilità con la classe OWASP, fornire numero di riga + perché rischioso + come sfruttare + prove per ciascuna, (2) scrivere almeno 1 scenario falso positivo per ogni risultato (ad esempio se l'input è ripulito in un altro livello), (3) suggerire una correzione ma con il segno "[review + write test]"; Valutare anche se la correzione introduce nuove vulnerabilità/bug. Aggiunta di una falsa vulnerabilità.[codice]
Un forte suggerimento fornisce il contesto, richiede classi e prove OWASP, mette in discussione falsi positivi e rischi di riparazione, impone la revisione umana.
Modelli di prompt copiabili
MODELLO DI SCANSIONE DELLA VULNERABILITÀ Esaminare il codice [linguaggio/framework] per OWASP Top 10. Per ogni possibile risultato: numero di riga, classe di vulnerabilità, perché è rischioso, esempio di exploit, forza delle prove (certo/probabile/debole). Contesto: input [fonte], output [destinazione]. Aggiunta di risultati fabbricati; Se non sei sicuro, digita "[deve essere verificato]". Codice: [incolla]
PATTERN DI ELIMINAZIONE FALSI POSITIVI Per la seguente ricerca del codice, elencare gli scenari in cui NON esiste una vera vulnerabilità: l'input potrebbe essere cancellato a un altro livello, questo percorso è accessibile, questo valore è un test/campione, il framework è protetto automaticamente. Scrivi come confermare per ognuno. Risultato: [incolla]
MODELLO DI VALUTAZIONE DELLA CORREZIONE Consiglia una correzione per la seguente vulnerabilità; quindi critica la tua soluzione: (1) chiude davvero la vulnerabilità, (2) introduce una nuova vulnerabilità/bug, (3) quale test dovrei scrivere (caso positivo e negativo), (4) impatto su prestazioni/funzionalità. Esaminerò e testerò la soluzione. Vulnerabilità + codice: [incolla]
MODELLO DIDATTICO DEL SECURE PATTERN per classe di vulnerabilità [es. SQL injection] mostrano comparativamente modelli di digitazione sicuri e modelli errati comuni in questo linguaggio/framework. Regola generale + fornire un esempio di codice; ma voglio che tu chieda il contesto prima di implementarlo nel mio codice. Lingua/struttura: [scrivere]
Errori comuni
- Recensione senza contesto. Senza linguaggio, struttura e contesto di input/output, l’intelligenza artificiale confonde sia i risultati reali che quelli spuri; Assicurati di fornire il contesto.
- Confondendo ogni segno per vera debolezza. L'intelligenza artificiale produce falsi positivi (dati di test, input ripuliti a un altro livello); Setaccia ogni risultato con il contesto.
- Applicando ciecamente la correzione dell'IA. Le patch consigliate potrebbero introdurre nuove vulnerabilità/bug; rivedere e scrivere test.
- Fidarsi del falso negativo. Anche se l’IA dice “nessuna vulnerabilità”, esamina tu stesso i percorsi critici; La scansione statica non rileva tutte le vulnerabilità.
- Fornire il codice/segreto allo strumento esterno. Il codice privato e i veri segreti (chiave, password) sono proprietà intellettuale e vulnerabilità; anonimizzare o utilizzare strumenti aziendali isolati.
Suggerimento: quando si dispone del codice di revisione AI, il filtro più efficiente è chiedere la “forza dell’evidenza” (certa/probabile/debole) per ciascun risultato. La maggior parte dei risultati contrassegnati come “deboli” sono falsi positivi; assegni la tua energia a quelli “sicuri”.
Attenzione: la soluzione di sicurezza proposta da AI non dovrebbe entrare nel magazzino senza essere testata. Una "correzione" errata può sia lasciare aperta la vulnerabilità che portare a un errore funzionale in produzione; Ogni patch passa attraverso il processo di revisione e test.
In sintesi
La revisione sicura del codice è il modo più economico per individuare le vulnerabilità prima che entrino in produzione e, poiché il codice è un linguaggio, l’intelligenza artificiale diventa qui un potente secondo occhio: segnala modelli pericolosi, spiega i rischi, suggerisce soluzioni. Ma l’IA non vede l’intero contesto operativo, produce falsi positivi e falsi negativi e la patch che consiglia può introdurre nuove vulnerabilità. Pertanto la revisione prevede sei passaggi (contesto, screening, giustificazione, eliminazione dei falsi positivi, verifica della correzione, approvazione umana) e la decisione spetta allo sviluppatore e all'esperto di sicurezza. Tre principi: nessuna scoperta viene interpretata senza contesto, ogni segno viene eliminato con il contesto, nessuna correzione viene immagazzinata senza essere testata. E il codice/segreto non viene mai fornito a uno strumento esterno senza anonimizzazione.
Compito dell'applicazione
Prendi uno snippet di codice di esempio (rimuovendo parti sensibili dal tuo codice o un codice di esempio con vulnerabilità). Chiedi all'IA di esaminarlo con il modello "Scansione delle vulnerabilità"; Applica il modello "Eliminazione falsi positivi" per ogni risultato ed elimina quelli reali. Prendi la correzione del risultato più grave con il modello "Valutazione della riparazione", rivedilo tu stesso e scrivi un caso di test positivo + uno negativo. Nota quanti risultati erano falsi positivi.
lista di controllo
- [ ] Ho fornito il linguaggio, la struttura e il contesto di input/output prima di rivedere il codice.
- [ ] Ho chiesto il numero di riga, la classe di vulnerabilità, il percorso dell'exploit e le prove per ciascun risultato.
- [ ] Ho esaminato ogni risultato per individuare falsi positivi contestualizzandoli.
- [ ] Non ho applicato ciecamente la correzione dell'IA; Ho rivisto e scritto un test.
- [ ] Nonostante l'output "Nessuna vulnerabilità", ho esaminato personalmente i percorsi critici.
- [ ] Ho reso anonimo il codice/segreti o utilizzato strumenti aziendali isolati.
- [ ] Ho superato il rilevamento e la correzione tramite lo sviluppatore + l'approvazione della sicurezza.