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. Elle vérifie également le code des pièges JavaScript courants.
  • Compiler le code en code intermédiaire: vous pouvez, par exemple, 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. Pour Par exemple, une compilation peut empaqueter du code Python dans une distribution créée Vous pouvez l'importer dans un magasin d'artefacts tel qu'Artifact Registry. PyPI afin que vous puissiez l'utiliser comme dépendance dans Cloud Functions. 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:

  • Une 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 aussi 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 attaquant avec une intention malveillante pour modifier le processus de compilation.
  • Les incohérences entre les environnements locaux et les pratiques des développeurs la reproduction des builds et le diagnostic des problèmes de compilation.

Les compilations manuelles rendent le processus inefficace en exploitant davantage d'infrastructures telles que le calcul, le stockage et les réseaux. Dans exigences pour le framework SLSA, les builds automatisés sont du SLSA de niveau 1 et d'utiliser un service de compilation au lieu d'un service 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 étapes vers 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é à d'autres services CI/CD sur comme Artifact Registry et Cloud Deploy, ainsi que des environnements d'exécution tels que GKE Cloud Run : intégration aux principaux codes sources systèmes de gestion de conteneurs 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 de compilation a été créé à partir d'un emplacement source approuvé et par un système de compilation de confiance.
  • Identifiez 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 la provenance de la compilation données. 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 SLSA niveau 1, la provenance de la compilation doit être disponible pour les consommateurs des les artefacts. Pour SLSA de niveau 2, les données de provenance de la compilation doivent également être:

  • Généré par le service de compilation ou lisible directement à partir du service de compilation.
  • Vérifiables par le consommateur pour vérifier leur authenticité et leur 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 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 une seule et même appel de compilation. Une fois la compilation terminée, l'environnement est effacé ou supprimé. Les builds éphémères garantissent que le service de compilation et les étapes de compilation s'exécuter 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 les détruit une fois le processus de compilation terminé.

Les environnements éphémères assurent les builds propres, car il n'y a aucun fichier résiduel ou les paramètres d'environnement des builds précédents, qui peuvent interférer avec le build processus. 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 et réduit les incohérences dans l'environnement de compilation.

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

Limiter l'accès au service de compilation

Suivez le principe de sécurité du moindre privilège en accordant les autorisations requises sur le service de compilation et les 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 pour le compte de service agissant au nom de Cloud Build afin qu'il ne dispose que des autorisations nécessaires à votre utilisation. Modifiez les autorisations compte de service Cloud Build, ou envisagez d'utiliser un compte de service personnalisé.
  • Utiliser les intégrations autorisées de Cloud Build une règle d'administration pour contrôler les services externes autorisés à et 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 des services Google Cloud dans le périmètre, mais limite sur l'ensemble du périmètre en fonction de 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 s'exécuter 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 la chaîne d'approvisionnement logicielle et l'exfiltration de données.

Évitez de stocker les 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 vos clés API, mots de passe et autres données sensibles. Vous pouvez configurer Cloud Build pour utiliser des secrets stockés dans Secret Manager.

Gérer vos dépendances

L'intégrité de vos applications repose sur celle de votre code, que vous développez et 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 Gérer les dépendances

Dans Cloud Build, vous utilisez des compilateurs Cloud pour exécuter commandes. Les compilateurs sont des images de conteneurs avec des langages et des outils communs qui y sont installés. 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 utiliser également des buildpacks comme compilateurs, y compris Les packs de création 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 builds qui spécifient des dépendances avec des plages ou des dépendances qui sont modifiable (par exemple, en utilisant une image avec le tag latest). Ces créent un risque que les builds utilisent des versions incorrectes ou indésirables les dépendances.

Les pratiques suivantes permettent d'atténuer ces risques:

  • Exécutez chaque build 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 Gestion des dépendances.

Software Delivery Shield

Software Delivery Shield est un entièrement gérée et de bout en bout pour la sécurité sur la chaîne d'approvisionnement logicielle. Il offre une un ensemble complet et modulaire de fonctionnalités et d'outils 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'UI Cloud Build console Google Cloud. Par exemple :

  • Le niveau SLSA, qui identifie le niveau de maturité de votre logiciel la sécurité de la chaîne d'approvisionnement.
  • Failles, nomenclature des logiciels (SBOM) et vulnérabilité Instructions Exploitability eXchange (VEX) pour les artefacts de compilation
  • La provenance de la compilation, qui est une collection de métadonnées vérifiables concernant un créer. 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é pour les applications créées, consultez Créez une application et affichez les insights sur la sécurité.

Étape suivante