Sårbarheder i open source-komponenter - såsom de udbredte fejl, der blev afsløret for 10 måneder siden i Log4j 2.0 - har tvunget dataforskere til at revurdere den open source-kode, der ofte bruges i analyser og skabelsen af maskinlæringsmodeller.
Ifølge en rapport fra Anaconda, et datavidenskabsplatformfirma, har 40 % af de adspurgte dataforskere, forretningsanalytikere og studerende i det seneste år reduceret deres brug af open source-komponenter, mens en tredjedel forblev stabil, og kun 7 % inkorporerede mere åben kildekode i deres projekter. Størstedelen af de adspurgte rapporterer ikke til informationsteknologiafdelingen (18%), men arbejder inden for deres egen datavidenskabs- eller forsknings- og udviklingsgruppe (47%), ifølge Anacondas "2022 State of Data Science" rapport, udgivet i sidste uge.
Mens softwareudviklere og it allerede er begyndt at undersøge sikker kode, er bekymringerne over sikkerheden i open source-software en relativt ny trend for datavidenskabsverdenen, siger Peter Wang, medstifter og administrerende direktør for Anaconda.
"Vi ser en enorm del af mennesker, der er i organisationer, hvor it har skabt en meget stram holdning omkring open source og Python," siger han. "Dette er ikke ekspertudviklere. … De er datavidenskabsmænd og maskinlæringsfolk, som måske slet ikke er særlig erfarne udviklere, og som bruger alt, hvad de kunne downloade til at lave deres analyse, og så overdrog de det til IT.”
Sikkerheden af open source-komponenter - og softwareforsyningskæden generelt - er blevet en primær overvejelse blandt softwareudviklere, virksomheder og nationale regeringer i løbet af de sidste to år. I maj, for eksempel US National Institute of Standards and Technology (NIST) udstedt vejledning for at håndtere risici i softwareforsyningskæden. Hertil kommer et stigende antal softwareleverandører har sluttet sig til Linux Foundations Open Software Security Foundation (OpenSSF).
Samlet set er modenheden af organisationers sikkerhedsindsats blevet forbedret. Omkring halvdelen af virksomhederne har en open source-sikkerhedspolitik på plads, hvilket fører til bedre præstationer i forhold til sikkerhedsberedskab, ifølge juniundersøgelsen. Derudover er indsatsen for at kontrollere open source-risikoen steget med 51 % i de seneste 12 måneder, en undersøgelse af sikkerhedsmodenhed angivet den sept. 21.
"[Med opmærksomheden på softwareforsyningskæder tager de fleste virksomhedsorganisationer en risikobaseret tilgang til applikationssikkerhed," sagde Jason Schmitt, general manager for Synopsys Software Integrity Group, i en erklæring, der annoncerede undersøgelsen. "En sådan tilgang erkender, at sikkerheden ikke er begrænset til kodebasen; det inkluderer processen med softwareudvikling, hvor sikkerhedsgennemgange og test 'skifter overalt' for løbende at forbedre sikkerhedsresultater."
Udviklere udvider brugen af open source
Softwarevirksomheder ser ikke nogen form for fald i open source-brug, ifølge andre data. I stedet fokuserer udviklingsorganisationer på at forbedre sikkerheden i open source-software og bruge sikkerheden som en primær guide i valg af komponenter.
I "2021 State of the Software Supply Chain" rapport, for eksempel fandt Sonatype ud af, at de fire bedste open source-økosystemer - Maven Central Repository (Java), Node.js (JavaScript), Python Package Index (Python) og NuGet-galleriet (.NET) - husede 37 mio. open source-projekter og -komponenter, en stigning på 20% år-til-år. Efterspørgslen efter disse komponenter er ligeledes stigende: Mere end 2.2 billioner komponenter blev downloadet, en årlig stigning på 73 %.
Et selvrapporteret træk væk fra open source-pakker fra datavidenskabssamfundet er sandsynligvis et tegn på større bevidsthed om sikkerhedsproblemer og mindre om at kassere open source-komponenter under udvikling, siger Tracy Miranda, leder af open source hos Chainguard.
Mens datavidenskabsteams og udviklingsteams kan have reageret forskelligt på store sikkerhedsproblemer — såsom Log4j 2.0 — Virksomheder har kun få muligheder, når de bevæger sig væk fra én open source-pakke end at vedtage en anden pakke, hvis vedligeholdere har lagt større vægt på sikkerhed, siger hun.
"Virksomheder udnytter open source som en måde at øge deres hastighed på, så hvis de skalerer tilbage, hvad skaler de så tilbage til? Skrive kode internt? Bruger du tredjepartsversioner pakket sammen?" Miranda siger og tilføjer, at i stedet, "Jeg tror, vi kan forvente at se virksomheder være mere kræsne med hensyn til kvaliteten af den open source, de bruger, især relateret til sikkerhedsfunktioner."
Dataforskere spiller indhentning
Afbrydelsen mellem de to sider skyldes sandsynligvis de forskellige målgrupper i de forskellige undersøgelser. Anacondas undersøgelse fokuserede på fagfolk inden for datavidenskab, som det kan ses af deres respondents valg af programmeringssprog - 58 % brugte Python og 42 % brugte SQL, mens kun 26 % brugte JavaScript.
Et bedre mål for softwareudviklerens følelser er StackOverflows "Udviklerundersøgelse i 2022,” som fandt ud af, at mens 58% af 'folk, der lærer at kode', bruger Python, så koder kun 44% af professionelle udviklere på det sprog. På den anden side bruger 68% af professionelle udviklere JavaScript, ifølge StackOverflows undersøgelse.
Derudover, mens datavidenskabsprofessionelle arbejder hos virksomheder, der overvejende (87%) tillader open source-software, har omkring en fjerdedel (26%) minimalt tilsyn af it-afdelingen med deres open source-valg, hedder det i Anaconda-rapporten. I yderligere 18 % af virksomhederne specificerer it-afdelingen kun omkring halvdelen af de tilgængelige open source-komponenter.
Vedligeholderne af de mest kritiske projekter - som der er hundredvis af, hvis ikke tusinder - skal bruge sikre afhængigheder, teste deres egen kode og validere bidragydernes troværdighed. Vedligeholderne bør også offentliggøre et sikkerhedsscorekort - et Google-skabt initiativ nu administreret af Open Source Security Foundation (OpenSSF), som giver en sikkerhedskarakter til et projekt ud fra næsten 20 forskellige kriterier.
Selvom bevidstheden sandsynligvis stiger, er der ingen hurtig løsning, siger Miranda.
"Virkeligheden er, at de mere sikre muligheder ikke tidligere har eksisteret," siger hun. "Trimning af unødvendige afhængigheder for at reducere angrebsoverfladen er fornuftigt, men det er svært at gøre, når først afhængighedstræet er blevet stort."
