Google stelt voor om nieuwe regels vast te stellen om de open source-beveiliging te verbeteren

De beveiliging van open source software heeft de aandacht van de industrie getrokken, maar oplossingen vereisen consensus over uitdagingen en samenwerking bij de uitvoering.

Het probleem is complex en er zijn veel facetten die moeten worden behandeld, uit de supply chain, afhankelijkheidsbeheer, identiteit, onder andere. Om dit te doen, heeft Google onlangs een raamwerk uitgebracht ("Know, Prevent, Fix") dat uitlegt hoe de industrie kan nadenken over kwetsbaarheden in open source en specifieke gebieden die eerst moeten worden aangepakt.

Google legt de redenen uit:

“Door recente gebeurtenissen heeft de softwarewereld een dieper inzicht gekregen in het reële risico van supply chain-aanvallen. Open source software zou vanuit beveiligingsoogpunt minder riskant moeten zijn, aangezien alle code en afhankelijkheden open en beschikbaar zijn voor inspectie en verificatie. En hoewel dit over het algemeen waar is, wordt aangenomen dat mensen dit inspectiewerk ook daadwerkelijk doen. Met zoveel afhankelijkheden is het onmogelijk om ze allemaal te controleren en veel open source-pakketten worden niet goed onderhouden.

“Het is normaal dat een programma direct of indirect afhankelijk is van duizenden pakketten en bibliotheken. Kubernetes is nu bijvoorbeeld afhankelijk van ongeveer 1000 pakketten. Open source gebruikt waarschijnlijk afhankelijkheden in plaats van propriëtaire software en is afkomstig van een breder scala aan leveranciers; het aantal onafhankelijke entiteiten dat kan worden vertrouwd, kan erg groot zijn. Dit maakt het buitengewoon moeilijk om te begrijpen hoe open source wordt gebruikt in producten en welke kwetsbaarheden relevant kunnen zijn. Er is ook geen garantie dat wat is gebouwd, overeenkomt met de broncode.

Binnen het door Google voorgestelde kader wordt voorgesteld om deze moeilijkheid op te splitsen in drie grotendeels onafhankelijke probleemgebieden, elk met specifieke doelstellingen:

Ken de kwetsbaarheden van uw software

Het kennen van uw softwarekwetsbaarheden is moeilijker dan u zou verwachten om vele redenen. Ja ok mechanismen bestaan ​​om kwetsbaarheden te melden, het is onduidelijk of ze echt invloed hebben op de specifieke versies van de software die u gebruikt:

• Doel: nauwkeurige kwetsbaarheidsgegevens: ten eerste is het essentieel om nauwkeurige metagegevens over kwetsbaarheden vast te leggen uit alle beschikbare gegevensbronnen. Als u bijvoorbeeld weet welke versie een kwetsbaarheid heeft geïntroduceerd, helpt dit om te bepalen of de software is getroffen, en als u weet wanneer het is gepatcht, resulteert dit in nauwkeurige en tijdige reparaties (en een smal venster voor mogelijke uitbuiting). Idealiter zou deze classificatieworkflow geautomatiseerd moeten worden.
• Ten tweede liggen de meeste kwetsbaarheden in uw afhankelijkheden, in plaats van in de code die u schrijft of rechtstreeks beheert. Dus zelfs als uw code niet verandert, kan het landschap van kwetsbaarheden die uw software beïnvloeden voortdurend veranderen - sommige zijn opgelost en andere worden toegevoegd.
• Doel: standaardschema voor kwetsbaarheidsdatabases Infrastructuur- en industriestandaarden zijn vereist om open source-kwetsbaarheden op te sporen en te onderhouden, de gevolgen ervan te begrijpen en de oplossingen ervan te beheren. Een standaard kwetsbaarheidsschema zou het mogelijk maken dat gemeenschappelijke tools op meerdere kwetsbaarheidsdatabases draaien en het traceren vereenvoudigen, vooral wanneer kwetsbaarheden meerdere talen of subsystemen kruisen.

Voeg geen nieuwe kwetsbaarheden toe

Het zou ideaal zijn om het ontstaan ​​van kwetsbaarheden te vermijden En hoewel test- en analysetools kunnen helpen, zal preventie altijd een moeilijk onderwerp zijn.

hier, Google stelt voor om zich te concentreren op twee specifieke aspecten:

• Begrijp de risico's bij het beslissen over een nieuwe afhankelijkheid
• Verbeter kritieke softwareontwikkelingsprocessen

Herstel of verwijder kwetsbaarheden

Google erkent dat het algemene probleem van reparatie buiten zijn bereik valt, maar de uitgever is van mening dat actoren veel meer kunnen doen om het probleem aan te pakken specifiek om kwetsbaarheden in afhankelijkheden te beheren.

Het vermeldt ook: 

“Tegenwoordig is er op dit gebied weinig hulp, maar naarmate we de nauwkeurigheid verbeteren, loont het de moeite om in nieuwe processen en tools te investeren.

“Een optie is natuurlijk om de kwetsbaarheid direct te patchen. Als u dit op een achterwaarts compatibele manier kunt doen, is de oplossing voor iedereen beschikbaar. Maar de uitdaging is dat het onwaarschijnlijk is dat u ervaring heeft met het probleem of direct in staat bent om veranderingen aan te brengen. Bij het verhelpen van een kwetsbaarheid wordt ook verondersteld dat degenen die verantwoordelijk zijn voor het onderhoud van de software, op de hoogte zijn van het probleem en over de kennis en middelen beschikken om de kwetsbaarheid te onthullen.

bron: https://security.googleblog.com