De ce constatările de severitate scăzută spun mai multe despre audit decât erorile critice Multe firme de audit își concentrează argumentul de vânzare pe numărul de High-uri găsite, ca și cum acest număr nu ar fi doar zgomot fără a se conecta la context: audituri anterioare, peer review, niveluri de acoperire a testelor, complexitatea codului, numărul de linii și mulți alți indicatori. Este cea mai mică formă de vânzare, nu diferită de compararea, de exemplu, a calității unităților USB prin lungimea lor în milimetri. Pentru a arăta o alternativă, trebuie mai întâi să afirmăm corectitudinea mai multor afirmații susținătoare: - Probabilitatea injectării accidentale a erorilor nu are nicio tendință spre un impact mai mare (dezvoltatorii nu sunt mai nesăbuiți în codul cu mize mari, de obicei opusul). - Aceleași metodologii cuprinzătoare utilizate pentru a descoperi defecte de diferite severități ar descoperi și probleme de severitate ridicată (opusul nu este valabil). - Există cerințe mult mai mari pentru ca o eroare aleatorie să se califice ca severitate ridicată (adesea ar fi închisă în spatele unor condiții inaccesibile sau ar atinge funcționalități necritice). - Din statisticile de bază: o rată de eșantionare mai mare se corelează cu o abatere/varianță așteptată mai mică și, prin urmare, o măsurare mai precisă. Să definim un raport de audit ca rezultat al eșantionării calității unei baze de cod. Deducem că numărul real așteptat de maxime este mult mai mic decât minimele, iar abaterea așteptată în jurul acestuia este mult mai mare (datorită eșantionului mai mic). Cu alte cuvinte, numărul de maxime ne spune foarte puțin despre numărul de maxime ratate. Deci, în mod surprinzător, un raport de 1 High, 10 Lows este mai liniștitor decât un raport de 10 Highs, 1 Low toate celelalte fiind egale. Deși, de fapt, marea majoritate a vânzătorilor ar prefera să o arate pe cea din urmă ca un indiciu al calității. Ideea este că o măsură de înaltă frecvență este un instrument mai bun pentru a măsura rezultatele de joasă frecvență. Constructorii Web3, data viitoare când firmele vă flutură numărul lor Crit / High și X miliarde de dolari linie securizată, știți unde să vă concentrați pentru a căuta semnalul adevărat. Auditorii Web3, recunoașteți că nu există o formulă secretă consistentă pentru a găsi toate High-urile fără a căuta și Low-urile - fiecare Low care nu este investigat pe deplin este un potențial High - și acordați cea mai bună atenție fiecărei linii. Clientul tău îți va mulțumi pentru asta. Severitatea scăzută este definită ca greșeli de codificare concrete care nu duc la impacturi de nivel mai ridicat. Nu include formatarea, cele mai bune practici și constatările de umplere.

Un critic în git lansat ieri care poate fi declanșat de clona git a unui depozit nesigur. Acesta este vectorul de vis pentru auditorii pwn și pentru a le fura recompensele / banii de audit. Corectați-vă sistemele înainte de a cita clienți noi! Și așteptați-vă la vizitatori în căsuța de e-mail în săptămânile următoare...

Se pare că poți obține recompense de 5 smochine în concursuri fără a descoperi de fapt nicio problemă, doar un creier semi-funcțional necesar. În concursul OP Fault Proofs din martie 2024, dezvoltatorii au rezolvat o problemă critică cu o zi înainte de a începe, dar nu au fuzionat-o. 🔗 Doar uitându-vă la jurnalul public de commit, obțineți un scor ridicat 🔗 🔗 A ajuns să fie o recompensă de $16680: Este doar unul dintre multele trucuri pentru a găsi bug-uri în domeniu fără a le căuta de fapt. Încercați întotdeauna să lucrați inteligent, nu din greu.

Am decis să încerc Cantina în octombrie anul trecut, 8 luni mai târziu rezultatele au fost în sfârșit publicate... Zeci de descoperiri solo în primul audit Java și depășirea frilor de clasament de top Cantina cu 3-7x se simt destul de bine, nu voi minți. Este păcat că experiența post-audit a fost atât de groaznică încât am jurat că nu mă voi mai întoarce niciodată pe acea platformă. *avertisment justificat* - Timp de rezolvare de 8 luni, la momentul scrierii - recompensa încă nu a fost trimisă. - Zeci de ore petrecute escaladând și apărând propunerile de verdicte greșite. - S-au numărat ~ 104 greșeli de jurizare (păcăli greșite, invalidități clare, severitate greșită) care au fost corectate. Mai mulți care nu au făcut-o. - Pierdere de valoare de ~110.000 USD din cauza rezoluției care durează cu 7 luni mai mult decât ar trebui și a token-ului OP care scade la ~50 de cenți. Sigur, atunci când concurezi în pot de concurs non-USD, fluctuațiile sunt un risc acceptat. Dar 8 luni în care judecătorii au fost incompetenți și nu au putut încheia un concurs nu au făcut parte din modelul meu de amenințare. În zilele de jurizare C4 am procesat complet 1000 de constatări în mai puțin de o săptămână (solo), OP-Java a avut 360 și mai mulți judecători. Nu este surprinzător faptul că Cantina nu a anunțat niciodată rezultatele pe rețelele de socializare, spre deosebire de alte 5 concursuri care s-au încheiat săptămâna aceasta, cu siguranță nu ar putea fi cazul că au vrut să evite presa proastă sau să evidențieze dominația TrustSec, nu? Este păcat că trebuie să continuăm să discutăm despre practicile necorespunzătoare ale platformei de recompense în loc de bug-uri critice, dar nu există altă opțiune decât să-i responsabilizăm pe toți. O postare tehnică pentru descoperirile solo va veni în curând.

Imaginați-vă o lume în care a spune că cercetătorii nu ar trebui abuzați este o abordare controversată. Asta se întâmplă atunci când apare o firmă cu numerar nelimitat și își croiește drum spre dominația pieței. Dumpingul asupra cercetătorilor cu politici extractive devine pur și simplu noul echilibru Nash

În fiecare zi care trece, devine din ce în ce mai clar pentru noi că @cantinaxyz este o entitate extractivă și un negativ net pentru spațiu. Cu o săptămână în urmă, articolul ucigaș al lui @jack__sanford despre nenumăratele deficiențe ale concursului din Cork și niciun indiciu de răspuns în curând. Cu atenția pe care a primit-o acel articol, dacă ar putea să se apere cu siguranță, cu siguranță ar face-o, adică tăcerea este o recunoaștere a vinovăției. Săptămâna aceasta, cererea noastră de recompensă Cantina, despre care au fost de acord că arată o pierdere limitată de fonduri pentru un operator blockchain cu mare probabilitate, rezolvată în mediere la severitate scăzută. După ce am citit 10 rapoarte Spearbit/Cantina și 100 de scrieri de recompense, pierderea monetară de orice sumă nu este niciodată sub impactul mediu, așa că transmit în mod clar perspectiva sponsorului într-o mentalitate clasică "clientul are întotdeauna dreptate", așa cum fac întotdeauna. De fapt, nici măcar nu se ascund făcând asta. Prin propriile documente, ei folosesc implicit perspectiva clientului. Cred că doar în cele mai flagrante cazuri resping părerea clientului. Și dacă clientul pur și simplu ignoră medierea? În orice altă platformă (de exemplu, @immunefi) cu care am lucrat, nerespectarea medierii este un motiv pentru eliminarea imediată a clientului. Pe Cantina, clientul are o alocație de 5 escrocherii de recompense pe an. Da, ai citit bine. De asemenea, am descoperit recent că programul lor de burse are o clauză de exclusivitate extrem de agresivă. Bursierii nu pot trimite nimic la alte platforme de recompense sau notifica direct proiectele, chiar dacă milioane de dolari sunt în pericol. În schimb, aceste cunoștințe extrem de sensibile și critice trebuie împărtășite cu Cantina, care decide cum să procedeze. Ei sunt șefii, dau deciziile, se înclină sau părăsesc mentalitatea. Avem mai multe exemple de manipulare scandaloasă pe Cantina, dar le vom lăsa pentru altă zi. Deocamdată, vrem să creștem gradul de conștientizare, ca și alți membri importanți ai comunității, că auditorii ar trebui să voteze cu picioarele atunci când vine vorba de locul în care își petrec timpul prețios vânând. O platformă de securitate care își pierde echilibrul și favorizează proiectele în detrimentul vânătorilor de recompense subminează întregul proces de pălărie albă și încurajează cercetătorii să-și câștige valoarea prin mijloace mai puțin etice! Să lucrăm ca o comunitate pentru a consolida organizațiile de înaltă integritate, transparente și pozitive în detrimentul agresorilor din industrie. Declarația de mai sus este opinia personală a membrilor directorilor TrustSec și ar trebui interpretată ca atare.

- Păstrați LoC de schimbare a stării sub 500 - Utilizați modelul ++counter pentru maparea tastelor - nu acceptă token-uri native - Păstrați mașina de stare în vizualizare deschisă prin enumerări de stare - Raport test/LoC 1:1 - formatați fiecare linie de cod cu o riglă Vezi, câștigarea jocului nu este atât de greu

În calitate de veteran al industriei concursurilor de audit, vă voi spune cum se fac astfel de tranzacții. > Fii protocol cu bani și fă 3+ audituri colaborative > Știți că baza de cod probabil nu are erori semnificative > Vrei să semnalezi comunității, investitorilor și altor părți interesate că îți pasă de securitate > Nu aveți intenția de a cheltui mai mulți bani pe securitate > platforma "Concurs" are soluție > Organizează un concurs de covoare care să garanteze că poturile High/Crit nu vor fi deblocate > Faceți oala Med foarte mică > Dacă High a găsit, atunci minimalizați sumisiunea, altfel clientul este nemulțumit (vă amintiți de Euler?) > Atât platforma "Concurs", cât și primești marketing gratuit > SR-uri robuste, dar nu-ți pasă > Repetați, dar faceți următorul anunț al concursului de covoare și mai optimist.

Avertisment ⚠️: Nu este o nouă scriere de recompensă Nouă, auditorilor, ne place să ne concentrăm pe criticile suculente și să menținem munca non-tehnică la minimum. Cui îi pasă de hârtii și întâlniri când tocmai ai găsit o modalitate nouă de a drena un contract DeFi? Dar toate lucrurile ar trebui făcute cu moderație și prea des vedem cercetători independenți care se zgârcesc total la semnarea chiar și a unui acord de bază cu clientul. Acest lucru a fost ceva ce am făcut și în primele luni de TrustSec - să ne conectăm cu un client pe TG / discord, să discutăm despre echipă, preț și cronologie și să începem. S-a simțit neted și fără frecare, deci care este problema? Ca și în multe alte lucruri, funcționează bine până când nu mai funcționează. Când gestionați 50+ audituri pe an, începeți să vă confruntați cu cazuri limită. Iar atunci când o faci, clarificarea din timp evită o mulțime de fricțiuni în momentele potențial sensibile din cronologia auditului. Vedeți, scopul unui contract de servicii nu este că poate fi judecat la o instanță aflată la mii de kilometri de locația dvs. Sigur, în cel mai rău caz, poate fi. Dar în mare parte este făcut pentru a alinia așteptările ambelor părți, o modalitate de a forța două părți să vorbească despre detalii pe care altfel nu le-ar face. Iată doar câteva scenarii care au apărut și ar trebui tratate în mod explicit: - Clientul nu este gata cu confirmarea finală înainte de data de începere. - Din motive neprevăzute, unul sau mai mulți auditori nu sunt disponibili pentru o parte sau pentru întreaga fereastră de audit. - Domeniul final necesită un timp de revizuire mai lung, crescând costurile. - Dezbaterea instrumentului și formatării utilizate pentru a număra SLOC-urile finale. - Clientul introduce o nouă funcționalitate pentru revizuire în auditul de remediere. - Solicitarea trimiterii plății numai după livrarea raportului. - Clientul dorește să anuleze auditul cu un preaviz de doar 24 de ore. - Clientul dorește să trimită plata pe blockchain-ul preferat. - Obiecții cu privire la publicarea raportului după o perioadă de așteptare acceptabilă. Pe lângă faptul că clarifică modul de gestionare a acestor scenarii, un acord oferă auditorilor și protecție critică: - Renunță la orice responsabilitate pentru bug-uri și exploit-uri ratate. - Menține drepturile de proprietate intelectuală asupra instrumentelor, concepte de atac dezvoltate în timpul auditului (în măsura în care legea permite). - Aranjează plățile în avans, taxele de anulare și așa mai departe. - Îndeplinește cerințele de due diligence, KYB și cadrul legal. Acest lucru este relevant pentru cerințele de impozitare, conformitate și sursă de fonduri. Din aceste motive, am descoperit rapid că merită să petrecem puțin timp suplimentar înainte de a rezerva lucrurile și încurajăm fiecare auditor care conduce o afacere legitimă să facă același lucru.

La sfârșitul anului 2024, TrustSec a descoperit o eroare de consens în @OPLabsPBC client Optimism. În cel mai rău caz, op-nodul ar avea o viziune greșită asupra stării L2, provocând o separare a lanțului de alți clienți. Pentru cercetarea noastră, OP Labs ne-a acordat cu generozitate o recompensă de 7,5 mii de dolari. Consultați toate detaliile în articolul tehnic de mai jos!