Waarom bevindingen van lage ernst meer zeggen over uw audit dan kritieke bugs Veel auditbedrijven richten hun verkoopargument op het aantal gevonden hoge bevindingen, alsof dit aantal niet gewoon ruis is zonder context: eerdere audits, peer reviews, testdekking, codecomplexiteit, aantal regels en vele andere metrics. Het is de laagste vorm van verkooptechniek, niet anders dan het vergelijken van bijvoorbeeld de kwaliteit van USB-sticks aan de hand van hun lengte in millimeters. Om een alternatief te tonen, moeten we eerst de juistheid van verschillende ondersteunende claims bevestigen: - De kans op onopzettelijke buginjectie heeft geen bias naar hogere impact (ontwikkelaars zijn niet roekelozer in code met hoge inzet, meestal het tegenovergestelde). - Dezelfde uitgebreide methodologieën die worden gebruikt om fouten van verschillende ernstniveaus te ontdekken, zouden ook hoge ernstproblemen ontdekken (het tegenovergestelde geldt niet). - Er zijn veel hogere vereisten voor een willekeurige bug om als hoge ernst te kwalificeren (vaak zou het achter onbereikbare voorwaarden moeten zitten, of niet-kritische functionaliteit raken). - Uit de basisstatistiek: een hogere steekproeffrequentie correleert met een lagere verwachte afwijking/variantie en dus een nauwkeurigere meting. Laten we een auditrapport definiëren als het resultaat van het bemonsteren van de kwaliteit van een codebase. We concluderen dat het verwachte werkelijke (geen missers) aantal hoge bevindingen veel lager is dan lage bevindingen, en de verwachte afwijking daaromheen veel hoger is (vanwege de kleinere steekproef). Met andere woorden, het aantal hoge bevindingen zegt ons heel weinig over het aantal gemiste hoge bevindingen. Dus verrassend genoeg is een rapport van 1 hoge, 10 lage bevindingen geruststellender dan een rapport van 10 hoge, 1 lage bevinding, alles gelijk. Hoewel in feite de overgrote meerderheid van de verkopers de laatste zou verkiezen als een indicatie van kwaliteit. Het punt is dat een hoge-frequentiemetric een beter hulpmiddel is om lage-frequentie-uitkomsten te meten. Web3-bouwers, de volgende keer dat bedrijven u hun Crit/Hoge tellingen en X miljarden $ beveiligde lijn voorhouden, weet u waar u zich moet concentreren om naar het ware signaal te zoeken. Web3-auditors, erken dat er geen consistente geheime formule is om alle hoge bevindingen te vinden zonder ook naar de lage te zoeken - elke lage die niet volledig is onderzocht is een potentiële hoge - en geef uw beste aandacht aan elke enkele regel. Uw klant zal u dankbaar zijn.

Een kritieke kwetsbaarheid in git die gisteren is uitgebracht en kan worden geactiveerd door git clone van een onbetrouwbare repo. Dat is de droomvector om auditors te hacken en hun beloningen / auditgeld te stelen. Patch je systemen voordat je nieuwe klanten aanhaalt! En verwacht bezoekers in je inbox in de komende weken...

Blijkt dat je 5-cijferige beloningen kunt scoren in wedstrijden zonder daadwerkelijk problemen te ontdekken, alleen een semi-functionele hersenpan is nodig. In de OP Fault Proofs-wedstrijd van maart 2024 hebben ontwikkelaars een kritisch probleem opgelost een dag voordat het begon, maar hebben het niet samengevoegd. 🔗 Door gewoon naar het openbare commitlog te kijken, scoor je hoog 🔗 🔗 Het eindigde met een beloning van $16680: Het is slechts een van de vele trucs om in-scope bugs te vinden zonder ze daadwerkelijk te zoeken. Probeer altijd slim te werken, niet hard.

Besloten om Cantina een kans te geven afgelopen oktober, 8 maanden later zijn de resultaten eindelijk binnen... Tientallen solo bevindingen in de 1e Java audit en het overtreffen van de top Cantina leaderboard bro's met 3-7x voelt best goed, om eerlijk te zijn. Het is jammer dat de ervaring na de audit zo verschrikkelijk was dat ik gezworen heb nooit meer naar dat platform terug te keren. *gerechtvaardigde rant waarschuwing* - 8 maanden resolutietijd, op het moment van schrijven - bounty is nog steeds niet verzonden. - Tientallen uren besteed aan het escaleren en verdedigen van inzendingen tegen verkeerde uitspraken. - Ongeveer 104 beoordelingsfouten geteld (verkeerde duplicaten, duidelijke ongeldig, verkeerde ernst) die zijn gecorrigeerd. Meer die dat nog niet zijn. - Waardeverlies van ~$110.000 door de resolutie die 7 maanden langer duurde dan het zou moeten en de OP-token die naar ~50 cent is gedaald. Zeker, wanneer je meedoet aan niet-USD wedstrijdpotten zijn fluctuaties een aanvaardbaar risico. Maar 8 maanden van incompetente juryleden en niet in staat zijn om een wedstrijd af te ronden, maakte geen deel uit van mijn dreigingsmodel. Tijdens de C4 beoordelingsdagen verwerkte ik volledig 1000 bevindingen in minder dan een week (solo), OP-Java had 360 en meerdere juryleden. Het is geen verrassing dat Cantina nooit de resultaten op sociale media heeft aangekondigd, in tegenstelling tot 5 andere wedstrijden die deze week zijn afgerond, het kan zeker niet zo zijn dat ze slechte publiciteit of het benadrukken van TrustSec-dominantie wilden vermijden, toch? Het is jammer dat we moeten blijven praten over malpractices van bountyplatforms in plaats van kritieke bugs, maar er is geen andere keuze dan iedereen verantwoordelijk te houden. Een rant-vrije technische analysepost voor de solo bevindingen komt binnenkort.

Stel je een wereld voor waarin zeggen dat onderzoekers niet misbruikt mogen worden een controversieel standpunt is.. Dat is wat er gebeurt wanneer een bedrijf met onbeperkte middelen opduikt en zijn weg naar marktdominantie koopt. Onderzoekers onder druk zetten met extractieve beleidsmaatregelen wordt simpelweg de nieuwe Nash-evenwicht.

Elke dag die voorbijgaat, wordt het steeds duidelijker voor ons dat @cantinaxyz een extractieve entiteit is en een netto negatief voor de ruimte. Een week na het dodelijke stuk van @jack__sanford over de talloze tekortkomingen van de Cork-wedstrijd en nog steeds geen teken van een reactie. Met de hoeveelheid aandacht die dat artikel heeft gekregen, als ze zich konden verdedigen, zouden ze dat zeker doen, oftewel stilte is een erkenning van schuld. Deze week werd onze Cantina bounty-indiening, waarvan ze het eens waren dat het een beperkte verlies van fondsen voor een blockchain-operator met hoge waarschijnlijkheid toont, in bemiddeling opgelost met een lage ernst. Na het lezen van tientallen Spearbit/Cantina-rapporten en honderden bounty-rapporten, is een monetair verlies van enige omvang nooit onder een gemiddelde impact, dus ze geven duidelijk de perspectief van de sponsor weer in een klassieke "de klant heeft altijd gelijk" mentaliteit, zoals ze altijd doen. In feite verbergen ze het zelfs niet. Volgens hun eigen documenten, geven ze standaard de voorkeur aan het perspectief van de klant. Ik denk dat ze alleen in de meest flagrante gevallen de visie van de klant afwijzen. En wat als de klant simpelweg hun bemiddeling negeert? Op elk ander platform (bijv. @immunefi) waar we mee hebben gewerkt, is het niet respecteren van de bemiddeling grond voor onmiddellijke verwijdering van de klant. Bij Cantina heeft de klant een toelating van 5 bounty-oplichtingen per jaar. Ja, je leest het goed. We hebben ook onlangs ontdekt dat hun Fellowship-programma een zeer agressieve exclusiviteitsclausule heeft. Fellows kunnen niets indienen bij andere bounty-platforms, of projecten rechtstreeks op de hoogte stellen, zelfs niet als er miljoenen dollars op het spel staan. In plaats daarvan moet deze zeer gevoelige en tijdkritische kennis met Cantina worden gedeeld, die beslist hoe verder te gaan. Zij zijn de baas, zij bepalen de regels, buig of ga weg mentaliteit. We hebben meer voorbeelden van schandalige behandeling op Cantina, maar laten die voor een andere keer. Voor nu willen we de bewustwording vergroten, net als andere leidende leden van de gemeenschap, dat auditors met hun voeten moeten stemmen als het gaat om waar ze hun kostbare tijd aan het jagen besteden. Een beveiligingsplatform dat zijn balans verliest en projecten boven bounty-jagers bevoordeelt, ondermijnt het hele white-hat proces en moedigt onderzoekers aan om hun waarde op minder ethische manieren te verdienen! Laten we als gemeenschap samenwerken om organisaties met hoge integriteit, transparant en netto positief te versterken boven industriebully's. De bovenstaande verklaring is de persoonlijke mening van de leden van de directie van TrustSec en moet als zodanig worden geïnterpreteerd.

- Houd de statusveranderende LoC onder de 500 - gebruik het ++counter patroon voor het mappen van sleutels - ondersteun geen native tokens - houd de statusmachine in open view via status enums - 1:1 test/LoC ratio - formatteer elke regel code met een liniaal Zie je, het winnen van het spel is niet zo moeilijk

Als veteraan in de auditwedstrijdindustrie zal ik je vertellen hoe dit soort deals worden gemaakt. > Wees protocol met geld en doe 3+ gezamenlijke audits > Weet dat de codebase waarschijnlijk geen significante bugs bevat > Wilt u de gemeenschap, investeerders en andere belanghebbenden het signaal geven dat u veiligheid belangrijk vindt > Heb niet de intentie om nog meer geld uit te geven aan beveiliging > "Contest" platform heeft een oplossing > Organiseer een tapijtwedstrijd om te garanderen dat de High/Crit-potten niet worden ontgrendeld > Maak Med pot super klein > Als High wordt gevonden, bagatelliseer dan de sumissie, anders is de klant ontevreden (herinner je je Euler?) > Zowel het "Wedstrijd" -platform als u krijgt gratis marketing > SR's robuust, maar het kan je niet schelen > Herhaal dit maar maak de volgende aankondiging van de tapijtwedstrijd nog optimistischer.

Waarschuwing ⚠️: Geen nieuwe bounty-beschrijving Wij auditors houden er allemaal van om ons te concentreren op de sappige kritieken en niet-technisch werk tot een minimum te beperken. Wie geeft er om papierwerk en vergaderingen als je net een nieuwe manier hebt gevonden om een DeFi-contract leeg te maken? Maar alles moet met mate worden gedaan, en te vaak zien we dat onafhankelijke onderzoekers volledig beknibbelen op het ondertekenen van zelfs maar een basisovereenkomst met de klant. Dit was iets wat we ook deden in de eerste maanden van TrustSec - contact opnemen met een klant op TG / discord, team, prijs en tijdlijn bespreken en gewoon aan de slag gaan. Voelde soepel en wrijvingsloos aan, dus wat is het probleem? Zoals met veel dingen, werkt het goed totdat het niet meer werkt. Wanneer u 50+ audits per jaar beheert, begint u tegen randgevallen aan te lopen. En als u dat doet, voorkomt het van tevoren opruimen van zaken een hoop wrijving op mogelijk gevoelige punten in de audittijdlijn. Kijk, het punt van een dienstenovereenkomst is niet dat deze kan worden geprocedeerd bij een rechtbank die duizenden kilometers van uw huidige locatie verwijderd is. Natuurlijk, in het ergste geval kan het dat zijn. Maar meestal wordt het gedaan om de verwachtingen van beide kanten op één lijn te brengen, een manier om twee partijen te dwingen over details te praten die ze anders niet zouden doen. Hier zijn slechts een paar scenario's die naar voren zijn gekomen en die expliciet moeten worden behandeld: - Cliënt is niet klaar met de definitieve toezegging voor de startdatum. - Om onvoorziene redenen zijn een of meer auditors niet beschikbaar voor een deel van of het gehele auditvenster. - De uiteindelijke scope vereist een langere beoordelingstijd, waardoor de kosten stijgen. - Debatteren over welke tool en opmaak wordt gebruikt om de uiteindelijke SLOC te tellen. - Client introduceert nieuwe functionaliteit voor beoordeling in de fix-audit. - Vragen om betaling pas te verzenden na levering van het rapport. - De klant wenst de audit te annuleren met een opzegtermijn van slechts 24 uur. - De klant wil betalen op de blockchain van zijn voorkeur. - Bezwaren tegen het publiceren van het rapport na een acceptabele wachttijd. Een overeenkomst maakt niet alleen duidelijk hoe met deze scenario's moet worden omgegaan, maar biedt auditors ook kritieke bescherming: - Doet afstand van elke verantwoordelijkheid voor gemiste bugs en exploits. - Behoudt IP-rechten op tools, aanvalsconcepten die tijdens de audit zijn ontwikkeld (voor zover de wet dit toestaat). - Regelt aanbetalingen, annuleringskosten enzovoort. - Voldoet aan due diligence-eisen, KYB en wettelijk kader. Dit is relevant voor de vereisten op het gebied van belastingen, naleving en financieringsbronnen. Om die redenen ontdekten we al snel dat het de moeite waard is om wat extra tijd te besteden aan het boeken van dingen, en we moedigen elke auditor die een legitiem bedrijf runt aan om hetzelfde te doen.

Eind 2024 ontdekte TrustSec een consensusbug in @OPLabsPBC Optimism-client. In het ergste geval zou op-node een verkeerd beeld hebben van de L2-status, waardoor een keten wordt gesplitst van andere clients. Voor ons onderzoek heeft OP Labs ons genereus beloond met een premie van $ 7.5k. Bekijk alle details in de technische beschrijving hieronder!