Interconexión de solicitud de extracción

El pull request pipeline ejecuta un conjunto de comprobaciones de estado de cumplimiento en un pull request para el repositorio de aplicaciones especificado.

Es posible que los intentos de fusionar una solicitud de extracción en la rama maestra se bloqueen debido a comprobaciones de estado de conformidad anómalas. Al abrir o actualizar una solicitud de extracción en la rama maestra desencadena la ejecución de la interconexión de la solicitud de extracción. Puedes ejecutar tu propia configuración para los pipelines y las pruebas en Scripts personalizados.

Etapas y tareas

La tabla siguiente lista las tareas ejecutadas en un conducto de SC. 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 por defecto: Indica si los DevSecOps pipelines vienen con una implementación predefinida o por defecto para la etapa. Notablemente, para ciertas etapas como unit-tests o setup, el DevSecOps pipeline no ofrece ninguna implementación out-of-the-box. 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. Cuando DevSecOps Pipeline proporcionan una implementación de referencia para una etapa, la recopilación de pruebas se realiza out-of-the-box. 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 el DevSecOps pipeline no proporciona una implementación out-of-the-box, necesitando que ellos realicen 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.

Tabla 1. Orden de conducto
Tarea o etapa	Descripción breve	Personalización permitida en `.pipeline-config.yaml`	Implementación de referencia predeterminada	Requisito de recopilación de pruebas	Omitir permitido
`start`	Configure el entorno de interconexión.	No	Sí	NA	No
`setup`	Configure el entorno de compilación y prueba.	Sí	No	NA	No
`detect-secrets`	Ejecute el escaneo de secretos de detección en el código de aplicación.	Sí	Sí	NA	No
`unit-tests`	Ejecutar pruebas de unidad y pruebas de aplicación en código de aplicación.	Sí	No	NA	Sí
`compliance-checks`	Ejecutar exploraciones de Code Risk Analyzer y otras comprobaciones de conformidad en repositorios de aplicaciones.	Sí	Sí	NA	Sí
`finish`	Consolidar el estado de la interconexión.	Sí	Sí	NA	Sí

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

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í.

Exploraciones y comprobaciones en las comprobaciones de conformidad

Tabla 2. 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.
Mend Unified Agent: exploración de vulnerabilidades	La herramienta de exploración de Mend Unified Agent explora los componentes de código abierto de los repositorios de aplicaciones en busca de bibliotecas vulnerables y archivos de origen. Para obtener más información, consulte Configuración de exploraciones de Mend Unified Agent.
Comprobación de conformidad del repositorios	Se comprueba que los valores de protección de rama sean correctos.

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.

Trabajos de tareas

Tabla 3. Exploraciones y comprobaciones de conformidad
Trabajo de tarea	Descripción
`code-pr-start`	Se clonan los repositorios de la app y de DevSecOps, y se establece el estado pendiente inicial para las comprobaciones de estado en los repositorios de Git Repos and Issue Tracking.
`code-setup`	El marcador de posición para un script personalizado de configuración definido por el usuario en el que el usuario puede completar la configuración de interconexión.
`code-detect-secrets`	Ejecuta el escaneo de secretos de detección para identificar dónde están visibles los secretos en el código de la app.
`code-unit-tests`	El marcador de posición para un script personalizado de prueba definido por el usuario en el que el usuario puede ejecutar sus propias pruebas.
`code-pr-finish`	Se ejecutan todas las comprobaciones de conformidad necesarias, se comentan los resultados en la solicitud de extracción y se establece su resultado en los repositorios de Git Repos and Issue Tracking.

Se fusionan las solicitudes de extracción con problemas

Puede utilizar los derechos de administrador para fusionar solicitudes de extracción con comprobaciones de estado con error en el repositorio. Sin embargo, estas solicitudes de extracción registran una failure como resultado de sus pruebas para la tarea con error. Este resultado se incluye en el resumen de pruebas y la descripción de la solicitud de cambio e incide en la puntuación de conformidad final en Security and Compliance Center.

Permitir la recopilación de pruebas en el proceso de relaciones públicas

La canalización de las relaciones públicas apoya la recopilación de pruebas junto con la gestión de problemas. Por defecto, el canal de relaciones públicas no recopila pruebas ni abre incidencias, pero los usuarios pueden optar por esta función. Para habilitar la recopilación de pruebas y la gestión de incidencias, establezca la variable de entorno collect-evidence-in-pr como una de las siguientes enum:

none: (por defecto) Establecer collect-evidence-in-pr a none, para evitar la recogida de pruebas en la tubería PR.
all: Establezca collect-evidence-in-pr en all para recopilar todas las evidencias independientemente del estado de la canalización del RP. Las incidencias se abrirán, actualizarán o cerrarán según el script collect-evidence.
success: Establezca collect-evidence-in-pr en success para recopilar evidencias solo si todo el canal de relaciones públicas se ejecutó correctamente. Si la cadena de relaciones públicas falla, las pruebas no se recopilarán ni se publicarán en el almacén de pruebas, y la gestión de problemas no se llevará a cabo.

Nota: Dado que, las tuberías PR se ejecutan generalmente con bastante frecuencia, la elección del modo correcto de collect-evidence-in-pr ahorrará de la recopilación de pruebas innecesarias. Se sugiere seleccionar el modo success durante la fase de desarrollo o en casos en los que se prevean fallos, para evitar la recogida de pruebas si falla la tubería.

Si la canalización PR desencadena una canalización Async, no se admite el modo collect-evidence-in-pr establecido en success. En caso de que el canal PR active un canal asíncrono, establezca collect-evidence-in-pr en all para recopilar evidencias.