Linux Foundation kondigt een nieuwe open-source software signing service aan

Dankzij de beveiligingsblunders van Solarwinds zijn we ons er nu allemaal van bewust hoe belangrijk het is om onze softwareleveringsketen te beschermen tegen ongeautoriseerde wijzigingen. Nu hebben de Linux Foundation en partners een nieuwe gratis cryptografische software-ondertekening ontwikkeld om de beveiliging van open-sourceprogramma’s te verbeteren.

Door Steven J. Vaughan-Nichols | ZDNet

Als je een paar maanden geleden iemand had gevraagd wat hun grootste zorg was over IT-beveiliging, zou je veel verschillende antwoorden hebben gekregen. Toen slaagde Solarwinds er catastrofaal niet in om zijn softwareleveringsketen te beveiligen, wat leidde tot wat wordt genoemd IT’s Pearl Harbor. Het is dus vandaag dat het afsluiten van uw softwareleveringsketen taak nummer één is geworden voor alle maatschappelijke organisaties en CISO’s die hun werk serieus nemen. Om deze oproep voor open source te beantwoorden, hebben de Linux Foundation samen met Red Hat, Google en Purdue University het sigstore-project gemaakt.

De zojuist aangekondigde sigstore heeft tot doel de beveiliging van de toeleveringsketen van software te verbeteren door de eenvoudige acceptatie van cryptografische software-ondertekening mogelijk te maken, ondersteund door transparantielogboektechnologieën. Het zal dit doen door ontwikkelaars in staat te stellen software-artefacten, zoals release-bestanden, containerafbeeldingen en binaire bestanden, veilig te ondertekenen. Deze ondertekeningsrecords worden vervolgens bewaard in een fraudebestendig openbaar logboek. Deze service is gratis voor alle ontwikkelaars en softwareleveranciers. De sigstore-code en bedieningstooling die zullen worden gebruikt om dit te laten werken, worden nog steeds ontwikkeld door de sigstore-gemeenschap.

Hiermee zijn we, zoals David A Wheeler, de directeur van Open Source Supply Chain Security van de Linux Foundation, eerder opmerkte, op weg om geverifieerde reproduceerbare builds te maken.

Wheeler legde uit: “Een reproduceerbare build is er een” die altijd dezelfde output oplevert met dezelfde inputs, zodat de buildresultaten kunnen worden geverifieerd. Een geverifieerde reproduceerbare build is een proces waarbij onafhankelijke organisaties een build maken op basis van de broncode en verifiëren dat de opgebouwde resultaten afkomstig zijn van de geclaimde broncode. ”

Dit zou op zijn beurt kunnen worden gebruikt om een ​​softwarelijst (SBOM) te maken. Met een SBOM weet u precies welke code u in een bepaald project gebruikt. Dit is een ander argument voor open source. Orion, het gehackte programma van Solarwinds, is bijvoorbeeld, net als alle propriëtaire software, een zwarte doos. Niemand behalve de bouwers weet wat erin zit. En zoals we nu weten, wist Solarwinds niet wat erin zat, totdat externe bedrijven de corruptie opmerkten.

Sigstore zal dit vermijden, legde Luke Hinds, Red Hat’s Security Engineering hoofd in het kantoor van de CTO, uit dat het “alle open-source gemeenschappen in staat zal stellen hun software te ondertekenen en herkomst, integriteit en vindbaarheid te combineren om een ​​transparante en controleerbare software te creëren. bevoorradingsketen.”

Dit is niet gemakkelijk. Hoewel er tegenwoordig enkele open-source tools voor digitale ondertekening beschikbaar zijn, gebruiken maar weinig ontwikkelaars deze. Veel programmeurs zien, zelfs nu nog, het nut niet in om de extra stappen te nemen die nodig zijn om hun software te “ondertekenen”.

Bovendien, zoals Matt Sicker, lid van de Apache Software Foundation en senior beveiligingsingenieur van CloudBees, zei: “Toepassingen die vaak worden gebruikt voor het ondertekenen van software hebben doorgaans verwarrende gebruikersinterfaces en vereisen het leren van basisconcepten voor cryptografie om ze correct te kunnen gebruiken. Zonder een soort van code-ondertekeningsbeleid. In plaats van een groter open source-project zijn veel ontwikkelaars zich gewoon niet bewust van de voordelen van het ondertekenen van hun software. ”

Daarom zijn de tools die er zijn om de oorsprong en authenticiteit van software te bevestigen, afhankelijk van een vaak ongelijksoortige reeks benaderingen en gegevensformaten. De oplossingen die er zijn, zijn vaak afhankelijk van samenvattingen die zijn opgeslagen op onveilige systemen die vatbaar zijn voor manipulatie.

Er komen nieuwere, betere ondertekeningshulpprogramma’s aan. Door Tidelift beheerde catalogi worden bijvoorbeeld bekende, proactief onderhouden componenten bijgehouden die algemene taalkaders omvatten, zoals JavaScript, Python, Java, Ruby, PHP, .NET en Rust.

Toch ondertekenen maar heel weinig open-sourceprojecten hun softwareversies cryptografisch. Dat komt grotendeels door de uitdagingen waarmee softwarebeheerders worden geconfronteerd op het gebied van veilig sleutelbeheer en het compromitteren / intrekken van sleutels. en de distributie van openbare sleutels en artefactsamenvattingen. Gebruikers worden maar al te vaak aan hun lot overgelaten om erachter te komen welke sleutels ze kunnen vertrouwen en hoe ze ondertekening kunnen valideren. Dat is geen klus voor gewone IT-ers.

Maar wacht, er is meer. De manier waarop we momenteel samenvattingen en openbare sleutels distribueren, is in één woord slecht. Al te vaak worden ze opgeslagen op hackbare websites of een README-bestand op een openbare git-repository. Dat is gewoon vragen om gehackt te worden. Sigstore probeert deze problemen op te lossen door gebruik te maken van kortstondige kortstondige sleutels met een vertrouwensbasis die wordt benut door een open en controleerbaar openbaar transparantielogboek.

Met andere woorden, zoals Alex Karasulu, ook een ASF-lid en OptDyn-CEO, opmerkte: “Het probleem is niet dat open-sourceontwikkelaars lui of terughoudend zijn. Het is dat een standaardmechanisme voor tweefactorauthenticatie (2FA) specifiek rond codeondertekening bestaat niet. Er zijn enkele technieken om dit te bereiken: Git-revisies kunnen worden ondertekend en het proces wordt losjes beschermd met verplichte 2FA-accounts op GitHub, of GPG-code-ondertekeningssleutels kunnen worden opgeslagen op apparaten die een tweede factor nodig hebben om alles digitaal te ondertekenen, inclusief code en geef checksums vrij. Er zijn veel manieren om deze kat te villen – maar er is geen standaard die het proces consistent maakt. Het is in wezen discretionair. ”

Zonder standaardisatie is het beveiligen van de softwareleveringsketen bijna onmogelijk. Het is de hoop van sigstore-backers dat ze deze problemen kunnen oplossen. Het doel is de moeite waard. Zoals Josh Aas, uitvoerend directeur van de Internet Security Research Group (ISRG) en Let’s Encrypt, zei: “Het beveiligen van een software-implementatie zou moeten beginnen met ervoor te zorgen dat we de software gebruiken die we denken te zijn. Sigstore is een geweldige kans om meer te brengen. vertrouwen en transparantie in de toeleveringsketen van open source software. ”

Er is tenslotte, zoals Santiago Torres-Arias, universitair docent elektrische en computertechnologie bij Purdue en oprichter van het project, opmerkte: “Het software-ecosysteem heeft dringend behoefte aan zoiets om de toestand van de toeleveringsketen te rapporteren. dat we, met het beantwoorden van alle vragen over softwarebronnen en eigendom, kunnen beginnen met het stellen van vragen over softwarebestemmingen, consumenten, compliance (wettelijk en anderszins), om criminele netwerken te identificeren en kritieke software-infrastructuur te beveiligen. ”

We hebben echt sigstore nodig. Zelfs nu hebben we nog steeds niet echt begrepen hoe erg de Solarwinds-ramp was. Zonder een echt veilige open-source supply chain kunnen we er zeker van zijn dat we nog ergere rampen zullen zien.

Bekijk het originele artikel op ZDNet