OpenSSF fügt Software-Supply-Chain-Tracks zum SLSA-Framework hinzu

Die Open Source Security Foundation (OpenSSF) hat v1.0 von Supply-Chain Levels for Software Artifacts (SLSA) mit spezifischen Bestimmungen für die Software-Lieferkette veröffentlicht.

Moderne Anwendungsentwicklungsteams verwenden regelmäßig Code aus anderen Anwendungen und beziehen Codekomponenten und Entwicklertools aus unzähligen Quellen. Untersuchungen von Snyk und der Linux Foundation aus dem letzten Jahr ergaben, dass 41 % der Unternehmen hatte kein großes Vertrauen in die Sicherheit von Open-Source-Software. Da Angriffe auf die Lieferkette eine allgegenwärtige und sich ständig weiterentwickelnde Bedrohung darstellen, erkennen sowohl Softwareentwicklungsteams als auch Sicherheitsteams jetzt, dass Open-Source-Komponenten und -Frameworks gesichert werden müssen.

SLSA ist ein von der Community betriebenes Projekt für Sicherheitsstandards in der Lieferkette, das von großen Technologieunternehmen wie Google, Intel, Microsoft, VMware und IBM unterstützt wird. SLSA konzentriert sich auf die Erhöhung der Sicherheitsrigorosität innerhalb des Softwareentwicklungsprozesses. Entwickler können die Richtlinien von SLSA befolgen, um ihre Softwarelieferkette sicherer zu machen, und Unternehmen können SLSA verwenden, um Entscheidungen darüber zu treffen, ob sie einem Softwarepaket vertrauen, so die Open Source Security Foundation.

SLSA bietet ein gemeinsames Vokabular, um über die Sicherheit der Softwarelieferkette zu sprechen; eine Möglichkeit für Entwickler, Upstream-Abhängigkeiten zu bewerten, indem sie die Vertrauenswürdigkeit von Quellcode, Builds und Container-Images bewerten, die in der Anwendung verwendet werden; eine umsetzbare Sicherheitscheckliste; und eine Möglichkeit, die Einhaltung des bevorstehenden Secure Software Development Framework (SSDF) zu messen.

Die SLSA v1.0-Version unterteilt die Level-Anforderungen von SLSA in mehrere Tracks, von denen jeder einen bestimmten Aspekt der Software-Supply-Chain-Sicherheit misst. Die neuen Tracks werden den Benutzern helfen, die mit Software-Lieferketten verbundenen Risiken besser zu verstehen und zu mindern und letztendlich sicherere und zuverlässigere Software zu entwickeln, zu demonstrieren und zu verwenden, so OpenSSF. SLSA v1.0 bietet auch eine explizitere Anleitung zur Überprüfung der Herkunft sowie entsprechende Änderungen an der Spezifikation und dem Herkunftsformat.

Das Strecke bauen Die Stufen 1–3, die in etwa den Stufen 1–3 in früheren SLSA-Versionen entsprechen, beschreiben die Stufen des Schutzes gegen Manipulationen während oder nach der Softwareerstellung. Die Build-Track-Anforderungen spiegeln die erforderlichen Aufgaben wider: Produzieren von Artefakten, Verifizieren von Build-Systemen und Verifizieren von Artefakten. Zukünftige Versionen des Frameworks werden auf Anforderungen aufbauen, um andere Aspekte des Lebenszyklus der Softwarebereitstellung zu berücksichtigen.

Build L1 gibt die Herkunft an und zeigt, wie das Paket gebaut wurde; Build L2 gibt die signierte Herkunft an, die von einem gehosteten Build-Service generiert wird; und Build L3 gibt an, dass der Build-Service gehärtet wurde.

Je höher das Level, desto größer das Vertrauen, dass ein Paket bis zu seiner Quelle zurückverfolgt werden kann und nicht manipuliert wurde, sagte OpenSSF.

Die Sicherheit der Softwarelieferkette ist eine Schlüsselkomponente der Biden-Administration Nationale Cybersicherheitsstrategie der USA, da es Softwareanbieter dazu drängt, mehr Verantwortung für die Sicherheit ihrer Produkte zu übernehmen. Und kürzlich haben 10 Regierungsbehörden aus sieben Ländern (Australien, Kanada, Deutschland, die Niederlande, Neuseeland, das Vereinigte Königreich und die Vereinigten Staaten) neue Richtlinien veröffentlicht, „Verschiebung des Gleichgewichts des Cybersicherheitsrisikos: Prinzipien und Ansätze für Security-by-Design und -Default“, um Softwareentwickler zu drängen, die notwendigen Schritte zu unternehmen, um sicherzustellen, dass sie Produkte liefern, die sowohl vom Design her als auch standardmäßig sicher sind. Das bedeutet, Standardkennwörter zu entfernen, in sichereren Programmiersprachen zu schreiben und Programme zur Offenlegung von Schwachstellen einzurichten, um Schwachstellen zu melden.

Als Teil der Sicherung der Softwarelieferkette sollten Sicherheitsteams mit Entwicklern zusammenarbeiten, um sie über sichere Codierungspraktiken aufzuklären und Schulungen zum Sicherheitsbewusstsein so anzupassen, dass sie die Risiken im Zusammenhang mit dem Lebenszyklus der Softwareentwicklung berücksichtigen.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Die Zukunft prägen mit Adryenn Ashley. Hier zugreifen.
• Quelle: https://www.darkreading.com/dr-tech/openssf-adds-software-supply-chain-tracks-to-slsa-framework