Zo beoordeel je een auditrapport van een smart contract
Een auditrapport van een smart contract is geen veiligheidsgarantie. Leer hoe je scope, bevindingen, oplossingen en de geloofwaardigheid van de auditor controleert, plus de signalen van nepaudits.
Om een auditrapport van een smart contract te beoordelen, controleer je of het echt is en door de auditor is gepubliceerd, ga je na of de scope de daadwerkelijk uitgerolde contracten dekt, lees je de kritieke en hoge bevindingen en of elk ervan is opgelost, en noteer je wat de audit uitdrukkelijk niet heeft gedekt. Een audit is een momentopname van specifieke code, geen garantie dat een project veilig of eerlijk is.
Projecten gebruiken ‘geaudit’ vaak als keurmerk. Sommige audits zijn grondig en zinvol; andere zijn beperkt, verouderd of nep. Als je weet hoe je het rapport leest, zie je het verschil in ongeveer een kwartier.
Wat een smart-contractaudit is
Een smart-contractaudit is een beveiligingsonderzoek waarbij specialisten de code van een project lezen, testen en zoeken naar kwetsbaarheden zoals reentrancy, fouten in toegangscontrole, rekenfouten en logische gebreken. Daarna publiceren ze een rapport met wat ze hebben gevonden, hoe ernstig elk probleem is en hoe het team heeft gereageerd. Lees ook: Exploits van smart contracts.
Audits zijn waardevol omdat smart contracts na uitrol moeilijk te wijzigen zijn en vaak grote bedragen beheren. Maar auditors werken met tijdslimieten, beoordelen alleen wat ze krijgen en kunnen subtiele problemen missen. Veel protocollen die zijn gehackt, waren geaudit.
De onderdelen van een typisch auditrapport
| Onderdeel | Waar je op let |
|---|---|
| Samenvatting | Naam van de auditor, project, data, algemene conclusie |
| Scope | Exacte bestanden, contracten, commit-hash of uitgerolde adressen die zijn beoordeeld |
| Methodologie | Handmatige review, geautomatiseerde tools, tests, formele verificatie |
| Bevindingen | Elk probleem met ernst, beschrijving en aanbeveling |
| Status | Of elke bevinding is opgelost, erkend of betwist |
| Disclaimer | Grenzen van de beoordeling |
Stap voor stap: zo beoordeel je het rapport
1. Controleer of het rapport echt is
Nepaudits zijn een bekende oplichterstruc. Zoek het rapport op de officiële website of GitHub van de auditor, die je zelf opzoekt. Als de auditor nog nooit van het project heeft gehoord of het rapport alleen als pdf op de site van het project staat, beschouw het dan als niet geverifieerd. Onze gids over nepaudits zet veelgebruikte trucs op een rij.
2. Vergelijk de scope met wat is uitgerold
Het rapport moet een code-commit of contractadressen noemen. Controleer in een blockexplorer of de uitgerolde contracten overeenkomen. Veelvoorkomende hiaten:
- De audit betrof een eerdere versie en de code is daarna gewijzigd.
- Alleen het tokencontract is geaudit, niet de staking-, vault- of bridgecontracten die gebruikersgelden bevatten.
- De contracten zijn upgradebaar, dus de code kan later worden vervangen.
3. Lees eerst de ernstige bevindingen
Ga direct naar de kritieke en hoge problemen. Vraag je bij elk ervan af:
- Is het als opgelost gemarkeerd, en heeft de auditor de oplossing geverifieerd?
- Als het ‘erkend’ is in plaats van opgelost, wat is dan de redenering van het team?
- Gaat het om beheerdersrechten, zoals de mogelijkheid om tokens te minten, overdrachten te pauzeren of geld op te nemen?
Erkende centralisatieproblemen wegen voor investeerders vaak zwaarder dan bugs in de code. Een eigenaar die onbeperkt tokens kan minten, is een risico, zelfs als de code perfect werkt.
4. Controleer de data
Noteer wanneer de audit is uitgevoerd en vergelijk dat met de uitroldatum en eventuele latere upgrades. Een oude audit van een protocol dat vaak wordt geüpgraded, zegt weinig over de huidige code.
5. Beoordeel de auditor
Kijk naar auditors met een openbare staat van dienst, gedetailleerde gepubliceerde rapporten en beveiligingsonderzoekers die bij naam worden genoemd. Een rapport van één pagina zonder details, van een bedrijf dat honderden tokens per maand audit, weegt minder zwaar.
6. Lees de disclaimer en beperkingen
Disclaimers vermelden meestal dat de audit geen economisch ontwerp, off-chaincomponenten, orakels, frontendcode of toekomstige wijzigingen dekt. Dat zijn precies de gebieden waar in de praktijk veel verliezen ontstaan.
De ernstniveaus begrijpen
De meeste auditors gebruiken een vergelijkbare schaal, al verschillen de definities per bedrijf:
| Ernst | Gebruikelijke betekenis | Hoe ongerust je moet zijn |
|---|---|---|
| Kritiek | Direct verlies of diefstal van geld is mogelijk | Moet voor de lancering zijn opgelost; onopgelost betekent: blijf weg |
| Hoog | Ernstig geldverlies of kapotte kernfuncties onder bepaalde omstandigheden | Hoort opgelost te zijn; controleer of de auditor het heeft bevestigd |
| Gemiddeld | Problemen in specifieke situaties, of aanzienlijke centralisatie | Lees zorgvuldig, vooral bevindingen over beheerdersbevoegdheden |
| Laag | Kleine problemen met beperkte impact | Meestal geen probleem als ze zijn erkend |
| Informatief | Codekwaliteit, gas-efficiëntie, best practices | Zelden een zorg voor gebruikers |
Een rapport met veel bevindingen is niet per se slecht nieuws. Het kan betekenen dat de auditor grondig was en dat het team de problemen voor de lancering heeft opgelost. Waar het om gaat, is hoe ernstig wat onopgelost blijft is en hoe het team heeft gereageerd. Een team dat elke bevinding betwist of ernstige bevindingen stilletjes negeert, vertelt je iets over zijn beveiligingscultuur.
Waarschuwingssignalen in auditrapporten
- Geen details over de scope, geen commit-hash of contractadressen.
- Kritieke problemen die als ‘erkend’ zonder oplossing zijn vermeld.
- Bevindingen over eigenaarsrechten die het project bagatelliseert.
- Rapport dat alleen door het project wordt gehost.
- Marketingclaims zoals ‘100% veilig’ of ‘volledig beveiligd door audit’.
- Audit die ruim vóór grote codewijzigingen is gedateerd.
Wat een audit je niet vertelt
Zelfs een sterke audit geeft geen antwoord op:
- Of het team echt en betrouwbaar is – zie zo controleer je of een cryptoteam echt is.
- Of de liquiditeit is vergrendeld of kan worden weggehaald.
- Of het tokenaanbod en de unlocks eerlijk zijn.
- Of het economische ontwerp van het protocol onder druk kan bezwijken.
Combineer de audit met andere controles, zoals een openbaar bugbountyprogramma, meerdere onafhankelijke audits, een periode in productie zonder incidenten en transparante beheerderscontroles.
Conclusie
Een auditrapport is alleen nuttig bewijs als het echt en actueel is en de contracten dekt die je daadwerkelijk gebruikt. Verifieer de bron, vergelijk de scope, lees de ernstige bevindingen en hoe ze zijn opgelost, en let op wat is weggelaten. Gebruik het als één onderdeel van je onderzoek, nooit als bewijs dat een project veilig is.
Veelgestelde vragen
Betekent een audit dat een cryptoproject veilig is?
Nee. Een audit is een beoordeling van specifieke code op een specifiek moment door een specifiek team. Hij kan bugs missen, zegt niets over de eerlijkheid van het team of de tokenomics en dekt geen code die na de beoordeling is gewijzigd. Veel protocollen die zijn gehackt, waren geaudit. Zie een audit als één bewijsstuk, niet als een garantie.
Hoe weet ik of een auditrapport echt is?
Zoek het rapport op de eigen website of de officiële GitHub van de auditor, niet alleen op de site van het project. Controleer of de contractadressen of de code-commit in het rapport overeenkomen met wat er daadwerkelijk is uitgerold. Sommige auditors laten je rapporten rechtstreeks verifiëren. Een pdf die alleen in de kanalen van het project bestaat, is niet genoeg.
Wat betekenen de ernstniveaus in een audit?
Auditors delen bevindingen meestal in als kritiek, hoog, gemiddeld, laag en informatief. Kritieke en hoge problemen kunnen leiden tot verlies van geld of een kapot protocol. Het belangrijkste is of die ernstige bevindingen zijn opgelost en of de auditor de oplossing in een vervolgbeoordeling heeft bevestigd.
Is één audit genoeg?
Voor grote protocollen die aanzienlijke gebruikersgelden beheren, geldt één audit vaak als minimum. Meerdere onafhankelijke audits, een openbaar bugbountyprogramma, formele verificatie van kerncomponenten en een lange staat van dienst zonder incidenten leveren samen veel sterker bewijs dan één los rapport.