Bewährte Methoden für eine sichere Softwarelieferkette

Open Source ist überall. Man findet es 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.

Der Zustand des Octoverse 2020 – Open Source

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.

Zu den Informationen gehören, wer den Code geschrieben hat, wann er beigetragen wurde, wie er auf Sicherheitsprobleme überprüft wurde, bekannte Schwachstellen, unterstützte Versionen, Lizenzinformationen und alle relevanten Aspekte, die zu jedem Zeitpunkt des Prozesses Einfluss haben.

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.

Schwachstellen

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.

"Der Stand des Octoverse 2020 – Abhängigkeiten"

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 in einer Abhängigkeit ein Sicherheitsrisiko existiert, das derzeit noch nicht ausnutzbar ist, kann es in Zukunft ausnutzbar werden.

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. Statt Fertigung ist es 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 real. 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.

The State of the Octoverse 2020 – Schwachstellenlebenszyklus

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?

• Das Wissen über Ihre 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 Sie Ihre 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.

The State of the Octoverse 2020 – Warnungen

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

Pakete mit bekannten Sicherheitsrisiken

📦 Paketnutzer | Paketautor

.NET 8 und Visual Studio 17.8 haben NuGetAudit hinzugefügt, das während der Wiederherstellung vor direkten Paketen mit bekannten Schwachstellen warnt. NET 9 und Visual Studio 17.12 haben den Standard geändert, um auch vor transitiven Paketen zu warnen.

NuGetAudit erfordert eine Quelle, die eine Datenbank bekannter Schwachstellen bereitstellt. Verwenden Sie nuget.org nicht als Paketquelle, sollten Sie es als Audit-Quelle hinzufügen.

Zu dem Zeitpunkt, an dem NuGet Sie warnt, ist die Sicherheitslücke bereits öffentlich bekannt. Angreifer können diese öffentliche Offenlegung nutzen, um Angriffe auf Ziele zu entwickeln, die ihre Anwendungen nicht gepatcht haben. Wenn Sie also eine Warnung erhalten, dass ein Paket, das Ihr Projekt verwendet, eine bekannte Sicherheitslücke aufweist, sollten Sie schnell handeln.

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 Projektstammverzeichnis
• – 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 die Abhängigkeiten Ihres Projekts oder Ihrer Lösung aufzulisten. Sie können den dotnet nuget why-Befehl auch verwenden, um zu verstehen, warum transitive Pakete (d. h. Pakete, die nicht direkt von Ihrem Projekt referenziert werden) in den Paketgraphen Ihres Projekts aufgenommen werden.

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

GitHub-Abhängigkeitsdiagramm

📦 Paketverbraucher | 📦🖊 Paketautor

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 den Abhängigkeiten von GitHub-Repositories finden Sie in der folgenden Dokumentation.

Abhängigkeitsversionen

📦 Paketkonsument | 📦🖊 Paketautor

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 & 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 Ihrer Projektmappe befinden. Sie können den Befehl dotnet list package --deprecated oder dotnet list package --vulnerable verwenden, das Ihnen eine Liste aller bekannten veralteten Elemente oder Schwachstellen bereitstellt. NuGetAudit kann Sie vor bekannten anfälligen Abhängigkeiten warnen, und ist standardmäßig aktiviert, wenn eine Quelle eine Schwachstellen-Datenbank bereitstellt.

Anfällige GitHub-Abhängigkeiten

📦 Paketbenutzer | Paketautor

Wenn Ihr Projekt auf GitHub gehostet wird, können Sie die GitHub-Sicherheit nutzen, um Sicherheitslücken und Fehler in Ihrem Projekt zu finden. Dependabot behebt diese automatisch, indem er einen Pull Request gegen Ihre Codebasis eröffnet.

Ein Ziel der „Shift Left“-Bewegung ist es, anfällige Abhängigkeiten abzufangen, bevor sie eingeführt werden. 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-Konfiguration

📦 Paketnutzer

Fügen Sie eine nuget.config Datei im Stammverzeichnis Ihres Projekt-Repositorys hinzu. Dies gilt als bewährte Methode, da sie die Wiederholbarkeit fördert und sicherstellt, dass verschiedene Benutzer dieselbe NuGet-Konfiguration haben. Es wird empfohlen, Elemente hinzuzufügen clear , um sicherzustellen, dass keine benutzer- oder computerspezifische Konfiguration angewendet wird. Erfahren Sie mehr darüber, wie Einstellungen angewendet werden.

Beispiel:

<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceMapping>
    <clear />
  </packageSourceMapping>
</configuration>

NuGet-Feeds

📦 📦 Paketverbraucher

Nutzen Sie Paketquellen, denen Sie vertrauen. Wenn Sie mehrere öffentliche und private NuGet-Quellfeeds verwenden, kann ein Paket aus allen Feeds heruntergeladen werden. Um sicherzustellen, dass Ihr Build vorhersagbar und sicher vor bekannten Angriffen wie der Dependency Confusion (Abhängigkeitsverwechslung) ist, ist es eine bewährte Methode, genau zu wissen, aus welchen spezifischen Feeds Ihre Pakete stammen. Sie können einen einzelnen Feed oder privaten Feed mit Upstreamingfunktionen für den Schutz verwenden.

Weitere Informationen zur Sicherung Ihrer Paketfeeds finden Sie unter 3 Möglichkeiten zur Risikominderung beim Einsatz privater Paketfeeds.

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

Clientvertrauensrichtlinien

📦 Softwarepaket-Verbraucher

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 Autor signiert ist, oder einem Paket vertrauen, wenn es sich im Besitz eines bestimmten Benutzers oder Kontos befindet und dessen Repository von NuGet.org signiert wurde.

Um Clientvertrauensrichtlinien zu konfigurieren, siehe die folgende Dokumentation.

Sperrdateien

Paketverbraucher

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

📦 Paket-Verbraucher

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

Um die Zuordnung der Paketquelle zu aktivieren, sehen Sie die folgende Dokumentation.

Sichere Computer

Directory-Berechtigungen

📦 Paketnutzer

Unter Windows und Mac sowie bei einigen Linux-Verteilungen sind die Basisverzeichnisse der Benutzerkonten standardmäßig privat. Einige Linux-Verteilungen machen Benutzerverzeichnisse jedoch standardmäßig für andere Konten auf demselben Computer lesbar. Darüber hinaus gibt es mehrere Konfigurationsoptionen, um den globalen NuGet-Paketordner und den HTTP-Cache an andere Orte als die Standardspeicherorte umzuleiten. (siehe [Verwaltung der globalen Paket- und Cache-Ordner](../consume-packages/managing-the-global-packages-and-cache-folders)). Lösungen, Projekte und Repositorys können auch außerhalb des Basisverzeichnisses des Benutzers erstellt werden.

Wenn Sie Pakete verwenden, die sich nicht auf nuget.org befinden, und ein anderes Konto auf dem Computer die globalen NuGet-Pakete, die HTTP-Cache-Verzeichnisse oder das Build-Output-Verzeichnis des Projekts lesen kann, werden diese Pakete möglicherweise Personen zugänglich gemacht, die keinen Zugriff auf diese Pakete haben sollten.

Unter Linux wird die Berechtigungen der Datei ändern, sodass sie nur vom Dateibesitzer gelesen werden kann. Wenn Sie die Datei nuget.config jedoch auf andere Weise bearbeiten und die Datei sich an einem Ort befindet, an dem andere Konten die Datei lesen können, kann es zur Offenlegung von Informationen über die Paketquellen-URL oder die Paketquellen-Anmeldedaten kommen. Sie sollten sicherstellen, dass eine nuget.config-Datei nicht von anderen Benutzern desselben Computers gelesen werden kann.

Lösungen im Downloadverzeichnis

📦 Paketverbraucher

Besondere Vorsicht ist geboten, wenn Sie an Lösungen oder Projekten in Ihrem Download-Verzeichnis arbeiten. NuGet sammelt Einstellungen aus mehreren Konfigurationsdateien, und MSBuild importiert typischerweise Directory.Build.props, Directory.NuGet.props, Directory.Build.targets, und möglicherweise andere Dateien von jedem übergeordneten Verzeichnis bis hin zum Stammverzeichnis des Dateisystems.

Der Downloads-Ordner birgt ein zusätzliches Risiko, da er in der Regel der Standardspeicherort ist, an dem Webbrowser Dateien aus dem Internet herunterladen.

Build-Agents

📦 Paketbenutzer

Build-Agenten (CI-Agenten), die nicht nach jedem Build auf einen Anfangszustand zurückgesetzt werden, bergen mehrere Risiken, die berücksichtigt werden müssen.

Um mehr über sichere Methoden zur Verwaltung von Anmeldedaten zu erfahren, sehen Sie in der Dokumentation nach, wie Pakete aus authentifizierten Feeds konsumiert werden.

Informationen zum Ändern der Verzeichnisse, in denen NuGet Daten speichert, finden Sie in der Dokumentation zur Verwaltung der globalen Pakete, des Cache und der Temp-Ordner. Diese Verzeichnisse sollten auf ein Verzeichnis konfiguriert werden, das der CI-Agent nach jedem Build bereinigt.

Beachten Sie, dass alle Pakete, die von Ihrem Projekt verwendet werden, möglicherweise im Build-Ausgabeverzeichnis Ihres Projekts verbleiben. Wenn Ihr Projekt Pakete aus authentifizierten Quellen verwendet, könnten andere Benutzer desselben CI-Agenten unbefugten Zugriff auf die Paket-Assemblies erhalten. Daher sollten Sie auch ihr Repository am Ende des Builds bereinigen, auch wenn der Build fehlschlägt oder abgebrochen wird.

Überwachen der Lieferkette

Geheime Überprüfung in GitHub

📦🖊 Paketautor

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

Weitere Informationen zur Geheimnisprüfung finden Sie unter Infos zur Geheimnisprüfung.

Signieren von Paketen durch den Autor

📦🖊 Paketautor

Die Signatur des Autors ermöglicht einem Paketautor, ein Paket mit seiner Identität zu versehen, sodass ein Kunde verifizieren kann, dass es von Ihnen 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.

Um ein Paket zu signieren, siehe Signieren eines Pakets.

Reproduzierbare Builds

📦🖊 Paketautor

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

Paketautor

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

Paket-ID-Präfix-Reservierung

📦🖊 Paketersteller

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

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

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 verwenden, das veraltet und nicht aufgelistet ist, sollten Sie die Nutzung des Pakets vermeiden.

In der folgenden Dokumentation über das Markieren von Paketen als veraltet und das Unauffindbar machen von Paketen erfahren Sie, wie Sie ein Paket als veraltet markieren und aus einer Liste entfernen können.

Ziehen Sie auch in Erwägung, das Bekannte an die GitHub-Advisories-Datenbank zu melden.

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 verschiedene Methoden kennengelernt, die von NuGet und GitHub bereitgestellt werden und mit denen Sie bereits heute effektiver Ihre Lieferkette einsehen, verwalten und überwachen können.

Weitere Informationen zur Sicherung der weltweiten Software finden Sie im The State of the Octoverse 2020 Security Report.