Perché i Risultati a Bassa Gravità Dicono di Più sul Tuo Audit Rispetto ai Bug Critici Molti studi di audit concentrano il loro discorso di vendita sul numero di problemi gravi trovati, come se questo numero non fosse solo rumore senza contestualizzazione: audit precedenti, revisione tra pari, livelli di copertura dei test, complessità del codice, conteggio delle righe e molti altri metriche. È la forma più bassa di vendita, non diversa dal confrontare, ad esempio, la qualità di una chiavetta USB in base alla sua lunghezza in millimetri. Per mostrare un'alternativa, dobbiamo prima affermare la correttezza di diverse affermazioni di supporto: - La probabilità di iniezione accidentale di bug non ha un bias verso impatti più elevati (gli sviluppatori non sono più imprudenti nel codice ad alto rischio, di solito è l'opposto). - Le stesse metodologie complete utilizzate per scoprire difetti di varie gravità scoprirebbero anche problemi di alta gravità (l'opposto non è vero). - Ci sono requisiti molto più elevati affinché un bug casuale possa qualificarsi come di alta gravità (spesso sarebbe bloccato dietro condizioni irraggiungibili o riguarderebbe funzionalità non critiche). - Dalla statistica di base: un tasso di campionamento più elevato si correla con una minore deviazione/varianza attesa e quindi una misurazione più accurata. Definiamo un rapporto di audit come il risultato del campionamento della qualità di un codice. Deduciamo che il numero atteso di problemi gravi (senza mancanze) è molto inferiore a quello dei problemi a bassa gravità, e la deviazione attesa attorno ad esso è molto più alta (a causa di un campione più piccolo). In altre parole, il numero di problemi gravi ci dice molto poco sul numero di problemi gravi mancati. Quindi sorprendentemente, un rapporto di 1 problema grave e 10 problemi a bassa gravità è più rassicurante di un rapporto di 10 problemi gravi e 1 problema a bassa gravità, a parità di condizioni. Anche se in realtà la stragrande maggioranza dei venditori preferirebbe mostrare quest'ultimo come indicazione di qualità. Il punto è che una metrica ad alta frequenza è uno strumento migliore per misurare risultati a bassa frequenza. Costruttori di Web3, la prossima volta che le aziende vi mostrano i loro conteggi di Crit/High e miliardi di $ garantiti, sapete dove concentrarvi per cercare il vero segnale. Auditori di Web3, riconoscete che non esiste una formula segreta consistente per trovare tutti i problemi gravi senza anche cercare i problemi a bassa gravità - ogni problema a bassa gravità non completamente investigato è un potenziale problema grave - e dedicate la vostra massima attenzione a ogni singola riga. Il vostro cliente vi ringrazierà per questo. La bassa gravità è definita come errori di codifica concreti che non comportano impatti di livello superiore. Non include formattazione, migliori pratiche e risultati di riempimento.

Una vulnerabilità critica in git rilasciata ieri che può essere attivata da un git clone di un repository non affidabile. Questo è il vettore ideale per compromettere gli auditor e rubare i loro premi / soldi per audit. Patching i vostri sistemi prima di citare nuovi clienti! E aspettatevi visitatori nella vostra casella di posta nelle prossime settimane...

Si scopre che puoi ottenere ricompense a 5 cifre nei concorsi senza effettivamente scoprire alcun problema, basta avere un cervello semi-funzionale. Nel concorso OP Fault Proofs di marzo 2024, gli sviluppatori hanno risolto un problema critico un giorno prima che iniziasse, ma non l'hanno integrato. 🔗 Basta guardare il registro dei commit pubblici per ottenere un punteggio alto 🔗 🔗 È finita con una ricompensa di $16680: È solo uno dei tanti trucchi per trovare bug in-scope senza cercarli effettivamente. Cerca sempre di lavorare in modo intelligente, non duro.

Ho deciso di provare Cantina lo scorso ottobre, 8 mesi dopo i risultati sono finalmente usciti... Decine di scoperte in solitaria nel primo audit di Java e superando i migliori fratelli della classifica di Cantina di 3-7 volte fa sentire piuttosto bene, non lo nego. È un peccato che l'esperienza post-audit sia stata così terribile che ho giurato di non tornare mai più su quella piattaforma. *avviso di sfogo giustificato* - 8 mesi di tempo di risoluzione, al momento della scrittura - bounty ancora non inviato. - Decine di ore spese ad escalare e difendere le sottomissioni da verdetti errati. - Ho contato ~ 104 errori di giudizio (duplicati errati, invalidi chiari, gravità errata) che sono stati corretti. Altri non sono stati corretti. - Perdita di valore di ~$110.000 a causa della risoluzione che ha impiegato 7 mesi in più di quanto dovesse e il token OP che è crollato a ~50 centesimi. Certo, quando si compete in contest con premi non in USD, le fluttuazioni sono un rischio accettato. Ma 8 mesi di giudici incompetenti e l'incapacità di concludere un contest non facevano parte del mio modello di minaccia. Durante i giorni di giudizio di C4 avrei elaborato 1000 scoperte in meno di una settimana (da solo), OP-Java aveva 360 e più giudici. Non sorprende che Cantina non abbia mai annunciato sui social i risultati, a differenza di altri 5 contest che si sono conclusi questa settimana, certamente non poteva essere il caso che volessero evitare cattiva pubblicità o mettere in evidenza il dominio di TrustSec, giusto? È un peccato che dobbiamo continuare a discutere delle malpratiche delle piattaforme di bounty invece di bug critici, ma non c'è altra scelta se non quella di mantenere tutti responsabili. Un post tecnico senza sfoghi per le scoperte in solitaria arriverà a breve.

Immagina un mondo in cui dire che i ricercatori non dovrebbero essere abusati è un'opinione controversa.. Questo è ciò che accade quando un'azienda con denaro illimitato si presenta e compra la propria strada verso il dominio del mercato. Sfruttare i ricercatori con politiche estrattive diventa semplicemente il nuovo equilibrio di Nash.

Ogni giorno che passa diventa sempre più chiaro per noi che @cantinaxyz è un'entità estrattiva e un netto negativo per lo spazio. Una settimana dopo il pezzo eccezionale di @jack__sanford sulle innumerevoli carenze del concorso Cork e nessun accenno a una risposta in arrivo. Con la quantità di attenzione che ha ricevuto quell'articolo, se potessero montare una difesa sicuramente lo farebbero, ovvero il silenzio è un'ammissione di colpa. Questa settimana la nostra sottomissione per il bounty di Cantina, che hanno concordato mostri una perdita massima di fondi per un operatore blockchain con alta probabilità, si è risolta in mediazione con bassa gravità. Avendo letto decine di rapporti di Spearbit/Cantina e centinaia di scritture di bounty, la perdita monetaria di qualsiasi importo non è mai inferiore a un impatto medio, quindi stanno chiaramente trasmettendo la prospettiva dello sponsor con una classica mentalità "il cliente ha sempre ragione", come fanno sempre. In effetti, non si nascondono nemmeno nel farlo. Secondo i loro stessi documenti, si attengono alla prospettiva del cliente. Immagino che solo nei casi più eclatanti rifiutino la visione del cliente. E se il cliente semplicemente ignorasse la loro mediazione? In qualsiasi altra piattaforma (ad es. @immunefi) con cui abbiamo lavorato, non rispettare la mediazione è motivo di rimozione immediata del cliente. Su Cantina, il cliente ha un limite di 5 truffe di bounty all'anno. Sì, hai letto bene. Abbiamo anche recentemente scoperto che il loro programma di Fellowship ha una clausola di esclusività altamente aggressiva. I Fellows non possono presentare nulla ad altre piattaforme di bounty, né notificare direttamente i progetti, anche se milioni di dollari sono a rischio. Invece, queste conoscenze altamente sensibili e critiche per il tempo devono essere condivise con Cantina, che decide come procedere. Loro sono il capo, loro prendono le decisioni, mentalità di sottomissione o di abbandono. Abbiamo altri esempi di gestione scandalosa su Cantina, ma li lasceremo per un altro giorno. Per ora, vogliamo aumentare la consapevolezza, come altri membri di spicco della comunità, che gli auditor dovrebbero votare con i piedi quando si tratta di dove spendere il loro prezioso tempo a caccia. Una piattaforma di sicurezza che perde il suo equilibrio e favorisce i progetti rispetto ai cacciatori di bounty mina l'intero processo white-hat e incoraggia i ricercatori a guadagnarsi il loro valore attraverso mezzi meno etici! Lavoriamo come comunità per rafforzare organizzazioni ad alta integrità, trasparenti e nettamente positive rispetto ai bulli del settore. La dichiarazione sopra è l'opinione personale dei membri della direzione di TrustSec e dovrebbe essere interpretata come tale.

- Mantieni le LoC che cambiano stato sotto 500 - usa il pattern ++counter per le chiavi di mapping - non supportare token nativi - mantieni la macchina a stati in vista aperta tramite enum di stato - rapporto 1:1 test/LoC - formatta ogni riga di codice con un righello Vedi, vincere il gioco non è così difficile

In qualità di veterano dell'industria dei concorsi di audit, vi dirò come vengono stipulati accordi come questi. > Sii protocollare con i soldi e fai 3+ audit collaborativi > Sappi che la base di codice probabilmente non ha bug significativi > Vuoi segnalare alla comunità, agli investitori e agli altri stakeholder che ti sta a cuore la sicurezza > Non ho intenzione di spendere altri soldi per la sicurezza > piattaforma "Contest" ha una soluzione > Organizza una gara di tappeti che garantisca che i vasi High/Crit non vengano sbloccati > Rendi la pentola Med super piccola > Se High ha trovato, minimizza la sumissione, altrimenti il cliente è insoddisfatto (ricordi Eulero?) > Sia la piattaforma "Contest" che il marketing gratuito > SR robusti ma non ti interessa > Ripeti, ma rendi ancora più rialzista l'annuncio del prossimo concorso di tappeti.

Attenzione ⚠️: non è una nuova recensione di taglie A tutti noi auditor piace concentrarci sulle critiche succose e ridurre al minimo il lavoro non tecnico. A chi importa delle scartoffie e delle riunioni quando hai appena trovato un nuovo modo per prosciugare un contratto DeFi? Ma tutte le cose dovrebbero essere fatte con moderazione, e troppo spesso vediamo ricercatori indipendenti lesinare totalmente sull'ottenere anche un accordo di base firmato con il cliente. Questo è stato qualcosa che abbiamo fatto anche nei primi mesi di TrustSec: collegarci con un cliente su TG / discord, discutere del team, del prezzo e della tempistica e iniziare. Sembrava liscio e senza attrito, quindi qual è il problema? Come per molte cose, funziona bene fino a quando non lo fa. Quando si gestiscono 50+ audit all'anno, si inizia a imbattersi in casi limite. E quando lo fai, avere le cose ripulite in anticipo evita un sacco di attriti in punti potenzialmente sensibili della sequenza temporale dell'audit. Vedi, il punto di un accordo di servizi non è che può essere discusso in un tribunale a migliaia di chilometri dalla tua posizione attuale. Certo, nel peggiore dei casi, può essere. Ma per lo più è fatto per allineare le aspettative di entrambe le parti, un modo per costringere due parti a parlare di dettagli che altrimenti non farebbero. Ecco solo alcuni scenari che sono emersi e che dovrebbero essere gestiti in modo esplicito: - Il client non è pronto con il commit finale prima della data di inizio. - Per motivi imprevisti, uno o più revisori non sono disponibili per una parte o per l'intera finestra di audit. - L'ambito finale richiede tempi di revisione più lunghi, aumentando i costi. - Dibattito su quale strumento e formattazione viene utilizzato per contare lo SLOC finale. - Il client introduce nuove funzionalità per la revisione nell'audit delle correzioni. - Richiesta di invio del pagamento solo dopo la consegna del referto. - Il cliente desidera annullare l'audit con un preavviso di sole 24 ore. - Il cliente desidera inviare il pagamento sulla sua blockchain preferita. - Obiezioni sulla pubblicazione del rapporto dopo un periodo di attesa accettabile. Oltre a chiarire come gestire questi scenari, un accordo fornisce anche ai revisori una protezione fondamentale: - Declina ogni responsabilità per bug ed exploit mancati. - Mantiene i diritti di proprietà intellettuale sugli strumenti e sui concetti di attacco sviluppati durante l'audit (nella misura consentita dalla legge). - Organizza acconti, spese di cancellazione e così via. - Soddisfa i requisiti di due diligence, KYB e quadro giuridico. Ciò è rilevante per i requisiti fiscali, di conformità e di fonte dei fondi. Per questi motivi, abbiamo rapidamente scoperto che vale la pena dedicare un po' di tempo in più prima di prenotare le cose e incoraggiamo ogni revisore che gestisce un'attività legittima a fare lo stesso.

Alla fine del 2024, TrustSec ha scoperto un bug di consenso nel @OPLabsPBC client Optimism. Nel peggiore dei casi, l'op-node avrebbe una visione errata dello stato L2, causando una divisione della catena da altri client. Per la nostra ricerca, OP Labs ci ha generosamente premiato con una taglia di $ 7,5k. Dai un'occhiata a tutti i dettagli nell'articolo tecnico qui sotto!