À 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.
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 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 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 ».