Pipeline de conformité continue

Le pipeline de conformité continue (pipeline CC) analyse périodiquement les artefacts déployés et leurs référentiels source.

Le pipeline CC traite les entrées du référentiel inventory en utilisant la valeur environment-tag pour déterminer quel est le dernier état déployé à examiner. Après avoir analysé et exécuté des vérifications sur les artefacts et les référentiels source, le pipeline crée un nouveau problème d'incident ou met à jour les problèmes d'incident existants dans le référentiel d'incidents. Enfin, à partir de ces questions et des résultats, le pipeline recueille des preuves et les résume pour mettre à jour l'état de conformité des artefacts trouvés.

Etapes et tâches

Le tableau suivant répertorie les tâches exécutées dans une CC Pipeline. 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 continues du processus de conformité
Tâche ou étape	Brève description	Personnalisation autorisée dans `.pipeline-config.yaml`	Implémentation de référence par défaut	Collecte d'informations collectées	Ignorer autorisé
`start`	Configurez l'environnement de pipeline.	Non	Oui	Pipeline	Non
`setup`	Configurez votre environnement de génération et de test.	Oui	Non	Non	Non
`detect-secrets`	Exécutez l'analyse des secrets de détection sur le code d'application.	Oui	Oui	Pipeline	Non
`static-scan`	Exécutez le code d'examen statique sur le code d'application.	Oui	Oui	Pipeline	Oui
`dynamic-scan`	Exécutez l'analyse dynamique sur l'application.	Oui	Oui	Pipeline	Oui
`compliance-checks`	Exécutez des analyses Code Risk Analyzer et d'autres vérifications de conformité sur les référentiels d'application.	Oui	Oui	Pipeline	Oui
`scan-artifact`	Analyse des artefacts générés.	Oui	Oui	Pipeline	Oui
`finish`	Collecter, créer et télécharger les fichiers journaux, les artefacts et les informations collectées dans le casier d'informations collectées.	Oui	Oui	Pipeline	Oui

Pour plus d'informations sur la personnalisation des étapes à l'aide du fichier .pipeline-config.yaml, voir Scripts personnalisés et Listes de 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`
`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`
`dynamic-scan`	`com.ibm.dynamic_scan`
`scan-artifact`	`com.ibm.cloud.image_vulnerability_scan`
`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.

Traitement de l'inventaire des artefacts et des référentiels

La phase de démarrage clone l'inventaire et traite les dernières entrées dans l'environnement de production. Vous pouvez spécifier cet environnement en fournissant les paramètres de pipeline suivants:

Artéfacts et référentiels du pipeline de conformité continue
Nom	Type	Description	Requise ou facultative
`environment-tag`	texte	Balise qui représente le dernier environnement cible dans l'inventaire. Exemple: `prod_latest` ou `us-south_prod_latest`	Obligatoire
`environment-branch`	texte	Nom de la branche qui représente l'environnement cible dans l'inventaire. Exemple:`prod`	Obsolète-préférer `environment-tag` à la place
`region-prefix`	texte	Nom de région comme préfixe de la balise `latest` pour l'environnement cible. Exemple : `us-south`	Obsolète-préférer `environment-tag` à la place

Les entrées d'inventaire contiennent des artefacts déployés et des sources de référentiel. Le pipeline traite et collecte les entrées d'inventaire et les enregistre pour l'exécution du pipeline à l'aide des commandes pipelinectl suivantes:

L'étape de démarrage clone également les référentiels trouvés, chaque référentiel et chaque paire de validations. Ainsi, par exemple, repo1 avec validation sha1 sont clonés dans un dossier, mais le pipeline clone le même repo1 avec validation sha2 dans un dossier distinct.

Le pipeline enregistre les artefacts et les référentiels pour l'exécution du pipeline en utilisant une notation de dénomination simple et en incrémentant l'index, comme dans les exemples suivants:

repo-1, repo-2, repo-3
artifact-1 artifact-2, artifact-3

Vous pouvez répertorier ces entrées dans les étapes personnalisées à l'aide des commandes pipelinectl suivantes:

Si vous extrayez les informations de branche dans votre pipeline CC à l'aide de la commande pipelinectl load_repo "$repo" branch, elle renvoie toujours master comme branche. Par conséquent, utilisez commit hashes plutôt que des branches.

Étape de configuration

L'étape de configuration dans le pipeline CC exécute le script qui se trouve dans l'étape setup définie par votre .pipeline-config.yaml. Vous pouvez déterminer dans quel pipeline le script s'exécute à l'aide de la commande suivante:

get_env pipeline_namespace

Cette commande renvoie cc, cd, ci ou pr, selon le pipeline en cours d'exécution. Ainsi, vous pouvez réutiliser le script de configuration entre les pipelines si nécessaire.

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 outil d'analyse de code statique sur les bases de codes de référentiel d'application spécifiées.

Le pipeline CC fournit les référentiels qui se trouvent dans l'inventaire du scanner.

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 static-scan exécute un scan sur les dépôts spécifiés.
Ajoutez votre code à l'étape personnalisée static-scan dans votre fichier .pipeline-config.yaml pour une mise en œuvre personnalisée.

Analyse dynamique

L'étape d'analyse dynamique exécute un outil de test de sécurité d'application dynamique pour détecter les vulnérabilités dans l'application déployée.

Ajoutez votre propre code de balayage dynamique à l'étape personnalisée de balayage dynamique dans votre fichier .pipeline-config.yaml pour une mise en œuvre personnalisée.

Pour en savoir plus sur la configuration de l'analyse dynamique à l'aide d'OWASP-ZAP, voir Configuration de l'analyse ZAP pour le pipeline CC.

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.

Ces scripts sont exécutés sur tous les référentiels d'applications dont le pipeline a connaissance. Le pipeline CC utilise l'interface pipelinectl save_repo pour enregistrer les référentiels trouvés dans les entrées de stock, puis utilise les commandes list_repos et load_repo pour itérer sur les référentiels et les envoyer aux scanners.

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

Analyse et signature d'artefact

L'étape d'analyse des artefacts fournit un comportement par défaut pour les images Docker, avec une étape personnalisable:

Container Registry Vulnerability Advisor balayage

Le pipeline CC utilise l'interface pipelinectl save_artifact pour enregistrer les artefacts trouvés dans les entrées d'inventaire, puis effectue une itération sur ces artefacts à l'aide des commandes list_artifacts et load_artifact.

Pour vous initier à cette étape, fournissez vos artefacts pour le pipeline à l'aide de 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 processus de numérisation différent ou pour traiter des artefacts autres que les images Docker dans icr.io, vous pouvez personnaliser ces étapes en utilisant la configuration .pipeline-config.yaml dans votre projet.

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

Le pipeline CC tente de traiter les résultats des vérifications et des analyses, en décomposant les résultats en problèmes individuels en fonction de chaque CVE, vulnérabilité ou alerte trouvée. Les problèmes détectés par le pipeline CC sont signalés par un libellé continuous-compliance-check qui identifie les problèmes détectés dans l'environnement de production.

Le pipeline collecte des informations collectées sur tous les contrôles et analyses et les stocke dans le casier d'informations collectées. Le collecteur d'informations collectées sauvegarde également les fichiers journaux de pipeline, les données de pipeline elles-mêmes, contenant les définitions Tekton. Les problèmes qui sont créés en fonction de l'analyse et vérifiez que les résultats sont également associés aux informations collectées.