Interconexión de integración continua

El proceso de integración continua compila los artefactos listos para su implementación a partir de los repositorios de las aplicaciones.

Antes de compilar un artefacto, el proceso comprueba que el código haya sido analizado y probado, del mismo modo que se procesan las solicitudes de incorporación de cambios. Los artefactos creados también se exploran para detectar vulnerabilidades y se firman en la interconexión antes de marcarlos para su publicación y despliegue en el inventario. A diferencia de la interconexión de la solicitud de extracción, la interconexión de integración continua recopila pruebas y artefactos de resultados en cada etapa de la compilación como, por ejemplo, pruebas, exploraciones y firmas. Estos datos se correlacionan con los artefactos creados y se pueden rastrear a través del proceso de despliegue y la gestión de cambios.

Etapas y tareas

En la siguiente tabla se enumeran las tareas que se ejecutan en una canalización de CI. 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 de integración continua
Tarea o etapa	Descripción breve	Personalización permitida en `.pipeline-config.yaml`	Implementación de referencia predeterminada	Recogida de pruebas	Saltar permitido
`start`	Se configura el entorno de interconexión.	No	Sí	Conducto	No
`setup`	Se configura el entorno de compilación y pruebas.	Sí	No	N/D	No
`detect-secrets`	Ejecute la exploración de secretos de detección en el código de aplicación.	Sí	Sí	Conducto	No
`test`	Se ejecutan las pruebas de unidad y de aplicación en el código de aplicación.	Sí	No	User	Sí
`static-scan`	Se ejecuta el código de exploración estático en el código de aplicación.	Sí	Sí	Conducto	Sí
`compliance-checks`	Se ejecutan exploraciones de Code Risk Analyzer y otras comprobaciones de conformidad en los repositorios de la app.	Sí	Sí	Conducto	Sí
`peer-review`	Recopilar datos de cumplimiento sobre las revisiones por pares de las solicitudes de incorporación de cambios fusionadas.	Sí	Sí	Conducto	Sí
`containerize`	Se crean los artefactos.	Sí	No	N/D	No
`sign-artifact`	Se firman los artefactos creados.	Sí	Sí	Conducto	No
`deploy`	Se despliegan los artefactos creados en el entorno de desarrollo.	Sí	No	N/D	No
`dynamic-scan`	Ejecute el escaneo dinámico en la aplicación.	Sí	Sí	Conducto	Sí
`acceptance-test`	Se ejecutan las pruebas de aceptación y de integración en los artefactos creados y desplegados en el entorno de desarrollo.	Sí	No	User	Sí
`scan-artifact`	Se exploran los artefactos creados.	Sí	Sí	Conducto	Sí
`release`	Los artefactos creados se añaden al inventario.	Sí	No	N/D	Sí
`finish`	Se recopilan, se crean y se cargan los archivos de registro, los artefactos y las pruebas en el archivo de pruebas.	Sí	Sí	N/D	Sí

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

Etapas y pruebas

El siguiente cuadro 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`
`test`	`com.ibm.unit_tests`
`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`
`peer-review`	`com.ibm.peer_review`
`containerize`	N/D
`sign-artifact`	`com.ibm.cloud.image_signing`
`deploy`	N/D
`dynamic-scan`	`com.ibm.dynamic_scan`
`acceptance-test`	`com.ibm.acceptance_tests`
`scan-artifact`	`com.ibm.cloud.image_vulnerability_scan`
`release`	N/D
`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.

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 la exploración aquí

Exploración de código estático

La etapa de exploración de código estático ejecuta un número de herramientas de analizador de código estático en los repositorios de aplicaciones especificados. Se exploran los repositorios que proporciona el mandato pipelinectl save_repo y el repositorio de la app predeterminada.

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 de exploración estática ejecuta una exploración en los repositorios especificados.
Si no tiene una instancia propia de SonarQube, la interconexión creará una instancia de SonarQube durante la ejecución de la interconexión. Es posible acceder a esta instancia después de que se ejecute correctamente la etapa static-scan.
Utilizando el parámetro opt-in-gosec para ejecutar la exploración de gosec para comprobaciones de seguridad de golang.
Añada su propio código de exploración estático a la etapa personalizada de exploración estática del archivo .pipeline-config.yaml para una implementación personalizada.

Adición de la exploración de SonarQube a los conductos

Para obtener más información sobre la integración de SonarQube con el conducto de integración continua, consulte Configuración de SonarQube.

Adición de la integración de exploración de gosec a las interconexiones

Utilice gosec para inspeccionar el código fuente golang en los repositorios explorados.

Para habilitar la exploración de gosec, proporcione el parámetro siguiente y establezca el valor en 1.

parámetros de exploración gosec
Nombre	Tipo	Descripción	Obligatorio u opcional
`opt-in-gosec`	text	opción para habilitar la exploración de gosec	opcional

Para obtener más información sobre cómo configurar la exploración de gosec en el conducto de integración continua, consulte Configuración de GoSec

Utilización de otros exploradores estáticos

Si prefiere utilizar su propia implementación de escaneo estático, puede modificar su archivo .pipeline-config.yaml y añadir su propio Script personalizado a la etapa static-scan.

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.
Comprobación de conformidad del repositorios	Se comprueba que los valores de protección de rama sean correctos. Por ejemplo, la rama maestro/principal siempre debe restringir el envío forzado. Para obtener más información, consulte Configuración del repositorio de Git Repos and Issue Tracking.

Estos scripts se ejecutan en todos los repositorios de aplicaciones de los que la interconexión tiene constancia. Para añadir repositorios a estas exploraciones, utilice la interfaz pipelinectl que se proporciona en la etapa de configuración.

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

Nota: Los pipelines CI no se activan sobre etiquetas porque no soportan funcionalidades como branch protection checks o peer review check. Si decide ejecutar una canalización CI en las etiquetas, asegúrese de desactivar las propiedades peer-review-compliance y branch-protection-check estableciéndolas en 0. Sin embargo, tenga en cuenta que en este caso, la recogida de pruebas no se producirá para estos.

Crear

En la etapa de compilación, puede crear sus propios artefactos. Aunque la interconexión proporciona algunas características predeterminadas para artefactos de tipo de imagen de Docker, se puede crear cualquier tipo de artefacto en esta etapa.

Utilice las variables de entorno de la interfaz de usuario de interconexión para proporcionar credenciales, secretos y parámetros para la compilación. Puede acceder a estas variables de entorno en esta etapa y en todas las etapas personalizadas. Para obtener más información sobre cómo acceder a parámetros y secretos en las etapas de script personalizados, consulte Scripts personalizados.

Exploración y firma de artefactos

Las etapas de exploración y de firma de artefactos proporcionan un comportamiento predeterminado para las imágenes de Docker, con pasos personalizables:

Firma de imágenes mediante la clave GPG.
Exploración de Container Registry Vulnerability Advisor.

Para empezar con estas etapas, proporcione los artefactos para que la interconexión utilice la interfaz pipelinectl. No es necesario que actualice los scripts de compilación y la configuración de .pipeline-config.yaml.

Para utilizar un proceso de exploración o de firma distinto, o para procesar artefactos que no sean imágenes de Docker en icr.io, puede personalizar estas etapas utilizando la configuración .pipeline-config.yaml en el proyecto.

Despliegue en dev

La etapa de despliegue despliega artefactos compilados en un entorno de desarrollo.

Exploración dinámica

El escaneo de código dinámico es una forma de escaneo de vulnerabilidades de caja negra que permite a los equipos de software escanear aplicaciones en ejecución e identificar vulnerabilidades.

La etapa Dynamic Scan se ejecuta inmediatamente después de la etapa Deploy to dev después de un despliegue satisfactorio en el entorno de desarrollo.

De forma predeterminada, la interconexión proporciona soporte para ejecutar Zed Attack Proxy (ZAP) Scan, que es una herramienta de pruebas de penetración de código abierto y gratuita que se mantiene bajo el paraguas de OWASP. Realiza exploraciones dinámicas de API y de interfaz de usuario, ambas se pueden ejecutar en la aplicación hello-compliance-app de ejemplo.

Para ejecutar la exploración dinámica, establezca el parámetro de interconexión opt-in-dynamic-scan en un valor no vacío. Para inhabilitar la etapa de la ejecución de exploraciones dinámicas, establezca el parámetro de interconexión opt-in-dynamic-scan en vacío. Para obtener más información sobre cómo establecer parámetros de interconexión, consulte Parámetros de interconexión.

La interconexión de AC crea problemas en el repositorio de problemas en función de la gravedad. La etiqueta que se adjunta al problema indica la gravedad de la vulnerabilidad.

Exploración de API de ZAP

La API de ZAP explora los puntos finales de la aplicación en busca de posibles fugas de datos, errores de tipo de contenido, redirecciones externas, inyección de código, inyección de SQL, inyección de mandatos del sistema operativo remoto y otras vulnerabilidades expuestas por la aplicación. Las exploraciones de la API de ZAP ayudan a los desarrolladores a proteger la aplicación detectando estas vulnerabilidades en una etapa o entorno de prueba y arreglándolas antes de que la aplicación se despliegue en un entorno de producción.

Las exploraciones de API de ZAP requieren las entradas siguientes para explorar la aplicación:

Archivo de definición de Swagger: describe las API de HTTP y sus parámetros asociados tal como los expone la aplicación.
Clave de API-Señal de autenticación necesaria para autenticarse con los puntos finales de API.
Punto final de API-Puntos finales de las definiciones de swagger que desea que ZAP explore.
URL excluidos-Los URL que el explorador ZAP debe ignorar.

El explorador de API de ZAP utiliza las entradas que se mencionan para ejecutar la exploración y generar un informe.

Establezca opt-in-dynamic-api-scan en un valor no vacío para que se ejecuten las exploraciones de API de ZAP. Para cancelar la participación, establezca este parámetro en vacío.

Exploración de IU de ZAP

ZAP UI analiza los puntos finales de la aplicación en busca de vulnerabilidades en las propias páginas web, como cookies no seguras que se están configurando, ajustes incorrectos de los encabezados de caché, inclusiones de archivos entre dominios, configuraciones incorrectas de « CORS » y otras vulnerabilidades a las que la aplicación está expuesta.

Las exploraciones de interfaz de usuario funcionan de forma similar a las exploraciones de API, pero utilizan un script de prueba de interfaz de usuario en lugar de un archivo Swagger. El script de prueba de interfaz de usuario inicia un navegador autónomo que está configurado para realizar proxy a través del proxy del explorador ZAP y ejecuta una prueba de interfaz de usuario en el punto final de la interfaz de usuario. El proceso para ejecutar pruebas de interfaz de usuario de ZAP es el siguiente:

Copie los scripts de prueba en los contenedores del explorador ZAP.
Ejecute el proxy ZAP.
Ejecute los scripts de prueba de zap.

El proxy ZAP registra el tráfico y descubre los puntos finales a explorar. Una vez finalizadas las exploraciones, el proxy genera un informe y genera problemas de la misma forma que en la exploración de la API de ZAP.

Establezca opt-in-dynamic-ui-scan en un valor no vacío para que se ejecuten las exploraciones de API de ZAP. Para cancelar la participación, establezca este parámetro en vacío.

Añade tu propio código de exploración dinámica a la etapa personalizada «dynamic-scan» de tu archivo « .pipeline-config.yaml » para crear una implementación personalizada.

Para obtener más información sobre la exploración de API de ZAP y las exploraciones de IU de ZAP, consulte Configuración de exploraciones de ZAP.

Publicación en inventario

Utilice la etapa de publicación en el script de usuario de inventario para añadir artefactos al inventario utilizando el mandato de la CLI cocoa inventory add. Para obtener más información sobre el mandato, consulte el tema sobre adición de inventario de cacao.

Si desea omitir la actualización de inventario si hay problemas en la interconexión, utilice las variables de entorno siguientes para comprobar el estado de la interconexión. Compruebe su estado antes de actualizar el inventario:

skip-inventory-update-on-failure Variable de entorno de participación de conducto para especificar si se debe realizar la actualización de inventario.
one-pipeline-status Se establece en 1 si hay algún error de etapa en la ejecución del conducto.

Puedes utilizar la interfaz pipelinectl para acceder a tus repositorios y artefactos mediante los comandos list_repos, load_repo, list_artifacts y load_artifact. Para obtener más información sobre los mandatos, consulte la documentación de pipelinectl.

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

Cuando la interconexión se ejecuta correctamente, puede recopilar información sobre la compilación.

Se recopilan pruebas den todas las comprobaciones, exploraciones, pruebas y firmas de artefactos en el archivo de pruebas. Los archivos de registro de interconexiones también se guardan en el archivo, junto con los datos de la propia interconexión, que contienen las definiciones de Tekton. Los datos de conformidad en las revisiones de iguales también se recopilan en este paso. La interconexión utiliza pipelinectl para buscar repositorios con solicitudes de extracción que se fusionaron después de la última compilación. También se comprueban sus estados de revisión, se guardan como artefacto y se crean pruebas basadas en el resultado.

El script final es un evaluador, que marca el estado de la interconexión en color verde o rojo, en función de los estados de las pruebas. Si contienen anomalías, la ejecución de la integración continua se marca de color rojo.