← Torna alla classifica

Come effettuiamo i test

L'efficacia dei benchmark dipende interamente dalla loro configurazione. Ecco come valutiamo se un modello è in grado di individuare vulnerabilità reali e a quale costo.

1. 1

   Scegli delle vulnerabilità reali

   Attingiamo i CVE noti dal database delle segnalazioni di GitHub, che copre numerosi linguaggi e tipi di progetti.

2. 2

   Aggiungi un pin al commit vulnerabile

   Ogni repository viene scaricato al commit immediatamente precedente alla correzione.

3. 3

   Eseguire all'interno dell'ambiente di produzione

   I modelli funzionano all'interno dello stesso framework di intelligenza artificiale fornito con Code Security Audit e Aikido Attack.

4. 4

   Indica il frammento di codice vulnerabile

   Poiché sappiamo dove si trova ogni vulnerabilità, gli agenti investigativi si concentrano sul codice vulnerabile. Un errore riflette il ragionamento — non uno spreco di budget dovuto alla ricerca in un angolo sbagliato del repository. I prompt rimangono brevi e indipendenti dal modello.

5. 5

   Eseguire l'operazione tre volte, quindi raggruppare i risultati

   I modelli sono non deterministici. Eseguiamo ciascuno di essi tre volte e consideriamo un CVE come individuato se compare in una qualsiasi delle esecuzioni. L'aggregazione dei risultati consente di individuare bug che una singola esecuzione non rileverebbe, e rappresenta un quadro più realistico di come questi agenti verrebbero effettivamente implementati.

6. 6

   Confronta la copertura e il costo

   Registriamo il numero di CVE individuati da ciascun modello e il costo sostenuto per ottenere tale risultato, poiché il modello più potente raramente rappresenta la soluzione più conveniente. Inoltre, confrontiamo i livelli di ragionamento, laddove il fornitore li renda disponibili.

---

Informazioni sulla configurazione del cablaggio

È proprio l’“imbracatura” a trasformare un modello linguistico in un revisore. Un assistente di programmazione generico è progettato per uno scopo diverso, ovvero quello di prendere un compito e produrre codice funzionante. Se gli si indica un repository e gli si chiede se è sicuro, si comporta come uno sviluppatore che setaccia il codice alla ricerca di qualcosa di palesemente errato, per poi fermarsi non appena trova qualcosa di plausibile. Il Code Security Audit di Aikido è costruito in modo diverso. Esplora il codice alla ricerca di potenziali punti di ingresso, indaga a fondo su ogni flusso sospetto, quindi seleziona i risultati in modo da individuare solo le vulnerabilità reali.

Poiché sapevamo dove si trovava ogni vulnerabilità, abbiamo indirizzato ogni agente investigativo direttamente verso il frammento di codice vulnerabile. In questo modo, un errore riflette il ragionamento piuttosto che uno spreco di budget dovuto alla ricerca in un’area sbagliata del codice. Il modello deve comunque comprendere il flusso, valutare la sfruttabilità e segnalarla correttamente. I prompt sono stati mantenuti brevi e indipendenti dal modello, in modo che nessun fornitore fosse avvantaggiato dalla formulazione.

---