Conducto de conformidad continua

La interconexión de conformidad continua (interconexión CC) explora periódicamente los artefactos desplegados y sus repositorios de origen.

La interconexión CC procesa las entradas del repositorio inventory utilizando el valor environment-tag para determinar cuál es el último estado desplegado que se debe examinar. Después de explorar y ejecutar comprobaciones en artefactos y repositorios de origen, el conducto crea un nuevo problema de incidencia o actualiza los problemas de incidencia existentes en el repositorio de incidencias. Por último, utilizando estas cuestiones y los resultados, la canalización recopila pruebas y las resume para actualizar el estado de conformidad de los artefactos encontrados.

Etapas y tareas

La siguiente tabla enumera las tareas que se ejecutan en un CC Pipeline. Además, la tabla también proporciona una visión general de cada una de estas etapas:

Tarea o etapa: hace referencia al nombre de la etapa tal como se define en el archivo de configuración .pipeline-config.yaml.
Descripción breve: proporciona una explicación concisa de las acciones realizadas durante la ejecución de la etapa.
Personalización permitida: indica si los usuarios tienen la flexibilidad de modificar o sustituir el comportamiento predeterminado de la etapa insertando un script personalizado en el archivo .pipeline-config.yaml.
Implementación de referencia predeterminada: Esto indica si elDevSecOps Las canalizaciones vienen con una implementación predefinida o predeterminada para el escenario. En particular, para ciertas etapas como unit-tests o setup, elDevSecOps pipeline no ofrece ninguna implementación lista para usar. En su lugar, los usuarios deben proporcionar scripts personalizados o código adaptado a los requisitos de su aplicación.
Recopilación de pruebas: indica si la etapa realiza la recopilación de pruebas estándar. CuandoDevSecOpsTubería proporciona una implementación de referencia para una etapa, la recopilación de evidencia se realiza de forma inmediata. Sin embargo, si Usuario elige modificar o sustituir estas etapas predefinidas, debe asegurarse de que sus implementaciones personalizadas incluyan la recopilación de pruebas adecuada. La misma responsabilidad recae en los usuarios para las etapas en las que elDevSecOps pipeline no proporciona una implementación lista para usar, lo que les obliga a realizar la recopilación de pruebas. La columna indica la entidad (User/Pipeline) responsable de llevar a cabo la recopilación de pruebas.
Omitir permisible (aplicable a la versión > = v10): indica si los usuarios pueden optar por no ejecutar esta etapa estableciendo la propiedad de omisión en true en .pipeline-config.yaml. Sin embargo, se recomienda precaución al utilizar esta característica, especialmente para las etapas diseñadas para recopilar pruebas. Omitir estas etapas puede hacer que falten pruebas esenciales para la compilación.

Etapas y tareas continuas del proceso de cumplimiento normativo
Task or stage	Descripción breve	Personalización permitida en `.pipeline-config.yaml`	Implementación de referencia predeterminada	Recopilación de pruebas	Omitir permisible
`start`	Configure el entorno de interconexión.	No	Sí	Interconexión	No
`setup`	Configure el entorno de compilación y prueba.	Sí	No	No	No
`detect-secrets`	Ejecute el escaneo de secretos de detección en el código de aplicación.	Sí	Sí	Pipeline	No
`static-scan`	Ejecute el código de escaneo estático en el código de aplicación.	Sí	Sí	Pipeline	Sí
`dynamic-scan`	Ejecute el escaneo dinámico en la aplicación.	Sí	Sí	Pipeline	Sí
`compliance-checks`	Ejecutar exploraciones de Code Risk Analyzer y otras comprobaciones de conformidad en repositorios de aplicaciones.	Sí	Sí	Pipeline	Sí
`scan-artifact`	Explorar los artefactos compilados.	Sí	Sí	Pipeline	Sí
`finish`	Recopilar, crear y cargar los archivos de registro, artefactos y pruebas en el casillero de pruebas.	Sí	Sí	Pipeline	Sí

Para obtener más información sobre cómo personalizar las etapas mediante el archivo .pipeline-config.yaml, consulte Scripts personalizados y Listas de parámetros de pipeline.

Etapas y pruebas

La siguiente tabla establece una relación entre los distintos tipos de pruebas y las fases específicas del proceso en las que se recopilan.

Etapas de integración continua y pruebas asociadas
Tarea o etapa	Tipo de prueba
`start`	N/D
`setup`	N/D
`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`

Para obtener más información sobre cómo recopilar pruebas dentro de las etapas de usuario personalizables utilizando el script collect-evidence, consulte script collect-evidence.

Procesando inventario para artefactos y repositorios

La etapa de inicio clona el inventario y procesa las últimas entradas en el entorno de producción. Puede especificar este entorno proporcionando los siguientes parámetros de interconexión:

Artefactos y repositorios del proceso de conformidad continua
Nombre	Tipo	Descripción	Obligatoria u opcional
`environment-tag`	Texto	Etiqueta que representa el entorno de destino más reciente en el inventario. Ejemplo: `prod_latest` o `us-south_prod_latest`	Obligatorio
`environment-branch`	Texto	Nombre de rama que representa el entorno de destino en el inventario. Ejemplo:`prod`	En su lugar, en desuso-preferir `environment-tag`
`region-prefix`	Texto	Nombre de región como prefijo para la etiqueta `latest` para el entorno de destino. Ejemplo: `us-south`	En su lugar, en desuso-preferir `environment-tag`

Las entradas de inventario contienen artefactos desplegados y orígenes de repositorio. La interconexión procesa y recopila las entradas de inventario y las registra para la ejecución de interconexión utilizando los siguientes mandatos pipelinectl:

La etapa de inicio también clona los repositorios encontrados, cada repositorio y cada par de confirmación. Por ejemplo, repo1 con confirmación sha1 se clonan en una carpeta, pero la interconexión clona el mismo repo1 con confirmación sha2 en una carpeta aparte.

La interconexión registra artefactos y repositorios para la ejecución de interconexión utilizando una simple notación de denominación y un índice incremental, como por ejemplo los ejemplos siguientes:

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

Puede listar estas entradas en las etapas personalizadas utilizando los siguientes mandatos pipelinectl:

Si recupera la información de ramificación en la interconexión CC utilizando el mandato pipelinectl load_repo "$repo" branch, siempre devuelve master como ramificación. Por lo tanto, utilice commit hashes en lugar de ramificaciones.

Etapa de configuración

La etapa de configuración en el conducto CC ejecuta el script que se encuentra en la etapa setup definida por el .pipeline-config.yaml. Puede determinar en qué interconexión se ejecuta el script utilizando el mandato siguiente:

get_env pipeline_namespace

Este mandato devuelve cc, cd, ci o pr, en función de qué interconexión se esté ejecutando. De esta forma, puede reutilizar el script de configuración entre interconexiones si es necesario.

Detectar exploración de secretos

La herramienta IBM Detect Secrets identifica dónde se ven los secretos en el código de la app. Encontrará más información sobre cómo configurar el repositorio para el escaneo aquí.

Exploración de código estático

La etapa de exploración de código estático ejecuta una herramienta del analizador de código estático en las bases de código de los repositorios de la app especificadas.

La interconexión CC proporciona los repositorios que se encuentran en el inventario para el explorador.

Puede utilizar cualquiera de los métodos siguientes para añadir código estático a la interconexión:

Proporcione un nombre de instancia, el URL y las credenciales de SonarQube ya en ejecución añadiendo la herramienta SonarQube a la cadena de herramientas. La tarea static-scan ejecuta un escaneo en los repos especificados.
Añada su código a la etapa personalizada static-scan en su archivo .pipeline-config.yaml para una implementación personalizada.

Exploración dinámica

La etapa de escaneo dinámico ejecuta una herramienta de pruebas de seguridad de aplicación dinámica para encontrar vulnerabilidades en la aplicación desplegada.

Añada su propio código de escaneo dinámico a la etapa personalizada de escaneo dinámico en su archivo .pipeline-config.yaml para una implementación personalizada.

Para obtener más información sobre cómo configurar la exploración dinámica utilizando OWASP-ZAP, consulte Configuración de la exploración de ZAP para la interconexión CC.

Exploraciones y comprobaciones en las comprobaciones de conformidad

Exploraciones y comprobaciones de conformidad
Exploración o comprobación	Descripción
Exploración de vulnerabilidad de Code Risk Analyzer	Busca vulnerabilidades para todas las dependencias del paquete de app, las imágenes base del contenedor y los paquetes del sistema operativo. Se utiliza la herramienta Code Risk Analyzer.
Comprobación CIS de Code Risk Analyzer	Ejecuta comprobaciones de configuración en los manifiestos de despliegue de Kubernetes. Se utiliza la herramienta Code Risk Analyzer.
Comprobación de la lista de materiales (BOM) de Code Risk Analyzer	La BOM para un repositorio especificado que captura el pedigrí de todas las dependencias. Esta BOM se recopila a diferentes niveles de granularidad. Por ejemplo, la BOM captura la lista de imágenes base que se utilizan en la compilación, la lista de paquetes de las imágenes base y la lista de paquetes de app que se instalan sobre la imagen base. La BOM actúa como datos reales para los resultados analíticos y se puede utilizarse potencialmente para imponer las políticas. Se utiliza la herramienta Code Risk Analyzer.

Estos scripts se ejecutan en todos los repositorios de aplicaciones de los que la interconexión tiene constancia. La interconexión CC utiliza la interfaz pipelinectl save_repo para registrar los repositorios que se encuentran en las entradas de inventario y, a continuación, utiliza los mandatos list_repos y load_repo para iterar sobre los repositorios y enviarlos a los exploradores.

Para obtener más información sobre la salida esperada de las etapas del script de usuario, consulte Scripts personalizados.

Exploración y firma de artefactos

La etapa de exploración de artefactos proporciona un comportamiento predeterminado para las imágenes de Docker, con un paso personalizable:

Container Registry Vulnerability Advisor escaneando

La interconexión CC utiliza la interfaz pipelinectl save_artifact para registrar artefactos encontrados en las entradas de inventario y, a continuación, itera sobre estos artefactos, utilizando los mandatos list_artifacts y load_artifact.

Para empezar con esta etapa, proporcione los artefactos para el conducto utilizando la interfaz de pipelinectl. No es necesario que actualice los scripts de compilación y la configuración de .pipeline-config.yaml.

Para utilizar un proceso de escaneado diferente o para procesar artefactos distintos de las imágenes de Docker en icr.io, puede personalizar estas etapas utilizando la configuración de .pipeline-config.yaml en su proyecto.

Recopilación de datos de conformidad en la compilación

La interconexión CC intenta procesar los resultados de comprobaciones y exploraciones, desglosando los resultados en problemas individuales por cada CVE, vulnerabilidad o alerta encontrada. Los problemas encontrados por la interconexión CC se marcan con una etiqueta continuous-compliance-check que identifica los problemas que se descubren en el entorno de producción.

El conducto recopila pruebas en todas las comprobaciones y exploraciones y las almacena en el bloqueador de pruebas. El recopilador de pruebas también guarda los archivos de registro de interconexión, los propios datos de interconexión, que contienen las definiciones de Tekton. Los problemas que se crean según el escaneo y comprueban que los resultados también se adjuntan a las pruebas.