Hva står egentlig i en Trail of Bits-revisjon?

Da ti revisjoner ikke stoppet et hack på over 100 millioner dollar

Balancer-protokollen hadde vært gjennom over ti sikkerhetsrevisjoner i løpet av sin levetid. Likevel forsvant over 100 millioner dollar fra protokollen 3. november 2025, drenert fra ni ulike blokkjeder på under en time. Årsaken var en avrundingssvakhet som i realiteten allerede var påpekt av Trail of Bits, fire år tidligere, i en revisjonsrapport med et funn merket «ubestemt».

Rapporten fantes. Funnet fantes. Alvorlighetsgraden var satt. Og likevel skjedde det. Det paradokset er kjernen i denne artikkelen, ikke fordi revisjoner er verdiløse, men fordi de færreste som stoler på ordet «revidert» faktisk har lest hva som står 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øye avgrenset omfang som definerer hva som faktisk ble undersøkt og hva som ikke ble det.

Denne artikkelen går 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å hva som skjer når den strukturen leses for overfladisk, eller ikke leses i det hele tatt.

Hva er egentlig en smart contract-revisjon?

En smart contract-revisjon er et tidsavgrenset, betalt oppdrag der et sikkerhetsteam gjennomgår en definert del av en kodebase, på et bestemt tidspunkt, låst til én bestemt commit-hash i versjonskontrollen. Arbeidet kombinerer typisk manuell kodegjennomgang linje for linje, automatisert statisk analyse som leter etter kjente feilmønstre, og fuzzing, altså automatisert testing som prøver enorme mengder tilfeldige eller motstridende inndata for å se om noen av dem bryter protokollens egne regler, gjerne kalt invarianter.

Det viktigste å forstå er hva en revisjon ikke er. I Norge er dette området fortsatt uregulert i praksis: MiCA-forordningen trådte i kraft her gjennom EØS-avtalen 1. juli 2025, og Finanstilsynet fører tilsyn med kryptoeiendelstjenesteytere under kryptoeiendelsloven, ifølge Finanstilsynets egen oversikt. Men verken MiCA eller det norske regelverket stiller krav om at en smart contract faktisk skal kodegjennomgås av noen, og fullt desentraliserte protokoller uten en identifiserbar utsteder faller uansett utenfor MiCA sitt virkeområde. En revisjonsrapport er med andre ord et frivillig, kommersielt dokument, ikke et lovpålagt sikkerhetsbevis. Den er heller ikke kontinuerlig overvåkning, bare et øyeblikksbilde av koden slik den så 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ådighet, om en bestemt, avgrenset del av systemet.

Trail of Bits er blitt bransjens referansepunkt

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ølge selskapets egen rapportkatalog. Åpen kildekode-verktøyene 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 Trail of Bits forklart: kryptobransjens mest kjente revisor, så her går vi ikke i dybden på selskapet, men på selve dokumentet de leverer fra seg.

Grunnen til at Trail of Bits egner seg spesielt godt som utgangspunkt for akkurat denne gjennomgangen, er at selskapet er uvanlig åpne om egen metodikk. De har publisert en egen guide, kalt «Anatomy of a report», 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.

Slik er en revisjonsrapport bygget opp: åtte deler du bør kjenne til

Ifølge Trail of Bits sin egen guide til rapportstrukturen består en typisk rapport av åtte deler. De færreste leser lenger enn til sammendraget og funnlisten, men de andre delene inneholder ofte informasjon som er like viktig for å vurdere hvor mye man kan stole på konklusjonene.

To detaljer i denne strukturen er verdt å dvele ved. Den første er at «level of effort», altså hvor mange ingeniører som brukte hvor mye tid, ligger på forsiden i stedet for gjemt bort i et vedlegg. Trail of Bits omtaler selv dette som noe av det viktigste enkelttallet for å vekte et funn: en revisjon utført av to personer på én uke bør veie helt annerledes enn en revisjon utført av et større team over flere måneder. Den andre er at hvert enkeltfunn skal inneholde det guiden kaller et konkret angriper-scenario, altså nøyaktig hva en angriper må gjøre, i hvilken rekkefølge, for å utnytte svakheten. Poenget er at leseren skal kunne bygge riktig mental modell av risikoen før noe blir rettet, ikke bare lese en overskrift og anta at den er forstått.

To akser, ikke én: alvorlighetsgrad og vanskelighetsgrad

Den vanligste misforståelsen når folk leser en revisjonsrapport, er å behandle alvorlighetsgrad som det eneste tallet som teller. Trail of Bits sin egen guide er tydelig på at funn plottes langs to akser samtidig: alvorlighetsgrad, altså hva som kan skje dersom svakheten utnyttes, og vanskelighetsgrad, altså hvor krevende det er for en angriper å faktisk komme dit. En enkel middels-alvorlig sak kan dermed rangere høyere i praktisk risiko enn en vanskelig kritisk sak, nettopp fordi matrisen fanger opp begge dimensjonene samtidig i stedet for å redusere alt til ett enkelt ord.

På tvers av bransjen, ikke bare hos Trail of Bits, går alvorlighetsgradene som regel fra informativ, via lav, middels og høy, til kritisk. Trail of Bits bruker i tillegg en sjette kategori i egne rapporter: ubestemt. Den brukes når revisoren finner en reell strukturell svakhet, men ikke klarer å bekrefte om den faktisk er utnyttbar under de konkrete forholdene protokollen kjører under, gitt tidsrammen de hadde til rådighet. Det er en ærlig kategori, ikke en runding oppover eller nedover, men den krever at leseren forstår at «ubestemt» ikke betyr «lite alvorlig».

«Level of effort»: tallet som avgjør hvor mye du kan stole på rapporten

Fordi «level of effort» sier noe om hvor grundig en revisjon faktisk var, er det verdt å sammenligne ytterpunktene. Da Aave-teamet skulle sikre Aave v4 før lansering, satte de av et budsjett på 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 åpen sikkerhetskonkurranse, til sammen godt over 345 personuker med gjennomgang, ifølge The Blocks dekning av programmet. Resultatet: ingen kritiske eller høyalvorlige funn i sluttrapporten.

Det er det motsatte ytterpunktet av et lite engasjement på en uke eller to. Ingen av dem er nødvendigvis «feil» isolert sett, et lite prosjekt med begrenset budsjett kan ikke alltid finansiere et program på Aave-nivå, men forskjellen i grundighet er enorm, og den forskjellen fremgår faktisk av forsiden på rapporten, ikke av funnlisten. En leser som hopper rett til «ingen kritiske funn» uten å sjekke hvor mye arbeid som faktisk ligger bak den setningen, går glipp av noe av den viktigste informasjonen i hele dokumentet.

Kodebase-modenhet: seks dimensjoner som sier mer enn funnlisten

En del av rapporten svært få legger merke til, er vurderingen av kodebasens modenhet. Her karaktersetter revisoren prosjektet langs seks dimensjoner: dokumentasjon, testdekning, tilgangskontroll, hygiene i forsyningskjeden (hvor pålitelige avhengigheter og byggeprosesser er), feilhåndtering og konfigurasjon. Karakterene er kvalitative, fra svak, via moderat og tilfredsstillende, til sterk, ikke tallfestet på samme måte som funnene.

Dette avsnittet er nyttig fordi det fanger opp risiko funnlisten ikke gjør. Et prosjekt kan i prinsippet gå gjennom en revisjon uten et eneste kritisk eller høyalvorlig funn, og likevel score svakt på testdekning eller dokumentasjon. Det er ikke en feil i seg selv, men det er et signal om at fremtidige endringer i koden har større sjanse for å introdusere nye feil som ingen fanger opp før 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å middels funn og en sterk modenhetsvurdering.

Fra funn til fiks: Vedlegg B og fellen i ordet «løst»

Etter at hovedgjennomgangen er ferdig, går revisoren som regel gjennom funnene på 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 åpent, 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ør, fordi ordet «fikset» beskriver hva teamet gjorde som svar på ett bestemt, konkret funn, ikke en garanti om at hele klassen av feil funnet tilhørte er eliminert for alltid.

Det er nøyaktig denne fellen Bunni-saken illustrerer, og som vi går 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. «Fikset» er ikke det samme som «denne typen feil kan aldri oppstå igjen», og forskjellen mellom de to setningene kostet Bunni over 8 millioner dollar.

Omfanget er alt: det revisoren ikke så på

Den kanskje viktigste, og mest oversette, delen av enhver revisjonsrapport er omfangsseksjonen: hvilke konkrete filer og kontrakter som ble gjennomgått, og hvilken commit-hash de var låst 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ører akkurat samme funksjonsfamilie som koden som faktisk ble gjennomgått.

Balancer-saken er det tydeligste eksempelet som finnes på hvor mye dette betyr i praksis, og vi går i dybden på 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 «new contracts were added to the repository but were not within the scope of our engagement», ifølge OpenZeppelins egen analyse. 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å, uansett hvor lite den endret seg eller hvor selvsagt det virker at den burde vært dekket.

Casestudie: Balancer og alvorlighetsgraden «ubestemt»

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åten Linear Pools brukte det underliggende Stable Math-biblioteket på. Alvorlighetsgraden ble satt til «ubestemt», fordi teamet, ifølge sin egen retrospektive gjennomgang publisert etter hacket, «couldn’t definitively determine whether the identified rounding behavior was exploitable in the Linear Pools as they were configured» på revisjonstidspunktet. De anbefalte omfattende fuzz-testing, men kunne ikke bekrefte utnyttbarhet der og da.

Tidslinjen er det som gjør saken spesielt urovekkende. Balancer v2-kodebasen ble til sammen revidert 11 ganger av fire uavhengige selskaper: OpenZeppelin, Trail of Bits, Certora og ABDK, ifølge Cointelegraphs gjennomgang av saken. 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ølge OpenZeppelins egen tekniske gjennomgang. En revisjon kan bare dekke koden som faktisk fantes den dagen den ble avsluttet, uansett hvor kort tid som går før noe nytt legges til.

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å under en time. Balancer v3, som er en annen kodebase, ble ikke berørt.

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økkeltyveri, ikke aritmetiske kanttilstander av denne typen. Selskapet la samtidig frem et firetrinns rammeverk for å unngå tilsvarende feil i fremtiden: dokumenter alle avrundings- og presisjonsinvarianter som formelle, beviselige påstander i stedet for bare kodekommentarer; sikt mot full enhets- og integrasjonstestdekning kombinert med mutasjonstesting; kjør kontinuerlige fuzzing-kampanjer med verktøy som Echidna og Medusa; og legg formell verifisering på toppen som et fjerde lag.

Suhail Kakar, utviklerrelasjonsansvarlig i TAC Blockchain, oppsummerte bransjens reaksjon slik på X, ifølge Cointelegraph: «Balancer 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 ‘audited by X’ means almost nothing. Code is hard, DeFi is harder.»

Casestudie: Bunni og fiksen som ikke dekket alt

Bunni var en desentralisert børs bygget på Uniswap v4. Trail of Bits hadde tidligere flagget funnet TOB-BUNNI-13: kodebasen manglet en systematisk tilnærming 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 å utnytte.

2. september 2025 lånte en angriper 3 millioner USDT gjennom et flash-lån og brukte det til å manipulere spotprisen i USDC/USDT-poolen på Ethereum til ekstreme nivåer, ifølge Halborns gjennomgang av hendelsen. Da poolens aktive USDC-saldo var presset ned til bare 28 wei, utførte angriperen 44 påfølgende, små 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ølge The Blocks omtale av Bunnis egen hendelsesrapport. Totalt tap: rundt 2,4 millioner dollar på Ethereum og 5,9 millioner dollar på Unichain, til sammen 8,4 millioner dollar, drøyt 80 millioner kroner.

Bunni-teamet stengte protokollen permanent kort tid etterpå, med begrunnelsen at de ikke hadde råd til å finansiere det seks- til sjusifrede sikkerhetsprogrammet en trygg relansering ville krevd. Det peker på 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 å betale for å gjøre det skikkelig på nytt.

Hvor finner du revisjonsrapportene?

Det gode med at flere store revisjonsselskaper, Trail of Bits inkludert, publiserer rapportene sine åpent, er at man faktisk kan sjekke påstander som «revidert av X» selv, i stedet for å ta et prosjekts ord for det.

Det siste punktet i tabellen er verdt å 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å kjeden stemmer med akkurat den commiten, ikke en nyere versjon som aldri ble sett av revisoren. Solodit er spesielt nyttig hvis du vil sammenligne hvordan flere ulike firmaer har vurdert lignende kodemønstre over tid, mens DeFiSafetys prosessvurderinger er nyttige nettopp fordi de er uavhengige av hvem som reviderte selve koden.

Det ingen kodesjekk kan fange opp

Selv en perfekt gjennomført revisjon, med bredt omfang, høy modenhetsscore og et team som brukte måneder på arbeidet, sier ingenting om flere av de vanligste årsakene til at folk faktisk mister penger i krypto. Alexander Urbelis, sikkerhetssjef (CISO) i ENS Labs, satte ord på dette poenget slik overfor CoinDesk: «The bugs that drain treasuries often turn on intent and adversarial incentives», ifølge CoinDesks dekning av sikkerhetsbransjen. Med andre ord: mange av de dyreste hendelsene handler om hensikt og motstridende insentiver, ikke om en linje kode som er teknisk feil.

Konkret er det minst fire risikokategorier en vanlig kodegjennomgang ikke er designet for å dekke. Rene svindelforsøk, temaet i Rug pull forklart: derfor forsvinner DeFi-prosjekter over natten, kan skje med teknisk plettfri kode, siden risikoen ligger i at teamet bevisst velger å forsvinne med midlene, ikke i en feil i koden. Styringsangrep, som vi går gjennom i Governance-angrep forklart: fra Beanstalk til BonkDAO i 2026, kan i prinsippet være en formelt gyldig avstemning som likevel drenerer en protokolls egen kasse, noe en kodegjennomgang ikke har noe å si om, fordi koden fungerte akkurat som den skulle. Brotillit, temaet i Bridge-hack forklart: hvorfor broer er kryptoens svakeste ledd, 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 Oracle-angrepene i 2026: den nye bølgen som rammer DeFi, rammer prisdata en låne- eller handelskontrakt er avhengig av, ofte et system som ligger helt utenfor det som faktisk sto i revisjonens omfang.

David Schwed, driftssjef i sikkerhetsselskapet SVRN og grunnlegger av videreutdanningsprogrammet i cybersikkerhet ved Yeshiva University, formulerte en beslektet advarsel om verktøy og rapporter generelt overfor CoinDesk: «’Claude, audit my smart contract, make no mistakes’ is not a security program.» Poenget generaliserer godt til revisjonsrapporter i sin helhet: å ha rapporten liggende er ikke det samme som å kunne lese den riktig.

Sjekklisten: seks spørsmål å stille før du stoler på en revisjon

Basert på alt over kan de fleste revisjonsrapporter vurderes raskt med disse seks spørsmålene:

• Er omfanget tydelig beskrevet, og dekker det koden som faktisk er deployert i dag, ikke bare koden slik den så ut på revisjonstidspunktet?
• Stemmer den verifiserte, deployerte bytekoden med commit-hashen rapporten faktisk viser til?
• Hvilken status har de mest alvorlige funnene i fiksgjennomgangen: fikset, åpent, eller akseptert risiko?
• Er det snakk om én enkelt revisjon, eller flere uavhengige team, slik som i Aave v4-programmet?
• Hva sier modenhetsvurderingen om testdekning og tilgangskontroll, ikke bare selve funnlisten?
• Hva ligger uttrykkelig utenfor omfanget, for eksempel styring, broer, orakler eller nøkkeladministrasjon?

Ingen av disse seks spørsmålene krever teknisk bakgrunn i Solidity eller kryptografi. De krever bare at man faktisk åpner rapporten og leser forbi de tre første sidene, noe et overraskende lite antall investorer, brukere og til og med journalister faktisk gjør før de skriver eller stoler på en overskrift som «revidert av Trail of Bits».

Ofte stilte spørsmål

Hva betyr det at en smart contract er «revidert» (audited)?

At koden er «revidert» betyr at et sikkerhetsselskap har gjennomgått et avgrenset utvalg av kildekoden på et bestemt tidspunkt, låst til én bestemt commit-hash, og dokumentert svakhetene de fant innenfor den avtalte tidsrammen, målt 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.

Hva betyr alvorlighetsgraden «ubestemt» (undetermined) i en revisjonsrapport?

«Ubestemt» brukes når revisoren finner en reell svakhet i koden, men ikke klarer å fastslå med sikkerhet om den faktisk lar seg utnytte under de konkrete forholdene protokollen kjører under. Det er verken en frikjennelse eller en alvorlighetsgrad som kan ignoreres, det er en beskjed om at spørsmålet forblir åpent. Balancers funn TOB-BALANCER-004 fra 2021 fikk nettopp denne merkelappen, og en beslektet svakhet ble utnyttet for over 100 millioner dollar fire år senere.

Er det trygt å investere i et prosjekt bare fordi det er revidert av Trail of Bits?

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 å fange opp.

Hvor kan jeg finne Trail of Bits sine revisjonsrapporter gratis?

Trail of Bits publiserer rapporter klienter har godkjent for offentliggjøring i sin egen katalog på trailofbits.com/reports, med råfiler tilgjengelig gjennom GitHub-organisasjonen trailofbits/publications. Søkbare databaser som Solodit samler i tillegg funn fra Trail of Bits og en rekke andre revisjonsselskaper på ett sted.

Hva er forskjellen på en revisjon og et bug-bounty-program?

En revisjon er et tidsavgrenset, betalt oppdrag der et fast team gjennomgår en definert kodebase før eller rundt lansering. Et bug-bounty-program er en løpende, åpen invitasjon der hvem som helst kan rapportere svakheter mot en belønning, ofte lenge etter at koden er i produksjon og har endret seg. De to utfyller hverandre snarere enn å 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.

Skrevet av Anneke de Vries, sikkerhetsjournalist i HOGE Wire.