Sauvegarder 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:

  • L'optimisation ou l'obscurcissement de code: par exemple, l'outil Open Source de Google Closure Compiler 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).
  • la compilation de code et d'associations, la création d'une bibliothèque ou d'un fichier exécutable : la compilation du code C++ dans une bibliothèque partagée (.so) ou un exécutable Windows (.exe).
  • Empaqueter le 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 compilé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 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 aussi conteneuriser le code Python l'image de 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 déploiement dans des environnements d'exécution plutôt que de compiler du code.

Utiliser des builds automatisés

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

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. Cependant, il est aussi il est important d'exécuter des compilations dans un environnement cohérent et fiable.

Bien que les builds locaux puissent être utiles à des fins de débogage, la publication de provenant de builds locaux peut entraîner de nombreux problèmes de sécurité, des incohérences et et d'inefficacité 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 exigences pour le framework SLSA, les compilations automatisées constituent pour le niveau 1 du SLSA, et utiliser un service de compilation au lieu d'un service de pour les builds est une exigence du niveau SLSA de niveau 2.

Cloud Build est le service de compilation géré 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 de la compilation

La provenance de compilation est une collection de données vérifiables sur un build.

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 compilation.

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

  • 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 stratégies qui n'autorisent que les déploiements de code créés à 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 fait avec une signature numérique générée par le service qui crée le build données de provenance.

Pour SLSA niveau 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 d'un utilisateur.

Cloud Build peut générer la provenance de la compilation 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 builds.

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 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

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 utilisent également une identité non humaine pour exécuter des builds et interagir pour le compte de la compilation.

Si vous utilisez Cloud Build:

  • Accordez le nombre minimal d'autorisations 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.
  • Utiliser les intégrations autorisées de Cloud Build une règle d'administration pour contrôler les services externes autorisés à pour 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. La le périmètre réduit également le risque d'exfiltration de 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 considérer où vous publiez vos dépendances, qui a accès en lecture et en écriture des dépôts d'artefacts et des règles pour 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 des langages courants. Vous pouvez utiliser des images de conteneurs publiques provenant de registres publics tels que Docker Hub, les compilateurs fournis par Cloud Build, les compilateurs issus de la communauté et les 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écouvrir qui les fournit et décider si vous leur faites confiance dans votre logiciel d'approvisionnement. Pour mieux contrôler le code d'un compilateur, vous pouvez Créer des compilateurs personnalisés au lieu de les utiliser à partir d'une source publique.

Réduire les possibilités de modification du build

De nombreux autres facteurs peuvent influencer une compilation, y compris les suivants:

  • Les builds s'exécutant simultanément et pouvant s'influencer les uns les autres qui persiste et a un impact sur une compilation ultérieure.
  • Les compilations qui acceptent des paramètres utilisateur autres que le point d'entrée de la compilation et le l'emplacement source de premier niveau.
  • Les compilations qui spécifient des dépendances avec des plages ou des dépendances modifiable (par exemple, en utilisant 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 compilation dans un environnement éphémère.
  • Éviter d'exécuter des compilations avec des paramètres supplémentaires afin que les utilisateurs ne puissent pas d'influence définies dans les scripts de compilation.
  • Limitez l'accès au service de compilation et aux ressources de compilation.
  • Référencer des versions immuables des dépendances plutôt que des identifiants tels que les 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.

Software Delivery Shield

Software Delivery Shield est une solution de sécurité de la chaîne d'approvisionnement logicielle entièrement gérée de bout en bout. Il 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 posture 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'UI Cloud Build console Google Cloud. Par exemple :

  • Niveau SLSA, qui identifie le niveau de maturité de la sécurité de votre chaîne d'approvisionnement logicielle.
  • Failles, nomenclature des logiciels (SBOM) et vulnérabilité Instructions 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é pour les applications créées, consultez Créez une application et affichez les insights sur la sécurité.

Étape suivante