Gestión de problemas de incidencias
Desde una perspectiva de conformidad, la creación, el almacenamiento y la actualización de problemas de incidencias (vulnerabilidad, CVE) como parte de las interconexiones de Continuous Integration y Continuous Compliance son esenciales para la recopilación de pruebas.
Durante la ejecución del pipeline PR con la recolección de evidencias habilitada, los pipelines CI y CC, el collect-evidence script crea incidencias, las adjunta
a las evidencias recolectadas y las almacena en el repositorio de incidencias.
El script collect-evidence utiliza las funciones del mandato proceso de incidencia de cacao, que procesa los resultados de exploración proporcionados
y crea nuevos problemas de incidencia en el repositorio proporcionado por vulnerabilidad o actualiza los problemas de incidencia existentes basándose en los pares de asunto e incidencia. Por lo tanto, los problemas de incidencia están vinculados
a activos y se crean de acuerdo con los resultados de herramientas específicas. Para obtener más información, consulte Diferencia entre el proceso de problemas en las interconexiones de AC y CC.
Tratamiento de incidencias en la cadena de relaciones públicas
La tubería PR con la recolección de pruebas habilitada puede crear problemas de incidentes cuando se encuentra cualquier vulnerabilidad o CVE. Para activar la recopilación de pruebas en el canal de relaciones públicas, consulte:Recopilación de pruebas en el canal de relaciones públicas
La gestión de incidencias en la cadena de suministro de RP es similar a la de la cadena de suministro de CI. La única diferencia radica en la lógica de autocierre.
Una incidencia creada por una canalización de RP sólo puede ser autocerrada por una canalización de RP que se ejecute en el mismo RP. La cuestión no puede ser autocerrado por una tubería de relaciones públicas cuando:
- El problema es encontrado por un PR pipeline ejecutándose en cualquier otro PR.
- El problema es encontrado por cualquier CI o CC pipelines.
Proceso de problemas de incidencias
Aunque las interconexiones CI y CC tienen pasos comunes, el proceso de problemas de estas interconexiones tiene algunas diferencias:
- Los problemas de incidencias que se crean durante el conducto de AC no tienen una fecha de vencimiento, mientras que los problemas de incidencias que se crean durante el conducto CC sí lo tienen.
- Los problemas de incidencia que se crean durante el conducto de AC se encuentran durante la compilación, mientras que los problemas de incidencia que se crean durante el conducto CC se encuentran en el entorno de producción.
Las figuras 1-6 muestran los posibles casos de uso que se basan en estas diferencias.
Ciclo de vida de problema
El ciclo de vida del problema se extiende desde las PR de código hasta las exploraciones de producción.
Caso de uso 1: vulnerabilidad encontrada en la compilación
La nueva compilación introduce una vulnerabilidad, que no se acepta. El despliegue se bloquea a menos que la solicitud de cambio sea un CR de emergencia que se apruebe manualmente.
Este flujo de construcción en caso de que se encuentre una vulnerabilidad, y las correspondientes acciones del usuario se explican en el siguiente diagrama.
Caso de uso 2: vulnerabilidad encontrada en la compilación que también está en producción
La nueva compilación contiene una vulnerabilidad que también está en la producción desplegada actualmente. Los equipos tienen una línea temporal para solucionar el problema, pero se pueden seguir desplegando nuevas características o arreglos.
La interconexión de CC establece la línea temporal para corregir cualquier vulnerabilidad de este tipo que se encuentre en producción. Sólo fallará cuando la línea temporal para arreglar la vulnerabilidad haya caducado. El flujo se describe en el siguiente diagrama.
El caso de uso 2A: vulnerabilidad que se encuentra en producción permite PR
La vulnerabilidad en la producción no impide que se fusionen los PR.
Caso de uso n.º 3: falsos positivos y excepciones
Si el equipo clasifica un problema como «falso positivo» o recibe una excepción de seguridad por una vulnerabilidad, el problema puede etiquetarse como « Exento ». A continuación, el problema se puede manejar como un problema no de bloqueo. Para mantener un seguimiento de auditoría, las solicitudes de cambio mantienen los problemas visibles.
Caso de uso 4: cierre automático de problemas solucionados
La ejecución periódica de la interconexión CC puede cerrar problemas que están abiertos y tienen una fecha de vencimiento establecida. Además, la vulnerabilidad relevante no se puede encontrar en las exploraciones.
El diagrama siguiente explica el diagrama de flujo del conducto CC que detecta qué problemas se deben cerrar y qué problemas se deben crear nuevos.
Gestión de los plazos de resolución de los incidencias
Cuando se detectan incidencias en el entorno de producción, se añade automáticamente la propiedad « Due Date » para especificar el plazo de gracia en el que debe solucionarse la incidencia. La duración del periodo de gracia viene
determinada por la gravedad de la vulnerabilidad encontrada.
Situaciones habituales relacionadas con la fecha de vencimiento
Los siguientes casos describen cómo se gestionan las fechas de vencimiento:
- Asignación inicial de la fecha límite: cuando el canal de CC detecta un problema en producción, calcula y establece automáticamente una fecha límite en función de la gravedad del problema.
- Ampliación del plazo: Si necesitas más tiempo para solucionar un problema, puedes ampliar el plazo tras obtener la autorización de un responsable de seguridad. Consulta « Aplazamiento de la fecha de vencimiento » para obtener más detalles.
- Problemas pendientes: Aunque haya problemas pendientes, los procesos de CI pueden seguir adelante con las implementaciones siempre y cuando la nueva compilación no empeore el entorno de producción (enfoque basado exclusivamente en la gestión de riesgos). Esto permite a los equipos seguir incorporando nuevas funcionalidades mientras trabajan para resolver los problemas de seguridad.
Para obtener más información sobre cómo personalizar los periodos de gracia, consulte Configuración de periodos de gracia personalizados en la interconexión CC.
Etiquetado de problemas de incidencia
Los problemas de incidencia creados por las interconexiones de integración continua (AC) o conformidad continua (CC) pueden tener etiquetas predeterminadas.
Etiquetas para problemas de incidencias descubiertos por Code Risk Analyzer
Code Risk Analyzer (CRA) detecta varios tipos de vulnerabilidades, como dependencia de aplicación y vulnerabilidad de imagen.
El tipo de vulnerabilidad puede ser el siguiente: name os, python, js, golang o java.
Si el tipo de vulnerabilidad es de tipo os, se adjunta una etiqueta os-vulnerability al problema. Para cualquier otro tipo de vulnerabilidad, se adjunta una etiqueta app-vulnerability al problema.
Etiquetas para problemas de incidencias con arreglos disponibles
Para los problemas de incidencia creados por la interconexión de integración continua (CI) o la interconexión de conformidad continua (CC), el explorador puede tener información de corrección como parte del resultado de la exploración. Si
la información de corrección está disponible, se añade una etiqueta fix-available al problema de incidencia con un enlace a la descripción del arreglo dentro de la descripción del problema.
La ausencia de la etiqueta fix-available no significa que no se pueda actuar sobre el problema porque no todos los escáneres incluyen la información de arreglo en el resultado del escaneo. El explorador sugiere la información
de arreglo, y dicha información procede de cualquier lugar donde el explorador obtiene estos datos de "arreglo". Es posible que algunos exploradores no tengan diccionarios de "arreglo" actualizados o que no contengan
información para un arreglo.
Problemas de incidencia con fecha de vencimiento
Cuando se utiliza el script collect-evidence, los problemas de incidencia se crean y se adjuntan a las pruebas recopiladas. Si se encuentran problemas en producción, pueden tener un periodo de tiempo especificado en el que deben arreglarse para que los despliegues no se bloqueen. El intervalo de tiempo que se proporciona para solucionar el problema en producción se denomina periodo de gracia. Sin embargo, para una mejor legibilidad, Fecha de vencimiento ahora está disponible en los problemas de incidencia para que los usuarios sepan la fecha en la que vence el arreglo sin calcularlo a partir del periodo de gracia.
Si se encuentra un problema como vulnerabilidad o CVE en producción, y también se encuentra el mismo problema en una compilación, la compilación no empeora la situación. La característica se puede desplegar y el equipo puede centrarse en solucionar el problema en producción.
Configuración de periodos de gracia personalizados en la interconexión CC
La interconexión de conformidad continua (CC) calcula las fechas de vencimiento de los problemas de incidencia basándose en la gravedad de un problema. Puede cambiar los valores predeterminados del periodo de gracia y sustituirlos por valores personalizados.
La interconexión calcula el periodo de gracia de acuerdo con la tabla siguiente:
| Gravedad | Periodo de gracia |
|---|---|
| Informativo | 180 días |
| Bajo | 180 días |
| Medio | 90 días |
| Alto | 30 días |
| Crítico | 30 días |
Para cambiar la configuración predeterminada, cree una nueva propiedad en las propiedades de entorno de la interconexión CC denominada grace-period-configuration. Esta propiedad de entorno debe ser una serie JSON y coincidir con
el formato siguiente:
{
"informational": 50,
"low": 40,
"medium": 30,
"high": 20,
"critical": 10
}
Si la propiedad de entorno no coincide con el formato esperado o no es una serie JSON válida, la interconexión utiliza los valores predeterminados.
La propiedad de entorno grace-period-configuration establece las fechas de vencimiento para los problemas que no tienen ya una fecha de vencimiento establecida. Para los problemas que tienen una fecha de vencimiento establecida,
la reconfiguración de grace-period-configuration no actualiza esas fechas de vencimiento.
Cálculo de fecha de vencimiento
La fecha de hallazgo es cuando se ejecuta el conducto de conformidad continua (CC) y encuentra el problema en el entorno de producción. Si el problema existe, CC lo actualiza con la Fecha de vencimiento que se calcula a partir de ese momento.
<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>
Formato de fecha de vencimiento
La fecha de vencimiento está en formato ISO 8601 y se muestra como AAAA-MM-DD.
Ejemplo:Due Date: 2022-04-01
Casos de uso
-
Se ha encontrado una vulnerabilidad en una de las imágenes base en producción por el conducto CC. Se notifica al equipo de un problema de incidencia con un periodo de gracia establecido de acuerdo con la gravedad de la vulnerabilidad. El periodo de gracia es el número de días que el equipo tiene que desplegar un arreglo.
-
El equipo crea un nuevo release con una nueva característica. La compilación busca una CVE asociada con la imagen base que se utiliza para la aplicación. El equipo ejecuta manualmente el conducto CC, que explora los artefactos que ya están en producción. La ejecución CC manual detecta la misma CVE en la misma aplicación en producción y añade el periodo de gracia al problema de incidencia. El equipo ahora puede crear y desplegar sin estar bloqueado.
Diferencias entre el proceso de problemas en conductos de AC y CC
Los problemas de incidencia se crean en conductos de AC y CC:
- Un problema que se crea en CI significa que se ha encontrado durante la compilación.
- Un problema que se crea en CC significa que se ha encontrado en el entorno de producción.
Una fecha de vencimiento se puede añadir automáticamente a los problemas sólo si están relacionados con problemas encontrados en el entorno de producción. Esto significa que sólo se permite al conducto CC añadir la fecha de vencimiento a un problema. Si el AC encuentra el problema y la fecha de vencimiento no está disponible, el valor de la fecha de vencimiento es n/d.
Procesando resultados en problemas
Los problemas encontrados se crean de acuerdo con los resultados de herramientas específicas. El script collect-evidence intenta procesar los archivos de resultados en los archivos adjuntos y crear una lista de problemas.
Los problemas están enlazados a activos, que pueden ser confirmaciones en un repositorio o una imagen de docker con un resumen.
Se crea un problema para cada ID de problema: un ID de problema se compone de los componentes siguientes:
- Activo enlazado
- La herramienta que ha encontrado la vulnerabilidad
- El identificador de vulnerabilidad (el ID de CVE, por ejemplo)
Por ejemplo, si CVE-2022-001 se encuentra mediante dos herramientas separadas, el proceso crea dos problemas hoy.
Herramientas soportadas
El proceso de gestión de incidencias admite los resultados de diversas herramientas de análisis integradas en los flujos de trabajo de DevSecOps. Para consultar la lista actualizada de herramientas de escaneo compatibles y sus funciones, consulta « Herramientas de escaneo compatibles ».
Herramientas o formatos de resultados no soportados
Si el script collect-evidence recibe un archivo adjunto de una herramienta no soportada, o el formato de archivo de resultados no se reconoce durante el proceso, el script se salta la creación de problemas y utiliza el archivo
de resultados como un simple archivo adjunto a las pruebas.
Contenido del problema
- Problema es el nombre del problema o vulnerabilidad.
- Fecha de vencimiento muestra la fecha en la que vence el arreglo o n/d si no hay ninguna fecha de vencimiento disponible.
- Asunto es el activo al que está enlazado el problema.
- URL es el enlace a la versión exacta del activo.
- Tipo de herramienta es la herramienta que ha generado el contenido del problema
Para las incidencias que se crean en Git Repos and Issue Tracking, la fecha de vencimiento se establece en el campo de fecha de vencimiento nativa de GitLab en lugar de en la descripción de la incidencia.
La descripción del problema contiene la indicación de fecha y hora en que se descubrió por primera vez el problema. Por ejemplo, First found on 2022-04-07. La fecha está en formato YYYY-MM-DD. Las ubicaciones donde
se produce el problema se listan en los comentarios del problema.
Ampliar el plazo de resolución de un incidente
Puedes ampliar el plazo de un incidente cuando se necesite más tiempo para aplicar una solución. Para ello es necesaria la autorización de un responsable de seguridad, con el fin de garantizar una supervisión adecuada de las vulnerabilidades de seguridad.
Procedimiento para prorrogar los plazos de vencimiento
- Solicita una revisión a tu responsable de seguridad, explicando por qué es necesaria la prórroga.
- Una vez recibida la aprobación, actualiza la fecha de vencimiento:
- Para « Git Repos and Issue Tracking »: Modifica el campo «
Due date» en los campos de metadatos de la incidencia. - Para « GitHub Enterprise »: Edita el campo «
Due date» en la descripción del problema.
- Para « Git Repos and Issue Tracking »: Modifica el campo «
- Haz referencia a la aprobación del responsable de seguridad en el asunto añadiendo un comentario con un enlace a la documentación de revisión o aprobación.
Asegúrese de hacer referencia a la revisión de punto focal de seguridad en el problema, como por ejemplo proporcionar un enlace al mismo en un comentario.
Excepciones de seguridad
Si tienes algún problema relacionado con una excepción de seguridad, puedes ampliar el plazo para que coincida con la fecha de caducidad de la excepción. De este modo se garantiza que la recopilación de pruebas y el seguimiento del cumplimiento se mantengan de forma adecuada hasta que caduque la excepción.
Alertas de Slack para problemas pendientes y vencidos para interconexión CC
El conducto de conformidad continua (CC) puede establecer fechas de vencimiento para los problemas de incidencia. La interconexión también puede notificar a los usuarios sobre problemas que tienen fechas de vencimiento próximas y fechas de vencimiento vencidas utilizando Slack, si la integración de Slack está habilitada.
Para obtener más información, consulte Configurar una cadena de herramientas de integración continua(CI). Para obtener más información sobre las fechas de vencimiento, consulte [Problemas de incidencia con fecha de vencimiento](/docs/devsecops? topic = devsecops-incident-issues#devsecops-devsecops-issues-due-date.
Los problemas que se notifican se clasifican de la siguiente manera:
- Problemas que tienen fechas de vencimiento pendientes dentro de un periodo de tiempo específico: problemas que están abiertos, tienen fechas de vencimiento y vencen dentro de un periodo de tiempo.
- Problemas que tienen fechas de vencimiento anteriores: problemas que están abiertos, tienen fechas de vencimiento y la fecha ha pasado.
Las duraciones de periodo de tiempo son overdue, due in 1 day, due in 2 days, due in 5 days y due in 10 days.
A continuación se muestra un ejemplo de esta prestación:
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 lista agregada se ordena con los problemas que han vencido en primer lugar, y los problemas con fechas de vencimiento más próximas se listan antes que aquellos con una fecha de vencimiento posterior.
La etapa cc-finish en las consultas de conducto CC para los problemas basándose en los criterios y desencadena una alerta de Slack.