Bewährte Methoden zum Schützen deines Buildsystems

Leitfaden, wie du das Ende deiner Lieferkette schützen kannst, d. h. die Systeme, mit denen du Artefakte erstellst und verteilst.

In diesem Artikel

Über diesen Leitfaden

Dieser Leitfaden beschreibt die Änderungen mit den größten Auswirkungen, die du vornehmen kannst, um die Sicherheit deines Buildsystems zu verbessern. In den einzelnen Abschnitten wird jeweils eine Änderung beschrieben, die du zur Verbesserung der Sicherheit an deinen Prozessen vornehmen kannst. Die Änderungen mit den größten Auswirkungen sind zuerst aufgeführt.

Welches Risiko besteht?

Einige Angriffe auf Softwarelieferketten zielen direkt auf das Buildsystem ab. Wenn ein Angreifer den Buildprozess ändern kann, kann er dein System missbrauchen, ohne persönliche Konten oder Code kompromittieren zu müssen. Es ist wichtig, dass du nicht vergisst, sowohl das Buildsystem als auch persönliche Konten und Code zu schützen.

Schützen deines Buildsystems

Ein Buildsystem sollte über mehrere Sicherheitsfunktionen verfügen:

  1. Die Buildschritte sollten klar und wiederholbar sein.

  2. Du solltest genau wissen, was während des Buildvorgangs ausgeführt wurde.

  3. Jeder Build sollte in einer neuen Umgebung beginnen, sodass ein kompromittierter Build nicht beibehalten wird, damit er keine zukünftigen Builds beeinflussen kann.

GitHub Actions kann dir helfen, diese Funktionen zu erfüllen. Buildanweisungen werden zusammen mit deinem Code in deinem Repository gespeichert. Du wählst aus, in welcher Umgebung dein Build ausgeführt wird, einschließlich Windows, Mac, Linux oder Runnern, die du selbst hostest. Jeder Build beginnt mit einem neuen Runner-Image, was es einem Angriff erschwert, in deiner Buildumgebung zu überleben.

Neben den Sicherheitsvorteilen kannst du mit GitHub Actions Builds manuell, periodisch oder bei Git-Ereignissen in deinem Repository auslösen, sodass häufige und schnelle Builds möglich sind.

GitHub Actions ist ein umfangreiches Thema, aber für den Einstieg ist Grundlegendes zu GitHub Actions sowie Workflowsyntax für GitHub Actions und Auslösen eines Workflows ein guter Ausgangspunkt.

Generieren von Artefaktnachweisen für Ihre Builds

Note

Artefaktenachweise befinden sich in der öffentlichen Betaversion und können geändert werden.

Mit Artefaktbescheinigungen können Sie fälschungssichere Herkunfts- und Integritätsgarantien für die von Ihnen entwickelte Software erstellen. Personen, die Ihre Software nutzen, können wiederum überprüfen, wo und wie Ihre Software erstellt wurde.

Wenn Sie Artefaktenachweise mit Ihrer Software generieren, erstellen Sie kryptografisch signierte Ansprüche, die die Provenienz Ihres Builds einrichten und die folgenden Informationen enthalten:

  • Eine Verknüpfung mit dem Workflow, der dem Artefakt zugeordnet ist.
  • Das Repository, die Organisation, die Umgebung, die SHA-Übertragung und das auslösende Ereignis für das Artefakt.
  • Andere Informationen aus dem OIDC-Token, die zur Feststellung der Herkunft verwendet werden. Weitere Informationen findest du unter Informationen zur Sicherheitshärtung mit OpenID Connect.

Sie können auch Artefaktnachweise generieren, die eine zugeordnete Software-Stückliste (SBOM) enthalten. Das Zuordnen Ihrer Builds zu einer Liste der darin verwendeten Open Source-Abhängigkeiten bietet Transparenz und ermöglicht es Verbrauchern, Datenschutzstandards einzuhalten.

Artefaktenachweise enthalten eine Signatur über ein integriertes Artefakt sowie Links zum Quellcode und Buildanweisungen. Wenn Sie Ihren Build mit Artefaktnachweisen signieren, müssen Sie kein eigenes Signierschlüsselmaterial verwalten. GitHub übernimmt dies für Sie mit der von uns betriebenen Signaturautorität.

Weitere Informationen findest du unter Verwenden von Artefaktnachweisen zur Ermittlung der Herkunft von Builds.

Signieren deines Builds

Sobald dein Buildprozess sicher ist, solltest du verhindern, dass jemand das Endergebnis deines Buildprozesses manipuliert. Eine gute Möglichkeit hierzu ist das Signieren deiner Builds. Wenn Software öffentlich verteilt wird, geschieht dies häufig mit einem öffentlichen/privaten kryptografischen Schlüsselpaar. Mit dem privaten Schlüssel signierst du den Build, und du veröffentlichst deinen öffentlichen Schlüssel, damit Benutzer deiner Software die Signatur auf dem Build überprüfen können, bevor sie sie verwenden. Wenn die Bytes des Builds geändert werden, wird die Signatur nicht bestätigt.

Wie genau du deinen Build signierst, hängt davon ab, welche Art von Code du schreibst, und wer deine Benutzer sind. Oft ist schwer zu entscheiden, wie der private Schlüssel sicher aufbewahrt werden kann. Eine grundsätzliche Möglichkeit ist die Verwendung verschlüsselter GitHub Actions-Geheimnisse, wobei du allerdings genau darauf achten musst, wer Zugriff auf diese GitHub Actions-Workflows hat. Wenn dein privater Schlüssel in einem anderen, über das öffentliche Internet zugänglichen System (wie Microsoft Azure oder HashiCorp Vault) gespeichert ist, ist eine erweiterte Option die Authentifizierung mit OpenID Connect, damit du keine Geheimnisse zwischen den Systemen austauschen musst. Wenn dein privater Schlüssel nur über ein privates Netzwerk zugänglich ist, ist eine weitere Option die Verwendung selbstgehosteter Runner für GitHub Actions.

Weitere Informationen findest du unter Verwenden von Geheimnissen in GitHub-Aktionen, Informationen zur Sicherheitshärtung mit OpenID Connect und Informationen zu selbstgehosteten Runnern.

Härten der Sicherheit für GitHub Actions

Du kannst viele weitere Schritte ausführen, um GitHub Actions zusätzlich zu schützen. Gehe insbesondere beim Evaluieren der Workflows von Drittanbietern sorgfältig vor, und erwäge die Verwendung von CODEOWNERS, um einzuschränken, wer Änderungen an deinen Workflows vornehmen kann.

Weitere Informationen finden Sie unter Sicherheitshärtung für GitHub Actions und unter Verwenden der Sicherheitsfeatures von GitHub zum Sichern Ihrer Verwendung von GitHub-Aktionen.

Nächste Schritte