Kodegenbrug udgør stadig et sikkerhedsmareridt

På trods af mange bestræbelser på at spore softwareafhængigheder findes der stadig blinde vinkler, der fører til tavse sårbarheder i software.

Moderne softwareapplikationer er flettet sammen fra tusindvis af tredjepartskomponenter. Kodegenbrug har store fordele for softwareindustrien, hvilket reducerer udviklingstiden, omkostningerne og giver udviklere mulighed for at tilføje funktionalitet hurtigere, men det genererer også store sårbarhedsproblemer på grund af det komplekse system af afhængigheder, der ofte er svære at spore.

Sårbarheder arvet fra tredjepartskode har plaget applikationer i årevis, men i en tid med regeringssponsorerede forsyningskædeangreb er problemet mere relevant end nogensinde før. Analyseværktøjer kan hjælpe med at afdække nogle af risiciene, men de underliggende blindspots eksisterer stadig og gør det derfor svært for selv sikkerhedsbevidste udviklere at fange alle nedarvede fejl.

Afhængighedssporing

For at opdage alle sårbarheder skal udviklere ikke kun spore, hvilke komponenter de bruger i deres egne applikationer, men også de tredjepartsbiblioteker og pakker, som komponenterne er baseret på. Afhængighedskæderne kan gå mange lag dybt. En analyse udført i 2019 af forskere ved Darmstadt University fandt, at import af en JavaScript-pakke i gennemsnit introducerede tillid til 79 andre pakker fra 39 forskellige vedligeholdere. På det tidspunkt fandt forskerne også, at næsten 40 procent af pakkerne var afhængige af en kode med mindst en offentligt kendt sårbarhed.

Kun de afhængigheder, der vedrører pakker på samme lager, spores af pakkelagre og deres tilsvarende pakkehåndteringsværktøjer, men det er ikke den eneste måde tredjeparts kode gør det til projekter. Nogle udviklere linker statisk biblioteker eller kompilerer manuelt kode fra andre projekter, der bor uden for pakkelagre, og disse oplysninger er ikke nemme at finde med automatiserede scanningsværktøjer.

Identifikation af tavse sårbarheder

Men sporing af afhængigheder kan være endnu sværere end det. Tag tilfældet med zlib, et af de mest anvendte open source-datakomprimeringsbiblioteker, der oprindeligt blev skrevet i 1995. Dette bibliotek er blevet en næsten de-facto standard og leveres af dets vedligeholdere som kildekode. Det betyder, at udviklere har en tendens til at kompilere det selv og forbinde det statisk i deres projekter, ofte uden at nævne dets tilstedeværelse, da det er så allestedsnærværende.

Risici i forsyningskæden

Flere pakkelagre eksistere dette sårbare afhængighedsproblem og ønsket er at flere udviklere skal være opmærksomme på sikkerhedsproblemerne. Nogle platforme er dog mere proaktive end andre. GitHub scanner aktivt de offentlige kodelagre, der er vært på deres platform, analyserer deres afhængigheder og giver deres ejere besked, hvis der er kendte sårbarheder. Virksomheden opretholder en offentlig rådgivningsdatabase med kendte sårbarheder i npm (JavaScript), RubyGems (Ruby), NuGet (.NET), pip (Python), Maven (Java).

I sin 2020 Software Supply Chain Report bemærkede open source-styringsfirmaet Sonatype år-til-år vækst på 430% i antallet af næste generations angreb, hvor hackere forsøgte aktivt at injicere malware i open source-softwareprojekter i et forsøg på at forgifte yderligere projekter og applikationer højere op på deres afhængighedskæde. Traditionelle angreb hvor hackere udnytter kendte sårbarheder i open source-komponenter går hurtigere. Tiden til at udnytte viden er faldet med angribere, der udnytter nyopdagede sårbarheder inden for få dage efter deres offentliggørelse. I mellemtiden er halvdelen af virksomhederne over en uge om at lære om fejlene og en uge eller mere om at gennemføre afhjælpning.

Hackere er klart interesseret i at udnytte softwareforsyningskæden, men alligevel sidder tusindvis af softwarepakker med nedarvede sårbarheder stadig i offentlige depoter og tjener som fundamentblokke for virksomhedssoftware.