{"id":178,"date":"2026-08-01T05:09:19","date_gmt":"2026-08-01T05:09:19","guid":{"rendered":"https:\/\/hoge.gg\/no\/slik-leser-du-en-trail-of-bits-revisjon\/"},"modified":"2026-08-01T05:09:19","modified_gmt":"2026-08-01T05:09:19","slug":"slik-leser-du-en-trail-of-bits-revisjon","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/slik-leser-du-en-trail-of-bits-revisjon\/","title":{"rendered":"Hva st\u00e5r egentlig i en Trail of Bits-revisjon?"},"content":{"rendered":"<h2 class='wp-block-heading'>Da ti revisjoner ikke stoppet et hack p\u00e5 over 100 millioner dollar<\/h2><p class=\"wp-block-paragraph\">Balancer-protokollen hadde v\u00e6rt gjennom over ti sikkerhetsrevisjoner i l\u00f8pet av sin levetid. Likevel forsvant over 100 millioner dollar fra protokollen 3. november 2025, drenert fra ni ulike blokkjeder p\u00e5 under en time. \u00c5rsaken var en avrundingssvakhet som i realiteten allerede var p\u00e5pekt av Trail of Bits, fire \u00e5r tidligere, i en revisjonsrapport med et funn merket \u00abubestemt\u00bb.<\/p><p class=\"wp-block-paragraph\">Rapporten fantes. Funnet fantes. Alvorlighetsgraden var satt. Og likevel skjedde det. Det paradokset er kjernen i denne artikkelen, ikke fordi revisjoner er verdil\u00f8se, men fordi de f\u00e6rreste som stoler p\u00e5 ordet \u00abrevidert\u00bb faktisk har lest hva som st\u00e5r i rapporten bak det ordet. En revisjonsrapport fra et selskap som Trail of Bits, kryptobransjens mest siterte sikkerhetsselskap, er ikke et stempel som sier trygt eller utrygt. Det er et strukturert dokument med alvorlighetsgrader, vanskelighetsgrader, statusmerker og, kanskje viktigst av alt, et n\u00f8ye avgrenset omfang som definerer hva som faktisk ble unders\u00f8kt og hva som ikke ble det.<\/p><p class=\"wp-block-paragraph\">Denne artikkelen g\u00e5r gjennom hvordan en revisjonsrapport faktisk er bygget opp, med Trail of Bits sin egen offentlige guide som utgangspunkt, og bruker sakene Balancer og Bunni som konkrete eksempler p\u00e5 hva som skjer n\u00e5r den strukturen leses for overfladisk, eller ikke leses i det hele tatt.<\/p><h2 class='wp-block-heading'>Hva er egentlig en smart contract-revisjon?<\/h2><p class=\"wp-block-paragraph\">En smart contract-revisjon er et tidsavgrenset, betalt oppdrag der et sikkerhetsteam gjennomg\u00e5r en definert del av en kodebase, p\u00e5 et bestemt tidspunkt, l\u00e5st til \u00e9n bestemt commit-hash i versjonskontrollen. Arbeidet kombinerer typisk manuell kodegjennomgang linje for linje, automatisert statisk analyse som leter etter kjente feilm\u00f8nstre, og fuzzing, alts\u00e5 automatisert testing som pr\u00f8ver enorme mengder tilfeldige eller motstridende inndata for \u00e5 se om noen av dem bryter protokollens egne regler, gjerne kalt invarianter.<\/p><p class=\"wp-block-paragraph\">Det viktigste \u00e5 forst\u00e5 er hva en revisjon ikke er. I Norge er dette omr\u00e5det fortsatt uregulert i praksis: MiCA-forordningen tr\u00e5dte i kraft her gjennom E\u00d8S-avtalen 1. juli 2025, og Finanstilsynet f\u00f8rer tilsyn med kryptoeiendelstjenesteytere under kryptoeiendelsloven, if\u00f8lge <a href='https:\/\/www.finanstilsynet.no\/tema\/kryptoeiendeler-mica\/'>Finanstilsynets egen oversikt<\/a>. Men verken MiCA eller det norske regelverket stiller krav om at en smart contract faktisk skal kodegjennomg\u00e5s av noen, og fullt desentraliserte protokoller uten en identifiserbar utsteder faller uansett utenfor MiCA sitt virkeomr\u00e5de. En revisjonsrapport er med andre ord et frivillig, kommersielt dokument, ikke et lovp\u00e5lagt sikkerhetsbevis. Den er heller ikke kontinuerlig overv\u00e5kning, bare et \u00f8yeblikksbilde av koden slik den s\u00e5 ut den dagen arbeidet ble avsluttet, og den er ikke en objektiv sannhet, men en faglig vurdering fra ett bestemt team, med en bestemt mengde tid til r\u00e5dighet, om en bestemt, avgrenset del av systemet.<\/p><h2 class='wp-block-heading'>Trail of Bits er blitt bransjens referansepunkt<\/h2><p class=\"wp-block-paragraph\">Trail of Bits ble grunnlagt i New York i 2012 og har siden bygget opp en katalog med over 620 offentlige revisjonsrapporter fra rundt 25 klientgrupper, if\u00f8lge selskapets egen <a href='https:\/\/trailofbits.com\/reports\/'>rapportkatalog<\/a>. \u00c5pen kildekode-verkt\u00f8yene deres, blant annet den statiske analysatoren Slither og fuzzerne Echidna og Medusa, brukes i dag av store deler av bransjen, ikke bare av Trail of Bits selv. Vi har tidligere skrevet en grundig gjennomgang av selve selskapet, historien og klientlisten i <a href='https:\/\/hoge.gg\/no\/trail-of-bits-forklart\/'>Trail of Bits forklart: kryptobransjens mest kjente revisor<\/a>, s\u00e5 her g\u00e5r vi ikke i dybden p\u00e5 selskapet, men p\u00e5 selve dokumentet de leverer fra seg.<\/p><p class=\"wp-block-paragraph\">Grunnen til at Trail of Bits egner seg spesielt godt som utgangspunkt for akkurat denne gjennomgangen, er at selskapet er uvanlig \u00e5pne om egen metodikk. De har publisert en egen guide, kalt \u00abAnatomy of a report\u00bb, som forklarer strukturen i rapportene sine punkt for punkt. Den guiden, sammen med de faktiske rapportene om Balancer og Bunni, er kildegrunnlaget for resten av denne artikkelen.<\/p><h2 class='wp-block-heading'>Slik er en revisjonsrapport bygget opp: \u00e5tte deler du b\u00f8r kjenne til<\/h2><p class=\"wp-block-paragraph\">If\u00f8lge Trail of Bits sin egen <a href='https:\/\/trailofbits.com\/anatomy-of-a-report\/'>guide til rapportstrukturen<\/a> best\u00e5r en typisk rapport av \u00e5tte deler. De f\u00e6rreste leser lenger enn til sammendraget og funnlisten, men de andre delene inneholder ofte informasjon som er like viktig for \u00e5 vurdere hvor mye man kan stole p\u00e5 konklusjonene.<\/p><figure class='wp-block-table'><table><thead><tr><th>Del av rapporten<\/th><th>Hva den forteller deg<\/th><\/tr><\/thead><tbody><tr><td>Forsiden<\/td><td>Engasjementsperiode, antall ingeni\u00f8rer og \u00ablevel of effort\u00bb m\u00e5lt i person-uker, samt metodikken som ble brukt<\/td><\/tr><tr><td>Sammendrag<\/td><td>Oversikt over funn plottet i en matrise mellom alvorlighetsgrad og vanskelighetsgrad<\/td><\/tr><tr><td>Vurdering av kodebasens modenhet<\/td><td>Karakter p\u00e5 seks dimensjoner: dokumentasjon, testing, tilgangskontroll, hygiene i forsyningskjeden, feilh\u00e5ndtering og konfigurasjon<\/td><\/tr><tr><td>Enkeltfunn<\/td><td>Hvert funn beskrevet med et konkret angrepsscenario, steg for steg<\/td><\/tr><tr><td>Anbefalinger<\/td><td>Kortsiktige rettelser og langsiktige strukturelle endringer<\/td><\/tr><tr><td>Vedlegg A<\/td><td>Tekniske artefakter: Semgrep-regler, CodeQL-sp\u00f8rringer, fuzz-rigger og bevis-for-konsept-kode<\/td><\/tr><tr><td>Vedlegg B<\/td><td>Fiksgjennomgang der hvert funn f\u00e5r en oppdatert status: fikset, \u00e5pent, eller akseptert risiko<\/td><\/tr><tr><td>Publisering<\/td><td>Valgfri offentliggj\u00f8ring av rapporten i den \u00e5pne katalogen, dersom klienten godkjenner det<\/td><\/tr><\/tbody><\/table><\/figure><p class=\"wp-block-paragraph\">To detaljer i denne strukturen er verdt \u00e5 dvele ved. Den f\u00f8rste er at \u00ablevel of effort\u00bb, alts\u00e5 hvor mange ingeni\u00f8rer som brukte hvor mye tid, ligger p\u00e5 forsiden i stedet for gjemt bort i et vedlegg. Trail of Bits omtaler selv dette som noe av det viktigste enkelttallet for \u00e5 vekte et funn: en revisjon utf\u00f8rt av to personer p\u00e5 \u00e9n uke b\u00f8r veie helt annerledes enn en revisjon utf\u00f8rt av et st\u00f8rre team over flere m\u00e5neder. Den andre er at hvert enkeltfunn skal inneholde det guiden kaller et konkret angriper-scenario, alts\u00e5 n\u00f8yaktig hva en angriper m\u00e5 gj\u00f8re, i hvilken rekkef\u00f8lge, for \u00e5 utnytte svakheten. Poenget er at leseren skal kunne bygge riktig mental modell av risikoen f\u00f8r noe blir rettet, ikke bare lese en overskrift og anta at den er forst\u00e5tt.<\/p><h2 class='wp-block-heading'>To akser, ikke \u00e9n: alvorlighetsgrad og vanskelighetsgrad<\/h2><p class=\"wp-block-paragraph\">Den vanligste misforst\u00e5elsen n\u00e5r folk leser en revisjonsrapport, er \u00e5 behandle alvorlighetsgrad som det eneste tallet som teller. Trail of Bits sin egen guide er tydelig p\u00e5 at funn plottes langs to akser samtidig: alvorlighetsgrad, alts\u00e5 hva som kan skje dersom svakheten utnyttes, og vanskelighetsgrad, alts\u00e5 hvor krevende det er for en angriper \u00e5 faktisk komme dit. En enkel middels-alvorlig sak kan dermed rangere h\u00f8yere i praktisk risiko enn en vanskelig kritisk sak, nettopp fordi matrisen fanger opp begge dimensjonene samtidig i stedet for \u00e5 redusere alt til ett enkelt ord.<\/p><p class=\"wp-block-paragraph\">P\u00e5 tvers av bransjen, ikke bare hos Trail of Bits, g\u00e5r alvorlighetsgradene som regel fra informativ, via lav, middels og h\u00f8y, til kritisk. Trail of Bits bruker i tillegg en sjette kategori i egne rapporter: ubestemt. Den brukes n\u00e5r revisoren finner en reell strukturell svakhet, men ikke klarer \u00e5 bekrefte om den faktisk er utnyttbar under de konkrete forholdene protokollen kj\u00f8rer under, gitt tidsrammen de hadde til r\u00e5dighet. Det er en \u00e6rlig kategori, ikke en runding oppover eller nedover, men den krever at leseren forst\u00e5r at \u00abubestemt\u00bb ikke betyr \u00ablite alvorlig\u00bb.<\/p><figure class='wp-block-table'><table><thead><tr><th>Alvorlighetsgrad<\/th><th>Hva det betyr i praksis<\/th><\/tr><\/thead><tbody><tr><td>Kritisk<\/td><td>Direkte og bekreftet vei til tap av midler eller full kompromittering av systemet<\/td><\/tr><tr><td>H\u00f8y<\/td><td>Alvorlig svakhet, men krever bestemte forutsetninger for \u00e5 kunne utnyttes<\/td><\/tr><tr><td>Middels<\/td><td>Reell risiko, ofte begrenset i omfang eller avhengig av privilegert tilgang<\/td><\/tr><tr><td>Lav<\/td><td>Begrenset konsekvens, gjerne knyttet til god praksis mer enn direkte tap<\/td><\/tr><tr><td>Informativ<\/td><td>Ingen direkte sikkerhetsrisiko, men verdt \u00e5 notere seg for fremtidig arbeid<\/td><\/tr><tr><td>Ubestemt<\/td><td>Svakheten er reell, men utnyttbarheten kunne ikke bekreftes p\u00e5 revisjonstidspunktet, som i Balancers TOB-BALANCER-004 (se lenger ned)<\/td><\/tr><\/tbody><\/table><\/figure><h2 class='wp-block-heading'>\u00abLevel of effort\u00bb: tallet som avgj\u00f8r hvor mye du kan stole p\u00e5 rapporten<\/h2><p class=\"wp-block-paragraph\">Fordi \u00ablevel of effort\u00bb sier noe om hvor grundig en revisjon faktisk var, er det verdt \u00e5 sammenligne ytterpunktene. Da Aave-teamet skulle sikre Aave v4 f\u00f8r lansering, satte de av et budsjett p\u00e5 1,5 millioner dollar, i underkant av 14,5 millioner kroner med dagens kurs, til et sikkerhetsprogram som varte fra mars 2025 til februar 2026. Programmet kombinerte formell verifisering fra Certora helt fra de tidligste designstadiene, manuelle revisjoner fra tre uavhengige firmaer, Trail of Bits, ChainSecurity og Blackthorn, invariant-testing og en \u00e5pen sikkerhetskonkurranse, til sammen godt over 345 personuker med gjennomgang, if\u00f8lge <a href='https:\/\/www.theblock.co\/post\/392410\/aave-labs-outlines-layered-security-plan-for-v4-after-1-5-million-audit-program'>The Blocks dekning av programmet<\/a>. Resultatet: ingen kritiske eller h\u00f8yalvorlige funn i sluttrapporten.<\/p><p class=\"wp-block-paragraph\">Det er det motsatte ytterpunktet av et lite engasjement p\u00e5 en uke eller to. Ingen av dem er n\u00f8dvendigvis \u00abfeil\u00bb isolert sett, et lite prosjekt med begrenset budsjett kan ikke alltid finansiere et program p\u00e5 Aave-niv\u00e5, men forskjellen i grundighet er enorm, og den forskjellen fremg\u00e5r faktisk av forsiden p\u00e5 rapporten, ikke av funnlisten. En leser som hopper rett til \u00abingen kritiske funn\u00bb uten \u00e5 sjekke hvor mye arbeid som faktisk ligger bak den setningen, g\u00e5r glipp av noe av den viktigste informasjonen i hele dokumentet.<\/p><h2 class='wp-block-heading'>Kodebase-modenhet: seks dimensjoner som sier mer enn funnlisten<\/h2><p class=\"wp-block-paragraph\">En del av rapporten sv\u00e6rt f\u00e5 legger merke til, er vurderingen av kodebasens modenhet. Her karaktersetter revisoren prosjektet langs seks dimensjoner: dokumentasjon, testdekning, tilgangskontroll, hygiene i forsyningskjeden (hvor p\u00e5litelige avhengigheter og byggeprosesser er), feilh\u00e5ndtering og konfigurasjon. Karakterene er kvalitative, fra svak, via moderat og tilfredsstillende, til sterk, ikke tallfestet p\u00e5 samme m\u00e5te som funnene.<\/p><p class=\"wp-block-paragraph\">Dette avsnittet er nyttig fordi det fanger opp risiko funnlisten ikke gj\u00f8r. Et prosjekt kan i prinsippet g\u00e5 gjennom en revisjon uten et eneste kritisk eller h\u00f8yalvorlig funn, og likevel score svakt p\u00e5 testdekning eller dokumentasjon. Det er ikke en feil i seg selv, men det er et signal om at fremtidige endringer i koden har st\u00f8rre sjanse for \u00e5 introdusere nye feil som ingen fanger opp f\u00f8r det er for sent, rett og slett fordi testene og dokumentasjonen som skulle avdekket dem ikke er der. En rapport med et perfekt funnavsnitt og en svak modenhetsvurdering fortjener like mye skepsis som en rapport med noen f\u00e5 middels funn og en sterk modenhetsvurdering.<\/p><h2 class='wp-block-heading'>Fra funn til fiks: Vedlegg B og fellen i ordet \u00abl\u00f8st\u00bb<\/h2><p class=\"wp-block-paragraph\">Etter at hovedgjennomgangen er ferdig, g\u00e5r revisoren som regel gjennom funnene p\u00e5 nytt og oppdaterer status for hvert av dem i det Trail of Bits kaller Vedlegg B: fikset, med henvisning til hvilken versjon eller commit fiksen kom i, eller \u00e5pent, noen ganger med en merknad om at risikoen bevisst er akseptert av teamet. Dette vedlegget er der mange lesere burde bruke mer tid enn de gj\u00f8r, fordi ordet \u00abfikset\u00bb beskriver hva teamet gjorde som svar p\u00e5 ett bestemt, konkret funn, ikke en garanti om at hele klassen av feil funnet tilh\u00f8rte er eliminert for alltid.<\/p><p class=\"wp-block-paragraph\">Det er n\u00f8yaktig denne fellen Bunni-saken illustrerer, og som vi g\u00e5r grundigere gjennom lenger ned: et funn ble flagget, teamet implementerte en fiks, og en fiksgjennomgang ville trolig ha vist funnet som adressert. Likevel dekket ikke fiksen den spesifikke kanttilstanden en angriper senere fant. \u00abFikset\u00bb er ikke det samme som \u00abdenne typen feil kan aldri oppst\u00e5 igjen\u00bb, og forskjellen mellom de to setningene kostet Bunni over 8 millioner dollar.<\/p><h2 class='wp-block-heading'>Omfanget er alt: det revisoren ikke s\u00e5 p\u00e5<\/h2><p class=\"wp-block-paragraph\">Den kanskje viktigste, og mest oversette, delen av enhver revisjonsrapport er omfangsseksjonen: hvilke konkrete filer og kontrakter som ble gjennomg\u00e5tt, og hvilken commit-hash de var l\u00e5st til. Kode som legges til, endres eller redeployes etter den datoen er per definisjon ikke dekket, selv om den ligger i akkurat samme repository, og selv om den tilh\u00f8rer akkurat samme funksjonsfamilie som koden som faktisk ble gjennomg\u00e5tt.<\/p><p class=\"wp-block-paragraph\">Balancer-saken er det tydeligste eksempelet som finnes p\u00e5 hvor mye dette betyr i praksis, og vi g\u00e5r i dybden p\u00e5 tidslinjen i neste avsnitt. Kort oppsummert: OpenZeppelin, som hadde revidert tidligere versjoner av Balancer v2-kodebasen, skrev i sin egen tekniske gjennomgang i etterkant av hacket at \u00abnew contracts were added to the repository but were not within the scope of our engagement\u00bb, if\u00f8lge <a href='https:\/\/www.openzeppelin.com\/news\/understanding-the-balancer-v2-exploit'>OpenZeppelins egen analyse<\/a>. Det er ikke en unnskyldning, det er en presis beskrivelse av hvordan omfang faktisk fungerer: en revisjon dekker koden som fantes den dagen den ble avsluttet, ikke koden som kom etterp\u00e5, uansett hvor lite den endret seg eller hvor selvsagt det virker at den burde v\u00e6rt dekket.<\/p><h2 class='wp-block-heading'>Casestudie: Balancer og alvorlighetsgraden \u00abubestemt\u00bb<\/h2><p class=\"wp-block-paragraph\">I 2021 reviderte Trail of Bits Balancers Linear Pools og fant det som senere ble katalogisert som funnet TOB-BALANCER-004: en avrundingssvakhet i m\u00e5ten Linear Pools brukte det underliggende Stable Math-biblioteket p\u00e5. Alvorlighetsgraden ble satt til \u00abubestemt\u00bb, fordi teamet, if\u00f8lge sin egen <a href='https:\/\/blog.trailofbits.com\/2025\/11\/07\/balancer-hack-analysis-and-guidance-for-the-defi-ecosystem\/'>retrospektive gjennomgang<\/a> publisert etter hacket, \u00abcouldn&#8217;t definitively determine whether the identified rounding behavior was exploitable in the Linear Pools as they were configured\u00bb p\u00e5 revisjonstidspunktet. De anbefalte omfattende fuzz-testing, men kunne ikke bekrefte utnyttbarhet der og da.<\/p><p class=\"wp-block-paragraph\">Tidslinjen er det som gj\u00f8r saken spesielt urovekkende. Balancer v2-kodebasen ble til sammen revidert 11 ganger av fire uavhengige selskaper: OpenZeppelin, Trail of Bits, Certora og ABDK, if\u00f8lge <a href='https:\/\/cointelegraph.com\/news\/balancer-finance-audits-exploit-security'>Cointelegraphs gjennomgang av saken<\/a>. OpenZeppelins andre revisjon, av StablePool- og StableMath-koden, ble avsluttet 10. september 2021. Den faktiske ComposableStablePool-kontrakten som til slutt ble utnyttet, ble lagt til i kodebasen 20. september 2021, ti dager senere, if\u00f8lge OpenZeppelins egen tekniske gjennomgang. En revisjon kan bare dekke koden som faktisk fantes den dagen den ble avsluttet, uansett hvor kort tid som g\u00e5r f\u00f8r noe nytt legges til.<\/p><p class=\"wp-block-paragraph\">Den samme typen avrundingssvakhet Trail of Bits hadde flagget i Linear Pools, dukket senere opp igjen i de beslektede Composable Stable Pools. 3. november 2025 utnyttet en angriper den, gjennom protokollens batchSwap-funksjon, og drenerte over 100 millioner dollar, godt over 950 millioner kroner med dagens valutakurs, fra ni blokkjeder, blant annet Ethereum, Base, Arbitrum og Avalanche, p\u00e5 under en time. Balancer v3, som er en annen kodebase, ble ikke ber\u00f8rt.<\/p><p class=\"wp-block-paragraph\">Trail of Bits publiserte selv en retrospektiv analyse der de tok ansvar for bommerten: alvorlighetsgraden ble undervurdert fordi trusselbildet i 2021 og 2022 var dominert av tilgangskontroll og n\u00f8kkeltyveri, ikke aritmetiske kanttilstander av denne typen. Selskapet la samtidig frem et firetrinns rammeverk for \u00e5 unng\u00e5 tilsvarende feil i fremtiden: dokumenter alle avrundings- og presisjonsinvarianter som formelle, beviselige p\u00e5stander i stedet for bare kodekommentarer; sikt mot full enhets- og integrasjonstestdekning kombinert med mutasjonstesting; kj\u00f8r kontinuerlige fuzzing-kampanjer med verkt\u00f8y som Echidna og Medusa; og legg formell verifisering p\u00e5 toppen som et fjerde lag.<\/p><p class=\"wp-block-paragraph\">Suhail Kakar, utviklerrelasjonsansvarlig i TAC Blockchain, oppsummerte bransjens reaksjon slik p\u00e5 X, if\u00f8lge Cointelegraph: \u00abBalancer went through 10+ audits. The vault was audited three separate times by different firms still got hacked for $110M. This space needs to accept that &#8216;audited by X&#8217; means almost nothing. Code is hard, DeFi is harder.\u00bb<\/p><h2 class='wp-block-heading'>Casestudie: Bunni og fiksen som ikke dekket alt<\/h2><p class=\"wp-block-paragraph\">Bunni var en desentralisert b\u00f8rs bygget p\u00e5 Uniswap v4. Trail of Bits hadde tidligere flagget funnet TOB-BUNNI-13: kodebasen manglet en systematisk tiln\u00e6rming til avrunding og presisjon i sentrale beregninger. Bunni-teamet implementerte det de betraktet som en fiks. Problemet var at fiksen ikke dekket den spesifikke kanttilstanden en angriper senere klarte \u00e5 utnytte.<\/p><p class=\"wp-block-paragraph\">2. september 2025 l\u00e5nte en angriper 3 millioner USDT gjennom et flash-l\u00e5n og brukte det til \u00e5 manipulere spotprisen i USDC\/USDT-poolen p\u00e5 Ethereum til ekstreme niv\u00e5er, if\u00f8lge <a href='https:\/\/www.halborn.com\/blog\/post\/explained-the-bunni-hack-september-2025'>Halborns gjennomgang av hendelsen<\/a>. Da poolens aktive USDC-saldo var presset ned til bare 28 wei, utf\u00f8rte angriperen 44 p\u00e5f\u00f8lgende, sm\u00e5 uttak. Hvert av dem utnyttet den samme avrundingsretningen Trail of Bits hadde advart om, og til sammen presset de poolens likviditet ned med over 84 prosent, if\u00f8lge <a href='https:\/\/www.theblock.co\/post\/369564\/bunni-smart-contract-rounding-error'>The Blocks omtale av Bunnis egen hendelsesrapport<\/a>. Totalt tap: rundt 2,4 millioner dollar p\u00e5 Ethereum og 5,9 millioner dollar p\u00e5 Unichain, til sammen 8,4 millioner dollar, dr\u00f8yt 80 millioner kroner.<\/p><p class=\"wp-block-paragraph\">Bunni-teamet stengte protokollen permanent kort tid etterp\u00e5, med begrunnelsen at de ikke hadde r\u00e5d til \u00e5 finansiere det seks- til sjusifrede sikkerhetsprogrammet en trygg relansering ville krevd. Det peker p\u00e5 et strukturelt problem som ligger under hele denne artikkelen: solid sikkerhetsarbeid koster mye, og et team som nettopp har blitt hacket er gjerne det teamet som har minst mulighet til \u00e5 betale for \u00e5 gj\u00f8re det skikkelig p\u00e5 nytt.<\/p><h2 class='wp-block-heading'>Hvor finner du revisjonsrapportene?<\/h2><p class=\"wp-block-paragraph\">Det gode med at flere store revisjonsselskaper, Trail of Bits inkludert, publiserer rapportene sine \u00e5pent, er at man faktisk kan sjekke p\u00e5stander som \u00abrevidert av X\u00bb selv, i stedet for \u00e5 ta et prosjekts ord for det.<\/p><figure class='wp-block-table'><table><thead><tr><th>Kilde<\/th><th>Hva du finner der<\/th><\/tr><\/thead><tbody><tr><td>trailofbits.com\/reports<\/td><td>Selskapets egen katalog med over 620 offentlige rapporter fra rundt 25 klientgrupper<\/td><\/tr><tr><td>GitHub-organisasjonen trailofbits\/publications<\/td><td>R\u00e5e PDF-filer og kildehenvisninger for de offentliggjorte rapportene<\/td><\/tr><tr><td>Solodit (solodit.cyfrin.io)<\/td><td>S\u00f8kbar database med over 50 000 funn samlet fra Trail of Bits, OpenZeppelin, Code4rena, Sherlock og flere andre firmaer<\/td><\/tr><tr><td>DeFiSafety (defisafety.com)<\/td><td>Uavhengig prosessvurdering, fra 0 til 100 poeng, av protokoller basert p\u00e5 offentlig tilgjengelig dokumentasjon<\/td><\/tr><tr><td>Blokkjedeutforsker, for eksempel Etherscan<\/td><td>Verifisert kildekode du kan sammenligne direkte mot commit-hashen som er oppgitt i rapporten<\/td><\/tr><\/tbody><\/table><\/figure><p class=\"wp-block-paragraph\">Det siste punktet i tabellen er verdt \u00e5 understreke, fordi det er det praktiske steget de fleste hopper over. Hvis en rapport oppgir en bestemt commit-hash, kan du i teorien sjekke om bytekoden som faktisk er deployert p\u00e5 kjeden stemmer med akkurat den commiten, ikke en nyere versjon som aldri ble sett av revisoren. <a href='https:\/\/solodit.cyfrin.io\/'>Solodit<\/a> er spesielt nyttig hvis du vil sammenligne hvordan flere ulike firmaer har vurdert lignende kodem\u00f8nstre over tid, mens <a href='https:\/\/defisafety.com\/our_review'>DeFiSafetys<\/a> prosessvurderinger er nyttige nettopp fordi de er uavhengige av hvem som reviderte selve koden.<\/p><h2 class='wp-block-heading'>Det ingen kodesjekk kan fange opp<\/h2><p class=\"wp-block-paragraph\">Selv en perfekt gjennomf\u00f8rt revisjon, med bredt omfang, h\u00f8y modenhetsscore og et team som brukte m\u00e5neder p\u00e5 arbeidet, sier ingenting om flere av de vanligste \u00e5rsakene til at folk faktisk mister penger i krypto. Alexander Urbelis, sikkerhetssjef (CISO) i ENS Labs, satte ord p\u00e5 dette poenget slik overfor CoinDesk: \u00abThe bugs that drain treasuries often turn on intent and adversarial incentives\u00bb, if\u00f8lge <a href='https:\/\/www.coindesk.com\/tech\/2026\/06\/20\/ai-is-making-crypto-security-cheaper-faster-and-harder-to-ignore'>CoinDesks dekning av sikkerhetsbransjen<\/a>. Med andre ord: mange av de dyreste hendelsene handler om hensikt og motstridende insentiver, ikke om en linje kode som er teknisk feil.<\/p><p class=\"wp-block-paragraph\">Konkret er det minst fire risikokategorier en vanlig kodegjennomgang ikke er designet for \u00e5 dekke. Rene svindelfors\u00f8k, temaet i <a href='https:\/\/hoge.gg\/no\/rug-pull-forklart-defi-svindel\/'>Rug pull forklart: derfor forsvinner DeFi-prosjekter over natten<\/a>, kan skje med teknisk plettfri kode, siden risikoen ligger i at teamet bevisst velger \u00e5 forsvinne med midlene, ikke i en feil i koden. Styringsangrep, som vi g\u00e5r gjennom i <a href='https:\/\/hoge.gg\/no\/governance-angrep-beanstalk-bonkdao-2026\/'>Governance-angrep forklart: fra Beanstalk til BonkDAO i 2026<\/a>, kan i prinsippet v\u00e6re en formelt gyldig avstemning som likevel drenerer en protokolls egen kasse, noe en kodegjennomgang ikke har noe \u00e5 si om, fordi koden fungerte akkurat som den skulle. Brotillit, temaet i <a href='https:\/\/hoge.gg\/no\/bridge-hack-forklart-kryptobroer-svakeste-ledd\/'>Bridge-hack forklart: hvorfor broer er kryptoens svakeste ledd<\/a>, handler ofte om hvor mye makt som er konsentrert hos et validatorsett eller en multisig, et designvalg en revisjon kan beskrive, men ikke fjerne. Og orakelmanipulasjon, som vi dekker i <a href='https:\/\/hoge.gg\/no\/oracle-angrep-2026-nye-bolgen-defi\/'>Oracle-angrepene i 2026: den nye b\u00f8lgen som rammer DeFi<\/a>, rammer prisdata en l\u00e5ne- eller handelskontrakt er avhengig av, ofte et system som ligger helt utenfor det som faktisk sto i revisjonens omfang.<\/p><p class=\"wp-block-paragraph\">David Schwed, driftssjef i sikkerhetsselskapet SVRN og grunnlegger av videreutdanningsprogrammet i cybersikkerhet ved Yeshiva University, formulerte en beslektet advarsel om verkt\u00f8y og rapporter generelt overfor CoinDesk: \u00ab&#8217;Claude, audit my smart contract, make no mistakes&#8217; is not a security program.\u00bb Poenget generaliserer godt til revisjonsrapporter i sin helhet: \u00e5 ha rapporten liggende er ikke det samme som \u00e5 kunne lese den riktig.<\/p><h2 class='wp-block-heading'>Sjekklisten: seks sp\u00f8rsm\u00e5l \u00e5 stille f\u00f8r du stoler p\u00e5 en revisjon<\/h2><p class=\"wp-block-paragraph\">Basert p\u00e5 alt over kan de fleste revisjonsrapporter vurderes raskt med disse seks sp\u00f8rsm\u00e5lene:<\/p><ul class='wp-block-list'><li>Er omfanget tydelig beskrevet, og dekker det koden som faktisk er deployert i dag, ikke bare koden slik den s\u00e5 ut p\u00e5 revisjonstidspunktet?<\/li><li>Stemmer den verifiserte, deployerte bytekoden med commit-hashen rapporten faktisk viser til?<\/li><li>Hvilken status har de mest alvorlige funnene i fiksgjennomgangen: fikset, \u00e5pent, eller akseptert risiko?<\/li><li>Er det snakk om \u00e9n enkelt revisjon, eller flere uavhengige team, slik som i Aave v4-programmet?<\/li><li>Hva sier modenhetsvurderingen om testdekning og tilgangskontroll, ikke bare selve funnlisten?<\/li><li>Hva ligger uttrykkelig utenfor omfanget, for eksempel styring, broer, orakler eller n\u00f8kkeladministrasjon?<\/li><\/ul><p class=\"wp-block-paragraph\">Ingen av disse seks sp\u00f8rsm\u00e5lene krever teknisk bakgrunn i Solidity eller kryptografi. De krever bare at man faktisk \u00e5pner rapporten og leser forbi de tre f\u00f8rste sidene, noe et overraskende lite antall investorer, brukere og til og med journalister faktisk gj\u00f8r f\u00f8r de skriver eller stoler p\u00e5 en overskrift som \u00abrevidert av Trail of Bits\u00bb.<\/p><h2 class='wp-block-heading'>Ofte stilte sp\u00f8rsm\u00e5l<\/h2><h3 class='wp-block-heading'>Hva betyr det at en smart contract er \u00abrevidert\u00bb (audited)?<\/h3><p class=\"wp-block-paragraph\">At koden er \u00abrevidert\u00bb betyr at et sikkerhetsselskap har gjennomg\u00e5tt et avgrenset utvalg av kildekoden p\u00e5 et bestemt tidspunkt, l\u00e5st til \u00e9n bestemt commit-hash, og dokumentert svakhetene de fant innenfor den avtalte tidsrammen, m\u00e5lt i person-uker. Det er ikke en garanti mot fremtidige hendelser, ingen sertifisering godkjent av noen myndighet, og det sier ingenting om kode som legges til etter at revisjonen er avsluttet.<\/p><h3 class='wp-block-heading'>Hva betyr alvorlighetsgraden \u00abubestemt\u00bb (undetermined) i en revisjonsrapport?<\/h3><p class=\"wp-block-paragraph\">\u00abUbestemt\u00bb brukes n\u00e5r revisoren finner en reell svakhet i koden, men ikke klarer \u00e5 fastsl\u00e5 med sikkerhet om den faktisk lar seg utnytte under de konkrete forholdene protokollen kj\u00f8rer under. Det er verken en frikjennelse eller en alvorlighetsgrad som kan ignoreres, det er en beskjed om at sp\u00f8rsm\u00e5let forblir \u00e5pent. Balancers funn TOB-BALANCER-004 fra 2021 fikk nettopp denne merkelappen, og en beslektet svakhet ble utnyttet for over 100 millioner dollar fire \u00e5r senere.<\/p><h3 class='wp-block-heading'>Er det trygt \u00e5 investere i et prosjekt bare fordi det er revidert av Trail of Bits?<\/h3><p class=\"wp-block-paragraph\">Nei. Balancer var revidert 11 ganger av fire ulike selskaper og ble likevel hacket for over 100 millioner dollar i november 2025. En revisjon reduserer risiko innenfor sitt avtalte omfang, men sier ingenting om styringsangrep, brotillit, orakelmanipulasjon eller ren svindel, risikoer som ligger utenfor det en kodegjennomgang i utgangspunktet er laget for \u00e5 fange opp.<\/p><h3 class='wp-block-heading'>Hvor kan jeg finne Trail of Bits sine revisjonsrapporter gratis?<\/h3><p class=\"wp-block-paragraph\">Trail of Bits publiserer rapporter klienter har godkjent for offentliggj\u00f8ring i sin egen katalog p\u00e5 trailofbits.com\/reports, med r\u00e5filer tilgjengelig gjennom GitHub-organisasjonen trailofbits\/publications. S\u00f8kbare databaser som Solodit samler i tillegg funn fra Trail of Bits og en rekke andre revisjonsselskaper p\u00e5 ett sted.<\/p><h3 class='wp-block-heading'>Hva er forskjellen p\u00e5 en revisjon og et bug-bounty-program?<\/h3><p class=\"wp-block-paragraph\">En revisjon er et tidsavgrenset, betalt oppdrag der et fast team gjennomg\u00e5r en definert kodebase f\u00f8r eller rundt lansering. Et bug-bounty-program er en l\u00f8pende, \u00e5pen invitasjon der hvem som helst kan rapportere svakheter mot en bel\u00f8nning, ofte lenge etter at koden er i produksjon og har endret seg. De to utfyller hverandre snarere enn \u00e5 erstatte hverandre: en revisjon fanger opp strukturelle svakheter tidlig, et bug-bounty-program fanger opp det som dukker opp i etterkant, inkludert i kode som aldri ble revidert.<\/p><script type='application\/ld+json'>{\"@context\":\"https:\/\/schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"Hva betyr det at en smart contract er \u00abrevidert\u00bb (audited)?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"At koden er \u00abrevidert\u00bb betyr at et sikkerhetsselskap har gjennomg\u00e5tt et avgrenset utvalg av kildekoden p\u00e5 et bestemt tidspunkt, l\u00e5st til \u00e9n bestemt commit-hash, og dokumentert svakhetene de fant innenfor den avtalte tidsrammen, m\u00e5lt i person-uker. Det er ikke en garanti mot fremtidige hendelser, ingen sertifisering godkjent av noen myndighet, og det sier ingenting om kode som legges til etter at revisjonen er avsluttet.\"}},{\"@type\":\"Question\",\"name\":\"Hva betyr alvorlighetsgraden \u00abubestemt\u00bb (undetermined) i en revisjonsrapport?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"\u00abUbestemt\u00bb brukes n\u00e5r revisoren finner en reell svakhet i koden, men ikke klarer \u00e5 fastsl\u00e5 med sikkerhet om den faktisk lar seg utnytte under de konkrete forholdene protokollen kj\u00f8rer under. Det er verken en frikjennelse eller en alvorlighetsgrad som kan ignoreres, det er en beskjed om at sp\u00f8rsm\u00e5let forblir \u00e5pent. Balancers funn TOB-BALANCER-004 fra 2021 fikk nettopp denne merkelappen, og en beslektet svakhet ble utnyttet for over 100 millioner dollar fire \u00e5r senere.\"}},{\"@type\":\"Question\",\"name\":\"Er det trygt \u00e5 investere i et prosjekt bare fordi det er revidert av Trail of Bits?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Nei. Balancer var revidert 11 ganger av fire ulike selskaper og ble likevel hacket for over 100 millioner dollar i november 2025. En revisjon reduserer risiko innenfor sitt avtalte omfang, men sier ingenting om styringsangrep, brotillit, orakelmanipulasjon eller ren svindel, risikoer som ligger utenfor det en kodegjennomgang i utgangspunktet er laget for \u00e5 fange opp.\"}},{\"@type\":\"Question\",\"name\":\"Hvor kan jeg finne Trail of Bits sine revisjonsrapporter gratis?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Trail of Bits publiserer rapporter klienter har godkjent for offentliggj\u00f8ring i sin egen katalog p\u00e5 trailofbits.com\/reports, med r\u00e5filer tilgjengelig gjennom GitHub-organisasjonen trailofbits\/publications. S\u00f8kbare databaser som Solodit samler i tillegg funn fra Trail of Bits og en rekke andre revisjonsselskaper p\u00e5 ett sted.\"}},{\"@type\":\"Question\",\"name\":\"Hva er forskjellen p\u00e5 en revisjon og et bug-bounty-program?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"En revisjon er et tidsavgrenset, betalt oppdrag der et fast team gjennomg\u00e5r en definert kodebase f\u00f8r eller rundt lansering. Et bug-bounty-program er en l\u00f8pende, \u00e5pen invitasjon der hvem som helst kan rapportere svakheter mot en bel\u00f8nning, ofte lenge etter at koden er i produksjon og har endret seg. De to utfyller hverandre snarere enn \u00e5 erstatte hverandre: en revisjon fanger opp strukturelle svakheter tidlig, et bug-bounty-program fanger opp det som dukker opp i etterkant, inkludert i kode som aldri ble revidert.\"}}]}<\/script><p class=\"wp-block-paragraph\">Skrevet av Anneke de Vries, sikkerhetsjournalist i HOGE Wire.<\/p>","protected":false},"excerpt":{"rendered":"<p>En revisjonsrapport har alvorlighetsgrad, vanskelighetsgrad og et n\u00f8ye avgrenset omfang. Balancer og Bunni viser hva som skjer n\u00e5r det blir lest for overfladisk.<\/p>\n","protected":false},"author":4,"featured_media":179,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[],"class_list":["post-178","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security-exploits"],"_links":{"self":[{"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/posts\/178","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/comments?post=178"}],"version-history":[{"count":0,"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/posts\/178\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/media\/179"}],"wp:attachment":[{"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/media?parent=178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/categories?post=178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hoge.gg\/no\/wp-json\/wp\/v2\/tags?post=178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}