Programvare er kjernen i alle moderne virksomheter og er avgjørende i alle aspekter av driften. Nesten alle bedrifter vil bruke åpen kildekode-programvare, bevisst eller på annen måte, siden selv proprietær programvare er avhengig av åpen kildekode-biblioteker. OpenUK sine "State of Open"-rapporten fra 2022 fant at 89 % av virksomhetene stolte på åpen kildekode-programvare, men ikke alle er klare på detaljene i programvaren de er avhengige av.
Bedrifter etterspør stadig mer informasjon om sin driftskritiske programvare. Ansvarlige virksomheter tar en detaljert interesse for programvareforsyningskjeden deres og lager en programvareliste (SBOM) for hver applikasjon. Dette informasjonsnivået er avgjørende slik at når sikkerhetsfeil blir identifisert i programvaren deres, kan de umiddelbart være sikre på hvilken programvare og versjoner som er i bruk, og hvilke systemer som er berørt. Kunnskap er makt i disse situasjonene!
Stol på frivillige
På slutten av 2021 ringte en sikkerhetssårbarhet Log4Shell ble identifisert i et mye brukt Java-loggingsrammeverk, Log4j. Siden dette er et mye brukt, åpen kildekode-bibliotek, ble sårbarheten godt publisert, og det var forventet å fikse det. Imidlertid vedlikeholdere av prosjektet var frivillige. De hadde dagjobber og var ikke på vakt for akutte sikkerhetsløsninger, selv om et stort antall systemer ble berørt. Denne sårbarheten alene ble anslått å ha påvirket 93 % av bedriftens skymiljøer.
På den tiden var det en del negativ presse om åpen kildekode, men sannheten er at hvis dette var en lukket kildekodekomponent, kan det hende at sårbarheten aldri har vært offentlig kjent, noe som gjør organisasjoner åpne for angrep. Bibliotekets åpen kildekode gjorde at det kunne bli inspisert, problemene funnet og råd gitt av andre. Så, ja, vedlikeholderne var ikke på vakt for sikkerhetsproblemer i deres frivillige prosjekt. Det store spørsmålet er da: Hvordan kom vi i en situasjon der store selskaper var avhengige av programvare som var ansvaret til noen som gjør noe annet for å betale regningene deres?
Forsømmelse av programvareavhengigheter er en risikabel virksomhet uansett lisensen til programvaren, men når den er åpen kildekode og veldig mye brukt, blir den spesielt farlig. Holder seg til historien om en sårbarhet; problemet hadde eksistert i kodebasen i årevis, men ble ikke oppdaget. Verktøyet som ble så mye brukt var faktisk ikke så bredt støttet - og det som skjedde videre er historie.
Denne historien gjentas om og om igjen, på tvers av så mange virksomheter som har kritiske avhengigheter, men som ikke iverksetter tiltak for å støtte verken vedlikeholderne eller selve prosjektene. Å ha en SBOM for programvaren som brukes av en bedrift betyr at de har informasjonen tilgjengelig. For organisasjoner som leverer programvare til andre, er forventningen om å levere SBOM sammen med koden i økende grad normen.
Kjenn til avhengigheter for å vurdere risiko
Å bringe kunnskap om avhengighetene gjør det lettere å vurdere risikoen knyttet til hver enkelt. Disse åpen kildekode-prosjektene er de enkleste å vurdere: blir problemer besvart, og har det vært noen utgivelser nylig? Å kunne se vedlikeholdere og prosjektaktivitet for hvert prosjekt gir god innsikt i prosjektets helse.
Bedrifter kan bidra til å redusere risikoen ved å støtte prosjektene de er avhengige av. Noen prosjekter aksepterer sponsing direkte via GitHub-sponsorordningen, andre kan i stedet sette pris på tilbud om hosting eller en sikkerhetsrevisjon. Ethvert åpen kildekodeprosjekt setter pris på bidrag. Hvis bedriften din hadde laget dette biblioteket selv, ville ingeniørene i selskapet måtte fikse hver eneste feil selv.
Åpen kildekode er mer som en delt eierskapsordning. Vi trenger ikke alle bygge det samme gjentatte ganger, men kan heller bidra, noe som både er mindre innsats og fører til bedre kvalitet som resultat. En av de mest virkningsfulle tingene bedrifter kan gjøre er å bruke litt av sine ingeniørressurser og bidra til feilrettinger eller funksjoner til prosjekter som er så kjernen i virksomheten.
Holde dine egne ingeniører involvert i et prosjekt har mange fordeler. De blir kjent med det og kan holde øye med nye funksjoner, eller når en ny utgivelse er tilgjengelig. Det er avgjørende at virksomheten har innsikt i helsen og statusen til det avhengige prosjektet og er en del av det som holder det sunt, og reduserer risikoen for virksomheten for et problem med en avhengighet. En rekke organisasjoner, inkludert Aiven, har et OSPO (open source program office), med ansatte dedikert til å bidra til eller til og med vedlikeholde prosjektene som brukes av organisasjonen. Disse avdelingene bidrar ofte til selskapets generelle tilstedeværelse i åpen kildekode-økosystemet og gjør det mulig for andre ansatte å engasjere seg med åpen kildekode.
En annen tilnærming er å støtte organisasjonene som eksisterer for å støtte åpen kildekode. De OpenSSF (Open Source Security Foundation) jobber for å forbedre sikkerheten til åpen kildekode-prosjekter og er finansiert av organisasjonene som er avhengige av disse prosjektene. Den publiserer også utmerkede læringsressurser slik at bedrifter kan utdanne seg selv om risikoen ved programvaren de bruker. En annen lignende organisasjon er Tidløft, som samarbeider med vedlikeholdere for å sikre at visse grunnleggende krav oppfylles, igjen finansiert av organisasjonene. Tidelift tilbyr også verktøy og utdanning for å hjelpe bedrifter med å administrere programvareforsyningskjeden og ta i bruk beste praksis på dette området.
Sikre en tryggere programvarefremtid
Bedrifter er avhengige av programvare, og dette inkluderer programvare med åpen kildekode, som er mye brukt og vanligvis sikrere enn proprietære alternativer.
Dette er et smart trekk, men et enda smartere trekk er å ha klar kunnskap om programvareforsyningskjeden og dens avhengigheter. Når et problem oppstår, hjelper det enhver organisasjon, avhengig av sunne prosjekter og å ha detaljene til programvaren tilgjengelig. Hvis hver organisasjon gjorde dette, reduseres risikoen for hendelser som Log4Shell-sårbarheten.
