Onlangs verscheen de publicatie van een nieuw rapport van ontwikkelaarsbeveiligingsbedrijf Snyk en de Linux Foundation, over hun gezamenlijke onderzoek naar de staat van open source softwarebeveiliging.
In je post detail dat de resultaten niet bemoedigend zijn voor bedrijven, voor er is een grote verscheidenheid aan significante veiligheidsrisico's als gevolg van het wijdverbreide gebruik van open source software binnen de ontwikkeling van moderne applicaties, evenals het aantal organisaties dat momenteel slecht is voorbereid om deze risico's effectief te beheersen.
Concreet vond het rapport:
Meer dan vier op de tien (41%) organisaties heeft weinig vertrouwen in de beveiliging van hun open source software;
Het gemiddelde applicatieontwikkelingsproject heeft 49 kwetsbaarheden en 80 directe afhankelijkheden (open source code die door een project wordt aangeroepen); ja,
De tijd die nodig is om kwetsbaarheden in open source-projecten op te lossen, neemt gestaag toe, meer dan een verdubbeling van 49 dagen in 2018 naar 110 dagen in 2021.
Er wordt gezegd dat over het algemeen een project applicatie ontwikkeling heeft gemiddeld 49 kwetsbaarheden en 80 directe afhankelijkheden. Bovendien is de tijd die nodig is om kwetsbaarheden in open source-projecten op te lossen gestaag toegenomen, meer dan een verdubbeling van 49 dagen in 2018 tot 110 dagen in 2021.
» De hedendaagse softwareontwikkelaars hebben hun eigen toeleveringsketens: in plaats van auto-onderdelen te assembleren, assembleren ze code door bestaande open source-componenten met hun unieke code samen te voegen. Als dit leidt tot verhoogde productiviteit en innovatie”, legt Matt Jarvis, Director of Developer Relations bij Snyk, uit. Samen met de Linux Foundation zijn we van plan voort te bouwen op deze bevindingen om ontwikkelaars over de hele wereld verder op te leiden en toe te rusten, zodat ze snel kunnen blijven bouwen en tegelijkertijd veilig kunnen blijven."
Onder andere resultaten, slechts 49% van de organisaties heeft een beveiligingsbeleid voor de ontwikkeling of het gebruik van vrije software (en dit cijfer is slechts 27% voor middelgrote en grote bedrijven). Terwijl 30% van de organisaties zonder een gratis-softwarebeveiligingsbeleid openlijk erkent dat niemand in hun team zich rechtstreeks bezighoudt met gratis-softwarebeveiliging.
Complexiteit van de toeleveringsketen is ook een probleem, waarbij meer dan een kwart van de respondenten aangeeft zich zorgen te maken over de beveiligingsimpact van hun directe afhankelijkheden. Slechts 18% zegt vertrouwen te hebben in de controles die ze uitvoeren.
Tot dit punt, Het is belangrijk om twee situaties te benadrukken:, de eerste van hen is op het moment dat ontwikkelaars een component toevoegen open source in uw applicaties, u bent meteen afhankelijk worden van dat onderdeel en lopen risico als dat onderdeel kwetsbaarheden bevat.
De andere en die de afgelopen jaren vaak is gezien, is dat dit risico ook wordt verergerd door indirecte of transitieve afhankelijkheden, die de afhankelijkheden zijn van de "andere afhankelijkheden", hier weten veel ontwikkelaars niet eens van deze afhankelijkheden, waardoor het zelfs moeilijker te volgen en te beschermen.
Hiermee kunnen we een beetje begrijpen dat het rapport laat zien hoe reëel dit risico is, met tientallen kwetsbaarheden ontdekt in veel directe afhankelijkheden in elke geëvalueerde applicatie. Dat gezegd hebbende, zijn de respondenten zich tot op zekere hoogte bewust van de beveiligingscomplexiteit die door open source in de hedendaagse softwaretoeleveringsketen wordt gecreëerd:
Meer dan een kwart van de respondenten zei zich zorgen te maken over de beveiligingsimpact van hun directe afhankelijkheden; slechts 18% van de respondenten zei te vertrouwen op de controle die ze hebben voor hun transitieve afhankelijkheden; en Veertig procent van alle kwetsbaarheden werden gevonden in transitieve afhankelijkheden.
Het is ook belangrijk om te vermelden dat als deze bedrijven of ontwikkelaars niet "veilig" zijn met de software die ze gebruiken, velen van ons het meest logische zullen bedenken, zodat ze "betalen" of "de ontwikkeling ondersteunen, hetzij door middelen toe te wijzen of developers", maar hier op dit punt komt een van de grote discussies over open source software om de hoek kijken, of open source "betaald" moet worden.
Als zodanig zijn er veel voorbeelden van open source software die twee versies aankan, die betaald en gratis zijn, en zelfs alleen betaald, maar de broncode is beschikbaar.
Aan de andere kant zijn er ook bewegingen geweest van ontwikkelaars en grote bedrijven, waarbij ze besluiten het distributiemodel te wijzigen of over te stappen op een betaalmodel, bijvoorbeeld QT.
Zonder meer voor wie er meer over wil weten over de notitie, kunt u de details raadplegen in de volgende link.