Google föreslår att man skapar nya regler för att förbättra säkerheten för öppen källkod

Säkerheten för programvara med öppen källkod har väckt branschens uppmärksamhet, men lösningar kräver enighet om utmaningar och samarbete i genomförandet.

Problemet är komplext och det finns många aspekter att täcka, från leveranskedjan, beroendehantering, identitet, bland annat. För att göra detta släppte Google nyligen ett ramverk ("Know, Prevent, Fix") som förklarar hur branschen kan tänka på sårbarheter i öppen källkod och specifika områden som måste åtgärdas först.

Google förklarar dess skäl:

”På grund av de senaste händelserna har mjukvaruvärlden fått en djupare förståelse för den verkliga risken för leveranskedjeattacker. Öppen källkodsprogramvara bör vara mindre riskabelt ur ett säkerhetsperspektiv, eftersom all kod och beroenden är öppna och tillgängliga för inspektion och verifiering. Och även om detta i allmänhet är sant, antas det att människor faktiskt gör detta inspektionsarbete. Med så många beroenden är det omöjligt att övervaka dem alla och många öppen källkodspaket är inte väl underhållna.

”Det är vanligt att ett program, direkt eller indirekt, är beroende av tusentals paket och bibliotek. Till exempel beror Kubernetes nu på cirka 1000 paket. Öppen källkod använder förmodligen beroenden snarare än egen programvara och kommer från ett större antal leverantörer; antalet oberoende enheter som kan lita på kan vara mycket stort. Detta gör det extremt svårt att förstå hur öppen källkod används i produkter och vilka sårbarheter som kan vara relevanta. Det finns heller ingen garanti för att det som byggs matchar källkoden.

Inom den ram som Google föreslår föreslås att dela upp denna svårighet i tre till stor del oberoende problemområden, var och en med specifika mål:

Känn sårbarheten i din programvara

Att känna till dina programvarusårbarheter är svårare än du förväntar dig av många anledningar. Ja OK mekanismer finns för att rapportera sårbarheter, det är oklart om de verkligen påverkar de specifika versionerna av programvaran du använder:

• Mål: Korrekta sårbarhetsdata: För det första är det viktigt att fånga korrekta sårbarhetsmetadata från alla tillgängliga datakällor. Att veta till exempel vilken version som introducerade en sårbarhet hjälper till att avgöra om programvaran påverkas och att veta när den har lappats resulterar i korrekta och snabba korrigeringar (och ett smalt fönster för potentiell exploatering). Helst bör detta klassificeringsarbetsflöde automatiseras.
• För det andra ligger de flesta sårbarheter i dina beroenden, snarare än i koden som du skriver eller kontrollerar direkt. Så även när din kod inte ändras kan landskapet med sårbarheter som påverkar din programvara ständigt förändras - vissa är fixade och andra läggs till.
• Syfte: Standardschema för sårbarhetsdatabaser Infrastruktur och industristandarder krävs för att spåra och upprätthålla sårbarheter i öppen källkod, förstå deras konsekvenser och hantera deras begränsningar. Ett vanligt sårbarhetsschema skulle tillåta vanliga verktyg att köras på flera sårbarhetsdatabaser och förenkla uppgiften att spåra, särskilt när sårbarheter korsar flera språk eller delsystem.

Undvik att lägga till nya sårbarheter

Det skulle vara perfekt att undvika att det skapas sårbarheter Och medan test- och analysverktyg kan hjälpa, kommer förebyggande alltid att vara ett svårt ämne.

här, Google föreslår att man fokuserar på två specifika aspekter:

• Förstå riskerna när du väljer ett nytt beroende
• Förbättra kritiska programvaruutvecklingsprocesser

Reparera eller ta bort sårbarheter

Google erkänner att det allmänna problemet med reparation ligger utanför dess räckvidd, men förlaget tror att det finns mycket mer som aktörer kan göra för att lösa problemet specifikt för att hantera sårbarheter i beroenden.

Det nämns också: 

”Idag finns det lite hjälp på den här fronten, men när vi förbättrar noggrannheten är det värt att investera i nya processer och verktyg.

”Ett alternativ är naturligtvis att korrigera sårbarheten direkt. Om du kan göra detta på ett bakåtkompatibelt sätt är lösningen tillgänglig för alla. Men utmaningen är att det är osannolikt att du har erfarenhet av problemet eller den direkta förmågan att göra förändringar. Åtgärda en sårbarhet förutsätter också att de som ansvarar för underhåll av programvaran är medvetna om problemet och har kunskapen och resurserna för att avslöja sårbarheten.

Fuente: https://security.googleblog.com