Bewährte Methoden für eine sichere Softwarelieferkette

Open Source ist überall. Man findet Open Source in vielen proprietären Codebasen und Communityprojekten. Organisationen und Einzelpersonen stellen sich heutzutage nicht die Frage, ob Software auf Open Source basiert oder nicht, sondern welcher Open-Source-Code verwendet werden sollte und in welchem Umfang.

Wenn Sie Ihre Lieferkette nicht kennen, kann ein Sicherheitsrisiko in einer Ihrer Abhängigkeiten in der vorgelagerten Lieferkette verheerend sein. Das führt dazu, dass Sie und Ihre Kunden für eine potenzielle Kompromittierung anfällig werden. In diesem Dokument wird ausführlicher darauf eingegangen, was mit dem Begriff „Softwarelieferkette“ gemeint ist, warum dieser von Bedeutung ist und wie Sie dazu beitragen können, die Lieferkette Ihres Projekts mit Best Practices zu schützen.

Abhängigkeiten

Der Begriff „Softwarelieferkette“ umfasst alle Elemente, die in Ihrer Software einfließen, und auch woher diese stammen. Dabei handelt es sich um die Abhängigkeiten und Eigenschaften Ihrer Abhängigkeiten, von denen Ihre Softwarelieferkette abhängt. Als Abhängigkeit werden alle Elemente bezeichnet, die Ihre Software benötigt, um ausgeführt werden zu können. Dabei kann es sich um Codeblöcke, Binärdateien oder andere Komponenten handeln und woher diese stammen, z. B. von einem Repository oder Paket-Manager.

Zur Lieferkette gehören außerdem die Person, die den Code geschrieben hat, der Zeitpunkt der Bereitstellung, die Art der Überprüfung auf Sicherheitsprobleme, bekannte Sicherheitsrisiken, unterstützte Versionen, Lizenzinformationen und alle sonstigen Prozesse.

Ihre Lieferkette umfasst auch andere Teile Ihres Stapels als nur die einzelne Anwendung, zum Beispiel Ihre Build- und Paketskripts oder die Software, die die Infrastruktur ausführt, auf der Ihre Anwendung basiert.

Sicherheitsrisiken

Heute sind Softwareabhängigkeiten in allen Bereichen zu finden. Es kommt häufig vor, dass Softwarehersteller Hunderte von Open-Source-Abhängigkeiten für Funktionalitäten verwenden, damit sie diese nicht selbst schreiben mussten. Dies kann bedeuten, dass der größte Teil Ihrer Anwendung aus Code besteht, den Sie nicht erstellt haben.

Da Sie Ihre Abhängigkeiten von Drittanbietern oder Open-Source-Abhängigkeiten vermutlich nicht so streng kontrollieren können wie den Code, den Sie selbst schreiben, können diese mögliche Sicherheitsrisiken in Ihrer Lieferkette hervorrufen.

Wenn Abhängigkeiten ein Sicherheitsrisiko aufweisen, ist die Wahrscheinlichkeit hoch, dass auch ein Sicherheitsrisiko bei Ihnen auftritt. Dies kann frustrierend sein, da sich eine Ihrer Abhängigkeiten unter Umständen ändert, ohne dass Sie dies überhaupt bemerken. Selbst wenn ein in einer Abhängigkeit vorhandenes Sicherheitsrisiko derzeit noch nicht ausnutzbar ist, kann es in der Zukunft so weit kommen.

Die Tatsache, dass Sie die Arbeit Tausender Open-Source-Entwickler und Bibliotheksersteller nutzen können, bedeutet auch, dass Tausende fremder Entwickler effektiv an Ihrem Produktionscode mitarbeiten können. Ihr Produkt wird durch Ihre Softwarelieferkette durch nicht gepatchte Sicherheitsrisiken, arglose Fehler oder sogar böswillige Angriffe auf Abhängigkeiten beeinträchtigt.

Kompromittierungen in der Lieferkette

Die gängige Definition einer Lieferkette stammt aus der Fertigungsindustrie und bezeichnet die Prozesskette von der Herstellung bis zum Vertrieb. Diese umfasst die Planung, die Materialbeschaffung, den Herstellungsprozess und den Verkauf. Eine Softwarelieferkette ist ähnlich, nur dass anstelle der Materialien Code genutzt wird. Die Fertigung ist hier die Entwicklung. Anstatt das Erz aus der Erde zu holen, wird Code von Anbietern bezogen (kommerziell oder Open Source), und in der Regel stammt Open-Source-Code aus Repositorys. Das Hinzufügen von Code aus einem Repository bedeutet, dass Ihr Produkt von diesem Code abhängig ist.

Ein Angriff auf die Softwarelieferkette liegt beispielsweise vor, wenn bösartiger Code absichtlich zu einer Abhängigkeit hinzugefügt wird, wobei der Code mithilfe der Lieferkette dieser Abhängigkeit an die Opfer verteilt wird. Angriffe auf Lieferketten sind ernst zu nehmen. Es gibt viele Methoden zum Angriff auf eine Lieferkette, zum Beispiel das direkte Einfügen von schädlichem Code als neuer Mitwirkender, das Übernehmen des Kontos eines Mitwirkenden, ohne dass andere dies bemerken, oder sogar das Kompromittieren eines Signaturschlüssels, um Software zu verteilen, die nicht offiziell Teil der Abhängigkeit ist.

Ein Angriff auf eine Softwarelieferkette ist an und für sich selten das Endziel, sondern eine erste gute Gelegenheit für einen Angreifer, Schadsoftware einzuschleusen oder eine Hintertür für zukünftigen Zugriff bereitzustellen.

Nicht gepatchte Software

Die Verwendung von Open Source hat beträchtliche Ausmaße erreicht und wird wahrscheinlich nicht so bald wieder abnehmen. Da wir die Verwendung von Open-Source-Software nicht unterbinden, stellt die nicht gepatchte Software die größte Bedrohung für die Sicherheit von Lieferketten dar. Wie können Sie ausgehend von dieser Tatsache mit dem Risiko umgehen, dass eine Abhängigkeit Ihres Projekts ein Sicherheitsrisiko aufweist?

• Kenntnis Ihrer Umgebung: Dies erfordert die Ermittlung Ihrer Abhängigkeiten und der transitiven Abhängigkeiten, um die Risiken dieser Abhängigkeiten wie Sicherheitsrisiken oder Lizenzierungseinschränkungen zu verstehen.
• Verwalten Ihrer Abhängigkeiten: Wenn ein neues Sicherheitsrisiko erkannt wird, müssen Sie feststellen, ob Sie betroffen sind. Wenn dies der Fall ist, führen Sie ein Update auf die aktuelle Version und das neueste verfügbare Sicherheitspatch durch. Dies ist besonders wichtig, um Änderungen zu prüfen, die neue Abhängigkeiten einführen, oder ältere Abhängigkeiten in regelmäßigen Abständen zu überprüfen.
• Überwachen der Lieferkette: Die Überwachung erfolgt durch Überprüfung der Kontrollmechanismen, die Ihnen zum Verwalten Ihrer Abhängigkeiten zur Verfügung stehen. Auf diese Weise können Sie restriktivere Bedingungen für Ihre Abhängigkeiten erzwingen.

Nachfolgend werden verschiedene Tools und Techniken behandelt, die von NuGet und GitHub bereitstellt werden und die Sie sofort nutzen können, um potenzielle Risiken in Ihrem Projekt zu beheben.

Wissen, was sich in Ihrer Umgebung befindet

NuGet-Abhängigkeitsdiagramm

📦 Paketnutzer

Sie können Ihre NuGet-Abhängigkeiten in Ihrem Projekt anzeigen, indem Sie direkt die entsprechende Projektdatei öffnen.

Diese ist in der Regel an zwei Stellen vorhanden:

• packages.config – im Projektstamm
• <PackageReference> – in der Projektdatei

Je nachdem, welche Methode Sie zum Verwalten Ihrer NuGet-Abhängigkeiten verwenden, können Sie auch Visual Studio verwenden, um Ihre Abhängigkeiten direkt im Projektmappen-Explorer oder im NuGet-Paket-Manager anzuzeigen.

In CLI-Umgebungen können Sie den Befehl dotnet list package verwenden, um Ihr Projekt oder die Abhängigkeiten der Projektmappe aufzulisten.

Weitere Informationen zum Verwalten von NuGet-Abhängigkeiten finden Sie in der folgenden Dokumentation.

GitHub-Abhängigkeitsdiagramm

📦 Paketnutzer | 📦🖊 Paketersteller

Sie können das Abhängigkeitsdiagramm von GitHub verwenden, um die Pakete, von denen Ihr Projekt abhängt, und die von ihm abhängigen Repositorys anzuzeigen. Dies kann Ihnen dabei helfen, erkannte Sicherheitsrisiken in den Abhängigkeiten anzuzeigen.

Weitere Informationen zu Repositoryabhängigkeiten von GitHub finden Sie in der folgenden Dokumentation.

Abhängigkeitsversionen

📦 Paketnutzer | 📦🖊 Paketersteller

Um eine sichere Lieferkette von Abhängigkeiten sicherzustellen, sollten Sie darauf achten, dass alle Ihre Abhängigkeiten und Tools regelmäßig auf die neueste stabile Version aktualisiert werden, da diese häufig die neuesten Funktionen und Sicherheitspatches für bekannte Schwachstellen enthält. Ihre Abhängigkeiten können Code, von dem Sie abhängig sind, von Ihnen verwendete Binärdateien, von Ihnen verwendete Tools und andere Komponenten enthalten. Dies kann enthalten:

• Visual Studio
• .NET SDK und .NET-Runtime
• NuGet
• NuGet-Pakete

Verwalten Ihrer Abhängigkeiten

Veraltete und anfällige NuGet-Abhängigkeiten

📦 Paketnutzer | 📦🖊 Paketersteller

Sie können die dotnet CLI verwenden, um alle bekannten veralteten oder anfälligen Abhängigkeiten aufzulisten, die sich möglicherweise in Ihrem Projekt oder in der Projektmappe befinden. Sie können den Befehl dotnet list package --deprecated oder dotnet list package --vulnerable verwenden, um eine Liste bekannter veralteter Elemente oder Sicherheitsrisiken bereitzustellen.

Anfällige GitHub-Abhängigkeiten

📦 Paketnutzer | 📦🖊 Paketersteller

Wenn Ihr Projekt auf GitHub gehostet wird, können Sie die GitHub-Sicherheit nutzen, um Sicherheitsrisiken und Fehler in Ihrem Projekt zu finden. Dependabot behebt diese Fehler anschließend, indem ein Pull Request für Ihre Codebasis eröffnet wird.

Ein Ziel der „Shift Left“-Bewegung (Linksverschiebung) ist das Abfangen anfälliger Abhängigkeiten vor deren Einführung. Wenn Sie Informationen zu Ihren Abhängigkeiten wie die Lizenz, transitive Abhängigkeiten und das Alter der Abhängigkeiten haben, können Sie genau das tun.

Weitere Informationen zu Dependabot-Warnungen und -Sicherheitsupdates finden Sie in der folgenden Dokumentation.

NuGet-Feeds

📦 Paketnutzer

Wenn Sie mehrere öffentliche und private NuGet-Quellfeeds verwenden, kann ein Paket aus allen Feeds heruntergeladen werden. Sie sollten wissen, aus welchen Feeds Ihr Paket stammt, um sicherzustellen, dass Ihr Build vorhersagbar und sicher vor bekannten Angriffen wie einer Dependency Confusion (Abhängigkeitsverwechslung) ist. Sie können einen einzelnen Feed oder privaten Feed mit Upstreamingfunktionen für den Schutz verwenden.

Weitere Informationen zum Schützen Ihrer Paketfeeds finden Sie unter 3 Möglichkeiten zur Risikominderung mit privaten Paketfeeds.

Wenn Sie einen privaten Feed verwenden, lesen Sie die bewährten Sicherheitspraktiken für die Verwaltung von Anmeldeinformationen.

Clientvertrauensrichtlinien

📦 Paketnutzer

Es gibt Richtlinien, die Sie aktivieren können und die erfordern, dass Ihre verwendeten Pakete signiert sind. So können Sie einem Paket vertrauen, sofern es vom Ersteller signiert ist oder sich im Besitz eines bestimmten Benutzers oder Kontos ist, dessen Repository von NuGet.org signiert wurde.

Informationen zum Konfigurieren von Clientvertrauensrichtlinien finden Sie in der folgenden Dokumentation.

Sperrdateien

📦 Paketnutzer

Sperrdateien speichern den Hash des Paketinhalts. Wenn der Inhaltshash eines Pakets, das Sie installieren möchten, mit der Sperrdatei übereinstimmt, wird die Wiederholbarkeit des Pakets sichergestellt.

Informationen zum Aktivieren von Sperrdateien finden Sie in der folgenden Dokumentation.

Paketquellenzuordnung

📦 Paketnutzer

Mithilfe der Paketquellenzuordnung können Sie in Ihrer Datei „nuget.config“ zentral deklarieren, aus welcher Quelle die einzelnen Pakete in Ihrer Projektmappe wiederhergestellt werden sollen.

Informationen zum Aktivieren der Paketquellenzuordnung finden Sie in der folgenden Dokumentation.

Überwachen der Lieferkette

Geheime Überprüfung in GitHub

📦🖊 Paketersteller

GitHub durchsucht Repositorys nach NuGet-API-Schlüsseln, um betrügerische Fälle von Geheimnisnutzung zu verhindern, die versehentlich committet wurden.

Weitere Informationen zur Geheimnisüberprüfung finden Sie in den Infos zur Geheimnisüberprüfung.

Erstellen der Paketsignierung

📦🖊 Paketersteller

Die Erstellung von Signierungen ermöglicht einem Paketersteller, ein Paket mit seiner Identität zu versehen, sodass ein Kunde nachverfolgen kann, ob es von diesem Ersteller stammt. Sie werden so vor Inhaltsmanipulation geschützt. Zudem fungiert diese Methode als „Single Source of Truth“(einziger Punkt der Wahrheit) bezüglich des Ursprungs und der Echtheit des Pakets. In Kombination mit Clientvertrauensrichtlinien können Sie so überprüfen, ob ein Paket von einem bestimmten Ersteller stammt.

Informationen zum Signieren eines Pakets als Ersteller finden Sie unter Signieren eines Pakets.

Reproduzierbare Builds

📦🖊 Paketersteller

Reproduzierbare Builds erstellen Binärdateien, die bei jeder Erstellung von Byte für Byte identisch sind, und enthalten Quellcodelinks und Compilermetadaten, die es Paketbenutzer*innen ermöglichen, die Binärdatei direkt neu zu erstellen und zu überprüfen, ob die Buildumgebung nicht kompromittiert wurde.

Weitere Informationen zu reproduzierbaren Builds finden Sie unter Erstellen von Paketen mit SourceLink und in der Spezifikation Validierung reproduzierbarer Builds.

Zweistufige Authentifizierung

📦🖊 Paketersteller

Jedes Konto auf nuget.org hat 2FA aktiviert. Dadurch wird eine zusätzliche Sicherheitsebene hinzugefügt, wenn Sie sich bei Ihrem GitHub-Konto oder Ihrem NuGet.org-Konto anmelden.

Reservierung für Paket-ID-Präfixe

📦🖊 Paketersteller

Wenn Sie die Identität Ihrer Pakete schützen möchten, können Sie ein Paket-ID-Präfix mit Ihrem Namespace reservieren, um dem Paket einen Besitzer zuzuordnen. Voraussetzung dafür ist, dass das Paket-ID-Präfix ordnungsgemäß die festgelegten Kriterien erfüllt.

Informationen zum Reservieren von ID-Präfixen finden Sie unter Reservierung von Paket-ID-Präfix.

Einstellen und Aufheben der Auflistung eines anfälligen Pakets

📦🖊 Paketersteller

Wenn Sie ein Sicherheitsrisiko in einem von Ihnen erstellten Paket erkannt haben, sollten Sie das Paket zum Schutz des .NET-Paketökosystems einstellen und die Auflistung dafür aufheben, sodass Benutzer, die nach Paketen suchen, es nicht mehr finden können. Wenn Sie ein Paket nutzen, das veraltet und nicht aufgelistet ist, sollten Sie es unbedingt außer Betrieb nehmen.

In der folgenden Dokumentation unter Als veraltet gekennzeichnete Pakete und Aufheben der Auflistung eines Pakets erfahren Sie, wie Sie ein Paket als veraltetet markieren und aus einer Auflistung entfernen.

Zusammenfassung

Ihre Softwarelieferkette besteht aus allen Elementen, die in Ihren Code einfließen und sich auf diesen auswirken. Obwohl Kompromittierungen in der Lieferkette ein aktuelles Thema sind und immer öfter auftreten, sind sie noch immer selten. Es hat also höchste Priorität, Ihre Lieferkette zu schützen, indem Sie sich Ihre Abhängigkeiten bewusst machen und diese verwalten sowie Ihre Lieferkette überwachen.

Sie haben unterschiedliche Methoden kennengelernt, die von NuGet und GitHub bereitgestellt werden, mit denen Sie noch heute Ihre Einblicke, die Verwaltung und die Überwachung Ihrer Lieferkette optimieren können.

Weitere Informationen zum Schützen der weltweit eingesetzten Software finden Sie im Sicherheitsbericht von „The State of the Octoverse 2020“.