Google foreslår at etablere nye regler for at forbedre open source-sikkerhed

Sikkerheden ved open source-software har tiltrukket sig industriens opmærksomhed, men løsninger kræver konsensus om udfordringer og samarbejde i implementeringen.

Problemet er komplekst, og der er mange facetter at dække over, fra forsyningskæden, afhængighedsstyring, identitet, blandt andet. For at gøre dette udgav Google for nylig en ramme ("Know, Prevent, Fix"), der forklarer, hvordan branchen kan tænke på sårbarheder i open source og specifikke områder, der skal behandles først.

Google forklarer årsagerne:

”På grund af nylige begivenheder har softwareverdenen fået en dybere forståelse af den reelle risiko for angreb på forsyningskæden. Open source-software skal være mindre risikabelt set ud fra et sikkerhedsperspektiv, da al kode og afhængighed er åben og tilgængelig til inspektion og verifikation. Og mens dette generelt er sandt, antages det, at folk rent faktisk udfører dette inspektionsarbejde. Med så mange afhængigheder er det umuligt at overvåge dem alle, og mange open source-pakker er ikke godt vedligeholdt.

”Det er almindeligt, at et program afhænger direkte eller indirekte af tusinder af pakker og biblioteker. For eksempel afhænger Kubernetes nu af omkring 1000 pakker. Open source bruger sandsynligvis afhængigheder snarere end proprietær software og kommer fra en bredere vifte af leverandører; antallet af uafhængige enheder, der kan stole på, kan være meget stort. Dette gør det ekstremt vanskeligt at forstå, hvordan open source bruges i produkter, og hvilke sårbarheder der kan være relevante. Der er heller ingen garanti for, at det, der er bygget, matcher kildekoden.

Inden for rammerne af Google foreslås det at opdele denne vanskelighed i tre stort set uafhængige problemområder, hver med specifikke mål:

Kend sårbarhederne i din software

At kende dine softwaresårbarheder er sværere end du kunne forvente af mange grunde. Ja OK der findes mekanismer til at rapportere sårbarheder det er uklart, om de virkelig påvirker de specifikke versioner af den software, du bruger:

• Mål: Nøjagtige sårbarhedsdata: For det første er det vigtigt at indfange nøjagtige sårbarhedsmetadata fra alle tilgængelige datakilder. For eksempel at vide, hvilken version der introducerede en sårbarhed, hjælper med at bestemme, om softwaren påvirkes, og at vide, hvornår den er blevet patched, resulterer i nøjagtige og rettidige rettelser (og et smalt vindue til potentiel udnyttelse). Ideelt set bør denne klassificeringsworkflow automatiseres.
• For det andet er de fleste sårbarheder i dine afhængigheder snarere end i den kode, du skriver eller styrer direkte. Så selv når din kode ikke ændres, kan landskabet af sårbarheder, der påvirker din software, konstant ændre sig - nogle er rettet, og nogle tilføjes.
• Formål: Standardskema for sårbarhedsdatabaser Der kræves infrastruktur og industristandarder til at spore og vedligeholde open source-sårbarheder, forstå deres konsekvenser og styre deres afbødninger. En standard sårbarhedsordning giver mulighed for, at almindelige værktøjer kører på flere sårbarhedsdatabaser og forenkler opgaven med at spore, især når sårbarheder krydser flere sprog eller undersystemer.

Undgå at tilføje nye sårbarheder

Det ville være ideelt at undgå skabelse af sårbarheder Og mens test- og analyseværktøjer kan hjælpe, vil forebyggelse altid være et vanskeligt emne.

her, Google foreslår at fokusere på to specifikke aspekter:

• Forstå risiciene, når du beslutter dig for en ny afhængighed
• Forbedre kritiske softwareudviklingsprocesser

Reparer eller fjern sårbarheder

Google erkender, at det generelle problem med reparation ligger uden for dets anvendelsesområde, men udgiveren mener, at der er meget mere, som skuespillere kan gøre for at løse problemet specifikt til at håndtere sårbarheder i afhængigheder.

Det nævnes også: 

”I dag er der lidt hjælp på denne front, men når vi forbedrer nøjagtigheden, betaler det sig at investere i nye processer og værktøjer.

”En mulighed er naturligvis at lappe sårbarheden direkte. Hvis du kan gøre dette på en bagudkompatibel måde, er løsningen tilgængelig for alle. Men udfordringen er, at det er usandsynligt, at du har erfaring med problemet eller den direkte evne til at foretage ændringer. At rette en sårbarhed forudsætter også, at de, der er ansvarlige for vedligeholdelse af softwaren, er opmærksomme på problemet og har viden og ressourcer til at afsløre sårbarheden.

kilde: https://security.googleblog.com