Protéger les compilations

Ce document décrit les bonnes pratiques à suivre pour protéger vos builds. Le code du bâtiment peut faire référence à différents types d'opérations, par exemple:

  • Optimisation ou obscurcissement du code: par exemple, l'outil Open Source de Google Closure Compiler analyse et analyse le code JavaScript, supprime le code mort, et réécrit et minimise ce qui reste. Il vérifie également le code pour détecter les écueils JavaScript courants.
  • Compilation du code en code intermédiaire: par exemple, vous pouvez compiler du code Java dans un fichier de classe Java (.class) ou du code C++ dans un fichier objet (.obj).
  • Compilation du code et association, création d'une bibliothèque ou d'un fichier exécutable: par exemple, compilation du code C++ dans une bibliothèque partagée (.so) ou un fichier exécutable Windows (.exe).
  • Empaqueter du code dans un format distribuable ou déployable: par exemple, créer des fichiers WAR Java (.war) à partir de fichiers de classe Java, créer une image Docker ou créer une distribution compilée Python (.whl).

Selon le langage de programmation que vous utilisez et l'environnement dans lequel vous effectuez le déploiement, votre build peut contenir différentes combinaisons de ces opérations. Par exemple, une compilation peut empaqueter du code Python dans une distribution compilée et l'importer dans un dépôt d'artefacts tel qu'Artifact Registry ou PyPI afin que vous puissiez l'utiliser comme dépendance dans les fonctions Cloud Run. Vous pouvez également conteneuriser le code Python et déployer l'image du conteneur dans Cloud Run ou Google Kubernetes Engine.

Les pratiques décrites dans ce document se concentrent sur la création de code pour l'empaquetage ou le déploiement dans des environnements d'exécution plutôt que sur la compilation de code.

Utiliser des compilations automatiques

Une compilation automatique ou une compilation avec script définit toutes les étapes de compilation dans le script de compilation ou la configuration de compilation, y compris les étapes de récupération du code source et de compilation du code. La seule commande manuelle, le cas échéant, est la commande permettant d'exécuter la compilation.

Par exemple, un script de compilation peut être:

  • cloudbuild.yaml Cloud Build
  • Un fichier Makefile que vous exécutez avec l'outil make.
  • Fichier de workflow GitHub Actions au format YAML stocké dans votre répertoire .github/workflows/.

Les compilations automatisées assurent la cohérence des étapes de compilation. Toutefois, il est également important d'exécuter des builds dans un environnement cohérent et fiable.

Bien que les compilations locales puissent être utiles à des fins de débogage, la publication de logiciels à partir de compilations locales peut entraîner de nombreux problèmes de sécurité, d'incohérences et d'inefficacités dans le processus de compilation.

  • Autoriser les builds locaux permet à un pirate informatique malveillant de modifier le processus de compilation.
  • Les incohérences dans les environnements locaux et les pratiques des développeurs rendent difficile la reproduction des builds et le diagnostic des problèmes de compilation.

Les builds manuels rendent le processus inefficace en exploitant davantage de ressources d'infrastructure telles que le calcul, le stockage et les réseaux. Dans les exigences du framework SLSA, les compilations automatisées sont obligatoires pour le niveau 1 de la certification SLSA, et l'utilisation d'un service de compilation au lieu d'environnements de développement pour les compilations est obligatoire pour le niveau 2 de la certification SLSA.

Cloud Build est le service de compilation géré sur Google Cloud. Il utilise un fichier de configuration de compilation pour fournir les étapes de compilation à Cloud Build. Vous pouvez configurer des compilations pour récupérer des dépendances, exécuter des tests unitaires, des analyses statiques et des tests d'intégration, et créer des artefacts à l'aide d'outils de compilation tels que Docker, Gradle, Maven, Go et Python. Cloud Build est entièrement intégré aux autres services CI/CD sur Google Cloud, tels que Artifact Registry et Cloud Deploy, ainsi qu'aux environnements d'exécution tels que GKE et Cloud Run. Il offre également une intégration aux principaux systèmes de gestion du code source, tels que GitHub et Bitbucket.

Générer la provenance du build

La provenance du build est une collection de données vérifiables concernant un build.

Les métadonnées de provenance incluent des détails tels que les condensés des images compilées, les emplacements de la source d'entrée, la chaîne d'outils de compilation et la durée de compilation.

Générer la provenance du build vous permet de:

  • Vérifier qu'un artefact compilé a été créé à partir d'un emplacement source fiable et par un système de compilation fiable.
  • Identifier le code injecté à partir d'un emplacement source ou d'un système de compilation non approuvés.

Vous pouvez utiliser des mécanismes d'alerte et de règles pour utiliser de manière proactive les données de provenance de compilation. Par exemple, vous pouvez créer des règles qui n'autorisent que les déploiements de code compilé à partir de sources validées.

Pour le niveau 1 de la norme SLSA, la provenance de compilation doit être disponible pour les consommateurs des artefacts compilés. Pour le niveau 2 de la norme SLSA, les données de provenance de la compilation doivent également:

  • Généré par le service de compilation ou lisible directement à partir de celui-ci.
  • Vérifiable par un consommateur pour en vérifier l'authenticité et l'intégrité. Cela doit être effectué à l'aide d'une signature numérique générée par le service qui crée les données de provenance de compilation.

Pour le niveau 3 de la SLSA, le contenu de provenance doit également inclure les éléments suivants:

  • Point d'entrée de la définition de compilation.
  • Tous les paramètres de compilation sous le contrôle d'un utilisateur.

Cloud Build peut générer une provenance de compilation pour les images de conteneurs qui fournissent une assurance de compilation SLSA de niveau 3. Pour en savoir plus, consultez la section Afficher la provenance de la compilation.

Utiliser un environnement de compilation éphémère

Les environnements éphémères sont des environnements temporaires destinés à durer une seule fois. Après la compilation, l'environnement est effacé ou supprimé. Les builds éphémères garantissent que le service de compilation et les étapes de compilation s'exécutent dans un environnement éphémère, tel qu'un conteneur ou une VM. Au lieu de réutiliser un environnement de compilation existant, le service de compilation provisionne un nouvel environnement pour chaque compilation, puis le détruit une fois le processus de compilation terminé.

Les environnements éphémères garantissent des builds propres, car aucun fichier résiduel ni aucun paramètre d'environnement des builds précédents ne peut interférer avec le processus de compilation. Un environnement non éphémère permet aux pirates informatiques d'injecter des fichiers et des contenus malveillants. Un environnement éphémère réduit également les coûts de maintenance et les incohérences dans l'environnement de compilation.

Cloud Build configure un nouvel environnement de machine virtuelle pour chaque compilation et le détruit après la compilation.

Limiter l'accès au service de compilation

Respectez le principe de sécurité du moindre privilège en accordant les autorisations minimales requises au service de compilation et aux ressources de compilation. Vous devez également utiliser une identité non humaine pour exécuter des compilations et interagir avec d'autres services au nom de la compilation.

Si vous utilisez Cloud Build:

  • Accordez les autorisations minimales requises aux membres de votre organisation.
  • Personnalisez les autorisations du compte de service qui agit au nom de Cloud Build afin qu'il ne dispose que des autorisations nécessaires à votre utilisation. Modifiez les autorisations du compte de service Cloud Build par défaut ou envisagez d'utiliser un compte de service personnalisé à la place.
  • Utilisez la règle d'administration Cloud Build Intégrations autorisées pour contrôler les services externes autorisés à appeler des déclencheurs de compilation.

  • Placez Cloud Build dans un périmètre de service à l'aide de VPC Service Controls. Le périmètre permet une communication libre entre les services Google Cloud au sein du périmètre, mais limite la communication au-delà du périmètre en fonction des règles que vous spécifiez. Le périmètre limite également le risque d'exfiltration des données.

    Cloud Build n'est compatible avec VPC Service Controls que pour les compilations que vous exécutez dans un pool privé.

Protéger les identifiants

Les builds incluent souvent des connexions à d'autres systèmes tels que le contrôle des versions, les dépôts d'artefacts et les environnements de déploiement. Protéger les identifiants que vous utilisez dans vos builds permet d'empêcher tout accès non autorisé aux systèmes de votre chaîne d'approvisionnement logicielle et l'exfiltration de données.

Évitez de stocker des identifiants codés en dur directement dans le contrôle de version ou dans la configuration de votre build. Stockez plutôt les identifiants dans un keystore sécurisé.

Dans Google Cloud, Secret Manager stocke de manière sécurisée des clés API, des mots de passe et d'autres données sensibles. Vous pouvez configurer Cloud Build pour utiliser les secrets stockés dans Secret Manager.

Gérer vos dépendances

L'intégrité de vos applications repose à la fois sur l'intégrité du code que vous développez et de toutes les dépendances que vous utilisez. Vous devez également déterminer où publier vos dépendances, qui a accès à la lecture et à l'écriture dans vos dépôts d'artefacts, ainsi que les règles concernant les sources fiables d'artefacts de compilation que vous déployez dans vos environnements d'exécution.

Pour en savoir plus sur la gestion des dépendances, consultez la section Gérer les dépendances.

Dans Cloud Build, vous utilisez des compilateurs cloud pour exécuter des commandes. Les compilateurs sont des images de conteneurs dans lesquelles sont installés des outils et langages courants. Vous pouvez utiliser des images de conteneur publiques à partir de registres publics tels que Docker Hub, des compilateurs fournis par Cloud Build, des compilateurs créés par la communauté et des compilateurs personnalisés que vous créez. Vous pouvez également utiliser des buildpacks comme compilateurs, y compris les buildpacks Google Cloud.

Examinez les compilateurs que vous utilisez dans vos compilations Cloud Build, découvrez qui les fournit et décidez si vous leur faites confiance dans votre chaîne d'approvisionnement logicielle. Pour mieux contrôler le code dans un compilateur, vous pouvez créer des compilateurs personnalisés au lieu d'utiliser des compilateurs à partir d'une source publique.

Réduire les possibilités de modifier le build

De nombreux autres facteurs peuvent influencer un build, y compris:

  • Builds exécutés simultanément et pouvant s'influencer mutuellement, ou build persistant et affectant un build ultérieur.
  • Compilations qui acceptent des paramètres utilisateur autres que le point d'entrée de la compilation et l'emplacement source de niveau supérieur.
  • Compilations qui spécifient des dépendances avec des plages ou des dépendances modifiables (par exemple, à l'aide d'une image avec le tag latest). Ces approches font courir le risque que les builds utilisent des versions de dépendances incorrectes ou indésirables.

Les pratiques suivantes permettent de limiter ces risques:

  • Exécutez chaque build dans un environnement éphémère.
  • Évitez d'exécuter des builds avec des paramètres supplémentaires afin que les utilisateurs ne puissent pas influencer les variables définies dans les scripts de compilation.
  • Limitez l'accès au service de compilation et aux ressources de compilation.
  • Référencez des versions immuables des dépendances au lieu d'identifiants tels que des balises qui peuvent pointer vers une autre version de l'artefact à l'avenir. Pour en savoir plus sur les dépendances, consultez la section Gestion des dépendances.

Sécurité sur la chaîne d'approvisionnement logicielle

Google Cloud fournit un ensemble de fonctionnalités et d'outils modulaires que vous pouvez utiliser pour améliorer la stratégie de sécurité de vos chaînes d'approvisionnement logicielles. Il affiche des insights de sécurité pour les applications créées par Cloud Build. Par exemple :

  • Niveau SLSA, qui identifie le niveau de maturité de la sécurité de votre chaîne d'approvisionnement logicielle.
  • Failles, nomenclature logicielle (SBOM) et instructions Vulnerability Exploitability eXchange (VEX) pour les artefacts de compilation.
  • La provenance du build, qui est un ensemble de métadonnées vérifiables sur un build. Il inclut des détails tels que les condensés des images compilées, les emplacements de la source d'entrée, la chaîne d'outils de compilation, les étapes de compilation et la durée de compilation.

Pour savoir comment afficher les insights sur la sécurité des applications compilées, consultez la section Créer une application et afficher les insights sur la sécurité.

Étape suivante