Varför resultat med låg allvarlighetsgrad säger mer om din revision än kritiska buggar Många revisionsbyråer fokuserar sin säljpitch på antalet upptäckta toppar som om denna siffra inte bara är brus utan att koppla in sammanhanget: tidigare revisioner, peer review, testtäckningsnivåer, kodkomplexitet, radantal och många andra mätvärden. Det är den lägsta formen av försäljning, som inte skiljer sig från att jämföra till exempel USB-enheternas kvalitet med deras längd i millimeter. För att visa på ett alternativ måste vi först hävda riktigheten av flera stödjande påståenden: - Sannolikheten för oavsiktlig felinjektion har ingen bias mot högre effekter (utvecklare är inte mer hänsynslösa i kod med höga insatser, vanligtvis tvärtom). - Samma omfattande metoder som används för att upptäcka brister av olika svårighetsgrad skulle också upptäcka problem med hög allvarlighetsgrad (motsatsen gäller inte). - Det finns mycket högre krav för att en slumpmässig bugg ska kvalificera sig som hög allvarlighetsgrad (ofta skulle den vara gated bakom ouppnåeliga villkor eller röra icke-kritiska funktioner). - Från grundläggande statistik: högre samplingsfrekvens korrelerar med lägre förväntad avvikelse/varians och därmed en mer exakt mätning. Låt oss definiera en revisionsrapport som ett resultat av att sampla kvaliteten på en kodbas. Vi drar slutsatsen att det förväntade sanna (inga missar) antalet toppar är mycket lägre än dalar, och den förväntade avvikelsen runt det är mycket högre (på grund av mindre urval). Med andra ord säger antalet toppar väldigt lite om antalet missade toppar. Så överraskande nog är en rapport om 1 hög, 10 dalar mer betryggande än en rapport om 10 toppar, 1 låg allt annat lika. Även om de allra flesta säljare faktiskt skulle föredra att visa det senare som en indikation på kvalitet. Poängen är att ett högfrekvent mått är ett bättre verktyg för att mäta lågfrekventa resultat. Web3-byggare, nästa gång företag viftar med sina Crit/High-räkningar och X miljarder dollar säkrad linje, vet du var du ska fokusera för att söka efter sann signal. Web3-revisorer, inse att det inte finns någon konsekvent hemlig formel för att hitta alla toppar utan att också söka efter dalar - varje låg som inte är fullständigt undersökt är en potentiell hög - och ge din bästa uppmärksamhet till varje enskild rad. Din kund kommer att tacka dig för det. Låg allvarlighetsgrad definieras som konkreta kodningsfel som inte leder till påverkan på högre nivå. Inkluderar inte formatering, bästa praxis och utfyllnadsresultat.

En kritisk git släpptes igår som kan utlösas av git-klonen av en ej betrodd lagringsplats. Det är drömvektorn för att pwn-revisorer och stjäla deras belöningar / revisionspengar. Patcha dina system innan du citerar några nya kunder! Och förvänta dig besökare i din inkorg under de kommande veckorna...

Det visar sig att du kan få 5-fig bounties i tävlingar utan att faktiskt upptäcka några problem, bara en halvfunktionell hjärna behövs. I mars 2024 OP Fault Proofs-tävlingen fixade utvecklarna ett kritiskt problem en dag innan det började, men slog inte ihop det. 🔗 Genom att bara titta på den offentliga incheckningsloggen får du en hög poäng 🔗 🔗 Det slutade med att det blev en belöning på $16680: Det är bara ett av många knep för att hitta buggar som omfattas utan att faktiskt leta efter dem. Försök alltid att arbeta smart, inte hårt.

Bestämde mig för att ge Cantina ett försök i oktober förra året, 8 månader senare är resultaten äntligen ute... Tiotals solofynd i 1:a Java-revisionen och att överträffa topp Cantina leaderboard bros med 3-7x känns ganska bra, inte ska ljuga. Det är synd att upplevelsen efter revisionen var så fruktansvärd att jag lovade att aldrig återvända till den plattformen. *Berättigad rant-varning* - 8 månaders upplösningstid, i skrivande stund - bounty har fortfarande inte skickats. - Tiotals timmar spenderade på att eskalera och försvara inlagor från felaktiga domar. - Räknade ~ 104 bedömningsfel (felaktiga dubbletter, tydliga ogiltigheter, fel allvarlighetsgrad) som har rättats. Fler som inte har gjort det. - Värdeförlust på ~110 000 dollar på grund av att upplösningen tar 7 månader längre än den borde och att OP-token sjunker ner till ~50 cent. Visst, när man tävlar i icke-USD-tävlingar är fluktuationer en accepterad risk. Men 8 månader av domare som var inkompetenta och inte kunde avsluta en tävling var inte en del av min hotbild. Under C4-bedömningsdagarna skulle jag fullständigt bearbeta 1000 fynd på mindre än en vecka (solo), OP-Java hade 360 och flera domare. Det kommer inte som någon överraskning att Cantina aldrig meddelade resultaten på sociala medier till skillnad från 5 andra tävlingar som avslutades den här veckan, kunde verkligen inte vara så att de ville undvika dålig press eller lyfta fram TrustSec-dominans, eller hur? Det är synd att vi måste fortsätta att diskutera oegentligheter på bounty-plattformar istället för kritiska buggar, men det finns inget annat val än att hålla alla ansvariga. Ett rant-fritt tekniskt uppdelningsinlägg för solofynden kommer inom kort.

Föreställ dig en värld där det är kontroversiellt att säga att forskare inte ska missbrukas. Det är vad som händer när ett företag med obegränsat med kontanter dyker upp och köper sig in i marknadsdominans. Att dumpa forskare med utvinningspolitik blir helt enkelt den nya Nashjämvikten

För varje dag som går blir det allt tydligare för oss att @cantinaxyz är en utvinningsmässig enhet och ett negativt netto för utrymmet. En vecka sedan @jack__sanford är dräpande artikel om de oräkneliga bristerna i Cork-tävlingen och ingen antydan till ett svar snart. Med den mängd uppmärksamhet som den artikeln fick, om de kunde sätta upp ett försvar skulle de definitivt göra det, aka tystnad är ett erkännande av skuld. Den här veckan vår Cantina bounty-inlämning, som de kom överens om visar en begränsad förlust av medel för en blockchain-operatör med hög sannolikhet, löst i medling till låg svårighetsgrad. Efter att ha läst 10-tals Spearbit/Cantina-rapporter och 100-tals bounty-skrivningar, är monetär förlust av något belopp aldrig under medelstor påverkan, så de förmedlar tydligt sponsorns perspektiv i en klassisk "klienten har alltid rätt"-mentalitet, som de alltid gör. Faktum är att de inte ens gömmer sig när de gör det. Enligt sina egna dokument utgår de som standard till kundens perspektiv. Jag antar att det bara är i de mest flagranta fallen som de avvisar klientens uppfattning. Och vad händer om klienten helt enkelt ignorerar deras medling? På alla andra plattformar (t.ex. @immunefi) som vi har arbetat med är det grund för omedelbar borttagning av klienten om man inte respekterar medlingen. På Cantina har kunden en ersättning på 5 bounty-bedrägerier per år. Ja, du läste rätt. Vi har också nyligen upptäckt att deras Fellowship-program har en mycket aggressiv exklusivitetsklausul. Stipendiater kan inte skicka in något till andra bounty-plattformar eller meddela projekt direkt, även om miljontals dollar är i fara. Istället måste denna mycket känsliga och tidskritiska kunskap delas med Cantina, som bestämmer hur man ska gå vidare. Det är de som bestämmer, de bestämmer eller ger sig av. Vi har fler exempel på skandalös hantering på Cantina, men de lämnar vi till en annan dag. För tillfället vill vi, liksom andra ledande medlemmar i communityn, öka medvetenheten om att revisorer bör rösta med fötterna när det gäller var de spenderar sin dyrbara tid på att jaga. En säkerhetsplattform som tappar balansen och gynnar projekt framför prisjägare underminerar hela white-hat-processen och uppmuntrar forskare att tjäna sitt värde på mindre etiska sätt! Låt oss arbeta som en gemenskap för att stärka organisationer med hög integritet, transparens och nettopositiva över branschmobbare. Uttalandet ovan är en personlig åsikt från TrustSecs styrelsemedlemmar och ska tolkas som en sådan.

- Håll tillståndsförändrande LoC under 500 - Använd ++räknarmönster för mappningstangenter - Stöder inte inbyggda tokens - Håll tillståndsmaskinen i öppen vy via tillståndsuppräkningar - 1:1 test/LoC-förhållande - Formatera varje kodrad med en linjal Du förstår, det är inte så svårt att vinna spelet

Som veteran inom revisionstävlingsbranschen kommer jag att berätta hur affärer som dessa görs. > Var protokoll med pengar och gör 3+ samarbetsrevisioner > Vet att kodbasen förmodligen inte har några större buggar > Vill signalera till samhället, investerare och andra intressenter att du bryr dig om säkerhet > Har inte för avsikt att spendera mer pengar på säkerhet > "Contest"-plattformen har en lösning > Arrangera en matttävling som garanterar att High/Crit-krukorna inte låses upp > Gör Med-krukan superliten > Om High hittade, tona ner sumissionen, annars är klienten missnöjd (minns du Euler?) > Både "Contest"-plattformen och du får gratis marknadsföring > SRs robust men du bryr dig inte > Upprepa men gör tillkännagivandet av nästa matttävling ännu mer hausseartat.

Varning ⚠️: Inte en ny bounty-skrivning Vi revisorer gillar alla att fokusera på de saftiga critsen och hålla icke-tekniskt arbete till ett minimum. Vem bryr sig om pappersarbete och möten när du precis har hittat ett nytt sätt att tömma ett DeFi-kontrakt? Men allt bör göras med måtta, och alltför ofta ser vi oberoende forskare som helt snålar med att få ens ett grundläggande avtal undertecknat med kunden. Detta var något vi också gjorde under de första månaderna av TrustSec - koppla upp oss med en kund på TG / discord, diskutera team, pris och tidslinje och bara komma igång. Kändes smidig och friktionsfri, så vad är problemet? Som med många saker fungerar det bra tills det inte gör det. När du hanterar 50+ revisioner per år börjar du stöta på gränsfall. Och när du gör det kan du undvika massor av friktion vid potentiellt känsliga punkter i revisionens tidslinje om du har saker och ting utrensade i förväg. Poängen med ett tjänsteavtal är inte att det kan prövas i en domstol tusentals mil från din nuvarande plats. Visst, i värsta fall kan det vara det. Men för det mesta görs det för att rada upp förväntningar från båda sidor, ett sätt att tvinga två sidor att prata om detaljer som de annars inte skulle prata om. Här är bara några scenarier som har dykt upp och som uttryckligen bör hanteras: - Kunden är inte klar med den slutliga incheckningen före startdatumet. - Av oförutsedda skäl är en eller flera revisorer inte tillgängliga för en del av eller hela revisionsfönstret. - Det slutliga omfånget kräver längre granskningstid, vilket ökar kostnaderna. - Diskutera vilket verktyg och vilken formatering som används för att räkna slutlig SLOC. - Klienten introducerar ny funktionalitet för granskning i fixrevisionen. - Be om att betalning ska skickas först efter att rapporten har levererats. - Kunden vill avbryta revisionen med bara 24 timmars varsel. - Kunden vill skicka betalning på sin föredragna blockchain. - Invändningar mot att rapporten publiceras efter en acceptabel väntetid. Förutom att göra det tydligt hur dessa scenarier ska hanteras, ger ett avtal också revisorer ett viktigt skydd: - Avsäger sig allt ansvar för missade buggar och kryphål. - Upprätthåller IP-rättigheter på verktyg, attackkoncept som utvecklats under revisionen (i den utsträckning lagen tillåter). - Ordnar med handpenning, avbokningsavgifter och så vidare. - Uppfyller kraven på due diligence, KYB och det rättsliga ramverket. Detta är relevant för krav på beskattning, efterlevnad och finansieringskälla. Av dessa skäl fann vi snabbt att det är väl värt att spendera lite extra tid innan vi bokar saker, och vi uppmuntrar alla revisorer som driver ett legitimt företag att göra detsamma.

I slutet av 2024 upptäckte TrustSec en konsensusbugg i @OPLabsPBC Optimism-klient. I värsta fall skulle op-node ha en felaktig vy av L2-tillståndet, vilket orsakar en kedjedelning från andra klienter. För vår forskning tilldelade OP Labs oss generöst en belöning på 7.5 000 dollar. Kolla in alla detaljer i den tekniska skrivningen nedan!