Über diesen Leitfaden
Dieser Leitfaden beschreibt die Änderungen mit den größten Auswirkungen, die Sie vornehmen können, um die Sicherheit Ihres Build-Systems 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 Build-System ab. Wenn ein Angreifer den Build-Prozess ändern kann, kann er dein System missbrauchen, ohne persönliche Konten oder Code kompromittieren zu müssen. Es ist wichtig, dass Sie nicht vergessen, sowohl das Build-System als auch persönliche Konten und Code zu schützen.
Schützen Ihres Build-Systems
Ein Build-System sollte über mehrere Sicherheitsfunktionen verfügen:
-
Die Build-Schritte sollten klar und wiederholbar sein.
-
Sie sollten genau wissen, was während des Build-Vorgangs ausgeführt wurde.
-
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 Ihnen dabei helfen, diese Funktionen zu erfüllen. Build-Anweisungen werden zusammen mit Ihrem Code in Ihren 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 Build-Umgebung zu überleben.
Zusätzlich zu den Sicherheitsvorteilen GitHub Actions können Sie Builds manuell, regelmäßig oder auf Git-Ereignissen in Ihrem Repository für häufige und schnelle Builds auslösen.
GitHub Actions ist ein großes Thema, aber ein guter Startpunkt ist [AUTOTITLE](/actions/learn-github-actions/understanding-github-actions), [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners) und [AUTOTITLE](/actions/using-workflows/triggering-a-workflow).
Generieren von Artefaktnachweisen für Ihre Builds
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, der Commit-SHA und das auslösende Ereignis für das Artefakt
- Andere Informationen aus dem OIDC-Token, die zur Feststellung der Herkunft verwendet werden. Weitere Informationen finden Sie unter 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.
Artefakte-Nachweise enthalten eine Signatur über ein integriertes Artefakt sowie Links zum Quell-Code und Build-Anweisungen. 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 Zertifizierungsstelle.
Weitere Informationen finden Sie unter Verwenden von Artefaktnachweisen zur Ermittlung der Herkunft von Builds.
Signieren deines Builds
Sobald Ihr Build-Prozess sicher ist, sollten Sie verhindern, dass jemand das Endergebnis Ihres Build-Prozesses 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 grundlegende Option hier ist die Verwendung GitHub Actions verschlüsselter geheimer Schlüssel, obwohl Sie vorsichtig sein müssen, um zu beschränken, wer Zugriff auf diese GitHub Actions Workflows hat. Wenn Ihr privater Schlüssel in einem anderen System gespeichert wird, auf das über das öffentliche Internet zugegriffen werden kann (z. B. Microsoft Azure oder HashiCorp Vault), besteht eine erweiterte Option darin, sich bei OpenID Connect zu authentifizieren, sodass Sie geheime Schlüssel nicht über Systeme hinweg freigeben müssen. Wenn auf Ihren privaten Schlüssel nur über ein privates Netzwerk zugegriffen werden kann, besteht außerdem die Möglichkeit, selbst gehostete Runner für GitHub Actions zu verwenden.
Weitere Informationen finden Sie unter Verwenden von Geheimnissen in GitHub-Aktionen, und .
Verwenden unveränderlicher Releases
Wenn Sie in Ihrem Build-System Release-Ressourcen aus weiteren Projekten verwenden oder Releases für Ihre eigene Arbeit erstellen, sollten Sie das Sicherheitsrisiko verringern, indem Sie sicherstellen, dass diese Releases unveränderlich sind. Das bedeutet, dass sie nach der Veröffentlichung nicht mehr geändert werden können. Unveränderliche Releases helfen dabei, Angriffe auf die Lieferkette und versehentliche Breaking Changes zu verhindern. Weitere Informationen finden Sie unter Unveränderliche Releases.
Härtung der Sicherheit für GitHub Actions
Dies sind einige zusätzliche Schritte, die Sie ausführen können, um GitHub Actions weiter abzusichern. 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 findest du unter Referenz zur sicheren Verwendung und Referenz zur sicheren Verwendung.
Nächste Schritte
-
[AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview) -
[AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts) -
[AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)