Pipeline de demande d'extraction

Le pipeline de demandes d'extraction exécute un ensemble de contrôles de conformité sur une demande d'extraction pour le référentiel d'applications spécifié.

Il se peut que les tentatives de fusion d'une demande d'extraction dans la branche principale soient bloquées en raison d'un échec des vérifications de statut de conformité. Lorsque la demande d'extraction est ouverte ou mise à jour sur la branche principale, l'exécution du pipeline de demande d'extraction est déclenchée. Vous pouvez exécuter votre propre configuration pour les pipelines et les tests dans les scripts personnalisés.

Etapes et tâches

Le tableau ci-dessous répertorie les tâches exécutées dans un pipeline PR. 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.
Mise en œuvre de référence par défaut: Ceci indique si les DevSecOps pipelines sont livrés avec une mise en œuvre prédéfinie ou par défaut pour l'étape. Notamment, pour certaines étapes comme unit-tests ou setup, le pipeline DevSecOps ne propose pas d'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. Lorsque DevSecOps Pipeline fournit une implémentation de référence pour une étape, la collecte de preuves est effectuée de manière prête à l'emploi. 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ù le DevSecOps pipeline ne fournit pas d'implémentation prête à l'emploi, ce qui les oblige à procéder à la 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.

Ordonnance sur les pipelines
Tâche ou étape	Description abrégée	Personnalisation autorisée dans `.pipeline-config.yaml`	Implémentation de référence par défaut	Exigence de collecte d'informations collectées	Ignorer
`start`	Configurez l'environnement de pipeline.	Non	Oui	Non	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	Non	Non
`unit-tests`	Exécutez des tests d'unité et des tests d'application sur le code d'application.	Oui	Non	NA	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	Non	Oui
`finish`	Consolider le statut du pipeline.	Oui	Oui	Non	Oui

Pour plus d'informations sur la personnalisation des étapes à l'aide du fichier .pipeline-config.yaml, voir Scripts personnalisés et Paramètres de pipeline.

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.

Analyses et vérifications 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 la conformité du référentiel | Vérifie que les paramètres de protection des branches sont corrects. |

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.

Travaux de tâche

Analyses et contrôles de conformité
Travail de tâche	Description
`code-pr-start`	Clone des référentiels d'applications et DevSecOps, et définit l'état En attente initial pour les vérifications de statut sur les référentiels Git Repos and Issue Tracking.
`code-setup`	Marque de réservation pour un script personnalisé de configuration défini par l'utilisateur qui permet à celui-ci de finaliser la configuration de son pipeline.
`code-detect-secrets`	Exécute l'analyse des secrets de détection pour identifier où les secrets sont visibles dans le code de l'application.
`code-unit-tests`	Marque de réservation pour un script personnalisé de test défini par l'utilisateur qui permet à celui-ci d'exécuter ses propres tests.
`code-pr-finish`	Exécution de toutes les vérifications de conformité requises, ajout de commentaires concernant les résultats à la demande d'extraction et définition des résultats sur les référentiels Git Repos and Issue Tracking.

Utilisation des changements PR/MR pour le repo de configuration du pipeline

Si la ligne PR doit prendre en compte les modifications des fichiers/scripts de configuration provenant de la PR/MR, alors le repo et la branche de configuration doivent être vides, ce qui peut être défini comme suit :

Les variables env one-pipeline-repo, one-pipeline-config-repo et pipeline-config-repo sont vides ou ne sont pas spécifiées dans les variables env
Les variables env one-pipeline-config-branch et pipeline-config-branch sont vides ou ne sont pas spécifiées dans les variables env.

Fusion de demandes d'extraction présentant des problèmes

Vous pouvez utiliser les droits d'administrateur pour fusionner les demandes d'extraction ayant des vérifications de statut en échec dans le référentiel. Toutefois, ces demandes d'extraction enregistrent un résultat failure dans leur preuve pour la tâche ayant échoué. Ce résultat est inclus dans le récapitulatif de preuves et la description de la demande de changement, et affecte le score final de conformité sur le Security and Compliance Center.

Permettre la collecte d'éléments de preuve dans le cadre du processus de relations publiques

Le pipeline de relations publiques permet de collecter des preuves et de gérer les problèmes. Par défaut, le pipeline de relations publiques ne recueille pas de preuves et n'ouvre pas de dossiers, mais les utilisateurs peuvent opter pour cette fonction. Afin de permettre la collecte de preuves et la gestion des problèmes, définissez la variable d'environnement collect-evidence-in-pr comme l'une des énumérations suivantes :

none: (par défaut) Définir collect-evidence-in-pr à none, pour empêcher la collecte de preuves dans le pipeline de la PR.
all: Définissez collect-evidence-in-pr à all pour collecter toutes les preuves, quel que soit le statut de la filière PR. Les questions seront ouvertes, mises à jour ou fermées selon le script collect-evidence.
success: Définissez collect-evidence-in-pr à success pour ne collecter des preuves que si l'ensemble du pipeline de relations publiques s'est déroulé avec succès. En cas d'échec de la chaîne de relations publiques, les preuves ne seront pas collectées ni publiées dans le casier à preuves et la gestion des problèmes n'aura pas lieu.

Remarque : étant donné que les PR pipelines sont généralement exécutés assez fréquemment, le choix du mode correct de collect-evidence-in-pr permet d'éviter la collecte de preuves inutiles. Il est conseillé de sélectionner le mode success pendant la phase de développement ou dans les cas où des défaillances sont anticipées, afin d'empêcher la collecte de preuves en cas de défaillance de la canalisation.

Si le pipeline PR déclenche un pipeline Async, le mode collect-evidence-in-pr réglé sur success n'est pas pris en charge. Si le pipeline PR déclenche un pipeline asynchrone, définissez collect-evidence-in-pr à all afin de collecter des preuves.

Note : Si le dépôt de l'application est un dépôt GitLab et que le MR (merge request) en cours de contribution provient d'un dépôt forké, l'utilisateur devra fournir une valeur pour la variable env git-token qui a accès à la fois au dépôt source et au dépôt cible afin de définir les statuts appropriés sur la demande de fusion. Cela signifie que le jeton git doit appartenir à un utilisateur qui est un contributeur à la fois dans le dépôt de base et dans le dépôt forké et que le jeton a les permissions de définir le statut d'un commit.

L'émergence de la CVE dans les relations publiques

Lorsqu'un PR est créé et que des vulnérabilités sont trouvées par le pipeline PR, ce dernier ajoute les informations relatives à la vulnérabilité telles que la gravité, l'identifiant cve, le paquet avec sa description et le correctif s'il est disponible sous la forme d'un commentaire. Cela permet aux utilisateurs de vérifier rapidement les vulnérabilités à corriger dans le PR au lieu d'avoir à parcourir les journaux du pipeline.

Une option opt-in-pr-updates permet d'activer ou de désactiver cette fonctionnalité dans le pipeline des relations publiques. Cette fonction est activée par défaut.

Mise en place d'un pipeline de RP pour gérer les RP de la Merge Queue de Github

Une Merge Queue est une fonctionnalité de Github qui permet d'augmenter la vélocité en automatisant les fusions de demandes de pull dans une branche occupée et en s'assurant que la branche n'est jamais cassée par des changements incompatibles. Pour en savoir plus sur la mise en place et l'utilisation de Github Merge Queue , cliquez ici.

Créer un nouveau déclencheur Git

Créez un nouveau déclencheur Git ou dupliquez un déclencheur existant. Conserver tous les paramètres par défaut, remplacer uniquement les propriétés suivantes :

Name le nom du déclencheur doit refléter le contexte de la file d'attente de fusion (Merge Queue): PR - Merge Queue
EventListener: sélectionner pr-listener-merge-queue
Trigger on: sélectionner CEL filter
- CEL filter: entrer body.action == 'checks_requested'

Les PR de la file d'attente de fusion utilisent des branches éphémères - créées "à la volée" lorsque le PR original est ajouté à la file d'attente de fusion - à partir desquelles le PR de la file d'attente de fusion est créé. Par conséquent, la charge utile de l'événement Git correspondant (qui déclenche le pipeline Pull Request) ne contient aucune information sur PR URL ou HTML URL.

Non pertinentes dans le contexte de la file d'attente de fusion, les fonctionnalités suivantes de DevSecOps doivent être désactivées en ajoutant les propriétés de texte correspondantes :

skip-merge-pr-to-base: doit être fixé à true (par défaut : false)
opt-in-pr-updates: doit être fixé à 0 (valeur par défaut : 1)

Sauvegarder le déclencheur.

Test du déclencheur de la file d'attente de fusion

Créer une nouvelle Pull Request sur la branche principale du dépôt de code source de l'application.
Observez : le pipeline "standard" DevSecOps PR est déclenché
Toujours sur la page PR, cliquez sur Merge when ready, puis sur Attempt merge when ready- cela permettra à enqueue de placer le PR dans la file d'attente de fusion une fois que le PR "standard" sera terminé.
Attendez que la procédure "standard" DevSecOps PR se termine avec succès
Observer : une fois le pipeline de RP terminé, le RP est ajouté à la file d'attente de fusion et le RP de la file d'attente de fusion est déclenché :
- Attendre que la PR de la file d'attente de fusion se termine
- En cas de succès, le PR est fusionné avec un commentaire du type Merged via the queue into main with commit abcdefg
- En cas d'échec (ex : échec du contrôle de conformité), le PR ne sera pas fusionné automatiquement et sera supprimé de la file d'attente de fusion.

Vue d'ensemble de la charge utile de la RP

Contenu

Une charge utile est un terme générique utilisé pour décrire un bloc structuré de données, généralement au format JSON, qui est transmis dans le cadre d'un événement ou d'une demande. Les charges utiles sont couramment utilisées dans les webhooks, les API et les systèmes d'automatisation pour transmettre des informations pertinentes sous une forme lisible par la machine.

Les données utiles peuvent représenter un large éventail de contenus en fonction du contexte - par exemple, des métadonnées de construction, l'activité des utilisateurs, des mises à jour de problèmes ou, dans le cas présent, des détails sur les demandes d'extraction.

Charge utile PR

cd-devsecops-pr-payload

Le PR Payload est une instance spécifique d'un payload qui encapsule des métadonnées et des informations contextuelles sur une pull request (PR). Il est généré lorsqu'un événement de demande d'extraction se produit et fournit un accès structuré aux attributs clés liés à cette demande d'extraction.

Cette charge utile comprend un large éventail de données telles que

Titre et description des RP
Auteur et évaluateurs
Branches source (tête) et cible (base)
Historique des engagements et références du CSA
Détails du référentiel
Horodatage, étiquettes, statuts, etc

Bien que la charge utile complète contienne de nombreuses informations, seul un sous-ensemble spécifique de champs est actuellement extrait et exposé en tant que variables d'environnement à utiliser dans les pipelines, les scripts et les fichiers de configuration.

Propriétés de l'environnement extraites de la charge utile de la RP

Les variables d'environnement suivantes sont actuellement dérivées de la charge utile du PR et activement utilisées :

Nom de la variable	Description
`head-branch`	La branche source du PR (branche à partir de laquelle le PR est fusionné)
`head-sha`	Le commit SHA du dernier commit sur la branche head
`head-repo`	Le référentiel d'où provient la RP
`base-branch`	La branche cible du PR (branche dans laquelle le PR est fusionné)
`base-repo`	La référence complète au référentiel de base
`base-repo-name`	Le nom du référentiel de base
`base-repo-owner`	Le propriétaire (utilisateur ou organisation) du référentiel de base
`commit-timestamp`	L'horodatage du commit le plus récent dans le PR
`pr-url`	L'API URL de la demande d'extraction
`pr-html-url`	Le site web (HTML) URL de la demande d'extraction
`pr-title`	Le titre de la demande d'extraction
`action`	statut de la RP
`base_ref`	branche cible de la RP

Ces valeurs sont injectées en tant que variables d'environnement afin de simplifier l'accès lors de l'exécution de flux de travail automatisés.

La charge utile de la RP comprend de nombreux champs supplémentaires en plus de ceux énumérés ci-dessus. Toutefois, seul le sous-ensemble extrait est actuellement exploité à des fins opérationnelles. Si nécessaire, l'accès à la charge utile complète peut être fourni pour des cas d'utilisation avancés ou une expansion future.