Spåra sårbarheter i tredjepartsbibliotek

Log4Shell är kodnamnet för en kritisk sårbarhet som strax innan nyår 2021 satte hela internet i brand. Formellt betecknades det CVE-2021-44228 och var ett säkerhetshål i Apache Log4j2, en populär komponent som miljontals applikationer och webbsidor över hela världen är beroende av.

A focused woman is seen working diligently on her laptop computer in a neat and organized office cubicle, View of a busy corporate office with people working on computers, AI Generated

Inom bara ett dygn delades fler än 60 olika verktyg för hackare som utnyttjar säkerhetshålet i sårbara program. Under flera månader utspelades en vild katt-och-råtta-lek där företag av alla storlekar sökte igenom sin kod för att hitta de program där Log4j2 användes. Idag, mer än två år senare dyker CVE-2021-44228 fortfarande upp i statistiken då och då. Sedan sårbarheten publicerades har flera sårbarheter i populära komponenter följt rad och gett upphov till nyheter i massmedia. Vi är till synes sårbara utom vår kontroll.

Sårbarhet i försörjningskedjan

En sårbarhet i försörjningskedjan, en så kallad supply chain vulnerability, är en sårbarhet vi ärver via komponenter från tredje part som våra system beror på. Det är alltså inte den kod vi skrivit själva som har ett säkerhetshål.

De senaste decenniernas innovationstakt är fundamentalt grundad på att utvecklare och företag världen runt delar information och kod med varandra. Vår värld hade inte fungerat utan tillgången till delade programbibliotek, men CVE-2021-44228 belyste hur vi nu har öppnat upp en stor risk när vi förlitar oss på en löst sammanflätad försörjningskedja.

Hetsen som följde kring att identifiera var CVE-2021-44228 fanns inkluderad visade också hur branschens bristande insikt i våra system kraftigt minskade förmågan att åtgärda en så djupgående sårbarhet.

Åtgärda sårbarheter i försörjningskedjan

Hur kan vi då åtgärda en sårbarhet i försörjningskedjan? Vi kan vänta på en uppdatering från personen, företaget, eller projektet som ligger bakom komponenten. Den väntan kan bli lång, särskilt om koden vi beror på är ett hobbyprojekt eller skapats av ett enmansföretag. Vi kan försöka jobba runt sårbarheten genom att skriva defensiv kod runt den felaktiga komponenten. Det är i vissa fall omständligt och negerar åtminstone en del av nyttan med delade bibliotek. Om föregående alternativ visar sig fruktlösa måste vi försöka byta ut den felande komponenten, men då ställs vi inför problemet att hitta en kompatibel komponent eller skriva en egen. Åtgärden kan alltså bli långdragen och kostsam.

Åtgärda säkerhetsrisker som inte syns

Men hur kan vi avhjälpa ett fel vi inte ser? Vi behöver kunna agera snabbt för hinna åtgärda en ny sårbarhet innan den utnyttjas. Det kräver att vi på kort tid kan få till oss informationen om nya sårbarheter såväl som att vi skyndsamt kan sätta in åtgärder där de behövs.

Software Composition Analysis (SCA) är en metod för att automatiskt hitta beroenden i applikationer och analysera dem. Den ger oss inblick, inte bara i vilka komponenter som används, utan även om det finns nyare versioner, om det finns publicerade sårbarheter och vilka licenser som används. Nästintill omedelbart kan vi med SCA identifiera var i vår teknologistack en viss sårbarhet från tredje part gömmer sig!

Processen

Processen består vanligtvis av två steg. Först skapas en materialförteckning, en så kallad Software Bill-of-Materials (SBOM), oftast med hjälp av ett speciellt stödprogram. En server tar sedan in SBOM-filen och analyserar den. Varje gång en ny sårbarhet publiceras kan verktyget kontrollera om och var just våra applikationer är sårbara. En fördel vi får på köpet är att vi nu kan visa upp vår materialförteckning för våra kunder, be om motsvarande från våra leverantörer, möta säkerhetstekniska efterlevnadskrav, samt ges inblick i hela vårt ekosystem av IT-tjänster.

Det finns flera stora kommersiella alternativ, men för den som vill komma i gång snabbt och enkelt finns OWASP Dependency Track, ett Open Source SCA-verktyg från Open Worldwide Application Security Project. Dependency Track tar in SBOM-filer som den kontinuerligt analyserar för att varna när uppgifter om en sårbarhet publiceras. Servern uppdaterar rullande databasen över sårbarheter från publika källor för att vi ska vara säkra på att få informationen i tid för att vidta åtgärd. Dependency Track kan till och med skicka notiser när nya sårbarheter upptäcks, via Slack, Microsoft Teams, eller via e-post, för att nämna några.

Sammanfattning

Komponenter från tredje part är väsentliga. De möjliggör innovation och nytta i våra moderna system. De skapar värde, men medför risk. Redan idag kan ni själva få den insyn som är nödvändig för att stärka försörjningskedjan i era system. Använd Software Composition Analysis. Det första steget till en säkrare framtid är vetskapen om era sårbarheter.