Nylig ble utgivelsen av en ny rapport fra utviklersikkerhetsfirmaet Snyk og Linux Foundation, om deres felles forskning på tilstanden til sikkerhet for åpen kildekode.
I innlegget ditt detalj at resultatene ikke er oppmuntrende for bedrifter, deretter det er en lang rekke betydelige sikkerhetsrisikoer som følge av den utbredte bruken av åpen kildekode-programvare innen moderne applikasjonsutvikling, samt hvor mange organisasjoner som for tiden er dårlig forberedt til å håndtere disse risikoene effektivt.
Konkret fant rapporten:
Mer enn fire av ti (41 %) organisasjoner er ikke veldig trygge på sikkerheten til åpen kildekode-programvare;
Det gjennomsnittlige applikasjonsutviklingsprosjektet har 49 sårbarheter og 80 direkte avhengigheter (åpen kildekode kalt av et prosjekt); Y,
Tiden det tar å fikse sårbarheter i åpen kildekode-prosjekter har økt jevnt og trutt, mer enn doblet fra 49 dager i 2018 til 110 dager i 2021.
Det er nevnt at generelt et prosjekt applikasjonsutvikling har et gjennomsnitt på 49 sårbarheter og 80 direkte avhengigheter. I tillegg har tiden som kreves for å fikse sårbarheter i åpen kildekode-prosjekter økt jevnt og trutt, mer enn doblet fra 49 dager i 2018 til 110 dager i 2021.
» Dagens programvareutviklere har sine egne forsyningskjeder: i stedet for å sette sammen bildeler, setter de sammen kode ved å slå sammen eksisterende open source-komponenter med sin unike kode. Hvis dette fører til økt produktivitet og innovasjon,” forklarer Matt Jarvis, direktør for utviklerrelasjoner hos Snyk. Sammen med Linux Foundation planlegger vi å bygge videre på disse funnene for å videreutdanne og utstyre utviklere over hele verden, slik at de kan fortsette å bygge raskt, samtidig som de er trygge."
Blant andre resultater, bare 49 % av organisasjonene har en sikkerhetspolicy for utvikling eller bruk av fri programvare (og dette tallet er kun 27 % for mellomstore og store bedrifter). Mens 30 % av organisasjoner uten en sikkerhetspolicy for fri programvare åpent erkjenner at ingen i teamet deres driver direkte med gratis programvaresikkerhet.
Forsyningskjedens kompleksitet er også et problem, med mer enn en fjerdedel av respondentene som angir at de er bekymret for sikkerhetseffekten av deres direkte avhengigheter. Bare 18 % sier de er trygge på kontrollene de håndterer.
Opp til dette punktet, Det er viktig å trekke fram to situasjoner, den første av dem er på det tidspunktet utviklere legger til en komponent åpen kildekode i applikasjonene dine, er du umiddelbart bli avhengig av den komponenten og er i faresonen hvis den komponenten inneholder sårbarheter.
Den andre og som har blitt sett hyppig de siste årene er at denne risikoen også forverres av indirekte eller transitive avhengigheter, som er avhengighetene til de "andre avhengighetene", her vet mange utviklere ikke engang om disse avhengighetene, noe som gjør det til og med vanskeligere å spore og beskytte.
Med dette kan vi forstå litt at rapporten viser hvor reell denne risikoen er, med dusinvis av sårbarheter oppdaget i mange direkte avhengigheter i hver applikasjon som er evaluert. Når det er sagt, er respondentene til en viss grad klar over sikkerhetskompleksitetene som skapes av åpen kildekode i dagens programvareforsyningskjede:
Mer enn en fjerdedel av respondentene sa at de er bekymret for sikkerhetseffekten av deres direkte avhengigheter, bare 18 % av respondentene sa at de stoler på kontrollene de har for sine transitive avhengigheter; og førti prosent av alle sårbarheter ble funnet i transitive avhengigheter.
Det er også viktig å nevne at dersom disse selskapene eller utviklerne ikke er «trygge» med programvaren de bruker, vil mange av oss tenke på det mest logiske, slik at de «betaler» eller «støtter utvikling, enten ved å allokere ressurser eller utviklere", men her i dette punktet er det hvor en av de store debattene om åpen kildekode-programvare kommer inn, hvor hvis åpen kildekode skal "betales".
Som sådan er det mange eksempler på åpen kildekode-programvare som håndterer to versjoner, som er betalt og gratis, og til og med bare betalt, men kildekoden er tilgjengelig.
På den annen side har det også vært bevegelser fra utviklere og store selskaper, der de bestemmer seg for å endre distribusjonsmodellen eller gå over til en betalingsmodell, for eksempel QT.
Uten mer, for de som er interessert i å vite mer om det om notatet, kan du se detaljene i følgende lenke.