Was ist Software-Lieferkettensicherheit?

Die Software-Lieferkette umfasst alles, was ein Produkt oder eine Anwendung während ihres gesamten Softwareentwicklungslebenszyklus (SDLC) beeinflusst oder eine Rolle darin spielt.

In den letzten Jahren werden Angriffe auf die Software-Lieferkette immer häufiger und raffinierter. In ihrem Bericht 2022 Gartner heißt es: „Rechnen Sie mit der kontinuierlichen Erweiterung der Angriffsfläche von Unternehmen und erhöhen Sie die Investitionen in Prozesse und Tools zur Erkennung und Behebung von Identitätsbedrohungen sowie zur Integrität der digitalen Lieferkette.“

Es ist wichtiger denn je, alle Komponenten, Aktivitäten und SDLC-Praktiken zu sichern, die an der Erstellung und Bereitstellung von Software beteiligt sind. Entwicklungsteams und Softwareanbieter müssen sicherstellen, dass sie nur Codekomponenten verwenden, die keine bekannten Schwachstellen aufweisen, und Wege finden, die Integrität ihres Builds zu validieren und auf unbefugte Manipulationen zu prüfen.

Definition der Sicherheit der Software-Lieferkette

Die Software-Lieferkette bezieht sich auf alles, was an der Entwicklung einer Anwendung über den gesamten Software Development Life Cycle (SDLC) beteiligt ist. Die Erstellung und Bereitstellung von Software erfordert die Sicherung der Aktivitäten, Prozesse und Komponenten ihrer Lieferkette. In diesem Zusammenhang sind viele Faktoren zu berücksichtigen, darunter benutzerdefinierter Code (interne Komponenten), Open-Source-Abhängigkeiten und Bibliotheken (Komponenten von Drittanbietern), DevOps-Tools und Infrastruktur, die den CI/CD-Prozess bilden, und schließlich Entwickler und DevOps Mannschaften.

Es liegt in der Verantwortung der Organisationen, diese Sicherheitsaktivitäten durchzuführen und den Verbrauchern den Nachweis ihrer Sicherheitsbemühungen zu erbringen.

 

 

Angriffe auf Software-Lieferketten: Warum kommen sie so häufig vor?

Moderne Software-Pipelines sind automatisierte Umgebungen, die auf einer Vielzahl von Tools für kontinuierliche Integration und kontinuierliche Bereitstellung basieren. Ein Softwareprojekt kann am Ende Tausende von Open-Source-Abhängigkeiten umfassen.

Böswillige Akteure können betrügerische Bibliotheken als legitim ausgeben, indem sie „logische Fehler“ in Open-Source-Paketmanagern ausnutzen. Beispielsweise können mit Malware infizierte Pakete ohne deren Wissen vertrauenswürdigen Betreuern zugeschrieben werden. Ein solches fehlgeleitetes Vertrauen kann zu problematischen und versteckten Schwachstellen in Ihrem Code führen. Diese Schwachstellen können Angreifern den Zugriff auf sensible Daten ermöglichen oder es ihnen ermöglichen, Malware einzuschleusen und Systeme in der gesamten Lieferkette zu steuern.

Die moderne Entwicklungsumgebung weist ihre eigenen Schwachstellen auf, und eine Vielzahl von Angriffen auf die Software-Lieferkette zielten auf die CI/CD-Pipeline ab, um irgendwann im Entwicklungsprozess bösartigen Code einzuschleusen. Auch hier ist eine Zero-Trust-Annahme der adäquate Ansatz, um Vertrauen in das finale Softwareprodukt zu gewinnen – prüfen, verifizieren und validieren Sie jeden Schritt in der internen Entwicklungskette.
Den heutigen CI/CD-Pipelines mangelt es an Transparenz und Kontrollen, um den Softwareentwicklungsprozess angemessen zu schützen. Außerdem haben sie Schwierigkeiten, Codemanipulationen zu erkennen, was diesen Angriffsvektor noch attraktiver macht.

Das SSDF (NIST 800-218) wurde fertiggestellt und ist in Kraft

Das SSDF-Framework (NIST 800-218). verlangt von Lieferanten die Implementierung von Sicherheitspraktiken, die den Software Development Life Cycle (SDLC) abdecken. Es fördert Transparenz und manipulationssichere Maßnahmen, um Sicherheitslücken und böswillige Eingriffe zu verringern.

Konkret enthält es Richtlinien für einen evidenzbasierten Ansatz zum Schutz der Software selbst vor Manipulationen.

Das SSDF besteht aus vier Hauptteilen:

01 /
Bereiten Sie die Organisation (PO) vor:

Stellen Sie sicher, dass die Mitarbeiter vorbereitet sind und Prozesse und Technologien vorhanden sind, um eine sichere Softwareentwicklung auf Organisationsebene und in einigen Fällen für einzelne Entwicklungsgruppen oder Projekte durchzuführen.

02 /
Schützen Sie die Software (PS):

Schützen Sie alle Softwarekomponenten vor unbefugtem Zugriff oder Manipulation.

03 /
Erstellen Sie gut gesicherte Software (PW):

Erstellen Sie gut gesicherte Software mit minimalen Sicherheitslücken in ihren Versionen.

04 /
Auf Schwachstellen reagieren (RV):

Identifizieren Sie verbleibende Schwachstellen in Softwareversionen, reagieren Sie angemessen auf diese Schwachstellen und verhindern Sie, dass ähnliche Schwachstellen in der Zukunft auftreten.

Sie sollten das SSDF nicht als Checkliste betrachten, sondern vielmehr als Leitfaden für die Planung und Umsetzung eines risikobasierten und evidenzbasierten Ansatzes zur Entwicklung sicherer Software.
Unternehmen müssen Maßnahmen ergreifen, um ihre Sicherheitslage zu verbessern, um die Einhaltung neuer regulatorischer Änderungen zu erleichtern.

SLSA ist ein Rahmenwerk, das Sie einhalten sollten

Ein von Google entwickeltes Framework namens SLSA (Supply-chain Levels for Software Artifacts) bietet Richtlinien zum Erreichen von vier Ebenen des Schutzes der Software-Lieferkette. Das Framework konzentriert sich auf die Integrität des Artefaktaufbaus mit der Absicht, Manipulationen zu verhindern und Artefakte zu sichern.

SLSA funktioniert folgendermaßen: Sie implementieren Checklisten mit Sicherheitskontrollen, die Sie in Ihrer Pipeline implementieren sollten, und diese Kontrollen befinden sich in Unterdomänen wie Quellcodeverwaltungssystemen, Build-Systemen und Abhängigkeiten, die Sie in Ihre Softwareprojekte einbringen.

SLSA legt vier Konformitätsstufen fest, mit dem Ziel, Stufe 4 zu erreichen, die den höchsten Sicherheitswert hätte, aber eine längere Liste von Anforderungen hätte.

Das SLSA-Framework basiert auf dem Konzept der Provenienz. Ein Dokument, das eine „Beweiskette“ darstellt, die den Ursprung und den Erstellungsprozess der Artefakte angibt. Wenn Sie die SLSA-Stufen erhöhen, müssen Sie die Beweise selbst besser schützen.

Sie sollten SLSA als Industriestandard betrachten, ein erkennbares und vereinbartes Maß an Schutz und Compliance, das Sie einhalten müssen.

Wie sichern Sie Ihre Software-Lieferkette?

Die verschiedenen Frameworks, die wir erwähnt haben, definieren die Grundsätze zur Sicherung der Software-Lieferkette und erfordern Ihre Aufmerksamkeit.

Wir möchten jedoch betonen drei Hauptklassen von Sicherheitskontrollen:

1. Sichern Sie die Konfiguration Ihres Softwareentwicklungslebenszyklus

Kompromittierte Anmeldeinformationen, unzureichende Kontrolle der Berechtigungen und anfällige Build-Systeme schaffen Angriffsflächen, die sich auf den Softwarehersteller auswirken. Angreifer, die diese Schwachstellen ausnutzen, können ungesicherte Geheimnisse stehlen oder Softwareartefakte manipulieren. Eine Reihe kommerzieller und Open-Source-Lösungen dieser Klasse bieten möglicherweise Kontrollen, um Lücken in der Sicherheitslage aufzudecken und diese zu beheben.

2. Vermeiden Sie es, sich auf anfällige oder böswillige Abhängigkeiten zu verlassen

Es werden immer wieder neue Schwachstellen in Open-Source- und kommerzieller Software entdeckt. Softwarehersteller müssen dieses Risiko mindern, indem sie anfällige Open-Source-Komponenten aktualisieren, nach selbstverschuldeten Schwachstellen in ihrem proprietären Code suchen und Softwarekonsumenten über die Software-Stückliste (SBOM) und die damit verbundenen Auswirkungen informieren. Diese Verbraucher können wiederum entsprechende Maßnahmen ergreifen.

Gekaperte Open-Source-Projektkonten und als legitim getarnte Schadpakete stellen zusätzliche Risiken dar, die sich vor allem auf den geheimen Diebstahl aus Pipelines auswirken. Die Open-Source-Community und einige kommerzielle Anbieter arbeiten daran, diesem Problem durch eine verbesserte Reputation und Erkennung böswilligen Verhaltens entgegenzuwirken.

3. Validieren Sie die Integrität und den sicheren Build der Softwareartefakte

Cybersicherheit erfordert eine umfassende Verteidigung. Angriffe können unbemerkt bleiben, wenn zum Schutz herkömmliche Angriffsflächenreduzierungs-, Erkennungs- und Reputationsstrategien zum Einsatz kommen. Darüber hinaus haben nachgelagerte Softwarekonsumenten heutzutage kaum noch Einfluss auf diese Kontrollen. Sie können sich höchstens auf punktuelle Sicherheitsüberprüfungen verlassen, wie z. B. Code-Scans, die einen Schwachstellen-Snapshot liefern, von Lieferanten, die kein wirkliches Vertrauen schaffen, dass das Software-Artefakt während des Entwicklungslebenszyklus gut gesichert und geschützt ist.

Jetzt ist eine neue, aufstrebende Klasse von Kontrollen verfügbar, die kontinuierlich die Integrität und den sicheren Entwicklungsprozess jedes Software-Artefakt-Builds nachweist. Diese Bescheinigungen sind nicht seriös und können zwischen Herstellern und nachgeschalteten Verbrauchern geteilt werden, die eine Validierung suchen. Die Nichtabstreitbarkeit wird durch kryptografische Methoden erreicht und erhöht daher den Preis für jeden Angreifer, der in die Lieferkette eindringt, erheblich.

Dieser Ansatz wird von Experten auf dem Gebiet der Sicherheit der Software-Lieferkette als wesentlich erachtet. Obwohl einige Open-Source-Bausteine ​​zur Unterstützung dieser Klasse von Kontrollen existieren, können nur wenige Anbieter eine integrierte Lösung anbieten.

Eine vollständige Software-Supply-Chain-Lösung muss Folgendes umfassen:

Das Sammeln von Beweisen und deren Unterzeichnung als Bescheinigungen aus den Softwareentwicklungs- und Build-Prozessen. Typischerweise handelt es sich bei diesen Beweisen um Datei-Hashes mit Metadaten, die zwischen relevanten Prozessschritten, Ereignissen zu sicherheitsrelevanten Schritten wie Code-Committer-Identitäten, Codeüberprüfungen, automatischen Sicherheitstests usw. verglichen werden. Es ist außerdem erforderlich, eine Bescheinigung über den Sicherheitsstatus des Build-Prozesses des Softwareherstellers zum Zeitpunkt der Erstellung des Software-Artefakts vorzulegen.

Ein sicherer Attestierungsspeicher, der Transparenz ermöglicht und Analysen wie die Validierung der Codeintegrität unterstützt.

Eine Richtlinien-Engine, die diese Attestierungen anhand einer von der Organisation definierten Richtlinie oder einer auf Standards basierenden Richtlinie misst, um die Konformität zu validieren und nachzuweisen.

Ein Hub für den Austausch vertrauensbezogener Informationen zwischen Softwareherstellern oder -konsumenten; Dies kann unternehmens- oder unternehmensintern sein).

Mehr erfahren

Die Validierung der Softwareintegrität ist eine Herausforderung

Theoretisch sollte die Überprüfung der Codeintegrität einfach sein. Vergleichen Sie einfach Dateien, oder? In Wirklichkeit gibt es viel zu beachten. Zunächst einmal kompiliert jede Sprache Dateien anders. Darüber hinaus werden Dateien je nach Verwendungszweck sehr unterschiedlich verwendet. Einige sollen sich ändern, während andere gelöscht werden und wieder andere während des Kompilierungsprozesses erstellt werden.

Hinzu kommt die Tatsache, dass Unternehmen ihren proprietären Code nicht aneinander weitergeben möchten.

Code-Sicherung während des gesamten SDLC

Scribe ist bestrebt, Ihren gesamten SDLC kontinuierlich zu sichern. Mit den in verschiedenen Phasen des Entwicklungs- und Erstellungsprozesses gesammelten Beweisen nutzt Scribe digitale Signaturen, um fälschungssichere Bescheinigungen zu erstellen.

Nach der Unterzeichnung kann jedes Beweisstück später überprüft werden, um sicherzustellen, dass alle Prozesse wie geplant abgelaufen sind und keine ungeplanten Änderungen stattgefunden haben.

Scribe folgt den im SSDF dargelegten Best Practices und ermöglicht Ihnen die Anwendung gesunder Menschenverstandsrichtlinien, um Ihr Vertrauen während des gesamten Entwicklungsprozesses zu stärken. Richtlinien wie das Erfordernis signierter Commits, 2FA für Entwickler, Codeüberprüfung durch zwei Personen usw. tragen dazu bei, Vertrauen zu schaffen, dass jede Software unter Einhaltung der richtigen Sicherheitslage erstellt wurde.

Das Sammeln all dieser Beweise an einem einzigen Ort, zusammen mit einem Code-Integritätsbericht und einer Zusammenfassung aller Richtlinien und Bescheinigungen, sorgt für mehr Transparenz und Vertrauen in den Entwicklungsprozess und die am Ende erzeugten Softwareartefakte und steht im Einklang mit den geltenden SSDF-Richtlinien Grundlage der neuen Cyber-Verordnung.

Indem Sie ausgewählten Abonnenten ermöglichen, die Einhaltung der Richtlinienanforderungen und Integritätsergebnisse des Produkts anzuzeigen, erhalten Benutzer mehr Transparenz und Vertrauen in Ihre Entwicklungspipelines und das endgültige Softwareprodukt.

Das Endergebnis ist nicht nur die Erkennung von Code- oder Pipeline-Manipulationen, sondern auch die Fähigkeit, die Tests und Sicherheitsverfahren zu bestätigen, die während des Entwurfs und der Erstellung der Software durchgeführt wurden, sowie die Integrität des Quellcodes und der Open-Source-Pakete beim Bau verwendet.

Mehr erfahren

Sicherheit der Software-Lieferkette erklärt

Was verbirgt sich in Ihrem Code?

Wie kann das Vertrauen in die Software-Lieferkette verbessert werden?

Welche Auswirkungen hat die endgültige Version von SSDF (NIST 800-218)?

Was ist mit Continuous Assurance und der Sicherheit der Software-Lieferkette?

Warum ist Continuous Assurance eine integrale Praxis für die Sicherheit der Software-Lieferkette?

Wie implementiert man eine automatisierte SLSA-Compliance-Bewertung?

Wie kann SBOM die Sicherheit der Software-Lieferkette verbessern?

Wie sichern Sie Ihre Software mit SBOMs?

Automatisierung der SLSA-Konformitätsbewertung

Die Sicherheit dynamischer Pipelines muss kontinuierlich gemessen werden. SLSA (Supply-Chain Levels for Software Artifacts) definiert vier Schutzstufen für die Software-Lieferkette sowie Richtlinien, wie diese erreicht werden können.

Eine SLSA-Konformitätsbewertung kann automatisiert werden, um ihren Anforderungen gerecht zu werden. Aber wie sollte eine Organisation bei der Anschaffung vorgehen? Gibt es bestimmte Best Practices, die Sie befolgen sollten?

Sehen Sie sich dieses Video an, in dem wir Best Practices für die Implementierung von Automatisierung unter Verwendung von Open-Source-Tools wie Sigstore und OPA in realen Szenarien vorstellen. Sowohl konzeptionelle als auch technische Best Practices beleuchten reale Details und Herausforderungen bei der Bewertung und Automatisierung der SLSA-Compliance.

Bevor Sie Scribe verwenden Nach der Verwendung von Scribe
Trust Hub – Informationsaustausch

  • Eine generierte SBOM wird lokal pro einzelner Pipeline gespeichert, ohne dass die Möglichkeit besteht, sie zu verwalten oder mit Stakeholdern im gesamten Unternehmen oder extern zu teilen.

  • Teilen und Verwalten von SBOMs, sowohl intern innerhalb der Organisation mit anderen Stakeholdern als auch extern mit Kunden oder Benutzern
  • Intelligente SBOM mit umsetzbaren Erkenntnissen
  • SBOM-Einblicke können als Go/No-Go-Gate für die Pipeline oder das Produkt verwendet werden, um festzustellen, ob das resultierende Bild den Erwartungen entspricht
  • Die Synchronisierung zwischen verschiedenen Teams und Organisationen ist jetzt möglich
Sicheres SDLC – Richtlinien und Compliance

  • Es gibt keine automatische oder zuverlässige Möglichkeit, sicherzustellen, dass sichere SDLC-Richtlinien wie erforderlich befolgt werden.

  • Eine evidenzbasierte und zuverlässige Methode, die sicherstellt, dass SDLC-Richtlinien gemäß den neuesten Sicherheitsvorschriften und -rahmen für die Software-Lieferkette (SLSA 3, SSDF) durchgesetzt werden.
Integritäts- und Manipulationserkennung

  • Nur das, was Sie aus Protokollen und APIs erfahren können
  • Nicht unterschrieben bis zum Ende des Prozesses – direkt vor der Lieferung (bezieht sich nur auf „Final Lag“ MITM)

  • Die fortlaufende Codesicherung durch kontinuierliches Code-Hashing und Signieren in jeder Phase des Entwicklungsprozesses ermöglicht die Validierung, dass das endgültige Artefakt das ist, was es sein sollte, und dass während des Entwicklungs- und Bereitstellungsprozesses kein bösartiger Code von einem böswilligen Akteur eingefügt wurde.
Sichtbarkeit

  • Alles, was Sie aus Protokollen und APIs erfahren können
  • Lokal gespeichert und nicht signiert, sodass die Möglichkeit besteht, dass böswillige Akteure daran manipuliert haben

  • Unterzeichnete Bescheinigungen werden in einem separaten, sicheren und manipulationssicheren Beweisspeicher gespeichert
Sicherheitslage

  • Überprüfung auf Fehlkonfigurationen der CI/CD-Tools
  • Auf der Suche nach durchgesickerten Geheimnissen
  • Auf bekannte Schwachstellen (CVEs) prüfen

  • Suchen Sie nach SDLC-Lücken in Ihrer CI/CD-Toolchain.
  • Überprüfung auf bekannte Schwachstellen (CVEs) und die Reputation von OSS-Repos
  • Registrierung manipulationssicherer Nachweise darüber, dass die erforderlichen Sicherheitsmaßnahmen in jeder Phase des Prozesses gemäß der SDLC-Richtlinie der Organisation rechtzeitig ergriffen wurden.

Scribe Security – ein neuer Software-Supply-Chain-Sicherheitsstandard

Continuous Code Assurance besteht aus Prozessen und Tools, die:

Verfolgen Sie jedes Detail und Ereignis im Softwareentwicklungsprozess sowie die Integrität der Softwarekomponenten und Artefakte

Stellen Sie sicher, dass in keinem Teil des Softwareentwicklungsprozesses Manipulationen stattgefunden haben

Überprüfen Sie die Integrität der CI/CD-Tools, die zum Erstellen des Codes verwendet werden

Bestätigen Sie die Integrität des Entwicklungsprozesses und stellen Sie sicher, dass sicherheitsrelevante Schritte gemäß den Richtlinien der Organisation durchgeführt und nicht umgangen wurden

Indem Sie in jeder Phase des Entwicklungslebenszyklus Beweise für alles sammeln und signieren, was mit dem Code geschieht, erschweren Sie es Angreifern, Dateien, Tools oder das erwartete Verhalten Ihrer CI/CD-Pipeline zu manipulieren.

Mehr Infos

Unsere Rubrik HILFE?

Unsere einzigartige Plattform stellt sicher, dass Codeartefakte von Git bis zur Produktion während des gesamten Softwareentwicklungslebenszyklus sicher sind, und nutzt dabei die führenden Sicherheitskonzepte und Frameworks.

Unsere Kunden, die für die Sicherung von Software-Builds und im Einsatz befindlicher Software verantwortlich sind, verlassen sich auf Scribe, um sicherzustellen, dass ihre Software sicher und vertrauenswürdig ist.

Kontaktieren Sie Uns

Bleib im Wissen

Kontinuierliche Sicherheit und Sicherheit der Software-Lieferkette | Scribe-Sicherheit Cyber-Risiko
Kontinuierliche Sicherheit: Eine integrale Praxis für die Sicherheit der Software-Lieferkette
Mehr Infos
SSDF ENDGÜLTIGE VERSION Cyber-Risiko
SSDF (NIST 800-218) endgültige Version – Unterschiede zum Entwurf und ihre Auswirkungen für Sie
Mehr Infos
IconBurst-Artikelbild Cyber-Risiko
IconBust, ein neuer NPM-Angriff
Mehr Infos

Angriffe auf die Softwarelieferkette sind in den letzten Jahren immer häufiger und ausgefeilter geworden. Laut a Gartner-BerichtPrognosen zufolge wird sich die Zahl der Angriffe auf die Software-Lieferkette bis 2025 verdreifachen und fast die Hälfte aller Unternehmen weltweit betreffen. Aufgrund dieser wachsenden Bedrohung ist die Sicherung aller Komponenten, Aktivitäten und SDLC-Praktiken wichtiger denn je.

Obwohl es schwierig ist, dies zu verhindern Angriffe auf die Software-LieferketteIm Folgenden sind einige der Dinge aufgeführt, die Sie tun können, um deren Auswirkungen abzumildern oder ihre Risiken zu verringern: Überprüfen Sie Ihre Infrastruktur, führen Sie ein aktuelles Inventar aller Ihrer Software-Ressourcen, bewerten Sie Anbieter und wenden Sie einen Zero-Trust-Ansatz an, verwenden Sie Sicherheitstools, sichern Sie Ihre Endpunkte usw.

Zwar gibt es im Leben keine Garantien, geschweige denn in der Sicherheit, aber es gibt sie Best Practices für die Sicherheit der Software-Lieferkette vorhanden, die Entwickler und Produktorganisationen befolgen müssen, um ihre Software-Lieferkette zu sichern. In den verschiedenen Phasen Ihres Software-Lebenszyklus können Sie diese Richtlinien verwenden, um Sicherheitspraktiken in Ihrem Unternehmen zu beschreiben, zu bewerten und zu messen. Die Best Practices kommen in jeder Phase der Software-Lieferkette ins Spiel, einschließlich Erwerb, Entwicklung und Bereitstellung.

Ein Anstieg der Zahl der Risiken in der Software-Lieferkette und eine Reihe von aufsehenerregenden Verstößen, die daraus resultieren, zeigen, wie ernst das Schwachstellenproblem ist. Es gibt mehrere Bedrohungen für die Softwarelieferkette, die von Software Dritter ausgehen können. Angreifer haben die Möglichkeit, Schwachstellen in Systemen, die von Software Dritter abhängen, auf verschiedene Weise auszunutzen. Zu diesen Angriffsmethoden gehören das Einschleusen von bösartigem Code in Software, das Verwirren von Abhängigkeiten und Tippfehler.

Angriffe auf die Lieferkette verbergen sich in der Regel hinter legitimen Prozessen, um uneingeschränkten Zugriff auf das Software-Ökosystem eines Unternehmens zu erhalten. In den meisten Fällen beginnen Angreifer damit, die Sicherheitsvorkehrungen eines Anbieters oder Softwarelieferanten zu durchbrechen. Sobald die Malware in die Lieferkette eingeschleust wurde, muss sie sich an einen legitimen, digital signierten Prozess anhängen. Software-Updates werden von Angreifern oft genutzt, um Malware über die gesamte Software-Lieferkette zu verbreiten. Einige der häufigsten Arten von Software-Supply-Chain-Angriffen Dazu gehören: Kompromittierte Tools zur Softwareerstellung, gestohlene Code-Sign-Zertifikate oder signierte Schad-Apps unter Verwendung einer gestohlenen Identität sowie kompromittierter Code in Hardware- oder Firmware-Komponenten.

Eine SBOM (Software-Stückliste) ist eine Reihe von Informationen über die vielen Komponenten, aus denen ein Softwareprodukt oder eine Softwareanwendung besteht. Sie enthält in der Regel Lizenzinformationen, Versionsnummern, Komponentendetails, Anbieter usw. Eine solch detaillierte und formelle Liste verringert Risiken sowohl für den Hersteller als auch für den Benutzer, indem sie es anderen ermöglicht, zu verstehen, was in ihrer Software enthalten ist, und entsprechend zu handeln.

SBOMs ermöglichen die Sichtbarkeit von Produktkomponenten, ermöglichen ein einfacheres Scannen von Schwachstellen, nutzen die Lizenzierungs-Governance-Funktionen und können zur Analyse von Bedrohungen für die Integrität verwendet werden.

Continuous Assurance zielt darauf ab, den blinden Fleck der Software-Lieferkette zu beseitigen. Dabei geht es darum, unterzeichnete Beweise für jedes Ereignis im Entwicklungslebenszyklus zu sammeln, das sich auf die Sicherheit des endgültigen Softwareprodukts auswirken kann, einschließlich Produkterstellung und -bereitstellung. Heutzutage nutzen Unternehmen eine Vielzahl von Sicherheitstools, um ihre Softwareprodukte sicherer zu machen. Allerdings legen sie selten eine Richtlinie für die konsequente Nutzung dieser Tools fest.

Kontinuierliche Sicherheit stellt sicher, dass Softwareprodukte während der Entwicklung nicht manipuliert wurden und sicherheitsrelevante Tests durchgeführt wurden.

Kleinere Codeänderungen können lange Zeit unentdeckt bleiben. Entwicklungsteams vertrauen dem Eigentümer des Codes, wenn das geänderte Produkt ordnungsgemäß signiert ist. Dadurch können mit Malware infizierte Pakete erstellt und ohne deren Wissen vertrauenswürdigen, beliebten Betreuern zugewiesen werden. Ein Fall von fehlgeleitetem Vertrauen könnte eine problematische Sicherheitslücke bedeuten oder sogar direkt Schadcode, der in Ihrem Code versteckt ist.

Es ist auch üblich, dass Entwickler Code aus vorhandenen Bibliotheken oder StackOverflow kopieren und einfügen, um ihn in ihrem eigenen Code zu verwenden oder in neue Bibliotheken hochzuladen. Dies erhöht die Wahrscheinlichkeit, dass auch unsicherer und anfälliger Code kopiert wird, der nun praktisch nicht mehr aufspürbar ist. 

Die endgültige Version von NIST SSDF 1.1 (Secure Software Development Framework) wurde am 22. März veröffentlicht. Im September 2021 wurde eine Entwurfsversion des Rahmenwerks veröffentlicht. Viele der Unterschiede sind auf die verschiedenen bereitgestellten Beispiele zurückzuführen und nicht auf hochrangige Praktiken und Aufgaben.

Bei der Entscheidung, welche Praktiken implementiert werden sollen, empfiehlt NIST, das Risiko gegen Kosten, Durchführbarkeit und Anwendbarkeit abzuwägen. Um die Softwaresicherheit zu gewährleisten, ist die Automatisierung möglichst vieler Prüfungen und Prozesse ein wichtiges Merkmal, das berücksichtigt werden muss.

Vertrauen in Ihre Software aufzubauen ist eine wichtige Aufgabe, insbesondere angesichts der neuen Standards und Best Practices wie SSDF und SLSA. Bald werden Anbieter, die dieses Vertrauen nicht nachweisen können, nicht mehr an die US-Bundesregierung verkaufen können.

Um Vertrauen aufzubauen, müssen Sie die SBOM Ihrer Produkte zusammen mit Nachweisen über deren sichere Entwicklung und Herstellung aufbewahren und mit den Stakeholdern teilen.

Schreibplattform, eine wirklich durchgängige Software-Supply-Chain-Sicherheitslösung, bietet Ihnen diese Möglichkeit. Es wendet eine kontinuierliche Codesicherung im gesamten SDLC im Rahmen eines Zero-Trust-Ansatzes an und generiert automatisch gemeinsam nutzbare SBOMS, sodass Sie Einblicke in Schwachstellen und Codemanipulationen gewinnen können.

Dynamische Pipelines müssen aus Sicherheitsgründen kontinuierlich überwacht werden. In SLSA Cybersecurity Framework (Supply Chain Levels for Software Artifacts) werden vier Schutzebenen für Software-Lieferketten definiert, zusammen mit Richtlinien, wie die einzelnen Ebenen erreicht werden können.

Sie müssen Best Practices für die Implementierung der Automatisierung befolgen und Open-Source-Tools wie Sigstore und OPA verwenden, um nur einige zu nennen.