Svært mye programvare inneholder utdaterte åpen kildekode-komponenter

Det er sjelden god bruk av tid å finne opp hjulet på nytt. Derfor bruker de fleste programvareutviklere i stor utstrekning kodekomponenter som andre allerede har laget.

Det er flere fordeler med dette, i tillegg til tidsbesparelsen. Slike komponenter er ofte skrevet av personer eller grupper med spesiell kompetanse innen akkurat den funksjonaliteten komponenten tilby. I tillegg gjør det at mange bruker den samme komponenten, det mer sannsynlig at feil og sårbarheter blir oppdaget og rettet. Ofte er komponentene utgitt som åpen kildekode, noe som gjør at mange har mulighet til finne og rette feil i koden.

En forutsetning for at dette skal gå bra, er at komponenten vedlikeholdes aktivt, og at programvareutviklerne som bruker den, tar i bruk de oppdaterte versjonene i oppdateringer til sin egen programvare.

Dobling i bruken

Slik er det dessverre ikke alltid.

Synopsis Cybersecurity Research Center har gått gjennom resultatene av revisjoner datterselskapet Black Duck Software har gjort på 1253 kommersielle kodebaser.

98,8 prosent av kodebasene som har blitt revidert det siste året, inneholder minst én åpen kildekode-komponent. I gjennomsnitt inneholdt kodebasene 445 åpen kildekode-komponenter, noe som i snitt utgjorde så mye som 70 prosent av koden i kodebasene. I en tilsvarende undersøkelse gjort i 2015 var andelen bare på 36 prosent.

Mange sårbarheter

I hele 88 prosent av kodebasene ble det funnet komponenter fra prosjekter som ikke har hatt noen aktivitet på minst to år. I 82 prosent av kodebasene var det komponenter som har blitt ansett som utdaterte i mer enn fire år.

Iblant blir det funnet sårbarheter i slike komponenter, uavhengig av om prosjekter er forlatt eller fortsatt er aktive. Men det er bare i aktive prosjekter at sårbarheter blir fjernet.

Resultatet av dette er at Black Duck fant sårbare tredjepartskomponenter i 75 prosent av kodebasene. 49 prosent av kodebasene inneholdt komponenter med sårbarheter som blir betegnet som høyrisiko. I gjennomsnitt har sårbarhetene som ble identifisert, vært kjent i 4,5 år. Den eldste sårbarheten som ble funnet i komponenter i kodebasene, har vært kjent siden 1999.

Når en kodebase først var sårbar på grunn av utdaterte komponenter, så var det dessuten sjelden at det bare ble funnet én sårbarhet. I gjennomsnitt ble det identifisert 82 kjente sårbarheter i hver kodebase.

Gammel JQuery

Mye av programvaren Black Duck Software har revidert, er webapplikasjoner. Hele 37 prosent av kodebasene benyttet versjoner av JQuery som er gamle nok til å inneholde en sårbarheter som ble beskrevet allerede i 2014 (BDSA-2014-0063), og som skal ha blitt fjernet med JQuery 3.0, som kom i 2016.

De mest benyttede åpen kildekode-komponentene i kodebasene var JQuery (55 prosent), Bootstrap (40 prosent), Font Awesome (31 prosent), Lodash (30 prosent) og JQuery UI (29 prosent).

De mest brukte programmeringsspråkene var JavaScript (74 prosent), C++ (57 prosent), Shell script (54 prosent), C (50 prosent) og Python (46 prosent).

Omfattende lisensbrudd

Selv om kildekoden er åpen, er det ikke nødvendigvis slik at det er fritt fram å bruke den. Det avhenger av lisensen, som brukerne er forpliktet til å følge. I revisjonene til Black Duck ble det funnet mange lisensbrudd. Hele 73 prosent av kodebasene inneholdt komponenter med lisenskonflikter eller ingen lisens i det hele tatt. Uten at en lisens eller avtale spesifikt tillater det, er det i mange land brudd på opphavsretten å bruke, kopiere, endre eller distribuere andres arbeid.

Hele 93 prosent av kodebasene til internett- og mobilapper som Black Duck har revidert, hadde lisenskonflikter.

Ta i bruk en materialfortegnelse

For å unngå både utdaterte komponenter og lisenskonflikter, mener Synopsis at det er nødvendig for utviklerteam å etablere og vedlikeholde en materialfortegnelse for programvaren.

I denne bør det blant annet være beskrevet hvilke tredjepartskomponenter som er brukt, hva slags lisens de er utgitt under, hvilken versjon som er brukt, om dette er den mest stabile versjonen tilgjengelig, om det er sikreste versjonen tilgjengelig, om komponenten aktivt vedlikeholdes, hvor den er lastet ned fra, samt hvilke biblioteker komponenten selv avhenger av.

I mindre prosjekter kan dette være en overkommelig oppgave å gjøre manuelt, men for at det ikke skal gå med for mye tid, anbefaler Gartner at det fortegnelsen genereres av et SCA-verktøy (Software Composition Analysis) i stedet.