À propos de ce guide
Ce guide décrit les modifications les plus importantes que vous pouvez apporter pour améliorer la sécurité de vos systèmes de génération. Chaque section décrit une modification que vous pouvez apporter à vos processus pour améliorer la sécurité. Les modifications les plus importantes sont listées en premier.
Quel est le risque ?
Certaines attaques sur les chaînes d’approvisionnement logicielles ciblent directement le système de génération. Si un attaquant peut modifier le processus de génération, il peut exploiter votre système sans avoir à compromettre les comptes personnels ou le code. Il est important de veiller à protéger le système de génération ainsi que les comptes personnels et le code.
Sécuriser votre système de génération
Un système de génération doit satisfaire à plusieurs critères de sécurité :
-
Les étapes de génération doivent être claires et reproductibles.
-
Vous devez savoir exactement ce qui s’exécutait pendant le processus de génération.
-
Chaque génération doit commencer dans un nouvel environnement, afin qu’une génération compromise ne puisse pas affecter une génération future.
GitHub Actions peut vous aider à atteindre ces capacités. Les instructions de génération sont stockées dans votre dépôt, en compagnie de votre code. Vous choisissez l’environnement sur lequel votre génération s’exécute, notamment Windows, Mac, Linux ou les exécuteurs que vous hébergez vous-même. Chaque build commence avec une image d’exécuteur propre, ce qui rend difficile la persistance d’une attaque dans votre environnement de build.
En plus des avantages de sécurité, GitHub Actions vous pouvez déclencher des builds manuellement, régulièrement ou sur des événements Git dans votre référentiel pour des builds fréquentes et rapides.
GitHub Actions est un sujet important, mais un bon endroit pour commencer est [AUTOTITLE](/actions/learn-github-actions/understanding-github-actions), ainsi que [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners), et [AUTOTITLE](/actions/using-workflows/triggering-a-workflow).
Générer des attestations d’artefacts pour vos builds
Les attestations d’artefact vous permettent de créer des garanties de provenance et d’intégrité non vérifiables pour le logiciel que vous créez. En retour, les personnes qui utilisent votre logiciel peuvent vérifier où et comment il a été conçu.
Lorsque vous générez des attestations d’artefact avec votre logiciel, vous créez des revendications signées par chiffrement qui établissent la provenance de votre build et incluent les informations suivantes :
- Un lien vers le flux de travail associé à l'artefact
- Le référentiel, l'organisation, l'environnement, le SHA de validation et l'événement déclencheur pour l'artefact
- Autres informations du jeton OIDC utilisées pour établir la provenance. Pour plus d’informations, consultez « OpenID Connect ».
Vous pouvez également générer des attestations d’artefact qui incluent une nomenclature logicielle (SBOM). L’association de vos builds à une liste des dépendances open source utilisées assure la transparence et permet aux consommateurs de se conformer aux normes de protection des données.
Les attestations d’artefacts incluent une signature sur un artefact généré, ainsi que des liens vers le code source et des instructions de génération. Si vous signez votre build avec des attestations d’artefacts, vous n’avez pas besoin de gérer vos propres clés de signature. GitHub gère cela pour vous avec l’autorité de signature que nous exploitons.
Pour plus d’informations, consultez « Utilisation des attestations d’artefacts pour établir la provenance des builds ».
Signer vos builds
Une fois votre processus de génération sécurisé, vous souhaitez empêcher qu’une personne en falsifie le résultat final. Pour ce faire, vous pouvez signer vos builds. Quand vous distribuez des logiciels publiquement, cela s’effectue souvent avec une paire de clés de chiffrement publique/privée. Vous utilisez la clé privée pour signer la build et vous publiez votre clé publique afin que les utilisateurs de votre logiciel puissent vérifier la signature sur la build avant de l’utiliser. Si les octets de la build sont modifiés, la signature ne sera pas vérifiée.
La façon dont vous signez exactement votre build dépend du type de code que vous écrivez et de vos utilisateurs. Il est souvent difficile de savoir comment stocker la clé privée de manière sécurisée. Une option de base ici consiste à utiliser GitHub Actions des secrets chiffrés, même si vous devez être prudent pour limiter les personnes ayant accès à ces GitHub Actions flux de travail. Si votre clé privée est stockée dans un autre système accessible via l’Internet public (comme Microsoft Azure ou HashiCorp Vault), une option plus avancée consiste à s’authentifier auprès d’OpenID Connect. Vous n’avez donc pas besoin de partager des secrets entre les systèmes. Si votre clé privée est accessible uniquement à partir d’un réseau privé, une autre option consiste à utiliser des exécuteurs auto-hébergés pour GitHub Actions.
Pour plus d’informations, consultez Utilisation de secrets dans GitHub Actions, OpenID Connect et Exécuteurs auto-hébergés.
Utiliser des versions immuables
Si vous utilisez des ressources de version provenant d’autres projets dans votre système de build, ou si vous créez des versions pour vos propres travaux, vous devez réduire les risques de sécurité en vous assurant que ces versions sont immuables, c’est-à-dire qu’elles ne peuvent pas être modifiées après leur publication. Les versions immuables permettent d’éviter les attaques sur la chaîne d’approvisionnement et les changements cassants accidentels. Pour plus d’informations, consultez « Versions immuables ».
Renforcer la sécurité pour GitHub Actions
Il existe de nombreuses autres étapes que vous pouvez effectuer pour sécuriser GitHub Actionsdavantage. En particulier, soyez prudent lors de l’évaluation des workflows tiers et envisagez d’utiliser CODEOWNERS pour limiter les personnes pouvant apporter des modifications à vos workflows.
Pour plus d’informations, consultez « Informations de référence sur l’utilisation sécurisée » et « Informations de référence sur l’utilisation sécurisée ».
Étapes suivantes
-
[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)