Pipeline d'intégration continue

Le pipeline d'intégration continue génère les artefacts prêts à être déployés à partir des dépôts des applications.

Avant de générer un artefact, le pipeline vérifie que le code a bien été analysé et testé, de la même manière que sont traitées les demandes de fusion. Les artefacts générés sont également analysés pour vérifier la présence de vulnérabilités et signés dans le pipeline avant d'être marqués prêts pour la publication et le déploiement dans l'inventaire. Contrairement au pipeline de demande d'extraction, le pipeline d'intégration continue collecte des preuves et des artefacts de résultat à chaque étape de la génération, telle que le test, l'analyse et la signature. Ces données sont en corrélation avec les artefacts de génération et peuvent faire l'objet d'un suivi via le processus de déploiement et la gestion des changements.

Etapes et tâches

Le tableau suivant répertorie les tâches exécutées dans un pipeline de CI. En outre, le tableau fournit également une vue d'ensemble de chacune de ces étapes:

  • Tâche ou étape: fait référence au nom de l'étape tel qu'il est défini dans le fichier de configuration .pipeline-config.yaml.

  • Brève description: fournit une explication concise des actions effectuées lors de l'exécution de l'étape.

  • Customisation admissible: indique si les utilisateurs ont la possibilité de modifier ou de remplacer le comportement par défaut de l'étape en insérant un script personnalisé dans le fichier .pipeline-config.yaml.

  • Implémentation de référence par défaut: Ceci indique si leDevSecOps les pipelines sont livrés avec une implémentation prédéfinie ou par défaut pour l'étape. Notamment pour certaines étapes comme unit-tests ou setup, leDevSecOps pipeline n'offre aucune implémentation prête à l'emploi. Au lieu de cela, les utilisateurs doivent fournir des scripts personnalisés ou du code adapté aux exigences de leur application.

  • Collecte des informations collectées: indique si l'étape effectue la collecte des informations collectées standard. QuandDevSecOpsPipeline fournir une implémentation de référence pour une étape, la collecte de preuves est effectuée immédiatement. Toutefois, si l'utilisateur choisit de modifier ou de remplacer ces étapes prédéfinies, il doit s'assurer que leurs implémentations personnalisées incluent une collecte d'informations collectées appropriée. La même responsabilité incombe aux utilisateurs pour les étapes où leDevSecOps Le pipeline ne fournit pas une implémentation prête à l'emploi, ce qui les oblige à effectuer une collecte de preuves. La colonne indique l'entité (Utilisateur / Pipeline) chargée de la collecte des informations collectées.

  • Ignorer autorisé (applicable à la version > = v10): indique si les utilisateurs peuvent refuser d'exécuter cette étape en définissant la propriété Ignorer sur true dans .pipeline-config.yaml. Toutefois, il est conseillé de faire preuve de prudence lors de l'utilisation de cette fonction, en particulier pour les étapes conçues pour collecter des preuves. L'omission de ces étapes peut entraîner l'absence d'informations collectées essentielles pour la génération.

Étapes et tâches de l'intégration continue
Tâche ou étape Brève description Personnalisation autorisée dans .pipeline-config.yaml Implémentation de référence par défaut Collecte des preuves Ignorer autorisé
start Configuration de l'environnement de pipeline. Non Oui Pipeline Non
setup Configuration de votre environnement de génération et de test. Oui Non ND Non
detect-secrets Exécutez l'analyse des secrets de détection sur le code d'application. Oui Oui Pipeline Non
test Exécution de tests d'unité et de tests d'application sur un code d'application. Oui Non User Oui
static-scan Exécution de code d'analyse statique sur le code d'application. Oui Oui Pipeline Oui
compliance-checks Exécution d'analyses Code Risk Analyzer et d'autres vérifications de conformité sur les référentiels d'applications. Oui Oui Pipeline Oui
peer-review Collecter des données de conformité issues des révisions par les pairs pour les pull requests fusionnées. Oui Oui Pipeline Oui
containerize Génération des artefacts. Oui Non ND Non
sign-artifact Signature des artefacts de génération. Oui Oui Pipeline Non
deploy Déploiement des artefacts de génération sur l'environnement de développement. Oui Non ND Non
dynamic-scan Exécutez l'analyse dynamique sur l'application. Oui Oui Pipeline Oui
acceptance-test Exécution de tests d'acceptation et d'intégration sur les artefacts de génération déployés sur l'environnement de développement. Oui Non User Oui
scan-artifact Analyse des artefacts de génération. Oui Oui Pipeline Oui
release Ajout des artefacts de génération à l'inventaire. Oui Non ND Oui
finish Collecte, création et téléchargement des fichiers journaux, des artefacts et des preuves dans le casier de preuves. Oui Oui ND Oui

Pour plus d'informations sur la personnalisation des étapes à l'aide du fichier « .pipeline-config.yaml », consultez les sections « Scripts personnalisés » et « Listes des paramètres de pipeline ».

Étapes et preuves

Le tableau suivant établit une relation entre les différents types d'éléments de preuve et les étapes spécifiques de la filière où leur collecte a lieu.

Les étapes de l'intégration continue et les preuves associées
Tâche ou étape Type de justificatif
start ND
setup ND
detect-secrets com.ibm.detect_secrets
test com.ibm.unit_tests
static-scan com.ibm.static_scan
compliance-checks com.ibm.code_bom_check, com.ibm.code_cis_check, com.ibm.code_vulnerability_scan, com.ibm.branch_protection
peer-review com.ibm.peer_review
containerize ND
sign-artifact com.ibm.cloud.image_signing
deploy ND
dynamic-scan com.ibm.dynamic_scan
acceptance-test com.ibm.acceptance_tests
scan-artifact com.ibm.cloud.image_vulnerability_scan
release ND
finish com.ibm.pipeline_logs, com.ibm.pipeline_run_data

Pour plus d'informations sur la façon de collecter des informations collectées dans les étapes utilisateur personnalisables à l'aide du script collect-evidence, voir script de collecte des informations collectées.

Détection de l'analyse des secrets

L'outil IBM Detect Secrets identifie l'endroit où les secrets sont visibles dans le code d'application. Pour plus d'informations sur la configuration de votre référentiel pour l'analyse, voir ici

Analyse de code statique

L'étape d'analyse de code statique exécute un certain nombre d'outils d'analyse de code statique sur les référentiels d'application spécifiés. Les référentiels qui sont fournis par la commande pipelinectl save_repo et le référentiel d'application par défaut sont analysés.

Vous pouvez utiliser l'une des méthodes suivantes pour ajouter du code statique à votre pipeline :

  • Fournissez le nom, l'URL et les données d'identification d'une instance SonarQube déjà en cours d'exécution en ajoutant l'outil SonarQube à votre chaîne d'outils. La tâche d'analyse statique exécute une analyse sur les référentiels spécifiés.

  • Si vous n'avez pas votre propre instance SonarQube, le pipeline crée une instance SonarQube lors de l'exécution du pipeline. Vous pouvez accéder à cette instance après l'exécution réussie de l'étape static-scan.

  • En utilisant le paramètre opt-in-gosec pour exécuter l'analyse gosec pour les contrôles de sécurité golang.

  • Ajoutez votre propre code d'analyse statique à l'étape personnalisée d'analyse statique dans votre fichier .pipeline-config.yaml pour une implémentation personnalisée.

Ajout de l'analyse SonarQube à vos pipelines

Pour plus d'informations sur l'intégration de SonarQube au pipeline d'intégration continue, voir Configuration de SonarQube.

Ajout de l'intégration de l'analyse gosec à vos pipelines

Utilisez gosec pour inspecter le code source golang dans vos référentiels analysés.

Pour activer l'analyse gosec, indiquez le paramètre suivant et définissez la valeur sur 1.

paramètres de balayage gosec
Nom Type Description Obligatoire ou facultatif
opt-in-gosec text option permettant d'activer l'analyse gosec facultatif

Pour plus d'informations sur la configuration de l'analyse gosec dans le pipeline d'intégration continue, voir Configuration de GoSec

Utilisation d'autres scanners statiques

Si vous souhaitez utiliser votre propre implémentation de scan statique, vous pouvez modifier votre fichier .pipeline-config.yaml et ajouter votre propre script personnalisé à l'étape d' static-scan.

Analyses et vérifications de conformité

Analyses et contrôles de conformité
Analyse ou vérification Description
Analyse de vulnérabilité via Code Risk Analyzer Recherche des vulnérabilités pour toutes les dépendances de package d'applications, les images de base de conteneur et les packages de système d'exploitation. Utilise l'outil Code Risk Analyzer.
Vérification de CIS via Code Risk Analyzer Exécute des vérifications de configuration sur les manifestes de déploiement Kubernetes. Utilise l'outil Code Risk Analyzer.
Vérification de nomenclature via Code Risk Analyzer Nomenclature d'un référentiel spécifié qui capture l'origine de toutes les dépendances. Cette nomenclature est collectée à différents niveaux de granularité. Par exemple, la nomenclature capture la liste des images de base qui sont utilisées dans la génération, la liste des packages à partir des images de base et la liste des packages d'applications qui sont installés par dessus l'image de base. la nomenclature agit comme des données de référence pour les résultats d'analyse et peut potentiellement être utilisée pour contrôler les jalons de politique. Utilise l'outil Code Risk Analyzer.
Vérification de conformité de référentiel Vérifie que les paramètres de protection de branche sont corrects. Par exemple, la branche principale / principale doit toujours limiter la force de poussée. Pour plus d'informations, voir Configuration de votre référentiel Git Repos and Issue Tracking.

Ces scripts sont exécutés sur tous les référentiels d'applications dont le pipeline a connaissance. Pour ajouter des référentiels à ces analyses, utilisez l'interface pipelinectl qui est fournie dans votre étape de configuration.

Pour plus d'informations sur la sortie attendue à partir des étapes de script utilisateur, voir Scripts personnalisés.

Remarque: les pipelines de CI ne sont pas déclenchés sur les balises car ils ne prennent pas en charge des fonctionnalités telles que branch protection checks ou peer review check. Si vous choisissez d'exécuter un pipeline CI sur les balises, assurez-vous de désactiver les propriétés peer-review-compliance et branch-protection-check en les réglant sur 0. Toutefois, il faut savoir que dans ce cas, la collecte de preuves n'aura pas lieu.

Générer

Au cours de l'étape de génération, vous pouvez générer vos propres artefacts. Bien que le pipeline fournisse des fonctions par défaut pour les artefacts de type d'image Docker, vous pouvez générer n'importe quel type d'artefact sur cette page.

Utilisez les variables d'environnement à partir de l'interface utilisateur de pipeline pour fournir des données d'identification, secrets et paramètres pour votre génération. Vous pouvez accéder à ces variables d'environnement au cours de cette étape et au cours de toutes les étapes personnalisées. Pour plus d'informations sur l'accès aux paramètres et aux secrets au cours des étapes de script personnalisé, voir Scripts personnalisés.

Analyse et signature d'artefact

Les étapes d'analyse et de signature d'artefact fournissent un comportement par défaut pour les images Docker, avec des étapes personnalisables :

  • Signature d'image à l'aide d'une clé GPG
  • Analyse via Container Registry Vulnerability Advisor

Pour commencer à utiliser ces étapes, fournissez vos artefacts pour le pipeline pour utiliser l'interface pipelinectl. Vous n'êtes pas tenu de mettre à jour les scripts de génération et la configuration .pipeline-config.yaml.

Pour utiliser un autre processus d'analyse ou de signature, ou pour traiter des artefacts autres que les images Docker dans icr.io, vous pouvez personnaliser ces étapes à l'aide de la configuration .pipeline-config.yaml dans votre projet.

Déploiement en environnement de développement

L'étape de déploiement déploie des artefacts de génération dans un environnement de développement.

Analyse dynamique

L'analyse de code dynamique est une forme d'analyse de vulnérabilité de boîte noire qui permet aux équipes de logiciels d'analyser les applications en cours d'exécution et d'identifier les vulnérabilités.

L'étape Dynamic Scan s'exécute immédiatement après l'étape Deploy to dev après un déploiement réussi dans l'environnement de développement.

Par défaut, le pipeline fournit la prise en charge de l'exécution de l'analyse ZAP (Zed Attack Proxy), qui est un outil de test de pénétration libre et open source géré sous l'égide d'OWASP. Il effectue à la fois des analyses dynamiques d'API et d'interface utilisateur, qui peuvent toutes deux être exécutées sur l'exemple hello-compliance-app.

Pour exécuter l'analyse dynamique, définissez le paramètre de pipeline opt-in-dynamic-scan sur une valeur non vide. Pour empêcher l'étape d'exécuter des analyses dynamiques, définissez le paramètre de pipeline opt-in-dynamic-scan sur vide. Pour plus d'informations sur la définition des paramètres de pipeline, voir Paramètres de pipeline.

Le pipeline d'EC crée des problèmes dans le référentiel d'anomalies en fonction de la gravité. Le libellé associé au problème indique la gravité de la vulnérabilité.

Analyse d'API ZAP

L'API ZAP analyse les noeuds finaux d'application à la recherche de fuites de données, d'erreurs de type de contenu, de redirections externes, d'injection de code, d'injection SQL, d'injection de commande de système d'exploitation distant et d'autres vulnérabilités qui sont exposées par l'application. Les analyses de l'API ZAP aident les développeurs à sécuriser l'application en détectant ces vulnérabilités dans une étape ou un environnement de test et en les corrigeant avant le déploiement de l'application dans un environnement de production.

Les analyses d'API ZAP requièrent les entrées suivantes pour analyser votre application:

  • Fichier de définition Swagger - Décrivant les API d' HTTP s et leurs paramètres associés tels qu'exposés par l'application.
  • Clé d'API-Jeton d'authentification requis pour l'authentification avec les noeuds finaux d'API.
  • Noeud final d'API-Noeuds finaux des définitions swagger que vous souhaitez que ZAP analyse.
  • URL exclues-URL à ignorer par le scanner ZAP.

Le scanner d'API ZAP utilise les entrées mentionnées pour exécuter l'analyse et générer un rapport.

Définissez opt-in-dynamic-api-scan sur une valeur non vide pour l'exécution des analyses d'API ZAP. Pour désactiver l'option de retrait, définissez ce paramètre sur vide.

Analyse de l'interface utilisateur ZAP

ZAP UI analyse les points de terminaison de l'application à la recherche de vulnérabilités présentes directement sur les pages Web, telles que la création de cookies non sécurisés, des paramètres d'en-tête de mise en cache incorrects, l'inclusion de fichiers interdomaines, des paramètres d' CORS s incorrects, ainsi que d'autres vulnérabilités exposées par l'application.

Les analyses d'interface utilisateur fonctionnent de la même manière que les analyses d'API, mais elles utilisent un script de test d'interface utilisateur au lieu d'un fichier Swagger. Le script de test d'interface utilisateur démarre un navigateur sans interface graphique qui est configuré pour effectuer un proxy via le proxy du scanner ZAP et exécute un test d'interface utilisateur sur le noeud final d'interface utilisateur. Le processus d'exécution des tests d'interface utilisateur ZAP est le suivant:

  • Copiez les scripts de test dans les conteneurs ZAP Scanner.
  • Exécutez le proxy ZAP.
  • Exécutez les scripts de test zap.

Le proxy ZAP enregistre le trafic et reconnaît les noeuds finaux à analyser. Une fois les analyses terminées, le proxy génère un rapport et génère des problèmes de la même manière que dans l'analyse de l'API ZAP.

Définissez opt-in-dynamic-ui-scan sur une valeur non vide pour l'exécution des analyses d'API ZAP. Pour désactiver l'option de retrait, définissez ce paramètre sur vide.

  • Pour une implémentation personnalisée, ajoutez votre propre code de balayage dynamique à l'étape personnalisée « dynamic-scan » dans votre fichier « .pipeline-config.yaml ».

Pour plus d'informations sur l'analyse de l'API ZAP et les analyses de l'interface utilisateur ZAP, voir Configuration des analyses ZAP.

Publication dans l'inventaire

Utilisez l'étape de script utilisateur de publication dans l'inventaire pour ajouter des artefacts à l'inventaire à l'aide de la commande CLI cocoa inventory add. Pour plus d'informations sur la commande, voir la rubrique cacao inventory add.

Si vous souhaitez ignorer la mise à jour de l'inventaire en cas de problèmes dans le pipeline, utilisez les variables d'environnement suivantes pour vérifier le statut du pipeline. Vérifiez leur statut avant de mettre à jour l'inventaire:

  • skip-inventory-update-on-failure Variable d'environnement d'option d'adhésion du pipeline pour indiquer si la mise à jour du stock doit être effectuée.
  • one-pipeline-status est défini sur 1 s'il y a un échec d'étape dans l'exécution du pipeline.

Vous pouvez utiliser l'interface pipelinectl pour accéder à vos dépôts et à vos artefacts à l'aide des commandes list_repos, load_repo, list_artifacts et load_artifact. Pour plus d'informations sur les commandes, voir la documentation pipelinectl.

Collecte de données de conformité sur la génération

Lorsque le pipeline s'exécute correctement, vous pouvez collecter des informations sur la génération.

Des preuves sont collectées sur la totalité des vérifications, analyses, tests, et sur la signature d'artefact dans le casier de preuves. Les fichiers journaux de pipeline sont également sauvegardés dans le casier, avec les données de pipeline proprement dites, contenant les définitions Tekton. Les données de conformité sur les évaluations par les pairs sont également collectées au cours de cette étape. Le pipeline utilise pipelinectl pour rechercher des référentiels contenant des demandes d'extraction qui ont été fusionnés depuis la dernière génération. Il vérifie également leur statut des vérification, les sauvegarde en tant qu'artefact et crée des preuves en fonction du résultat.

Le script final est un évaluateur, qui affecte la couleur verte ou rouge au statut du pipeline en fonction des statuts de preuve. S'ils contiennent des erreurs, la couleur rouge est affectée à l'exécution de l'intégration continue.