Nem ritkán tízmillió dolláros veszteségeket okoznak az okosszerződések (egy látványos esetről például itt írtunk). De nem csak a hekkertámadások jelentenek problémát, hanem az is, ha például hibásan kódolják egy szerződés pénzügyi feltételeit. Az okosszerződések fejlesztői közömbösek a kód biztonságával szemben, és gyakran nem is rendelkeznek megfelelő technikai erőforrásokkal, hogy ne silány minőségű kód kerüljön ki a kezük közül.
A kód nem okos, hangsúlyozza az a kutatás, melyet az Illinois Egyetemen készítettek (letölthető az arXiv-ról pdf-ben). Az okosság ugyanis a szoftverfejlesztőnél kezdődik. Egy átlagos szoftver kódjában 100 sorra kb. egy hiba jut. Mitől lenne jobb az arány egy okosszerződés kódjában?
Bár a szerződési forma egyelőre közel sem általános, 2021-ben 680 millió dollár értékű, okosszerződések által ellenőrzött digitális eszköz veszett el biztonsági rések miatt. A tanulmány szerzői ezért okosszerződés-fejlesztőkkel (szám szerint 29-cel a világ minden tájáról az USA-tól Ghánán át Új-Zélandig) készítettek interjúkat, hátha azokból fény derül az okosszerződések biztonsági hiányosságainak okaira.
A válaszokból kiderült: a fejlesztők több mint négyötödénél a biztonság nem prioritás. A leggyakrabban három magyarázat hangzott el. Gyorsan kell szállítani, és akkor az a lényeg, hogy működjön, és nem az, hogy biztonságos is legyen. A fejlesztők nem a nulláról építkeztek, hanem olyan népszerű projekteket forkoltak, amelyeket a fejlesztői közösség (elvileg) már ellenőrzött. És végül előkerült magyarázatként az is, hogy a biztonsági auditot valaki más végzi, ezért az ilyen kérdésekkel nem is foglalkoznak.
A fejlesztők többsége emiatt főleg a funkcionális korrektségre törekszik (ezt állította kétharmaduk), de felük az erőforrás-optimalizálást is prioritásként kezeli.
Hiányzik a megfelelő technikai háttér
Az interjúkból kiderült, hogy a fejlesztők közel harmada egyszerűen kézi módszerekkel próbálja keresni a biztonsági problémákat, míg másik harmaduk használ erre okosszerződésekhez készített speciális eszközöket. Igaz, azt is megjegyezték többen, hogy azokat nehéz használni. Az egyébként hamar kiderült, hogy a kézi vizsgálat mennyire lutri. Amikor a fejlesztőknek az interjú során egy mintakódban biztonsági hibát kellet azonosítaniuk, 16-an csak egy hibát találtak meg a kettőből, és csak 6-nak sikerült helyesen javítani. (Öten egyik hibát sem találták meg.)
Ha belépnek a képbe az auditorok, akik ellenőrzik a kódot biztonsági szempontból, a fejlesztők a jelzett hiányosságokat általában kézzel, támogató eszközök nélkül javítják – sokszor rosszul.
A fejlesztők közül többen megjegyezték, hogy az okosszerződéseknél leggyakrabban használt nyelv, a Solidity csak korlátozottan segíti a biztonságos kód létehozását. (A programozási nyelv pár éve még kitalálóját, Gavin Woodot is alaposan megtréfálta.) Mint a The Register megjegyzi a kutatásról készített összefoglalójában, már évek óta ismert, hogy emiatt az Ethereum blokkláncon futó okosszerződések sérülékenyek.
A jövőálló digitális megoldások sikere az üzleti értékteremtésben mérhető
Az informatikai fejlesztések gyakran technológiai kérdésként jelennek meg, pedig egy kódsor vagy digitális megoldás önmagában soha nem lehet végcél. A 4D Soft több mint 35 éve ennek szellemében fókuszál a projektek negyedik dimenziójára: az üzleti értékteremtésre.
a melléklet támogatója a Clico
A hibakeresés nem egyenlő az alkalmazásbiztonsággal
Építsünk olyan AppSec környezetet, amely csökkenti az alkalmazásfejlesztés kockázatait, de nem válik a gyors leszállítás akadályává!
CIO kutatás
Merre tart a vállalati IT és annak irányítója?
Hiánypótló nagykép a hazai nagyvállalati informatikáról és az IT-vezetőkről: skillek, felelősségek, feladatkörök a múltban, a jelenben és a jövőben.
Töltse ki Ön is, hogy tisztábban lássa, hogyan építse vállalata IT-ját és saját karrierjét!
Az eredményeket május 8-án ismertetjük a 17. CIO Hungary konferencián.
Projektek O-gyűrűje. Mit tanulhat egy projektvezető a Challenger tragédiájából?