Bonnes pratiques pour les chaînes d'outils DevSecOps

Les sections suivantes décrivent les bonnes pratiques pour chaque chaîne d'outils DevSecOps: intégration continue (CI), CI pour l'infrastructure en tant que code ( IaC ), déploiement continu (CD) et conformité continue (CC).

Bonnes pratiques pour la chaîne d'outils d'intégration continue (CI)

La chaîne d'outils CI DevSecOps respecte les pratiques suivantes :

S'exécute detect-secrets sur les référentiels d'applications afin d'empêcher les fuites de secrets dans le code source des applications.
Exécute des tests unitaires et des tests d'application sur le code de l'application.
Exécute des analyseurs de code statiques sur les référentiels d'applications afin d'identifier les failles de sécurité dans le code source.
Effectue des contrôles de conformité à l'aide d'outils tels que Code Risk Analyzer sur tous les référentiels d'applications, y compris l'analyse des vulnérabilités et la vérification de la nomenclature (BOM) de toutes les dépendances des paquets.
Collecte les données de conformité issues des révisions par les pairs pour toutes les demandes de fusion (pull requests) fusionnées depuis la dernière version.
Crée une image de conteneur à chaque commit Git, en attribuant une balise basée sur le numéro de build, l'horodatage et l'ID du commit à des fins de traçabilité.
Signe l'image de conteneur générée.
Analyse l'image du conteneur à la recherche de failles de sécurité.
Déploie l'artefact compilé dans un environnement de développement et effectue une analyse dynamique (analyses via l'API ZAP et l'interface utilisateur) de l'application en cours d'exécution afin de détecter les vulnérabilités d'exécution.
Exécute des tests d'acceptation et d'intégration sur l'artefact déployé dans l'environnement de développement.
Rassemble toutes les données justificatives (résultats d'analyse, résultats de test, journaux, données d'examen par les pairs et données d'exécution du pipeline) dans un espace de stockage dédié à la fin de chaque exécution du pipeline.

Bonnes pratiques en matière d'intégration continue (CI) pour la chaîne d'outils Infrastructure as Code ( IaC )

La chaîne d'outils DevSecOps CI pour l' IaC respecte les pratiques suivantes :

S'exécute sur detect-secrets les référentiels IaC pour empêcher les fuites de secrets dans la configuration Terraform.
Exécute des tests unitaires sur la configuration IaC à chaque commit Git.
Effectue une analyse statique du code sur les référentiels IaC, notamment à l'aide d'outils spécifiques à Terraform tels que pour tflint la vérification syntaxique et l'application des bonnes pratiques, ainsi que terraform fmt et terraform validate pour assurer la cohérence de la mise en forme et la validité de la configuration.
Effectue des contrôles de conformité sur les référentiels IaC s à l'aide d'outils IaC-specific s (tels que Code Risk Analyzer ou checkov) afin de détecter les problèmes de conformité.
Crée un fichier Tar contenant la configuration Terraform à chaque validation Git.
Signe l'artefact Tar généré.
Déploie la configuration IaC vers un environnement de développement à l'aide d' IBM Cloud Schematics ou de l'interface de ligne de commande Terraform.
Exécute des tests d'acceptation et d'intégration sur la configuration déployée dans l'environnement de développement.
Ajoute les artefacts créés au référentiel d'inventaire à des fins de traçabilité et de déploiement vers les environnements en aval.
Rassemble toutes les preuves (résultats d'analyse, résultats de test, données de signature, journaux et données d'exécution du pipeline) dans un coffre-fort de preuves à la fin de chaque exécution du pipeline.

Bonnes pratiques relatives à la chaîne d'outils de déploiement continu (CD) pour déployer une application sécurisée

Pour déployer une application sécurisée, la chaîne d'outils CD DevSecOps suit les pratiques suivantes :

Utilise une demande de promotion (pull request) sur le référentiel d'inventaire pour définir la portée du déploiement et calculer le delta de déploiement, c'est-à-dire l'ensemble des artefacts qui ont changé depuis le dernier déploiement achevé.
Vérifie que toutes les demandes de fusion (pull requests) relevant du périmètre de déploiement actuel ont fait l'objet d'une révision par les pairs et ont été approuvées avant de poursuivre. Le déploiement est interrompu si une pull request n'est pas approuvée.
Vérifie que chaque élément dont le déploiement est prévu est correctement signé. Bloque le déploiement si une signature valide fait défaut.
Calcule la nomenclature (BOM) du déploiement à partir du delta de déploiement et rassemble un résumé des justificatifs provenant à la fois de l'exécution du pipeline CI associé et de l'exécution actuelle du pipeline CD.
Crée une demande de modification dans le système de gestion des changements configuré et y joint la nomenclature de déploiement, le résumé des justificatifs et les données de conformité issues de la révision par les pairs.
La demande de modification est automatiquement approuvée si tous les critères de conformité sont remplis. Prend en charge la validation manuelle ou le marquage d'urgence lorsque les critères ne sont pas entièrement remplis.
Déploie les artefacts depuis l'inventaire vers l'environnement cible (tel que l'environnement de préproduction ou de production) une fois que la demande de modification a été approuvée ou marquée comme urgente.
Exécute des tests d'acceptation et d'intégration après le déploiement afin de vérifier que celui-ci s'est déroulé avec succès et que l'application fonctionne comme prévu.
Annule automatiquement le déploiement au cours de la même exécution du pipeline si une erreur survient pendant la phase de déploiement ou de test d'acceptation, en conservant le dernier état connu comme étant correct dans l'inventaire.
Clôture la demande de modification avec un close_category de ou Successful Successful with issues, et déplace la balise d'inventaire <target-environment>_latest vers le commit déployé.
Récupère et télécharge tous les fichiers journaux, artefacts et éléments de preuve vers le coffre-fort de preuves à la fin de chaque exécution du pipeline.
Il est possible d'ajouter le label aux pull requests fusionnées après deploy:{region}:{env} un déploiement réussi, afin d'assurer la traçabilité du déploiement de bout en bout sans nécessiter d'accès aux détails du pipeline.

Bonnes pratiques pour la chaîne d'outils de conformité continue (CC)

La chaîne d'outils CC DevSecOps respecte les pratiques suivantes :

S'exécute detect-secrets sur tous les référentiels de code source de l'inventaire afin d'identifier les fuites de secrets dans le code source de l'application.
Effectue une analyse statique du code ( SonarQube ou implémentation personnalisée) sur tous les dépôts de code source répertoriés dans l'inventaire.
Effectue un scan dynamique de sécurité des applications (OWASP ZAP) sur l'application déployée afin de détecter les vulnérabilités d'exécution.
Effectue des contrôles de conformité à l'aide d'outils (tels que Code Risk Analyzer) sur tous les dépôts source de l'inventaire, notamment l'analyse des vulnérabilités, les contrôles CIS sur les manifestes de déploiement Kubernetes, les contrôles BOM sur toutes les dépendances des paquets et la vérification de la protection des branches.
Analyse toutes les images de conteneurs déployées à la recherche de failles de sécurité.
Crée ou met à jour des tickets d'incident pour chaque CVE, vulnérabilité ou alerte détectée lors de l'exécution du pipeline et fixe une date d'échéance pour chaque ticket.
Rassemble les preuves relatives à chaque étape dans le référentiel de preuves, joint les résultats de l'analyse et de la vérification aux tickets correspondants, et met à jour le statut de conformité de tous les artefacts analysés.