Älysopimuksen auditointi: mitä tarkastus kertoo ja mitä se ei lupaa?

Älysopimuksen auditointi kertoo, että joku on tarkastanut tiettyä koodia tietyssä laajuudessa. Se ei yksin osoita, että käyttämäsi sopimus on sama kuin tarkastettu versio tai että koodi olisi virheetöntä. Aloita siis raportista, älä projektin etusivun auditointimerkistä.

Tarkista ainakin tarkastuksen kohde, koodiversio, havaitut ongelmat ja niiden käsittely. Jos jokin näistä jää epäselväksi, auditointia on vaikea käyttää päätöksen tukena. Ethereum.orgin mukaan käsin tehty tarkastus voi löytää tapauksia, joita automaattinen työkalu ei huomaa, mutta myös ihmistarkastaja voi ohittaa virheitä.16

Mikä auditointi oikeastaan on?

Älysopimus on ohjelmakoodia, jonka toimintaa käytetään lohkoketjussa. Auditoinnissa ulkopuolinen tarkastaja tutkii sovittua kokonaisuutta ja etsii muun muassa mahdollisia haavoittuvuuksia. Raportti kuvaa työn tuloksia, mutta sen todistusarvo riippuu siitä, mitä oli mukana ja millä oletuksilla työtä tehtiin.

Ethereum.org kuvaa auditoinnin sisältävän tavallisesti testausta ja koodin manuaalista tarkastelua; muodollinen verifiointi voi olla mukana, mutta se ei ole automaattisesti osa jokaista auditointia.16 Älä siis oleta pelkän sanan perusteella, mitä menetelmiä raportissa käytettiin. Tarkista se raportin omasta menetelmäosiosta.

Auditointia kannattaa verrata rajattuun tarkastukseen, ei vakuutustodistukseen. Tarkastus voi lisätä tietoa ja nostaa esiin korjattavia kohtia. Sen perusteella ei kuitenkaan voi päätellä, että kaikki mahdolliset virheet on löydetty tai että kaikki muut projektin osat kuuluisivat tarkastukseen.

Aloita raportin rajauksesta

Etsi raportista kohta, jossa kuvataan tarkastuksen laajuus eli scope. Siinä voidaan yksilöidä esimerkiksi koodivarasto, sopimustiedostot tai toiminnot, joita tarkastaja sai tutkittavakseen. Vertaa luetteloa siihen toimintaan, jota olet itse käyttämässä.

Jos raportti koskee vain yhtä sopimusta, sen ulkopuolelle voi jäädä muu järjestelmän koodi. Samoin raportin yleisnimi voi olla laajempi kuin varsinainen tarkastus. Hanke voi käyttää useita osia, vaikka tarkastuksessa mainitaan vain rajattu osa niistä. Pelkkä projektin nimen vastaavuus ei siten riitä.

Käytännössä voit kysyä itseltäsi:

• Mitkä sopimukset tai tiedostot raportissa on nimetty?
• Kuuluuko käyttämäni toiminto tähän joukkoon?
• Mitä raportti nimenomaisesti jättää tarkastamatta?
• Onko tarkastusraportti saatavilla kokonaisuudessaan vai vain markkinointiväite?

Jos raportti ei ole julkinen, älä täytä puuttuvia kohtia oletuksilla. Voit pyytää hankkeelta lisätietoa, mutta ilman raporttia ulkopuolisen on vaikeampi arvioida tarkastuksen sisältöä.

Vastaako versio käytössä olevaa koodia?

Tarkastettu koodi on tunnistettava mahdollisimman täsmällisesti. Raportissa voi olla esimerkiksi koodivaraston commit-tunniste, joka yksilöi tarkastettavan version. Vertailussa tarvitaan lisäksi tieto siitä, mikä versio vastaa juuri käyttämääsi käyttöön otettua sopimusta ja osoitetta kyseisessä verkossa.

Tämä on usein vaikein kohta tavalliselle käyttäjälle. Projektin raporttilinkki, koodivarasto ja lohkoketjussa käytössä oleva osoite voivat olla eri paikoissa. Jos niiden välille ei löydy luotettavaa yhteyttä, johtopäätös ei ole automaattisesti, että hanke on huijaus. Oikea johtopäätös on rajatumpi: raportin soveltuvuutta käytössä olevaan koodiin ei ole pystytty varmistamaan.

Päivämäärä auttaa hahmottamaan järjestystä mutta ei yksin osoita koodien vastaavuutta. Vanha raportti voi koskea edelleen käytössä olevaa versiota, ja tuore raportti voi koskea eri versiota. Vertaa tunnisteita ja kuvauksia sen sijaan, että arvioisit asiaa vain raportin iän perusteella.

Miksi päivitykset muuttavat johtopäätöstä?

Jotkin sopimusjärjestelmät ovat päivitettävissä. Ethereum.org huomauttaa, että sopimuksen päivittäminen voi olla monimutkaista ja tuoda virheitä, jos se tehdään väärin.16 Tarkastuksen jälkeen tehty muutos ei automaattisesti kuulu aiemman raportin piiriin.

Selvitä, osoittaako dokumentaatio myöhempiin muutoksiin ja mahdollisiin lisätarkastuksiin. Jos järjestelmässä on erillinen päivitystä hallitseva osa, sen rooli on hyvä tunnistaa: kysymys ei ole vain siitä, miltä koodi näytti tarkastuspäivänä, vaan myös siitä, voiko käytössä oleva toteutus muuttua.

Älä kuitenkaan päättele, että jokainen muutos olisi vaarallinen tai että jokainen päivittämätön sopimus olisi turvallinen. Vertailun tarkoitus on ymmärtää, mihin versioon tarkastajan havainnot liittyvät. Jos tätä yhteyttä ei pysty todentamaan, raportti jää rajalliseksi näyttöaineistoksi.

Mitä löydöksille tapahtui?

Lue havaintoluettelo sen sijaan, että etsisit vain loppupäätelmän. Raportti voi kuvata ongelman, sen vakavuuden, mahdolliset seuraukset ja projektin vastauksen. Olennaista on erottaa ilmoitettu korjaus tarkastajan myöhemmin vahvistamasta korjauksesta.

Merkintä korjatusta ongelmasta kannattaa liittää siihen versioon, jossa korjauksen väitetään olevan. Tarkista myös, kertooko raportti uuden version uudelleentarkastuksesta vai ainoastaan kehittäjän ilmoittamasta muutoksesta. Nämä ovat erilaisia todisteita. Jos havainto on hyväksytty riskinä tai jätetty avoimeksi, katso mitä se käytännössä koskee.

Vakavuusluokitus on tarkastajan tapa jäsentää havaintoja, ei lupaus siitä, miten jokin yksittäinen tilanne toteutuu. Vaikka raportissa ei olisi vakavimpaan luokkaan merkittyjä löydöksiä, rajauksen ulkopuoliset osat ja tarkastuksessa huomaamatta jääneet virheet ovat eri kysymyksiä.

Hypoteettinen esimerkki: kaksi samannimistä versiota

Kuvitellaan palvelu, joka kertoo etusivullaan älysopimuksensa olevan auditoitu. Linkitetty raportti koskee sopimuksen alkuperäistä versiota. Palvelun dokumentaatiossa näkyy myöhemmin käyttöön otettu uusi toteutus, mutta yhteyttä raporttiin ei avata.

Tässä tilanteessa raportti voi kertoa paljon alkuperäisen version tarkastuksesta. Se ei sellaisenaan kerro, että uusi toteutus olisi tarkastettu samassa laajuudessa. Tarkista, löytyykö uudelle versiolle erillinen raportti tai lisäselvitys ja onko uudessa raportissa käsitelty muutetut osat.

Jos hankkeen vastaus on vain mainoslause, säilytä epävarmuus. Älä myöskään päättele raportin sisällöstä sellaista, mitä siinä ei sanota. Esimerkki on kuvitteellinen eikä kuvaa tiettyä palvelua tai tehtyä auditointia.

Kuka tarkasti ja miten?

Raportissa pitäisi näkyä, kuka työn teki, milloin ja mitä menetelmiä käytettiin. Tarkastajan nimi on hyödyllinen lähtökohta, mutta nimen tunnettuus ei korvaa sisällön lukemista. Jos raportti näyttää kopiolta tai linkki vie vain logoon, etsi alkuperäinen julkaisu tarkastajan omasta kanavasta.

Manuaalinen tarkastus ja automaattiset testit voivat täydentää toisiaan. Ethereum.org erottaa nämä menetelmät ja toteaa, että niillä on erilaisia hyötyjä ja rajoituksia.16 Raportista voi siksi etsiä sekä menetelmän että siihen liittyvät rajaukset. Tarkastukseen käytetty menetelmä ei silti poista tarvetta selvittää, mitä koodia tutkittiin.

Jos et osaa arvioida teknistä yksityiskohtaa itse, voit pyytää apua riippumattomalta asiantuntijalta. Tässäkin kysymys kannattaa rajata: vastaavatko raportin tunnisteet käyttöönotettua sopimusta ja mitä avoimet havainnot tarkoittavat? Yleinen kysymys turvallisuudesta voi tuottaa liian yleisen vastauksen.

Raportin lukeminen käytännössä

Tarkastelun voi tehdä vaiheittain, vaikka et ymmärtäisi jokaista teknistä havaintoa. Avaa ensin raportin alku ja etsi sen tilaaja, tarkastaja, päivämäärät ja kohteen kuvaus. Katso sitten rajaus: liittyvätkö siinä mainitut tiedostot tai sopimukset niihin toimintoihin, joista palvelu kertoo? Kirjaa epäselvät kohdat ylös sen sijaan, että tulkitsisit ne hiljaiseksi hyväksynnäksi.

Siirry sen jälkeen havaintoihin. Erota, mitkä ongelmat ovat raportin mukaan avoimia, mitkä kehittäjä ilmoittaa korjanneensa ja mitkä tarkastaja kertoo tarkistaneensa uudelleen. Nämä tiedot voivat olla eri kohdissa raporttia. Jos löydöksen tekninen seuraus jää epäselväksi, sen vakavuutta ei kannata arvioida yksin otsikon tai värimerkinnän perusteella.

Viimeiseksi vertaa raportin tunnisteita hankkeen nykyisiin tietoihin. Jos dokumentaatiossa on useita sopimusosoitteita tai versioita, tarkista, mitä niistä aiot käyttää. Jos verkko tai osoite puuttuu, kysy lisätietoa suoraan hankkeen virallisen yhteyskanavan kautta. Sopimusosoitteen kopioiminen pelkästä mainoksesta ei vielä osoita yhteyttä tarkastettuun versioon.

Testaus, tarkastus ja muut arviot

Testi ja auditointi vastaavat osin eri kysymyksiin. Yksikkötesti tarkastelee Ethereum.orgin mukaan erillisiä sopimustoimintoja, kun taas auditoinnissa voidaan yhdistää testausta ja manuaalista koodin tarkastusta.16 Testin läpäisemisestä ei siis yksin seuraa, että kaikki käyttötapaukset olisi selvitetty. Vastaavasti auditointiraportin olemassaolo ei kerro kaikkien testien sisällöstä.

Raportissa saatetaan kuvata myös oletuksia järjestelmän toiminnasta. Ne ovat tärkeitä, koska arvio koskee kirjoitettua tarkastuskohdetta ja raportissa esitettyjä lähtökohtia. Jos jokin käytännön toteutus tai riippuvuus poikkeaa oletetusta, kysy, muuttaako se raportin sovellettavuutta. Vastaus voi vaatia teknistä asiantuntemusta; sitä ei pidä keksiä markkinointitekstin perusteella.

Voit tehdä myös yksinkertaisen päätöksen tiedon laadusta. Jos raportti on saatavilla, kohde yksilöity ja löydökset selitetty, sinulla on aineistoa lisäkysymyksiin. Jos taas vain logo on näkyvissä eikä raporttia tai koodiversiota löydy, varsinaista tarkastuksen laajuutta ei voi arvioida. Kumpikaan havainto ei yksin anna varmuutta lopputuloksesta.

Lopullinen tarkistus ennen johtopäätöstä

Jos raportissa viitataan erilliseen korjausraporttiin, avaa myös se ja varmista, mitä alkuperäisiä havaintoja siinä käsitellään. Sama asiakirja ei välttämättä vastaa kaikkiin kysymyksiin. Säilytä raportin linkki ja tunnistetiedot myöhempää vertailua varten, sillä palvelun dokumentaatio voi muuttua. Jos et saa vastausta siihen, mikä sopimus on käytössä ja kattaako raportti sen, voit jättää johtopäätöksen avoimeksi. Epävarmuus on silloin lukijalle olennaista tietoa.

Milloin raportti ei riitä?

Raportti ei yksin todista järjestelmän kaikkia ominaisuuksia, jos tarkastuksen kohde tai käytössä oleva versio jää epäselväksi. Se ei myöskään todista, että tarkastuksen ulkopuolinen koodi olisi käyty läpi. Puuttuva tieto voi johtua useasta syystä; lukijan ei tarvitse arvata niistä oikeaa.

Pidä siksi erillään kolme asiaa: tarkastuksen olemassaolo, raportin sisältö ja sen soveltuvuus juuri käytössä olevaan versioon. Vasta niiden yhdistelmä kertoo, miten paljon auditoinnista voi päätellä. Jos jokin lenkki puuttuu, käsittele auditointiväitettä vajavaisena tietona, älä turvallisuusleimana.