OpenSSF voegt Software Supply Chain Tracks toe aan SLSA Framework

OpenSSF voegt Software Supply Chain Tracks toe aan SLSA Framework

Tijdstempel: 20 april 2023 6:00 uur
OpenSSF voegt software supply chain-tracks toe aan SLSA Framework PlatoBlockchain Data Intelligence. Verticaal zoeken. Ai.

De Open Source Security Foundation (OpenSSF) heeft versie 1.0 van Supply-chain Levels for Software Artifacts (SLSA) uitgebracht met specifieke voorzieningen voor de software-toeleveringsketen.

Moderne applicatieontwikkelingsteams hergebruiken regelmatig code uit andere applicaties en halen codecomponenten en ontwikkelaarstools uit talloze bronnen. Uit onderzoek van Snyk en de Linux Foundation vorig jaar bleek dat 41% van de organisaties dit doet had geen groot vertrouwen in de beveiliging van open source-software. Met aanvallen op de toeleveringsketen die een altijd aanwezige en zich steeds verder ontwikkelende dreiging vormen, erkennen zowel softwareontwikkelingsteams als beveiligingsteams dat open source-componenten en -frameworks moeten worden beveiligd.

SLSA is een door de gemeenschap aangestuurd project voor beveiligingsstandaarden voor de supply chain, ondersteund door grote technologiebedrijven, zoals Google, Intel, Microsoft, VMware en IBM. SLSA richt zich op het vergroten van de beveiligingsnauwkeurigheid binnen het softwareontwikkelingsproces. Ontwikkelaars kunnen de richtlijnen van SLSA volgen om hun softwaretoeleveringsketen veiliger te maken, en bedrijven kunnen SLSA gebruiken om beslissingen te nemen over het al dan niet vertrouwen van een softwarepakket, aldus de Open Source Security Foundation.

SLSA biedt een gemeenschappelijk vocabulaire om te praten over beveiliging van de software supply chain; een manier voor ontwikkelaars om stroomopwaartse afhankelijkheden te beoordelen door de betrouwbaarheid van de broncode, builds en container-images die in de applicatie worden gebruikt te evalueren; een bruikbare beveiligingschecklist; en een manier om de naleving van het aanstaande Secure Software Development Framework (SSDF) te meten.

De SLSA v1.0-release verdeelt de niveauvereisten van SLSA in meerdere sporen, waarbij elk spoor een bepaald aspect van de beveiliging van de softwaretoeleveringsketen meet. De nieuwe tracks zullen gebruikers helpen de risico's die gepaard gaan met softwaretoeleveringsketens beter te begrijpen en te beperken en uiteindelijk veiligere en betrouwbaardere software te ontwikkelen, demonstreren en gebruiken, zegt de OpenSSF. SLSA v1.0 biedt ook explicietere richtlijnen voor het verifiëren van de herkomst, samen met het aanbrengen van overeenkomstige wijzigingen in de specificatie en het herkomstformaat.

De Spoor bouwen Niveaus 1-3, die grofweg overeenkomen met niveau 1-3 in eerdere SLSA-versies, beschrijven niveaus van bescherming tegen manipulatie tijdens of na het bouwen van software. De Build Track-vereisten weerspiegelen de vereiste taken: het produceren van artefacten, het verifiëren van bouwsystemen en het verifiëren van artefacten. Toekomstige versies van het raamwerk zullen voortbouwen op de vereisten om andere aspecten van de levenscyclus van softwarelevering aan te pakken.

Build L1 geeft de herkomst aan en laat zien hoe het pakket is gebouwd; Build L2 geeft de ondertekende herkomst aan, gegenereerd door een gehoste bouwservice; en Build L3 geeft aan dat de build-service is versterkt.

Hoe hoger het niveau, hoe groter het vertrouwen dat een pakket kan worden herleid tot de bron en dat er niet mee is geknoeid, aldus OpenSSF.

De beveiliging van de softwaretoeleveringsketen is een belangrijk onderdeel van de Biden-administratie Amerikaanse nationale cyberbeveiligingsstrategie, omdat het softwareleveranciers ertoe aanzet een grotere verantwoordelijkheid te nemen voor de veiligheid van hun producten. En onlangs hebben tien overheidsinstanties uit zeven landen (Australië, Canada, Duitsland, Nederland, Nieuw-Zeeland, het Verenigd Koninkrijk en de Verenigde Staten) nieuwe richtlijnen vrijgegeven: “De balans van cyberbeveiligingsrisico's verschuiven: principes en benaderingen voor beveiliging door ontwerp en standaard”, om softwareontwikkelaars aan te sporen de nodige stappen te ondernemen om ervoor te zorgen dat ze producten leveren die zowel qua ontwerp als standaard veilig zijn. Dat betekent het verwijderen van standaardwachtwoorden, het schrijven in veiligere programmeertalen en het opzetten van programma's voor het onthullen van kwetsbaarheden voor het melden van fouten.

Als onderdeel van het beveiligen van de softwaretoeleveringsketen moeten beveiligingsteams samenwerken met ontwikkelaars om hen voor te lichten over veilige codeerpraktijken en om beveiligingsbewustzijnstrainingen af ​​te stemmen op de risico's rond de levenscyclus van softwareontwikkeling.

Tijdstempel:

Meer van Donkere lezing