Masser af software indeholder sårbar og forældet open souce-kode

Illustration: Bigstock
Sikkerhedsfirma fandt hul fra 1999 i kundens kode samt mange licenskonflikter.

Det er sjældent godt at bruge tid på at opfinde hjulet igen. Derfor bruger de fleste softwareudviklere i vid udstrækning kodekomponenter, som andre allerede har skabt.

Det er der flere fordele ved, ud over tidsbesparelsen. Sådanne komponenter er ofte skrevet af personer eller grupper med nøjagtig særlig ekspertise i komponentens funktionalitet. Når mange mennesker derudover bruger den samme komponent, er der mere sandsynligt, at fejl og sårbarheder bliver opdaget og rettet. Ofte frigives komponenterne som open source, hvilket gør det muligt at mange kan finde og rette kodefejl.

En forudsætning for at dette kan fungere er, at komponenten vedligeholdes aktivt, og at softwareudviklerne, der bruger den, tageer de opdaterede versioner i brug i opdateringer til deres egen software.

Fordobling i anvendelse

Desværre er det ikke altid tilfældet.

Synopsis Cybersecurity Research Center har gennemgået resultaterne af de revisioner, som datterselskabet Black Duck Software har foretaget på 1253 kommercielle kodebaser.

98,8 procent af kodebaser, der er gennemgået i løbet af det forløbne år, indeholder mindst én open source-komponent. I gennemsnit indeholdt kodebaserne 445 open source-komponenter, som i gennemsnit var op til 70 procent af koden. I en lignende undersøgelse udført i 2015 var andelen kun på 36 procent.

Mange sårbarheder

I 88 procent af kodebaserne blev komponenter fundet fra projekter, der ikke har haft nogen aktivitet i mindst to år. I 82 procent af kodebaserne var der komponenter, der blev betragtet som værende forældede i mere end fire år.

Lejlighedsvis findes sårbarheder i sådanne komponenter, uanset om projekterne er forladt eller stadig aktive. Men det er kun i aktive projekter, at sårbarheder fjernes.

Som et resultat fandt Black Duck sårbare tredjepartskomponenter i 75 procent af kodebaserne. 49 procent indeholdt komponenter med sårbarheder betegnet som høj risiko. I gennemsnit har de identificerede sårbarheder været kendt i 4,5 år. Den ældste sårbarhed, der findes i kodebasekomponenter, er kendt siden 1999.

Når en kodebase først var sårbar på grund af forældede komponenter, var det sjældent, at kun én sårbarhed blev fundet. I gennemsnit blev 82 kendte sårbarheder identificeret i hver kodebase.

Gammel JQuery

Meget af softwaren, Black Duck Software har undersøgt, er webapplikationer. Så mange som 37 procent af kodebaserne brugte versioner af JQuery, der er gamle nok til at indeholde sårbarheder, der allerede blev beskrevet i 2014 (BDSA-2014-0063), og som burde have været fjernet med JQuery 3.0, som kom i 2016.

De mest udbredte open source-komponenter i kodebaserne var JQuery (55 procent), Bootstrap (40 procent), Font Awesome (31 procent), Lodash (30 procent) og JQuery UI (29 procent).

De mest almindeligt anvendte programmeringssprog var Javascript (74 procent), C ++ (57 procent), Shell-script (54 procent), C (50 procent) og Python (46 procent).

Omfattende licensbrud

Selvom kildekoden er åben, er det ikke nødvendigvis gratis at bruge den. Det afhænger af licensen, som brugerne er forpligtet til at følge. I revisionerne af Black Duck blev der fundet mange licensovertrædelser. Så mange som 73 procent af kodebaserne indeholdt komponenter med licenskonflikter eller slet ingen licens. Uden en licens eller aftale, der specifikt tillader det, er det i mange lande et brud på ophavsretten at anvende, kopiere, ændre eller distribueres andres arbejder.

Så mange som 93 procent af kodebasen for internet- og mobilapps, som Black Duck har undersøgt, havde licenskonflikter.

Brug en materialeopgørelse

For at undgå forældede komponenter og licenskonflikter mener Synopsis, at det er nødvendigt for et udviklerteam at etablere og vedligeholde en materialeopgørelse til softwaren.

Denne skal blandt andet beskrive, hvilke tredjepartskomponenter der bruges, hvilken type licens de er udstedt under, hvilken version der bruges, om dette er den mest stabile version der er tilgængelig, om den sikreste version er tilgængelig, om komponenten er aktivt vedligeholdt, hvor den downloades fra, samt hvilke biblioteker komponenten selv afhænger af.

I mindre projekter kan dette være en overkommelig opgave at udføre manuelt, men for ikke at spilde for meget tid anbefaler Gartner, at fortegnelsen genereres af et SCA (Software Composition Analyse) værktøj i stedet.

Denne artikel stammer fra Digi.no.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

Der bruges også masser af closed-source komponenter i software, og mange af disse bliver ikke eller kun i ringe grad opdateret. Og så er man på herrens mark, for et er svært at opdate sårbarheder og endnu sværere at rette dem. Med open source kan man trods alt selv gå ind og rette sårbarhederne, selv om modulet ikke aktivt vedligeholdes af andre.

  • 13
  • 3
#2 Sune Marcher

Der bruges også masser af closed-source komponenter i software, og mange af disse bliver ikke eller kun i ringe grad opdateret.

Måske fordi folk har en tendens til at smide libraries ind fra højre og venstre, når de ikke skal have pengepungen op, uden at være kritiske i forhold til kodekalitet, support/vedligehold og licenser?

Det er naturligvis ikke et problem med opensource i sig selv, det er sløsede udviklere der har ansvaret – men det kan give enddog store problemer, så pointen med noget automatik til at holde styr på versioner og licenser er ret god.

Det er ikke særligt sjovt at være ham der skal fortælle kunden at man har overset at projektet bruger en licenspligtig version af iText, fordi en anden udvikler missede at den var transitiv dependency under to-tre lags MIT-licenseret kode :)

  • 5
  • 0
#4 Nis Schmidt

Skal open source gemmes væk, når udviklerne ikke længere vedligeholder den?

Eller bør al kode (ligesom mit første javeprojekt i 2004) leveredes med indlejret test, som udføres hver gang programmet startes.

Test Driven Delevopment, TDD, (test drevet udvilking) er en hurtigere og sjovere måde at skrive kode på.

Havde drømt om at bruge TDD siden 1989, men der var ikke tid før - eller rettere: der var ikke tid til andet i 2004, hvor 2 dage før deadline på kurset, besluttede mig for at vende tilbage til første udkast og gøre det færdigt. Sidste rettelse 10 minutter før deadline.

  • 0
  • 2
Log ind eller Opret konto for at kommentere