Gestion des problèmes d'incident
Du point de vue de la conformité, la création, le stockage et la mise à jour des problèmes d'incident (vulnérabilité, CVE) dans le cadre des pipelines Intégration continue et Conformité continue sont essentiels pour la collecte d'informations collectées.
Pendant l'exécution du pipeline PR avec la collecte de preuves activée, des pipelines CI et CC, le collect-evidence script crée des problèmes d'incident, les
attache aux preuves collectées et les stocke dans le référentiel des problèmes d'incident.
Le script collect-evidence utilise les fonctions de la commande Cocoa incident process, qui traite les résultats d'analyse fournis et crée de nouveaux
problèmes d'incident dans le référentiel fourni par vulnérabilité ou met à jour les problèmes d'incident existants en fonction des paires d'incidents-sujet. Par conséquent, les problèmes d'incident sont liés aux actifs et créés en fonction des
résultats d'outils spécifiques. Pour plus d'informations, voir Différence entre le traitement des problèmes dans les pipelines d'EC et de CC.
Traitement des incidents dans le pipeline des relations publiques
Le pipeline PR avec la collecte de preuves activée peut créer des problèmes d'incident lorsqu'une vulnérabilité ou un CVE est rencontré. Pour activer la collecte d'éléments de preuve dans le pipeline PR, voir:Collecte d'éléments de preuve dans le pipeline PR
La gestion des incidents dans le pipeline PR est similaire à celle du pipeline CI. La seule différence réside dans la logique d'autoclavage.
Un incident créé par un pipeline de relations publiques ne peut être éliminé que par un pipeline de relations publiques fonctionnant sur le même PR. Le problème ne peut pas être résolu par un pipeline de relations publiques quand :
- Le problème est détecté par un pipeline de RP fonctionnant sur n'importe quel autre RP.
- Le problème est détecté par n'importe quel pipeline CI ou CC.
Traitement des incidents
Même si les pipelines d'EC et de CC comportent des étapes communes, le traitement des problèmes de ces pipelines présente certaines différences:
- Les problèmes d'incident créés au cours du pipeline d'EC ne comportent pas de date d'échéance, contrairement aux problèmes d'incident créés au cours du pipeline CC.
- Les problèmes d'incident créés au cours du pipeline d'EC sont détectés au cours de la génération, tandis que les problèmes d'incident créés au cours du pipeline CC sont détectés dans l'environnement de production.
Les figures 1 à 6 montrent les cas d'utilisation possibles qui sont basés sur ces différences.
Cycle de vie des problèmes
Le cycle de vie des problèmes s'étend des demandes de données de code aux analyses de production.
Cas d'utilisation 1: vulnérabilité détectée dans la génération
La nouvelle génération introduit une vulnérabilité, qui n'est pas acceptée. Le déploiement est bloqué sauf si la demande de changement est une ressource personnalisée d'urgence qui est approuvée manuellement.
![Vulnérabilité trouvée dans la version "](images/vuln-uc-1.svg "Vulnérabilité trouvée dans la version "")
Le flux du pipeline de construction en cas de découverte d'une vulnérabilité et les actions correspondantes de l'utilisateur sont expliqués dans le diagramme suivant.
Cas d'utilisation 2: vulnérabilité détectée dans la génération qui est également en production
La nouvelle génération contient une vulnérabilité qui se trouve également dans la production actuellement déployée. Les équipes disposent d'une chronologie pour résoudre le problème, mais de nouvelles fonctions ou de nouveaux correctifs peuvent encore être déployés.
Le pipeline CC définit le calendrier pour corriger les vulnérabilités détectées en production. Elle n'échouera que lorsque la chronologie de correction de la vulnérabilité aura expiré. Le flux est décrit dans le diagramme suivant.
Le cas d'utilisation 2A: une vulnérabilité détectée en production autorise les demandes de service
La vulnérabilité en production n'empêche pas la fusion des DA.
Cas d'utilisation n° 3 : faux positifs et exemptions
Si l'équipe classe un problème comme « faux positif » ou reçoit une exception de sécurité concernant une vulnérabilité, le problème peut être marqué comme « Exempté ». Le problème peut ensuite être traité comme un problème non bloquant. Pour conserver une trace d'audit, les demandes de changement conservent les problèmes visibles.
Cas d'utilisation 4: fermeture automatique des problèmes corrigés
L'exécution périodique du pipeline CC peut fermer les problèmes qui sont ouverts et dont la date d'échéance est définie. De plus, la vulnérabilité appropriée est introuvable dans les examens.
Le diagramme suivant explique le diagramme du pipeline CC qui détecte les problèmes à fermer et les problèmes à créer.
Gestion des dates d'échéance pour les problèmes liés aux incidents
Lorsque des problèmes liés à un incident sont détectés en production, la propriété « Due Date » est automatiquement ajoutée afin de préciser le délai de grâce dont dispose l'équipe pour résoudre le problème. La durée du délai de
grâce est déterminée par la gravité de la vulnérabilité détectée.
Cas de figure courants concernant les dates d'échéance
Les scénarios suivants décrivent comment sont gérées les dates d'échéance :
- Attribution initiale de la date d'échéance: lorsque le pipeline CC détecte un problème en production, il calcule et définit automatiquement une date d'échéance en fonction de la gravité du problème.
- Prolongation du délai: si vous avez besoin de plus de temps pour résoudre un problème, vous pouvez prolonger le délai après avoir obtenu l'accord d'un responsable de la sécurité. Pour plus de détails, consultez la rubrique « Report de la date d'échéance ».
- Problèmes en retard: même lorsque des problèmes sont en retard, les pipelines CI peuvent continuer à procéder aux déploiements tant que la nouvelle version n'aggrave pas la situation de l'environnement de production (approche purement axée sur la gestion des risques). Cela permet aux équipes de continuer à déployer des fonctionnalités tout en s'attachant à résoudre les problèmes de sécurité.
Pour plus d'informations sur la personnalisation des délais de grâce, voir Configuration de délais de grâce personnalisés sur le pipeline CC.
Etiquetage des problèmes d'incident
Les problèmes d'incident créés par les pipelines d'intégration continue (EC) ou de conformité continue (CC) peuvent avoir des libellés par défaut.
Libellés des problèmes d'incident détectés par Code Risk Analyzer
Code Risk Analyzer (CRA) détecte plusieurs types de vulnérabilités, comme la dépendance d'application et la vulnérabilité d'image.
Le type de vulnérabilité peut être name os, python, js, golang ou java.
Si le type de vulnérabilité est de type os, un libellé os-vulnerability est associé au problème. Pour tout autre type de vulnérabilité, un libellé app-vulnerability est associé au problème.
Libellés des problèmes d'incident avec les correctifs disponibles
Pour les problèmes d'incident créés par le pipeline d'intégration continue (CI) ou le pipeline de conformité continue (CC), le scanner peut avoir des informations de résolution dans le résultat de l'analyse. Si des informations de résolution
sont disponibles, un libellé fix-available est ajouté au problème d'incident avec un lien vers la description du correctif dans la description du problème.
L'absence du libellé fix-available ne signifie pas que le problème ne peut pas être résolu car tous les scanners n'incluent pas les informations de correction dans le résultat de l'analyse. Le scanner suggère les informations
de correction, et ces informations proviennent de l'endroit où le scanner fournit ces données de "correction". Certains scanners peuvent ne pas disposer de dictionnaires de "correctifs" à jour ou ne pas contenir d'informations
pour un correctif.
Problèmes d'incident avec la date d'échéance
Lorsque vous utilisez le script collect-preuve, des problèmes d'incident sont créés et associés aux informations collectées collectées. Si des problèmes sont détectés en production, ils peuvent avoir une période de temps spécifiée au cours de laquelle ils doivent être corrigés afin que les déploiements ne soient pas bloqués. Le délai imparti pour résoudre le problème en production est appelé délai de grâce. Toutefois, pour une meilleure lisibilité, Date d'échéance est désormais disponible dans les problèmes d'incident afin que les utilisateurs connaissent la date d'échéance du correctif sans le calculer à partir du délai de grâce.
Si un problème tel qu'une vulnérabilité ou une CVE est détecté en production et que le même problème est également détecté dans une génération, la génération n'aggrave pas la situation. La fonction peut être déployée et l'équipe peut se concentrer sur la résolution du problème en production.
Configuration de périodes de grâce personnalisées sur le pipeline CC
Le pipeline Continuous Compliance (CC) calcule les dates d'échéance des problèmes d'incident en fonction de la gravité d'un problème. Vous pouvez modifier les valeurs de délai de grâce par défaut et les remplacer par des valeurs personnalisées.
Le pipeline calcule le délai de grâce en fonction du tableau suivant:
| Gravité | Délai de grâce |
|---|---|
| Information | 180 jours |
| Faible | 180 jours |
| Moyen | 90 jours |
| Elevé | 30 jours |
| Critique | 30 jours |
Pour modifier la configuration par défaut, créez une nouvelle propriété dans les propriétés d'environnement du pipeline CC nommée grace-period-configuration. Cette propriété d'environnement doit être une chaîne JSON et correspondre
au format suivant:
{
"informational": 50,
"low": 40,
"medium": 30,
"high": 20,
"critical": 10
}
Si la propriété d'environnement ne correspond pas au format attendu ou n'est pas une chaîne JSON valide, le pipeline utilise les valeurs par défaut.
La propriété d'environnement grace-period-configuration définit des dates d'échéance pour les problèmes pour lesquels aucune date d'échéance n'est déjà définie. Pour les problèmes pour lesquels une date d'échéance est définie, la
reconfiguration de grace-period-configuration ne met pas à jour ces dates d'échéance.
Calcul de la date d'échéance
La date de la constatation est le moment où le pipeline de conformité continue (CC) s'exécute et trouve le problème dans l'environnement de production. Si le problème existe, CC le met à jour avec la Date d'échéance calculée à partir de ce moment.
<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>
Format de date d'échéance
La date d'échéance est au format ISO 8601 et s'affiche sous la forme AAAA-MM-JJ.
Exemple:Due Date: 2022-04-01
Cas d'utilisation
-
Une vulnérabilité est détectée dans l'une des images de base en production par le pipeline CC. L'équipe est informée d'un problème d'incident avec un délai de grâce défini en fonction de la gravité de la vulnérabilité. Le délai de grâce correspond au nombre de jours dont dispose l'équipe pour déployer un correctif.
-
L'équipe génère une nouvelle édition avec une nouvelle fonction. La génération trouve une CVE associée à l'image de base utilisée pour l'application. L'équipe exécute le pipeline CC manuellement, qui analyse les artefacts déjà en production. L'exécution CC manuelle détecte le même CVE dans la même application en production et ajoute le délai de grâce au problème d'incident. L'équipe peut désormais générer et déployer sans être bloquée.
Différences entre le traitement des problèmes dans les pipelines d'EC et de CC
Les problèmes d'incident sont créés dans les pipelines d'EC et de CC:
- Un problème créé dans EC signifie qu'il a été détecté lors de la génération.
- Un problème créé dans CC signifie qu'il a été détecté dans l'environnement de production.
Une date d'échéance peut être ajoutée automatiquement aux problèmes uniquement s'ils sont liés à des problèmes détectés dans l'environnement de production. Cela signifie que seul le pipeline CC est autorisé à ajouter la date d'échéance à un problème. Si l'EC trouve le problème et que la date d'échéance n'est pas disponible, la valeur de la date d'échéance est n / a.
Traitement des résultats en problèmes
Les problèmes détectés sont créés en fonction des résultats d'outils spécifiques. Le script collect-evidence tente de traiter les fichiers de résultats dans les pièces jointes et de créer une liste de problèmes.
Les problèmes sont liés aux actifs, qui peuvent être des validations dans un référentiel ou une image Docker avec un prétraitement.
Un problème est créé pour chaque ID de problème-un ID de problème est composé des composants suivants:
- Actif lié
- L'outil qui a trouvé la vulnérabilité
- L'identificateur de vulnérabilité (l'ID CVE, par exemple)
Par exemple, si CVE-2022-001 est trouvé par deux outils distincts, le processus crée deux problèmes aujourd'hui.
Outils pris en charge
Le traitement des incidents prend en charge les résultats provenant de divers outils d'analyse intégrés aux pipelines d' DevSecOps. Pour consulter la liste actualisée des outils de numérisation pris en charge et de leurs fonctionnalités, reportez-vous à la section « Outils de numérisation pris en charge ».
Outils ou formats de résultat non pris en charge
Si le script collect-evidence reçoit une pièce jointe d'un outil non pris en charge ou si le format du fichier de résultats n'est pas reconnu lors du traitement, le script ignore la création des problèmes et utilise le fichier
de résultats en tant que pièce jointe simple aux informations collectées.
Contenu de l'anomalie
- Problème est le nom du problème ou de la vulnérabilité.
- Date d'échéance indique la date d'échéance du correctif ou n / a si aucune date d'échéance n'est disponible.
- Subject est l'actif auquel le problème est lié.
- URL est le lien vers la version exacte de l'actif.
- Type d'outil est l'outil qui a généré le contenu du problème
Pour les questions créées sur Git Repos and Issue Tracking, la date d'échéance est définie dans le champ GitLab native due date au lieu de la description de la question.
La description du problème contient l'horodatage de la première découverte du problème. Par exemple, First found on 2022-04-07. La date est au format YYYY-MM-DD. Les emplacements où le problème se produit sont répertoriés
dans les commentaires du problème.
Report de la date d'échéance d'un ticket d'incident
Vous pouvez repousser la date d'échéance d'un incident lorsque vous avez besoin de plus de temps pour mettre en œuvre une solution. Cela nécessite l'accord d'un responsable de la sécurité afin de garantir un suivi adéquat des failles de sécurité.
Procédure de report des dates d'échéance
- Demandez à votre référent sécurité de rédiger un avis expliquant pourquoi cette prolongation est nécessaire.
- Une fois l'autorisation obtenue, mettez à jour la date d'échéance :
- Pour les « Git Repos and Issue Tracking s » : modifiez le champ «
Due date» dans les métadonnées de l'incident. - Pour les « GitHub Enterprise s » : modifiez le champ «
Due date» dans la description du ticket.
- Pour les « Git Repos and Issue Tracking s » : modifiez le champ «
- Mentionnez l'accord du responsable de la sécurité concernant ce dossier en ajoutant un commentaire contenant un lien vers le document de révision ou d'approbation.
Veillez à faire référence à la revue de contact de sécurité dans le problème, par exemple en fournissant un lien vers celle-ci dans un commentaire.
Exceptions de sécurité
Si vous rencontrez un problème lié à une exception de sécurité, vous pouvez prolonger la date d'échéance afin de l'aligner sur la date d'expiration de l'exception. Cela garantit que la collecte des preuves et le suivi de la conformité se poursuivent de manière appropriée jusqu'à l'expiration de l'exception.
Alertes Slack pour les problèmes en attente et en retard pour le pipeline CC
Le pipeline Continuous Compliance (CC) peut définir des dates d'échéance pour les problèmes d'incident. Le pipeline peut également informer les utilisateurs des problèmes dont les dates d'échéance approchent et des dates d'échéance en retard à l'aide de Slack, si l'intégration de Slack est activée.
Pour plus d'informations, voir Configuration d'une chaîne d'outils d'intégration continue(CI). Pour plus d'informations sur les dates d'échéance, voir [Incident issues with due date](/docs/devsecops? topic = devsecops-incident-issues#devsecops-devsecops-issues-due-date.
Les problèmes notifiés sont classés comme suit:
- Problèmes ayant des dates d'échéance en attente dans un délai spécifique: problèmes qui sont ouverts, ont des dates d'échéance et sont dus dans un délai.
- Problèmes ayant des dates d'échéance passées: les problèmes sont ouverts, ont des dates d'échéance et la date est passée.
Les durées de délai sont overdue, due in 1 day, due in 2 days, due in 5 days et due in 10 days.
Voici un exemple de cette fonction:
Overdue issues:
- <issue url#1>
- <issue url#2>
- <issue url#3>
Issues due in 1 day:
- <issue url#4>
Issues due in 2 days:
- <issue url#5>
Issues due in 5 days:
- <issue url#6>
- <issue url#7>
Issues due in 10 days
- <issue url#8>
- <issue url#9>
- <issue url#10>
- <issue url#11>
- <issue url#12>
La liste agrégée est ordonnée en fonction des problèmes qui sont en retard en premier, et les problèmes dont les dates d'échéance sont les plus proches sont répertoriés avant ceux dont la date d'échéance est ultérieure.
L'étape cc-finish du pipeline CC recherche les problèmes en fonction des critères et déclenche une alerte Slack.