Skrevet af Steven Vaughan-Nichols, Senior Contributing Editor
Steven Vaughan-Nichols Senior Contributing Editor
Steven J. Vaughan-Nichols er freelanceskribent.
Fuld biografi Udgivet i Linux og Open Source den 4. februar 2022 | Emne: Sikkerhed
Hvad er Alpha-Omega-projektet? Dens formål er at “forbedre global open source-softwareforsyningskædesikkerhed ved at arbejde sammen med projektvedligeholdere for systematisk at lede efter nye, endnu uopdagede sårbarheder i open source-kode” og derefter rette dem. Dette er afgørende for at forbedre open source-sikkerheden.
For at få dette til at ske, går Linux Foundations partnergruppe – Open Source Security Foundation (OpenSSF), Google og Microsoft – sammen om at arbejde med sikkerhedseksperter og bruge automatiseret sikkerhedstest til at forbedre open source-sikkerheden. Microsoft og Google bringer en indledende investering på $5 millioner til Alpha-Omega-projektet.
Softwareforsyningskædesikkerhed er blevet afgørende. Det ene større sikkerhedsproblem efter det andet – inklusive SolarWinds softwareforsyningskædeangrebet, Log4j-sårbarheden og episoden med npm dårlig kodeindsprøjtning – kan spores tilbage til softwareforsyningskædens sårbarheder.
Hackere og nationale modstandere har gjort vidt udbredte open source-projekter til deres topmål. I disse dage, hvor en ny sårbarhed afsløres, er det kun et spørgsmål om timer, før den bliver udnyttet. For eksempel tvang de meget udbredte Log4j-biblioteksproblemer mange organisationer i krisetilstand, da de løb for at opdatere applikationer, før de kunne blive angrebet.
En separat del af problemet, som Jack Aboutboul VP of Products hos softwarekædesikkerhedsfirmaet CodeNotary påpeger, er at betale udviklere og vedligeholdere for dette arbejde. Han spørger: “Hørte du om Fortune 500-selskabet, der mailede en open source-vedligeholder til “Demand Answers” om hans softwarepakke, som de aldrig har betalt for, og som de nu har indset bliver brugt i deres software ? Det gjorde vi. Og vi syntes ikke, det var sjovt. Denne historie viser, hvad der måske er den mest åbenlyse sandhed om, hvordan softwareforsyningskæden kan sikres – ved at betale vedligeholdere. Ethvert projekt eller initiativ, som det, der blev lanceret af OpenSSF , vil aldrig blive fuldstændig og aldrig fuldt ud aktualiseret, medmindre der øremærkes penge til at betale disse vedligeholdere af Omega-software. Ellers vil resultatet blot være at identificere flere huller i en vedligeholders kode, som vil få dem til at arbejde flere timer, ikke mindre, for den samme ikke-eksisterende kompensation.”
Alpha-Omega-projektet har til formål at springe alt dette over ved at finde open source-kodesårbarheder og rette dem, før de kan målrettes. Jeg ønsker dem held og lykke.
Alfa…
Alpha vil arbejde med de mest kritiske open source-projektvedligeholdere. Specifikt vil Alpha dække både selvstændige projekter og kerneøkosystemtjenester udvalgt baseret på arbejdet fra OpenSSF Securing Critical Projects-arbejdsgruppen. For at gøre dette vil Alpha bruge både ekspertudtalelser og data. Dette vil omfatte data fra open source-sikkerhedsprojekter, såsom OpenSSF Criticality Score og Harvards “Census”-analyse.
For disse udvalgte projekter vil Alpha-teammedlemmer give skræddersyet hjælp til at forstå og løse sikkerhedshuller. Dette vil omfatte trusselsmodellering, automatiseret sikkerhedstest, kildekoderevision og støtte til afhjælpning af sårbarheder, der opdages. Dens bedste praksis vil delvist blive trukket fra OpenSSF Scorecard og Best Practices Badge-kriterierne.
…og Omega
Omega-siden af projektet vil starte med at identificere mindst 10.000 udbredte open source-programmer. Når det er gjort, vil projektets team anvende automatiseret sikkerhedsanalyse og scoring til programmernes kode. Endelig vil Omega-besætningen følge op ved at give afhjælpningsvejledning til vedligeholdelsesmiljøerne.
Dette er på ingen måde nemt. Omega vil gøre dette med automatiserede metoder og værktøjer til at identificere kritiske sikkerhedssårbarheder. For at få dette til at ske, vil dets udviklere bruge en kombination af teknologi, cloud-skala-analysefolk, sikkerhedsanalytikere, der trigger resultater; og proces, fortrolig rapportering af kritiske sårbarheder til programmernes interessenter. For at få dette til at ske, vil Omega bruge et dedikeret team af softwareingeniører. De vil løbende arbejde på at reducere antallet af falske positive og identificere nye sårbarheder.
Selv med sit eget sikkerhedsteam, som Eric Brewer, Google VP of Infrastructure and Fellow påpegede, “Den lange hale af vigtig open source-software, 'Omega'en i denne bestræbelse, er altid den sværeste del – det vil ikke kun kræve betydelig finansiering og vedholdenhed, men dens omfang vil også drive omfattende automatisering til sporing og ideelt set udbedring af sårbarheder. Aktivering af automatisering vil være en af de største forbedringer for open source-sikkerhed.”
“Open source-software er en vital komponent af kritisk infrastruktur for det moderne samfund. Derfor skal vi tage alle nødvendige forholdsregler for at holde den og vores softwareforsyningskæder sikre,” siger Brian Behlendorf, OpenSSF's General Manager. “Alpha-Omega understøtter denne indsats på en åben og gennemsigtig måde ved direkte at forbedre sikkerheden for open source-projekter gennem proaktivt at finde, rette og forhindre sårbarheder.”
Hvis alt går vel, sagde Mark Russinovich, Microsoft Azure CTO, “Alpha-Omega vil give sikkerhed og gennemsigtighed for vigtige open source-projekter gennem direkte engagement med vedligeholdere og ved at bruge state-of-the-art sikkerhedsværktøjer til at opdage og rette kritiske sårbarheder. Vi ser frem til at samarbejde med industripartnere og open source-fællesskabet om dette vigtige initiativ.”
Der er stadig spørgsmål
Men er dette nok? Det mener Aboutboul ikke. Teknisk set er Aboutboul bekymret for, at hverken Alpha-Omegas sigstore-teknologi (især cosign og Rekor) eller dets økonomiske og personalemæssige ressourcer er klar til opgaven. “For det første er cosign baseret på certifikater og nøgler – ældgamle teknologier. Hvad sker der, hvis du underskriver milliarder af artefakter med et certifikat, og så er det certifikat nu kompromitteret? Vil du gå tilbage og tilbagekalde tilliden til alle dine aktiver? Ydermere, hvad nu hvis den faktiske tillidsrod på en eller anden måde bliver kompromitteret? Seriøse spørgsmål skal stilles og besvares.”
Aboutboul bekymrer sig også om, at Rekor, der er ment som projektets uforanderlige, manipulationssikre hovedbog og fungerer som en gennemsigtighedslog over metadata om artefakter i en forsyningskæde, ikke er god nok. Det er fordi “Rekor bruger Googles Trillian til dens underliggende append-only datastruktur og kræver MySQL eller MariaDB og Redis nedenunder. I sidste ende giver dette plads til sårbarhed. Der er for mange bevægelige brikker på spil her, og jo flere brikker betyder flere brikker du har brug for at stole på, eller burde faktisk ikke have behov for at stole på.”
Til sidst, hvad angår den tekniske side af tingene, bemærker Aboutboul, at Rekor kommer med det samme og siger: “'VIGTIGT: Denne instans drives i øjeblikket efter bedste evne. Vi vil tage loggen ned og nulstille den med ingen varsel. Vi vil forbedre stabiliteten og publicere SLO'er over tid.' Yikes!”
Aboutboul håndterer disse problemer ved at stole på sin open-source uforanderlige database, immudb. Hvorfor? CodeNotary spiser sit eget hundefoder, fordi “immudb i sig selv er en uforanderlig database og ikke er afhængig af noget eksternt stykke infrastruktur, der er ingen plads til tvivl, ingen plads til risiko. Det, der går ind i immudb, er gemt i immudb, i en sabotage -bevis og verificerbar måde.”
Udover teknologien har Aboutboul to andre vigtige spørgsmål, som han mener skal løses. For det første: “Mens 5 millioner dollars lyder som mange penge (og det er det), virker det som en sølle sum at udføre denne mission. Dybden af penetration af open source i den globale softwareforsyningskæde er skræmmende. Når du begynder at tag et kig på dine potentielle Alpha-projekter, f.eks. Linux-kernen osv. indsatsen der alene kan potentielt udnytte næsten alt det. Hvordan kommer du så til alle dine Omega-projekter?”
Når det er sagt Aboutboul er enig i, at Alpha-Omega er et godt, stort skridt fremad. Men Aboutboul har flere fremragende pointer. I sidste ende er elefanten i rummet penge for udviklere og vedligeholdere. Kan vi lide det eller ej, vi må gøre betaling for open source-sikkerhed til en prioritet.
Relaterede historier:
Sikring af open source-økosystemet: SBOM'er er ikke længere valgfrie Kodenotar: Notariser og verificer din softwarestykliste Alene af hensyn til sikkerheden kunne vi prøve at betale åben -source projekter korrekt Linux | Sikkerheds-tv | Datastyring | CXO | Datacentre