Création d'un pipeline avec une configuration DevSecOps inférée

Taches de code

Les points de code sont liés à un langage de code source pris en charge, notamment :

• Node.js (avec npm, Yarn ou Gradle)
• Java (avec Maven ou Gradle)
• Golang
• Python
• Fichier Dockerfile
• Langage de configuration de Terraform

Les spots " code gèrent les processus suivants :

• building: Définit les outils qui réalisent la construction du code source donné.
• unit-testing: localise les outils qui effectuent les tests unitaires du résultat de la construction.

Points de déploiement

Les spots " deployment localisent un véhicule de déploiement, y compris les ressources et les outils de déploiement. les spots deployment présentent un processus de déploiement qui énumère les outils de déploiement. Les véhicules de déploiement actuellement pris en charge sont les suivants

• Définitions des ressources Kubernetes comme 'Pod, 'ReplicaSet, 'ReplicationController, 'Deployment, 'Daemonset, 'StatefulSet, 'Job, 'Cronjob' , 'NetworkPolicy, 'Ingress, 'Service, 'Route ' - kubectl comme outil

• Websphere Liberty Application Custom Resource- kubectl comme outil

• Open Liberty Ressource personnalisée de l'application- 'kubectl en tant qu'outil

• Carte deHelm- la barre comme outil

• Configuration de Terraform- IBM Cloud Schematics ou Terraform CLI comme outil

• Ressource personnalisée Wazi 'DeploymentMethod- 'Déploiement de Wazi en tant qu'outil

• Dockerfile lorsque IBM Cloud Code Engine a été configuré pour le déploiement- IBM Cloud Code Engine CLI comme outil

Taches du test d'acceptation

Les points " acceptance-test localisent une suite de tests d'acceptation à exécuter. les points acceptance-test ont un processus " acceptance-testing qui identifie les outils permettant d'exécuter la suite de tests d'acceptation.

Spots à balayage dynamique

Les points " dynamic-scan identifient les emplacements pour un balayage dynamique. Les spots de balayage dynamique disposent d'un processus " scanning pour dresser la liste des outils de balayage invoqués pendant le balayage dynamique.

L'analyse ZAP de l'OWASP est le seul outil pris en charge pour démarrer un déclencheur de sous-connexion Web.

Taches de libération

Les points " release localisent le processus de libération. Les spots de diffusion ont un processus " releasing qui énumère les outils à utiliser pendant la phase de diffusion. Actuellement, les outils pris en charge pour le processus de déblocage sont les suivants :

• libération sémantique
• maven avec la phase 'maven deploy.

Configuration de la branche d'injection

Vous pouvez configurer le nom de la branche dans laquelle sont injectés les fichiers déduits de DevSecOps en utilisant la propriété de pipeline " inferred-devsecops-branch La valeur par défaut est inferred-devsecops.

Utilisez la propriété du pipeline push-inferred-pipeline-configuration-files (la propriété push-polyglot-files est dépréciée au profit de la propriété push-inferred-pipeline-configuration-files ) pour activer ou désactiver la création et la mise à jour de la branche inferred-devsecops:

Ignorer les taches

Vous pouvez ignorer des points spécifiques lors de l'extraction en utilisant des expressions régulières. Les options de configuration suivantes sont disponibles :

• ignore-code-spot-pattern: ignore les points de code qui correspondent à l'expression régulière spécifiée.
• ignore-deployment-spot-pattern: Ignore les spots de déploiement qui correspondent à l'expression régulière spécifiée.
• ignore-dynamic-scan-spot-pattern: ignore les spots de balayage dynamique qui correspondent à l'expression régulière spécifiée.
• ignore-acceptance-test-spot-pattern: Ignore les spots des tests d'acceptation qui correspondent à l'expression régulière spécifiée.
• ignore-release-spot-pattern: Ignore les spots de libération qui correspondent à l'expression régulière spécifiée.

Configuration du Code Engine

Si vous utilisez IBM Cloud Code Engine pour le déploiement, indiquez le projet Code Engine et configurez le processus de construction avec les propriétés suivantes de l'environnement du pipeline :

• code-engine-project: Spécifie le projet Code Engine
• code-engine-build-use-native-docker: (Défaut : 'false) Indique s'il faut utiliser la CLI de Docker au lieu de la commande 'ibmcloud code-engine buildrun
• root-as-build-context: (Par défaut : false ) indique que le contexte de construction pour un outil de construction lié à l' Dockerfile, tel que docker ou code-engine, doit utiliser la racine du référentiel comme contexte de construction et non le dossier contenant le Dockerfile.

Configuration de la création d'images de conteneurs

• container-image-builder: (Par défaut docker) Pour les builds liés à Dockerfile, spécifiez l'outil à utiliser (docker ou podman) pour créer l'image du conteneur.
• root-as-build-context: (Par défaut : false) indique que le contexte de compilation pour l'outil de Dockerfile compilation associé (tel que docker, podman ou code-engine) doit utiliser la racine du référentiel comme contexte de compilation et non le dossier contenant le fichier Dockerfile.

Configuration de Golang

Pour configurer le processus d'extraction de points pour Golang, définissez les propriétés suivantes de l'environnement du pipeline :

• go-ignore-main: (Défaut : 'false) Indique si l'extraction de points de code ne doit pas se concentrer sur la détection du paquet principal et de la fonction principale pour l'argument source principal.
• go-output: Spécifie le fichier de sortie exécutable de la commande go build.

Configuration de Gradle

Pour configurer les tâches Gradle pour l'installation, les tests unitaires, les artefacts de construction et les tests d'acceptation, utilisez les propriétés suivantes de l'environnement du pipeline :

• gradle-setup-tasks: (Défaut : 'assemble) Liste de tâches Gradle séparées par des virgules pour l'étape de configuration.
• gradle-unit-testing-tasks: (Défaut : 'test) Liste de tâches Gradle séparées par des virgules pour l'étape de test unitaire.
• gradle-build-artifact-tasks: (Défaut : 'build) Liste de tâches Gradle séparées par des virgules pour l'étape build-artifact.
• gradle-acceptance-testing-tasks: Liste de tâches Gradle séparées par des virgules pour l'étape du test d'acceptation.

Configuration de NPM

Vous pouvez configurer la détection des scripts de tests unitaires et de tests d'acceptation de NPM.

• hint-npm-unit-testing-script: (Défaut : 'test) Indications pour la détection des scripts de tests unitaires de NPM.
• hint-npm-acceptance-testing-script: (Défaut : 'acceptance-test) Indications pour la détection des scripts de tests d'acceptation de NPM.

Configuration de Python

Pour configurer la version de Python Poetry, utilisez les propriétés suivantes de l'environnement du pipeline :

• hint-python-poetry-version: (Défaut : '1.8.2) Indications pour la version de Python Poetry.
• discover-python-unittest-from-ancestor: (Défaut : false) indique que le répertoire ancêtre est utilisé comme point de départ pour la découverte de python unittest (par exemple, afin de découvrir les tests unitaires à partir du répertoire contenant le requirements.txt à la racine du référentiel et non le requirements.txt (s'il y en a un) qui est le plus proche des fichiers python unittest).

Configuration Terraform

Pour configurer le processus de déploiement Terraform, utilisez les propriétés suivantes de l'environnement du pipeline :

• terraform-deployment: (Défaut : 'false) Désactive Schematics comme véhicule de déploiement en faveur de Terraform et Cloud Object Storage pour le stockage de l'état.

Téléchargement d'un artefact

Pour configurer le processus de téléchargement des artefacts, utilisez les propriétés suivantes de l'environnement du pipeline :

• artifact-upload-to-devsecops-cos: (Défaut : 'false) Permet le téléchargement d'artefacts dans un seau de Cloud Object Storage en utilisant le CLI DevSecOps pour les artefacts non sauvegardés dans des images.

Injection de variables d'environnement dans les étapes d'exécution du pipeline

La fonction de configuration du pipeline DevSecOps inféré fournit un utilitaire " export-properties permettant d'exporter les propriétés du pipeline et des déclencheurs en tant que variables d'environnement pendant l'exécution de l'étape. Cet utilitaire est invoqué à chaque étape personnalisée :

export-properties "GLOBAL" && export-properties "${STAGE^^}"

Exécution et configuration de l'outil

Certains outils de la fonctionnalité Configuration inférée du pipeline DevSecOps utilisent les propriétés du pipeline et du déclencheur pour inférer une configuration complémentaire.

Activer la protection des branches par défaut

Les pipelines DevSecOps PR et CI activent par défaut la protection des branches sur le dépôt de code source. Cette vérification a lieu au cours de la phase de configuration du code.

Désactiver la protection de la branche

Pour désactiver la protection des branches, définissez la propriété " setup-branch-protection comme étant " false.

Personnaliser les contrôles d'état de la protection des branches

Pour personnaliser le préfixe des contrôles de l'état de protection de la branche, définissez la propriété " branch-protection-status-check-prefix. Le préfixe par défaut est " tekton.

Configurer Poetry pour les dépôts privés

Lorsque l'on utilise Poetry (pyproject.toml est identifié comme un point de code) et qu'une source ou un référentiel alternatif est défini pour récupérer les dépendances, par exemple :

[[tool.poetry.source]]
name = "local"
url = "https://na-public.artifactory.swg-devops.com/artifactory/api/pypi/ip-devops-team-pypi-virtual/simple"
secondary = true

ou lorsque la Poésie est impliquée (par exemple, pyproject.toml contenant une section build-system avec build-backend égal à poetry.core.masonry.api est un point de diffusion identifié), il peut être nécessaire de fournir des informations d'identification pour s'authentifier auprès des registres privés.

S'authentifier avec des référentiels privés dans IBM Cloud

Il est nécessaire de fournir des informations d'identification pour ce référentiel source " local La documentation de Poetry sur la configuration des informations d'identification indique que les variables d'environnement pour fournir l'utilisateur et le mot de passe http doivent être " POETRY_HTTP_BASIC_LOCAL_USERNAME et " POETRY_HTTP_BASIC_LOCAL_PASSWORD.

Utilisez la fonction d'injection de variables d'environnement et ajoutez les propriétés suivantes à l'environnement du pipeline :

• ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_USERNAME (texte) avec la valeur appropriée
• ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_PASSWORD (sécurisé) avec la valeur sécurisée appropriée

Configurer Maven pour les fichiers de paramètres personnalisés dans IBM Cloud

Si votre projet Maven définit un fichier de configuration spécifique avec un nom de fichier personnalisé, tel que " ci-settings.xml, définissez une propriété d'environnement de pipeline maven-user-settings-file-path avec la valeur " ci_settings.xml au niveau des propriétés PR, pipeline CI ou trigger.

En outre, s'il y a un " env.<VARIABLE> à résoudre, par exemple :

    <server>
      <username>${env.MAVEN_USERNAME}</username>
      <password>${env.MAVEN_PASSWORD}</password>
      <id>central</id>
    </server>

Utilisez la fonctionnalité d'injection de variables d'environnement pour fournir ces variables en ajoutant 2 propriétés de pipeline (dans le pipeline PR et CI):

• ENV_GLOBAL_MAVEN_USERNAME (texte) avec la valeur à utiliser pour le nom d'utilisateur maven
• ENV_GLOBAL_MAVEN_PASSWORD (sécurisé) avec la valeur à utiliser pour le mot de passe maven

Activer les liens statiques pour les constructions Go

Par défaut, " go build produit un binaire lié dynamiquement. Pour l'utiliser dans un conteneur Docker, activez la liaison statique en définissant 'CGO_ENABLED=0 pendant la construction.

Configurer la variable d'environnement pour la construction de Go

Pour activer la liaison statique, utilisez la fonction d'injection de variables d'environnement pour ajouter la propriété d'environnement suivante dans le pipeline CI :

• ENV_SETUP_CGO_ENABLED avec la valeur " 0