Best Practices für die Sicherheit der Software-Lieferkette

Die Software-Lieferkette bezieht sich auf alles und jeden, der während des gesamten Entwicklungslebenszyklus in irgendeiner Weise mit Ihrem Softwarecode verbunden ist. Jede Software besteht aus mehreren Komponenten. Neben dem von Grund auf neu geschriebenen proprietären Code erfordert der Code auch eine externe Software-Infrastruktur, Cloud-Dienste und Betriebssysteme, um ordnungsgemäß zu funktionieren. Die Register, Repositorys, Codebasen und sogar die Personen, die diese Software geschrieben haben, sind alle Teil der Software-Lieferkette.

Jeder Knoten in dieser komplexen Kette stellt eine potenzielle Schwachstelle dar, die sich in gewisser Weise auf die Leistung und Sicherheit Ihrer Software auswirken kann. Eine Sicherheitslücke, die an irgendeinem Punkt entlang dieser Abhängigkeitskette entsteht, hat nachgelagerte schwerwiegende Auswirkungen. Denn die Komplexität der Software-Lieferkette verschleiert die Risiken und macht es schwierig, sie ohne einen standardisierten Rahmen zur Sicherung der Lieferkette vorherzusagen und zu identifizieren. Aus diesem Grund ist es für Entwickler und Produktorganisationen wichtig, dies zu tun Erfahren Sie, was Software-Lieferkettensicherheit ist.

Die Sicherheit der Software-Lieferkette bezieht sich auf die Reihe standardisierter Praktiken, die eingeführt werden, um Ihre Software über den gesamten Softwareentwicklungslebenszyklus hinweg vor potenziellen Schwachstellen zu schützen, angefangen bei der Anwendungsentwicklung bis hin zur kontinuierlichen Integration und Bereitstellung (CI/CD-Pipeline).

Es ist wichtig, dass Sicherheitsteams die Liste der Best Practices für die Sicherheit der Software-Lieferkette verstehen und befolgen, um die Sicherheit der Software-Lieferkette ihres Unternehmens zu gewährleisten. In diesem Beitrag werden die Best Practices für die Lieferkette beschrieben, die Sie kennen sollten.

Best Practices zur Sicherung Ihrer Software-Lieferkette

In diesem Abschnitt wird auf Standardverfahren verwiesen, die Entwickler und Produktorganisationen befolgen müssen, um ihre Software-Lieferkette zu sichern. Sie können diese Richtlinien als Grundgerüst verwenden, um Sicherheitspraktiken für Ihr Unternehmen in den verschiedenen Phasen Ihres Software-Lebenszyklus zu beschreiben, zu bewerten und zu messen. Diese Best Practices erstrecken sich über die gesamte Erwerbs-, Entwicklungs- und Bereitstellungsphase der Software-Lieferkette, um die Integrität Ihrer Entwicklungsumgebung, Ihres Quellcodes und Ihres Endprodukts sicherzustellen.

Erwerben Sie gut gesicherte Komponenten

Die Integration von Drittanbieterkomponenten in Software ist für Entwickler gängige Praxis, da sie dadurch vorhandene API-Funktionen nutzen können, um gewünschte Funktionalitäten bereitzustellen, anstatt sie von Grund auf neu zu entwickeln. Komponenten von Drittanbietern können entweder in Form kommerzieller proprietärer Software oder kostenloser Open-Source-Tools vorliegen. Bei der Beschaffung einer dieser Komponenten ist es wichtig, dass Sie die Sicherheit als eines der wichtigsten Kriterien betrachten, die die Softwarekomponente erfüllen muss.

Um die Sicherheit von Komponenten von Drittanbietern zu ermitteln, müssen Sie möglicherweise erweiterte Sicherheitsanalysen durchführen, z. B. eine Analyse der sicheren Zusammensetzung, eine Analyse der Schwachstellendatenbank, eine Quellcodebewertung und eine Risikobewertungsanalyse. Das Ergebnis dieser Prüfungen hilft festzustellen, ob diese Komponente sicher ist und für Ihr Produkt zugelassen werden sollte

Darüber hinaus müssen ausgewählte Komponenten kontinuierlich mithilfe eines automatisierten Schwachstellen-Tracking-Dienstes überwacht werden, um Schwachstellen schnellstmöglich zu erkennen und umgehend zu beseitigen.

Erstellen Sie intern sichere Softwarekomponenten unter Einhaltung sicherer Codierungspraktiken

Obwohl in Ihre Software integrierte externe Softwarekomponenten wichtig sind, hängen die Sicherheit und Integrität von Softwareprodukten auch von den sicheren Codierungspraktiken ab, die Sie intern befolgen.

Jede Organisation benötigt ein umfassendes Framework für den Softwareentwicklungslebenszyklus, das sichere Codierungspraktiken beinhaltet, um sicherzustellen, dass erstellte Artefakte den festgelegten Richtlinien entsprechen.

Zunächst einmal hängt die Integrität Ihrer Softwareprodukte und der Artefakte, die Sie intern erstellen, von der Qualität Ihres Teams ab. Zu Ihrem Entwicklungsteam sollten Entwicklungsexperten, Qualitätssicherungsexperten, Cybersicherheitsexperten und Bauingenieure mit guten Kenntnissen der Standardsicherheitspraktiken gehören.

Zum Produktmanagementteam sollten auch Sicherheitsarchitekten, Produktmanager und Produktleiter gehören, die daran arbeiten, die Einhaltung sicherer Entwicklungsrichtlinien sicherzustellen. Zu den grundlegenden Strategien, um sicherzustellen, dass Sie intern sichere Softwareartefakte erstellen, gehören:

• Generierung von Design- und Architekturdokumenten für jedes Artefakt
• Erstellen von Bedrohungsmodellen für Softwareprodukte
• Definieren und Implementieren von Sicherheitstests
• Festlegen spezifischer Freigabekriterien für die Produktbewertung
• Festlegung von Richtlinien zum Umgang mit Schwachstellen für jedes Produkt
• Dokumentation und Veröffentlichung von Sicherheitsverfahren für jede Softwareversion

 Nutzen Sie sichere Software-Toolchains und Kompatibilitätsbibliotheken von Drittanbietern

Viele integrierte Entwicklungsumgebungen (IDE), die im Softwareentwicklungsprozess verwendet werden, sind eigenständig. Das bedeutet, dass Sie damit verschiedene Schritte im Entwicklungsprozess wie Codierung, Kompilierung, Paketierung und Debugging von Code ausführen können – alles mit demselben Tool. Einige IDEs verfügen auch über Tools zum Verbinden einer Quelle mit einem externen Repository. IDEs mit dieser Funktion unterstützen mehrere Compilersprachen. Zusätzlich zu diesen Kernfunktionen können Entwickler möglicherweise die Funktionen der von ihnen verwendeten IDE mit Plugins erweitern. Aufgrund der Komplexität nicht vertrauenswürdiger Quellen wie dieser stellt dies eine potenzielle Schwachstelle für die lokale Entwicklungsumgebung dar.

Um die Sicherheit Ihrer Entwicklungsumgebung zu gewährleisten, müssen alle IDEs und Plugins, die in der Umgebung verwendet werden sollen, geprüft und vorab genehmigt werden, nachdem sie auf Schwachstellen gescannt und validiert wurden.

Neben Plugins, die die Funktionen Ihrer Build-Umgebung erweitern, sind Software-Toolchains und Kompatibilitätsbibliotheken eine weitere Kategorie von Build-Tools von Drittanbietern, die Sie möglicherweise auf Schwachstellen überprüfen müssen. Diese Betriebssystemtools von Drittanbietern werden in der Entwicklungsumgebung installiert, um Ihnen die Verwendung spezifischer Dienstprogramme und Befehle zu ermöglichen, die für dieses Betriebssystem einzigartig sind. Beispielsweise kann eine Windows-Entwicklungsumgebung während des Erstellungsprozesses einige Betriebssystembefehle erfordern, die nur für das Linux-Betriebssystem gelten, um während des Produktionsprozesses Kompatibilität zwischen beiden Systemen sicherzustellen.

Ebenso helfen Ihnen API-Konvertierungsbibliotheken dabei, eine gemeinsame Codierungsumgebung für zwei verschiedene Betriebssysteme zu erstellen. Diese API-Toolchains sind Open-Source- und kommerzielle Tools und müssen auf Schwachstellen überprüft werden, bevor sie für Ihre Build-Umgebung übernommen und für Ihr Projekt verwendet werden.

Reduzieren Sie die Änderung oder Ausnutzung des Quellcodes durch Insider

Nach Angaben der Cybersecurity and Infrastructure Security Agency (CISA) ist ein Insider jede Person mit autorisiertem Zugriff oder Wissen über die Ressourcen einer Organisation. Personen, die Zugang zu Ihren Einrichtungen, Netzwerken, Geräten und Systemen haben oder hatten, können möglicherweise absichtlich oder unwissentlich die Integrität Ihres Softwareprodukts gefährden.

Im Rahmen der Bemühungen, Ihre Software zu schützen, müssen Sie sicherstellen, dass im Entwicklungsprozess Richtlinien vorhanden sind, um zu verhindern, dass Insider, beispielsweise gefährdetes Personal, schlecht ausgebildete Ingenieure oder inaktive Mitarbeiter, schädlichem Code in Ihrem Produktionscode absichtlich oder unbeabsichtigt ausgesetzt werden. Zu den Maßnahmen, die Sie ergreifen können, um dies zu mildern, gehören:

• Ausgewogener und authentifizierter Quellcode-Check-in-Prozess
• Automatisierte Sicherheitsüberprüfung auf Schwachstellen
• Sichere Schulung zur Softwareentwicklung
• Härten der Entwicklungsumgebung
• Priorisierung von Codeüberprüfungen

Speichern Sie Code oder ausführbare Dateien und überprüfen Sie alle Änderungen vor der Genehmigung

Die Versionierung ist eine der Standardpraktiken, die dazu beitragen kann, die Integrität Ihrer Software aufrechtzuerhalten. Als Teil Ihres kontinuierlichen Integrations- und Bereitstellungsprozesses (CI/CD-Pipeline) müssen Sie ein Repository verwalten, um Ihren Code und Ihre ausführbaren Dateien zu speichern. Dadurch erhalten Sie einen Arbeitsverlauf Ihres Codes, sodass Sie leicht nachverfolgen können, was bis zu diesem Zeitpunkt in den Entwicklungsstapel gelangt ist.

Sie benötigen außerdem ein kontinuierliches Genehmigungssystem, um alle an Ihrer Software vorgenommenen Änderungen zu überprüfen, bevor sie genehmigt werden. Dies ist besonders nützlich, wenn Sie innerhalb von Teams mit anderen Entwicklern zusammenarbeiten. In diesem Fall ist die Behebung von Problemen einfacher, da Sie leicht erkennen können, welche Änderungen vorgenommen werden und wer sie vornimmt.

Unabhängig davon, wie einfach oder komplex die Software ist, die Sie erstellen, können Sie mit einem Quellcode- oder Versionskontrollsystem problemlos alle an Ihrem Code vorgenommenen Änderungen sehen und verfolgen, bei Bedarf den Versionsverlauf verfolgen und sogar zu einer früheren Version Ihres Codes zurückkehren Code, wenn nötig.

Erstellen und pflegen Sie eine SBOM für jedes erstellte Softwarepaket

Das Software-Stückliste ist eine wichtige Dokumentation, die alle in Ihr Softwareprodukt integrierten Drittanbieterkomponenten detailliert beschreibt. Eine SBOM erleichtert die Validierung aller genehmigten Komponenten einer Software und die einfache Identifizierung etwaiger Schwachstellen oder Mängel. Für jedes Softwarepaket, das Sie erstellen, sollten Sie auch eine SBOM dafür erstellen und verwalten.

Eine Software-Stückliste kann auf der Grundlage der Spezifikationen erstellt werden, die in Standardformaten wie den Tags Software Package Data Exchange (SPDX), CycloneDX und Software Identification (SWID) definiert sind, wie sie jeweils von Linux, OWASP und NIST definiert sind.

Für jedes von Ihnen erstellte Softwareprodukt sollten die Lieferanten oder Eigentümer der von Ihnen verwendeten Drittanbieterkomponenten eine umfassende Software-Stückliste bereitstellen. Die Leistungen für Ihr Projekt und die vom Lieferanten bereitgestellten SBOMs können auch mithilfe eines Tools zur Zusammensetzungsanalyse (SCA) validiert werden.

Auch wenn der Lieferant keine SBOM bereitstellt, kann die mit dem Software-Kompositionsanalysetool generierte SBOM dennoch die erforderlichen Informationen zur Beschreibung der Drittanbieterkomponenten der Software liefern. Der Prozess von Generieren von SBOMs sollte automatisiert werden. SBOM-Automatisierung Dies ist von entscheidender Bedeutung, da die Drittanbieter und Entwickler jedes Mal, wenn eine Software eines Drittanbieters geändert wird, eine neue SBOM erstellen müssen und dies manuell nicht praktikabel ist. Die aktualisierte SBOM beschreibt alle Verbesserungen oder Änderungen im Komponentencode und deren Beziehung dazu das Softwareprodukt.

Härten Sie die Build-Umgebung ab

Eine Möglichkeit, die Integrität Ihrer Software sicherzustellen, besteht darin, die Entwicklungsumgebung gegen potenzielle Schwachstellen abzusichern. Dies umfasst sowohl die einzelne Entwicklerumgebung als auch die gesamte Produktionsumgebung.

Unabhängig davon, ob Ihre Build-Umgebung in der Cloud oder vor Ort gehostet wird, müssen Sie sie konfigurieren und Maßnahmen ergreifen, um den Server und das Netzwerk zu sichern und gleichzeitig zu kontrollieren, wer Zugriff auf was hat. Wenn Sie bei der Optimierung und Sicherung der Build-Umgebung auf diese Weise die gebotene Sorgfalt walten lassen, stellen Sie die Integrität Ihres Quellcodes und des Endprodukts sicher.

Die Sicherung der Build-Pipeline umfasst die Sicherung aller Systeme, die Sie während des Build-Prozesses für Ihr Produkt verwenden. Dazu gehören Code-Repositorys, Signierserver, Engineering-Workstations, Bereitstellungsserver usw. Zu den Maßnahmen, die Sie zur Sicherung Ihrer Build-Pipeline-Infrastruktur ergreifen können, gehören:

Sperren Sie Systeme

Um Ihre Systeme zu schützen, sollten Sie den Systembetrieb auf bestimmte Funktionen beschränken, die das System ausführen soll. Beispielsweise sollte Ihr Build-System nur für Build-Vorgänge und nichts anderes verwendet werden.

Begrenzen Sie externe und Off-LAN-Netzwerkaktivitäten

Sowohl ein- als auch ausgehende Netzwerkaktivitäten können Ihr System potenziell Risiken aussetzen Attacken. Sie sollten alle externen und Off-LAN-Aktivitäten blockieren und externe Verbindungen auf die erforderlichen URLs beschränken.

Überwachen Sie Systeme auf Datenlecks

Um die Integrität Ihres Produktquellcodes sicherzustellen, sollten Sie Ihre Cybersicherheitsmaßnahmen einrichten, um Ihr Repository, Ihre Workstation und andere Teile Ihrer Build-Umgebung vor der Exfiltration und Infiltration von Daten zu schützen. Dazu gehört das Blockieren jeglichen böswilligen Verhaltens, das Isolieren von Apps und das Einrichten von Erkennungssystemen, um jeden Einbruch sofort zu erkennen.

Konfigurieren Sie Ihre Versionskontrollpipeline

Ihre Codepipeline sollte einer Versionskontrolle unterliegen. Bei Änderungen an Ihrem Produkt sollten Aktualisierungen am Konfigurationscode und nicht an den tatsächlichen Systemen vorgenommen werden.

Multi-Faktor-Authentifizierung

Jedes System, das Teil Ihrer Build-Umgebung ist, sollte nach Möglichkeit mit Multi-Faktor-Authentifizierung konfiguriert werden. Zusätzliche Sicherheitsmaßnahmen wie rollenbasierter Zugriff, geringste Privilegien usw. sollten ebenfalls eingeführt werden. Die NIST-Richtlinie empfiehlt außerdem ein duales Autorisierungssystem für alle kritischen oder sensiblen Systeme in Ihrer Build-Umgebung.

Trennen Sie Ihr Engineering-Netzwerk

Der Zugriff auf Ihr Build-System sollte nur über ein isoliertes Engineering-Netzwerk erfolgen, das sich vom restlichen Netzwerk Ihres Unternehmens unterscheidet. Wenn möglich, sollte das Engineering-Netzwerk offline sein.

Analysieren Sie jede Schwachstelle, um ausreichend Informationen für die Planung ihrer Behebung zu sammeln

Bei der Entwicklung von Software müssen Maßnahmen ergriffen werden, um sicherzustellen, dass Ihr Produkt und alle seine Komponenten frei von bekannten Schwachstellen mit hohem Risiko sind. Wenn ein Kunde neue Schwachstellen entdeckt oder meldet, sollten Sie ebenfalls sofort auf den Vorfall reagieren. In einigen Fällen ist es erforderlich, dass Sie Ihr System aktualisieren, um die mit der neu entdeckten Sicherheitslücke verbundenen Risiken zu mindern.

Softwareanbieter sollten über einen Prozess verfügen, um Aktualisierungen oder Berichte über potenzielle Schwachstellen oder Mängel in ihren Produkten anzunehmen, entweder von externen Forschern oder Kunden. Sie benötigen außerdem ein automatisiertes System, das Sie über Schwachstellenaktualisierungen benachrichtigt, die von vertrauenswürdigen Organisationen wie der Cybersecurity & Infrastructure Security Agency (CISA) angekündigt wurden.

Jede Organisation benötigt eine interne Richtlinie zum Schwachstellenmanagement, die den Standardrichtlinien entspricht. Warnungen zu Bedrohungen mit hohem Risiko sollten auf der Grundlage der Beziehung zwischen Ihrem Produkt und seinen Komponenten bewertet werden, die möglicherweise von der gemeldeten Sicherheitslücke betroffen sind. Ihr Engineering-Team muss außerdem über ein umfassendes System zur Überprüfung, Diagnose und möglicherweise Lösung von Problemen verfügen

Komponentenwartung

Ein Softwareprodukt und seine Komponenten sind niemals statisch. Sie sollten bedenken, dass in Ihre Produkte integrierte Komponenten von Drittanbietern vom Lieferanten regelmäßig geändert oder aktualisiert werden können. Sie sollten diese Änderungen insbesondere dann überwachen, wenn sie mit Common Vulnerabilities and Exposures (CVEs) in Zusammenhang stehen.

Ein großer Teil der Wartung Ihrer Softwarekomponenten besteht in der Überwachung standardmäßiger CVE-Berichtsmechanismen und anderer Supportkanäle, um festzustellen, ob neu identifizierte Schwachstellen in einer in Ihr Produkt integrierten Drittanbieterkomponente die Integrität Ihrer eigenen Systeme beeinträchtigen, und um geeignete Maßnahmen zur Risikominderung zu ergreifen ( wenn überhaupt).

Wenn Sie Komponenten von Drittanbietern auswählen, die in Ihr Produkt aufgenommen werden sollen, sollten Sie den Vertrag überprüfen, um sicherzustellen, dass der Eigentümer der Komponente über Richtlinien verfügt, wie er Produktorganisationen über Aktualisierungen seiner Systeme, das Vorhandensein von Schwachstellen und den Zeitrahmen für die Schwachstelle informiert Lösung sowie alle Aktionen, die Sie möglicherweise auf Ihrer Seite durchführen müssen, um optimale Sicherheit zu gewährleisten.