Åpen kildekode utgjør i dag en stor del av all kode brukt både profesjonelt og privat. Hovedtankene bak åpen kildekode er at åpent tilgjengelig kode vil kunne gagne flest mulig, og potensielt utvikle seg bedre og raskere enn om man hadde drevet utvikling i et lukket miljø. I populære prosjekt som Linux fungerer det veldig bra, og er en av grunnene til at det er brukt så mye i dag. Men i mindre prosjekter som ikke har like mange bidragsytere går man glipp av mange av fordelene som man i teorien skal få av åpen kildekode, og man kan ende opp med en situasjon som vist i figuren til høyre. I øyeblikket det oppdages en sårbarhet i det lille prosjektet, vil ansvaret for å minske trusselen til programmet falle på den som bruker programmet. Se heartbleed for et eksempel!
Dependency-check
OWASP (Open Web Application Security Project) har identifisert problemer rundt tredjepartsbiblioteker som et av de 10 største problemene innen web-applikasjon-design. Som et “shift-left” tiltak for å håndtere tredjepartsbiblioteker, har OWASP lansert verktøyet dependency-check. Dependency-check er et SAST (Static Application Security Testing)-verktøy som består av fire deler: en gruppe scannere som henter ut hvilke tredjepartsbiblioteker som blir brukt i prosjektet, en analysemodul som kobler sårbarheter til biblioteker, en rapportmodul som presenterer funn på en måte som skal være lett for mennesker å forstå, og en modul som samler de andre modulene i ett program. Hver scanner har sitt eget anvarsområde, for eksempel er det en scanner som leter etter en fil ved navn requirements.txt for python prosjekter, mens en annen leter etter en fil ved navn package.config for C#-prosjekter.
Grunnleggende om bruk
Programmet forutsetter tilgang til kildekode. Dependency-check kommer i flere former, blant annet som en plugin til enkelte CI-verktøy og som et CLI-verktøy (som er det jeg har undersøkt). I tillegg til offisielt dokumenterte versjoner finnes også en uoffisiell “action” til github actions. Dokumentasjonen anbefaler å laste ned den siste stabile utgivelsen fra github-repoet, for å så verifisere den ved hjelp av gpg.
De fleste bestanddelene av dependency-check er skrevet i java, men for *nix-systemer er programmet samlet i et shell-skript som du må manuelt legge til i “path” for å kunne bruke applikasjonen uten å måtte referere til installasjonsplasseringen når den brukes. Dette gir programmet et litt “uferdig” preg.
Rapportgjennomgang
Nedenfor er utdrag av rapport generert av å skanne OpenPLC, som er et rammeverk for styring av mikrokontrollere. PLC (eller programmerbar logisk styring på norsk) er mikrokontrollere typisk anvendt i en industriell kontekst for styring av tidskritiske prosesser i krevende miljø. Gjennom en rask skanning av prosjektet med alle skannere aktivert danner dependency-check en provisorisk oversikt over programvare som er brukt. En rask kikk på figuren under viser at mengden falske positiver, dvs. filer identifisert som biblioteker uten å være det er ganske høy.
Dependency-check fant en alvorlig sårbarhet i biblioteket libmodbus. Sårbarheten ble fikset i 2019, men openPLC bruker en versjon fra 2018. Dette ble oppdaget med minimal innsats fra vår side, uten å ha satt oss grundig inn i prosjektet.
Svakheter og fordeler
Dependency-check burde ikke være det eneste du bruker når det gjelder å håndtere tredjepartsbiblioteker.
Enkelte biblioteker har ikke en CPE (Common Product Enumeration) assosiert med seg, og dermed vil ikke sårbarheter funnet kunne kobles til biblioteket i offentlige sårbarhetsdatabaser som brukes av dependency-check, NIST NVD. I OpenPLC har verken bibliotekene asio eller matiec en CPE, og de er begge utdaterte versjoner.
I tillegg til at ikke alle biblioteker er registrert i offentlige databaser, er dependency-check i stor grad avhengig av hvilket rammeverk man bruker for å holde styr på biblioteker. For eksempel finnes Maven og gradle for java, og dersom du mot formodning ikke skulle bruke noen av disse vil dependency check ikke kunne hente ut hvilke java-biblioteker som brukes i prosjektet.
En annen svakhet med dependency-check er at den ikke henter ut bibliotekene som brukes inne i andre biblioteker. Dette kan være med på å gi en falsk trygghet til brukeren av dependency-check.
På den annen side, å senke terskelen for å begynne å holde styr på tredjepartsbiblioteker er definitivt bra. Som sagt av G. K. Chesterton, skaperen av “Father Brown”: “Anything worth doing is worth doing badly.” Om det er et bruksområde som dependency-check ikke utfyller for deg, er det mulig å lage en egen plugin. Dokumentasjonen beskriver utfyllende hvordan programmet er bygget opp, og er designet med tanke på å gjøre det så enkelt som mulig å utvide selv. For eksempel finnes det som nevnt ikke en offisiell såkalt action til bruk i CI-løsningen til github, men det finnes noen i open-source miljøet som har laget det på eget initiativ.
Alternativer
Selv om at det å bruke et SAST-verktøy for å holde styr på tredjepartsbiblioteker er greit for å danne seg et grovt overblikk, må man i lengden ha et mer robust system for å håndtere tredjepartsbiblioteker. På tampen skal vi nevne et par eksempler.
SBOM
Å bevisstgjøre seg på hvilke biblioteker man tar i bruk er en fremtidssikker måte å bedrive utvikling på, og man kan håpe at programvare som brukes i offentlig kontekst vil være pålagt å lage en nøyaktig “ingrediensliste” i form av en SBOM (Software Bill Of Materials). Hvis alle som publiserer biblioteker også benytter seg av SBOM, vil man til slutt få et tre med biblioteker som er avhengige av hverandre som vil være mye lettere å skanne med verktøy. En standardisert løsning som dette vil med det første kanskje innebære mer arbeid for den som bruker det, i og med at man må legge til biblioteker manuelt i systemet. Til gjengjeld vil resultatet være mer nøyaktig og vil bidra til å minimere risiko som publiserte sårbarheter utgjør i programmet ditt.
Dependency-track
Det finnes allerede løsninger som baserer seg på en SBOM i stedet for å skanne kildekode. Et eksempel på et slikt verktøy er Dependency-Track, også under OWASP utvikling. Dependency-Track ser ikke bare på biblioteker, men støtter andre typer “komponenter” som maskinvare, rammeverk, operativsystemer. Ikke bare skannes det for sårbarheter i tredjepartsbiblioteker, brukere av programmet kan også definere “policies” for lisenstyper, en spesiell CPE eller hash som f.eks. forbyr bruk av programmer som bruker GPL, og kun tillater bruk av programmer som implementerer apache-lisensen.
Artikkelen er skrevet som en del av sommerjobb i SINTEF i regi av SFI NORCICS
Illustrasjon ved Randall Munroe, CC BY-NC 2.5