Protéger les builds

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

  • Optimisation ou obscurcissement du code: par exemple, l'outil Open Source Closure Compiler de Google analyse le code JavaScript, supprime le code mort, puis réécrit et réduit le contenu restant. Il vérifie également le code pour détecter les pièges JavaScript courants.
  • Compilation du code en code intermédiaire: par exemple, vous pouvez compiler le code Java dans un fichier de classe Java (.class) ou le code C++ dans un fichier objet (.obj).
  • Compiler du code et l'associer, 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 du code dans un format distribuable ou déployable: par exemple, créer des fichiers Java WAR (.war) à partir de fichiers de classe Java, créer une image Docker ou créer une distribution créée en 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 intégrée et l'importer dans un magasin d'artefacts tel que Artifact Registry ou PyPI afin que vous puissiez l'utiliser comme 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 décrites dans ce document visent à compiler du code pour l'empaqueter ou le déployer dans des environnements d'exécution plutôt que de compiler du code.

Utiliser des builds automatisés

Une compilation automatisée ou compilation scriptée définit toutes les étapes de compilation dans le script ou la configuration de compilation, y compris les étapes pour récupérer le code source et les étapes pour compiler le code. La seule commande manuelle, le cas échéant, est celle qui permet d'exécuter la compilation.

Par exemple, un script de compilation peut être:

  • Un fichier cloudbuild.yaml Cloud Build.
  • 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 les compilations dans un environnement cohérent et fiable.

Bien que les builds locaux puissent être utiles à des fins de 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 compilations locales permet à un pirate informatique à l'intention malveillante de modifier le processus de compilation.
  • Les incohérences dans les environnements locaux et les pratiques des développeurs compliquent la reproduction des builds et le diagnostic des problèmes.

Les compilations manuelles 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 SLSA 1. L'utilisation d'un service de compilation plutôt que d'environnements de développement pour les compilations est requise pour le niveau SLSA 2.

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 extraire 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 Cloud Deploy, ainsi qu'aux environnements d'exécution tels que GKE et Cloud Run. Il s'intègre également aux principaux systèmes de gestion de code source tels que GitHub et Bitbucket.

Générer la provenance de la compilation

La origine de la 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 des sources d'entrée, la chaîne d'outils de compilation et la durée de la compilation.

La génération de la provenance de la compilation vous aide à:

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

Vous pouvez vous servir de mécanismes d'alerte et de règles pour exploiter les données de provenance de compilation de manière proactive. 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 SLSA 1, la provenance de la compilation doit être accessible aux consommateurs des artefacts de compilation. Pour le niveau SLSA 2, les données de provenance de la compilation doivent également être:

  • Générés par le service de compilation ou lisibles directement à partir du service de compilation.
  • L'authenticité et l'intégrité du produit peuvent être vérifiées par le consommateur. Pour ce faire, utilisez une signature numérique générée par le service qui crée les données de preuve de compilation.

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

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

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

Utiliser un environnement de compilation éphémère

Les environnements éphémères sont des environnements temporaires conçus pour durer dans un seul appel de compilation. Après la compilation, l'environnement est effacé ou supprimé. Les builds éphémères garantissent que le service 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 build, 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 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 du contenu 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 et aux ressources de compilation. Vous devez également utiliser une identité non humaine pour exécuter des builds et interagir avec d'autres services au nom du build.

Si vous utilisez Cloud Build:

  • Accordez les autorisations minimales requises aux membres de votre organisation.
  • Personnalisez les autorisations pour le 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 plutôt un compte de service personnalisé.
  • Utilisez la règle d'administration Intégrations autorisées 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 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. Ce périmètre réduit également le risque d'exfiltration des données.

    Cloud Build n'est compatible qu'avec VPC Service Controls pour les compilations exécutées 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'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 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 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ù vous publiez vos dépendances, qui a accès en lecture et en écriture à vos dépôts d'artefacts, ainsi que les règles applicables aux 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 page Gérer les dépendances.

Dans Cloud Build, vous utilisez des compilateurs Cloud pour exécuter les commandes. Les compilateurs sont des images de conteneurs dans lesquelles sont installés des langages et des outils communs. 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 buildpacks en tant que 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 d'un compilateur, vous pouvez créer des compilateurs personnalisés au lieu d'utiliser des compilateurs d'une source publique.

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

Différents autres facteurs peuvent influencer une compilation, y compris les suivants:

  • Builds exécutés simultanément et capables de s'influencer les uns les autres, ou build qui persiste et affecte une compilation ultérieure.
  • Compilations qui acceptent les paramètres utilisateur autres que le point d'entrée de la compilation et l'emplacement source de premier niveau.
  • Les compilations qui spécifient des dépendances avec des plages ou des dépendances modifiables (par exemple, en utilisant une image avec le tag latest) Ces approches présentent un risque que les builds utilisent des versions incorrectes ou indésirables des dépendances.

Les pratiques suivantes permettent d'atténuer 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 et aux ressources de compilation.
  • Référencer des versions immuables des dépendances plutôt que des identifiants tels que des balises 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 afin de découvrir comment créer des images de conteneurs plus fiables et moins vulnérables aux attaques, y compris:

  • Empaqueter des applications uniques
  • Traiter les processus
  • Optimiser le cache de build de Docker
  • Supprimer les outils inutiles et réduire au maximum la taille de vos images
  • Recherchez des failles avec Artifact Analysis. Vous pouvez analyser les images stockées dans Artifact Registry ou les analyser localement avant de les stocker.
  • Bonnes pratiques concernant le taggage
  • Considérations de sécurité concernant l'utilisation d'images publiques

Software Delivery Shield

Software Delivery Shield est une solution de sécurité de la chaîne d'approvisionnement logicielle de bout en bout entièrement gérée. Elle fournit un ensemble complet et modulaire de fonctionnalités et d'outils dans les services Google Cloud, que les développeurs, les équipes DevOps et les équipes de sécurité peuvent utiliser pour améliorer la stratégie de sécurité de la chaîne d'approvisionnement logicielle. Il affiche des insights sur la sécurité pour les applications créées dans l'interface utilisateur Cloud Build de la console Google Cloud. Ce bloc inclut les éléments suivants :

  • Le niveau SLSA, qui identifie le niveau de maturité de la sécurité de votre chaîne d'approvisionnement logicielle.
  • Failles, nomenclature du logiciel (SBOM) et instructions Vulnerability Exploitability eXchange (VEX) pour les artefacts de compilation
  • La provenance de la compilation, qui est une collection de métadonnées vérifiables concernant une compilation Il inclut des détails tels que les condensés des images compilées, les emplacements des sources 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 créées, consultez Créer une application et afficher des insights sur la sécurité.

Étapes suivantes