À 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 à satisfaire à ces critères. 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.
Outre les avantages en matière de sécurité, GitHub Actions vous permet de déclencher des générations rapides et fréquentes manuellement, périodiquement ou sur des événements Git dans votre dépôt.
GitHub Actions est un sujet à part entière, mais pour bien démarrer, vous pouvez consulter Comprendre GitHub Actions, Workflow syntax for GitHub Actions et Déclenchement d’un workflow.
Générer des attestations d’artefact 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 :
- Lien vers le flux de travail associé à l’artefact.
- Le référentiel, l’organisation, l’environnement, le commit SHA et l’événement de déclenchement de l’artefact.
- Autres informations du jeton OIDC utilisées pour établir la provenance. Pour plus d’informations, consultez « À propos du renforcement de la sécurité avec 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’artefact 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’artefact, vous n’avez pas besoin de gérer votre propre matériau de clé de signature. GitHub s’en charge pour vous grâce à l’autorisation de signature dont nous disposons.
Pour plus d’informations, consultez « Utilisation d’attestations d’artefact 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. L’une des options de base consiste à utiliser des secrets chiffrés GitHub Actions, même si vous devez veiller à limiter les personnes ayant accès à ces workflows GitHub Actions. 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, afin que vous n’ayez pas besoin de partager de 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, À propos du renforcement de la sécurité avec OpenID Connect et À propos des exécuteurs auto-hébergés.
Durcir la sécurité pour GitHub Actions
Vous pouvez prendre de nombreuses mesures supplémentaires pour sécuriser GitHub Actions. 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 « Durcissement de la sécurité pour GitHub Actions » et « Utiliser les fonctions de sécurité de GitHub pour sécuriser votre utilisation des actions GitHub ».