Protéger les builds

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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

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

Selon le langage de programmation que vous utilisez et l'environnement dans lequel vous déployez, votre build peut contenir différentes combinaisons de ces opérations. Par exemple, une compilation peut empaqueter le code Python dans une distribution créée et l'importer dans un magasin d'artefacts, tel que Artifact Registry ou PyPI, afin de pouvoir l'utiliser en tant que dépendance dans Cloud Functions. Vous pouvez également conteneuriser le code Python et déployer l'image de conteneur dans Cloud Run ou Google Kubernetes Engine.

Les pratiques de ce document sont axées 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 du code.

Utiliser des compilations automatiques

Une compilation automatisée ou une compilation scriptée définit toutes les étapes du script ou de la configuration de compilation, y compris les étapes de récupération du code source et les étapes 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:

  • Un objet Cloud Build cloudbuild.yaml.
  • Un fichier Makefile que vous exécutez avec l'outil make.
  • Un 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. Cependant, il est également important d'exécuter des compilations dans un environnement cohérent et fiable.

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

  • Autoriser les builds locaux permet à un pirate informatique malveillant de modifier le processus de compilation.
  • Des incohérences au niveau des environnements locaux et des pratiques de développement s'avèrent difficiles à reproduire et à diagnostiquer les problèmes de compilation.

Les builds manuels rendent le processus inefficace en exploitant plus de ressources d'infrastructure telles que le calcul, le stockage et les réseaux. Dans les exigences du framework SLSA, les builds automatiques sont obligatoires pour le niveau 1 de SLSA. Il est nécessaire d'utiliser un service de compilation au lieu d'environnements de développement pour les builds pour le niveau SLSA.

Cloud Build est le service de compilation géré sur Google Cloud. Il utilise un fichier de configuration de compilation pour fournir des étapes de compilation à Cloud Build. Vous pouvez configurer des builds 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é à d'autres services CI/CD sur Google Cloud tels que Artifact Registry et Google Cloud Deploy, ainsi qu'à des environnements d'exécution tels que GKE et Cloud Run. Il est également intégré aux principaux systèmes de gestion de code source tels que GitHub et Bitbucket.

Générer la provenance du build

Une origine de compilation est une collection de données vérifiables sur une compilation.

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 la compilation et la durée de la compilation.

Générer la provenance d'un build vous permet de:

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

Vous pouvez utiliser des mécanismes d'alerte et des 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 créé à partir de sources validées.

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

  • Généré par le service de compilation ou lisible directement à partir de ce service.
  • Vérifiable par un consommateur pour son authenticité et son intégrité. Cela doit être effectué avec une signature numérique générée par le service qui crée les données de provenance de la compilation.

Pour le niveau 3 de SLSA, le contenu de provenance doit également inclure:

  • Point d'entrée de la définition de compilation.
  • Tous les paramètres de compilation sont contrôlés par un utilisateur.

Cloud Build peut générer une provenance de compilation pour les images de conteneurs offrant une garantie de compilation de niveau 3. Pour en savoir plus, consultez Afficher la provenance du build.

Utiliser un environnement de compilation éphémère

Les environnements éphémères sont des environnements temporaires conçus pour durer un seul appel de compilation. Après la compilation, les données de l'environnement sont effacées ou supprimées. Les compilations é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 assurent la sérénité des builds, car les fichiers résiduels ou les paramètres d'environnement des builds précédents n'interfèrent pas avec le processus de compilation. Un environnement non éphémère permet aux pirates informatiques d'injecter du contenu et des fichiers 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

Suivez 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 pour 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 utilisez plutôt un compte de service personnalisé.
  • Utilisez la règle d'administration Intégrations autorisées de Cloud Build pour contrôler les services externes autorisés à appeler des déclencheurs de compilation.
  • placer Cloud Build dans un périmètre de service à l'aide de VPC Service Controls ; Le périmètre permet une communication gratuite entre les services Google Cloud au sein du périmètre, mais limite la communication à travers le périmètre en fonction des règles que vous spécifiez. Le périmètre réduit é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 magasins d'artefacts et les environnements de déploiement. La protection des identifiants que vous utilisez dans vos compilations permet d'éviter tout accès non autorisé aux systèmes de votre chaîne d'approvisionnement logicielle et l'exfiltration des données.

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

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

Gérer vos dépendances

L'intégrité de vos applications dépend de l'intégrité du code que vous développez et des dépendances que vous utilisez. Vous devez également prendre en compte où vous publiez vos dépendances, qui a accès en lecture et en écriture à vos dépôts d'artefacts, et des règles pour les sources de confiance des 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 page 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 langages et des outils courants. Vous pouvez utiliser des images de conteneurs publiques issues de registres publics tels que Docker Hub, des compilateurs fournis par Cloud Build, des compilateurs issus de la communauté et des compilateurs personnalisés que vous créez. Vous pouvez également utiliser des packs de création, y compris des packs de création Google Cloud.

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

Réduire les opportunités de modification de la compilation

D'autres facteurs peuvent avoir une incidence sur un build, parmi lesquels:

  • Compilations qui s'exécutent simultanément et peuvent s'influencer les unes les autres, ou une compilation qui persiste et a une incidence sur une compilation ultérieure.
  • Compilations qui acceptent des paramètres utilisateur autres que le point d'entrée de compilation et l'emplacement source de premier niveau.
  • Compilations spécifiant des dépendances avec des plages ou des dépendances pouvant être modifiées (par exemple, en utilisant une image avec le tag latest). Ces approches créent un risque pour que les compilations 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 compilations 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 de dépendances au lieu d'identifiants tels que des tags pouvant pointer vers une autre version de l'artefact à l'avenir. Pour en savoir plus sur les dépendances, consultez la page Gestion des dépendances.

Suivre les bonnes pratiques pour la création de conteneurs

Consultez les bonnes pratiques pour la création de conteneurs pour en savoir plus sur la création d'images de conteneurs plus fiables et moins vulnérables aux attaques, y compris:

  • Empaqueter des applications uniques
  • Processus de traitement
  • Optimiser le cache de compilation Docker
  • Supprimer les outils inutiles et réduire au maximum la taille des images
  • Analyser les failles avec Container Analysis. Vous pouvez analyser des images stockées dans Artifact Registry ou les analyser en local avant de les stocker.
  • Bonnes pratiques concernant l'ajout de tags
  • Considérations de sécurité concernant l'utilisation d'images publiques

Bouclier de livraison de logiciels

Software Delivery Shield est une solution de sécurité de la chaîne d'approvisionnement logicielle entièrement gérée. Il fournit un ensemble complet de fonctionnalités et d'outils dans les services Google Cloud, que les développeurs, le DevOps et les équipes de sécurité peuvent utiliser pour améliorer la sécurité de la chaîne d'approvisionnement logicielle. Il affiche des insights de sécurité pour les applications créées dans l'interface utilisateur de Cloud Build, dans la console Google Cloud. Notre offre comprend :

  • le niveau SLSA, qui identifie le niveau de maturité de la sécurité de votre chaîne d'approvisionnement logicielle ;
  • Failles liées aux artefacts de compilation
  • La provenance de la compilation, qui est une collection de métadonnées vérifiables sur une compilation Il inclut des informations telles que les condensés des images compilées, les emplacements des sources d'entrée, la chaîne d'outils de compilation, les étapes et la durée de la compilation.

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

Étapes suivantes