Hvorfor funn med lav alvorlighetsgrad sier mer om revisjonen din enn kritiske feil Mange revisjonsfirmaer fokuserer salgsargumentet sitt på antall høyder funnet som om dette tallet ikke bare er støy uten å koble til kontekst: tidligere revisjoner, fagfellevurdering, testdekningsnivåer, kodekompleksitet, linjeantall og mange andre beregninger. Det er den laveste formen for salgskunst, ikke forskjellig fra å sammenligne for eksempel USB-stasjonskvalitet etter lengden i millimeter. For å vise et alternativ må vi først hevde riktigheten av flere støttende påstander: - Sannsynligheten for utilsiktet feilinjeksjon har ingen skjevhet mot høyere innvirkning (utviklere er ikke mer hensynsløse i kode med høy innsats, vanligvis det motsatte). - De samme omfattende metodene som brukes til å oppdage feil av ulik alvorlighetsgrad vil også oppdage problemer med høy alvorlighetsgrad (motsatt holder ikke). - Det er mye høyere krav for at en tilfeldig feil skal kvalifisere som høy alvorlighetsgrad (ofte vil den være inngjerdet bak utilgjengelige forhold, eller berøre ikke-kritisk funksjonalitet). - Fra grunnleggende statistikk: høyere samplingsfrekvens korrelerer med lavere forventet avvik/varians og dermed en mer nøyaktig måling. La oss definere en revisjonsrapport som et resultat av sampling av kvaliteten på en kodebase. Vi utleder at det forventede sanne (ingen glipp) antallet høyder er mye lavere enn nedturer, og det forventede avviket rundt det er mye høyere (på grunn av mindre utvalg). Med andre ord, antallet høyder forteller oss veldig lite om antall tapte høyder. Så overraskende nok er en 1 High, 10 Lows-rapport mer betryggende enn en 10 Highs, 1 Low-rapport alt annet likt. Selv om faktisk de aller fleste selgere foretrekker å vise sistnevnte som en indikasjon på kvalitet. Poenget er at en høyfrekvent beregning er et bedre verktøy for å måle lavfrekvente utfall. Web3-byggere, neste gang firmaer vinker deg sine Crit/High-tellinger og X milliarder av $ sikret linje, vet du hvor du skal fokusere for å søke etter ekte signal. Web3-revisorer, erkjenn at det ikke er noen konsekvent hemmelig formel for å finne alle høydepunktene uten også å søke etter nedturene - hver lav som ikke er fullstendig undersøkt er en potensiell høy - og gi din beste oppmerksomhet til hver eneste linje. Klienten din vil takke deg for det. Lav alvorlighetsgrad er definert som konkrete kodefeil som ikke resulterer i påvirkninger på høyere nivå. Inkluderer ikke formatering, anbefalte fremgangsmåter og utfyllende funn.

En kritisk i git utgitt i går som kan utløses av git-klone av uklarert repo. Det er drømmevektoren for å pwn-revisorer og stjele dusørene deres/revisjonspengene. Oppdater systemene dine før du siterer nye kunder! Og forvent besøkende i innboksen din i løpet av de kommende ukene ...

Det viser seg at du kan score 5-fig dusører i konkurranser uten å faktisk oppdage noen problemer, bare en semi-funksjonell hjerne som trengs. I OP Fault Proofs-konkurransen i mars 2024 fikset utviklere et kritisk problem en dag før det startet, men slo det ikke sammen. 🔗 Ved å bare se på offentlig commit-logg scorer du høyt 🔗 🔗 Endte opp med å bli en dusør på $16680: Det er bare ett av mange triks for å finne feil i omfang uten å faktisk lete etter dem. Prøv alltid å jobbe smart, ikke hardt.

Bestemte meg for å prøve Cantina i oktober i fjor, 8 måneder senere er resultatene endelig ute... Titalls solofunn i 1st Java-revisjon og å overgå topp Cantina-ledertavlebros med 3-7x føles ganske bra, kommer ikke til å lyve. Det er synd at opplevelsen etter revisjonen var så forferdelig at jeg sverget å aldri komme tilbake til den plattformen. *berettiget rant advarsel* - 8 måneders løsningstid, i skrivende stund - dusør fortsatt ikke sendt. - Titalls timer brukt på å eskalere og forsvare innlegg fra gale dommer. - Telte ~ 104 dommerfeil (feil dupes, klare ugyldige, feil alvorlighetsgrad) som har blitt rettet. Flere som ikke har det. - Verditap på ~$110 000 på grunn av oppløsning som tar 7 måneder lenger enn den burde og OP-tokenet tanker seg ned til ~50 cent. Jada, når du konkurrerer i ikke-USD-konkurransepotter, er svingninger en akseptert risiko. Men 8 måneder med dommere som var inkompetente og ikke kunne avslutte en konkurranse var ikke en del av trusselmodellen min. I løpet av C4-dommerdagene ville jeg behandle 1000 funn på under en uke (solo), OP-Java hadde 360 og flere dommere. Det kommer ikke som noen overraskelse at Cantina aldri kunngjorde resultatene på sosiale medier i motsetning til 5 andre konkurranser som ble fullført denne uken, kunne absolutt ikke være tilfelle at de ønsket å unngå dårlig presse eller fremheve TrustSec-dominans, ikke sant? Det er synd at vi må fortsette å diskutere uregelmessigheter på dusørplattformer i stedet for kritiske feil, men det er ikke noe annet valg enn å holde alle ansvarlige. Et rant-fritt teknisk sammenbruddsinnlegg for solofunnene kommer snart.

Se for deg en verden der det å si at forskere ikke bør misbrukes er en kontroversiell tilnærming. Det er det som skjer når et firma med ubegrensede kontanter dukker opp og kjøper seg inn i markedsdominans. Dumping på forskere med utvinningspolitikk blir rett og slett den nye Nash-likevekten

For hver dag som går blir det stadig tydeligere for oss at @cantinaxyz er en utvinningsenhet og en netto negativ for rommet. En uke gikk @jack__sanford sin killer-artikkel om de utallige manglene i Cork-konkurransen og ingen antydning til en respons snart. Med mengden oppmerksomhet den artikkelen fikk, hvis de kunne mønstre et forsvar, ville de absolutt gjort det, også kjent som taushet er en innrømmelse av skyld. Denne uken vår Cantina-dusørinnsending, som de var enige om viser et begrenset tap av midler for en blokkjedeoperatør med høy sannsynlighet, løst i mekling til lav alvorlighetsgrad. Etter å ha lest 10-vis av Spearbit/Cantina-rapporter og 100-vis av dusør-oppskrivninger, er økonomisk tap av et hvilket som helst beløp aldri under middels innvirkning, så de videreformidler tydelig sponsorens perspektiv i en klassisk "klient har alltid rett"-mentalitet, som de alltid gjør. Faktisk gjemmer de seg ikke engang for å gjøre det. Med sine egne dokumenter bruker de som standard klientens perspektiv. Jeg antar at de bare i de mest alvorlige tilfellene avviser klientens oppfatning. Og hva om klienten rett og slett ignorerer meklingen deres? På alle andre plattformer (f.eks. @immunefi) vi har jobbet med, er det å ikke respektere meklingen grunnlag for umiddelbar fjerning av klienten. På Cantina har klienten en godtgjørelse på 5 dusørsvindel per år. Ja, du leste riktig. Vi har også nylig funnet ut at deres Fellowship-program har en svært aggressiv eksklusivitetsklausul. Stipendiater kan ikke sende inn noe til andre dusørplattformer, eller varsle prosjekter direkte, selv om millioner av dollar er i fare. I stedet må denne svært sensitive og tidskritiske kunnskapen deles med Cantina, som bestemmer hvordan hun skal gå frem. De er sjefen, de bestemmer, bøyer seg ned eller forlater mentaliteten. Vi har flere eksempler på opprørende håndtering på Cantina, men lar dem ligge til en annen dag. Foreløpig ønsker vi å øke bevisstheten, som andre ledende samfunnsmedlemmer, om at revisorer bør stemme med føttene når det gjelder hvor de bruker sin dyrebare tid på jakt. En sikkerhetsplattform som mister balansen og favoriserer prosjekter fremfor dusørjegere, undergraver hele white-hat-prosessen og oppmuntrer forskere til å tjene sin verdi gjennom mindre etiske midler! La oss jobbe som et fellesskap for å styrke organisasjoner med høy integritet, gjennomsiktige og netto positive organisasjoner fremfor bransjemobbere. Uttalelsen ovenfor er den personlige meningen til TrustSec-styremedlemmer og bør tolkes slik.

- Hold tilstandsendrende LoC under 500 - Bruk ++tellermønster for kartlegging av nøkler - støtter ikke native tokens - Hold tilstandsmaskinen i åpen visning via tilstandsoppregninger - 1:1 test/LoC-forhold - formater hver kodelinje med en linjal Se, det er ikke så vanskelig å vinne kampen

Som en veteran i revisjonskonkurransebransjen vil jeg fortelle deg hvordan avtaler som disse gjøres. > Vær protokoll med penger og gjør 3+ samarbeidsrevisjoner > Vet at kodebasen sannsynligvis ikke har vesentlige feil > Ønsker å signalisere til fellesskapet, investorer og andre interessenter at du bryr deg om sikkerhet > Har ingen intensjon om å bruke mer penger på sikkerhet > "Konkurranse"-plattformen har løsning > Sett opp en teppekonkurranse som garanterer at High/Crit pottene ikke blir låst opp > Gjør Med pot super liten > Hvis High fant, så bagatellisere utelatelsen, ellers klienten misfornøyd (husker du Euler?) > Både "Konkurranse"-plattformen og du får gratis markedsføring > SR-er robuste, men du bryr deg ikke > Gjenta, men gjør den neste kunngjøringen om teppekonkurransen enda mer bullish.

Advarsel ⚠️: Ikke en ny bounty-oppskrivning Vi revisorer liker alle å fokusere på de saftige kritikkene og holde ikke-teknologisk arbeid på et minimum. Hvem bryr seg om papirarbeid og møter når du nettopp har funnet en ny måte å tømme en DeFi-kontrakt på? Men alt bør gjøres med måte, og altfor ofte ser vi uavhengige forskere som sparer totalt på å få en grunnleggende avtale signert med klienten. Dette var noe vi også gjorde i de første månedene av TrustSec - koble opp med en klient på TG / discord, diskutere team, pris og tidslinje, og bare komme i gang. Føltes glatt og friksjonsfri, så hva er problemet? Som med mange ting, fungerer det bra til det ikke gjør det. Når du administrerer 50+ revisjoner i året, begynner du å støte på kantsaker. Og når du gjør det, unngår du massevis av friksjon på potensielt sensitive punkter i revisjonstidslinjen. Se, poenget med en tjenesteavtale er ikke at den kan behandles ved en domstol tusenvis av kilometer fra din nåværende plassering. Jada, i verste fall kan det muligens være det. Men for det meste gjøres det for å stille opp forventningene fra begge sider, en måte å tvinge to sider til å snakke om detaljer de ellers ikke ville gjort. Her er bare noen få scenarier som har dukket opp, og som bør håndteres eksplisitt: - Klienten er ikke klar med endelig forpliktelse før startdato. - Av uforutsette årsaker er en eller flere revisorer ikke tilgjengelige for deler av eller hele revisjonsvinduet. - Endelig omfang krever lengre gjennomgangstid, noe som øker kostnadene. - Debatt om hvilket verktøy og formatering som brukes for å telle endelig SLOC. - Klient introduserer ny funksjonalitet for gjennomgang i reparasjonsrevisjonen. - Ber om at betaling sendes først etter at rapporten er levert. - Kunden ønsker å kansellere revisjonen med bare 24 timers varsel. - Kunden ønsker å sende betaling på sin foretrukne blokkjede. - Innvendinger mot at rapporten publiseres etter en akseptabel ventetid. Bortsett fra å gjøre det klart hvordan disse scenariene skal håndteres, gir en avtale også revisorer kritisk beskyttelse: - Fraskriver seg ethvert ansvar for tapte feil og utnyttelser. - Opprettholder IP-rettigheter på verktøy, angrepskonsepter utviklet under revisjonen (i den grad loven tillater det). - Ordner med forskuddsbetalinger, avbestillingsgebyrer og så videre. - Oppfyller krav til aktsomhet, KYB og juridisk rammeverk. Dette er relevant for beskatning, etterlevelse og krav til finansieringskilder. Av disse grunnene fant vi raskt ut at det er vel verdt det å bruke litt ekstra tid før vi får bestilt ting, og vi oppfordrer alle revisorer som driver en legitim virksomhet til å gjøre det samme.

På slutten av 2024 oppdaget TrustSec en konsensusfeil i @OPLabsPBC Optimism-klient. I verste fall vil op-node ha et feil syn på L2-tilstanden, noe som forårsaker en kjedesplittelse fra andre klienter. For vår forskning tildelte OP Labs oss sjenerøst en dusør på $7.5k. Sjekk ut alle detaljene i den tekniske artikkelen nedenfor!