Agrega Codex Security a tu pipeline

Elige el ejemplo de tu plataforma de CI. Sigue sus instrucciones para instalar la CLI de Codex Security y proporcionar una clave de API mediante el almacén de secretos de tu proveedor de CI.

Elige un punto de partida:

• GitHub Actions: usa el flujo de trabajo para pull requests para analizar los cambios propuestos y conservar los resultados.
• GitLab CI/CD: consulta la guía del pipeline para configurar análisis en merge requests, análisis de la rama predeterminada y análisis programados. La guía incluye un pipeline descargable y explica qué opciones habilitar.
• Otras plataformas de CI: adapta los comandos de análisis y exportación de Ejecuta Codex Security en CI a los eventos y al almacén de secretos de tu proveedor, así como a la forma en que este obtiene la copia de trabajo del código y gestiona los artefactos.

Configura el evento que activa el análisis y su alcance

Cuando los cambios lleguen a main, analiza el repositorio tal como quedó en el commit enviado. Programa también análisis periódicos para la rama que elijas. Puedes empezar con un análisis semanal y ajustar la frecuencia según la actividad del repositorio, la duración de los análisis y su costo.

Para las pull requests o merge requests, obtén el historial de la rama de destino y el de la rama que contiene los cambios propuestos. Analiza las diferencias entre la base de fusión de ambas ramas y el commit propuesto.

Configura cada trabajo según el código que deba analizar. Para los análisis programados y los commits enviados a main, analiza todo el repositorio. Para las pull requests, analiza los cambios propuestos. Sigue el ejemplo de tu plataforma para configurar el análisis correspondiente.

Establece un presupuesto acorde con el alcance y la frecuencia. Analizar todo el repositorio puede llevar más tiempo y costar más que analizar solo las diferencias. Usa --max-cost como límite estimado de costo. No garantiza un tope estricto de gasto. Si el análisis alcanza ese límite, parte del código puede quedar sin analizar.

Ejecuta el pipeline y revisa los resultados

Envía el cambio del pipeline a revisión mediante tu proceso habitual y luego inicia un análisis. Verifica en los detalles de la ejecución y en scan-manifest.json que la versión del código y el alcance sean los previstos.

Revisa los hallazgos y la evidencia que los respalda en los informes guardados. Consulta coverage.json para identificar las partes del código cuyo análisis quedó incompleto o se pospuso, incluso si el análisis no reportó hallazgos. Revisa el tiempo de ejecución y el costo antes de aumentar la frecuencia o extender el análisis a más repositorios.

Conserva los informes como artefactos de CI. Define quién puede acceder a los artefactos y cuánto tiempo se conservan en función del código fuente y la evidencia que contienen.

Si lo deseas, exporta los resultados en SARIF, un formato estructurado para hallazgos de seguridad, para mostrarlos en la interfaz de seguridad de tu plataforma. Consulta la guía de la plataforma para conocer las versiones compatibles, los permisos y los requisitos de licencia.

Decide si los hallazgos deben bloquear la fusión de cambios

Empieza por revisar los hallazgos sin bloquear las fusiones. Cuando tu equipo se sienta cómodo con los resultados, puedes exigir que las pull requests pasen una verificación de seguridad. Por ejemplo, puedes bloquear la fusión si el análisis detecta una vulnerabilidad de gravedad alta o crítica.

Verifica siempre si el análisis se completó y qué código abarcó. Si el análisis falló u omitió parte del código, revisa lo ocurrido aunque no haya reportado hallazgos.

Para obtener más detalles sobre la configuración, consulta Configura los umbrales de gravedad e interpreta los resultados del análisis.

Da seguimiento a los hallazgos

Sigue el proceso habitual de tu equipo para asignar cada hallazgo a quien deba investigarlo o corregir el problema. Incluye el commit analizado, el código afectado y la evidencia que respalda el hallazgo para que otro desarrollador pueda investigarlo.

Verifica las correcciones antes de cerrar los hallazgos. Si la cobertura quedó incompleta, analiza el código pendiente en un análisis posterior.