Herramientas de auditoría en la entrega de software: siguiendo la evidencia desde el requerimiento hasta producción

Una versión llega a producción y las verificaciones salen bien. El ticket de cambio dice «aprobado». Hasta ahí, todo parece estar en orden. Pero queda una pregunta importante: ¿el código que se desplegó fue el mismo que se revisó y aprobó? Que la aplicación funcione no nos dice cómo llegó esa versión a producción.

Para contestar esa pregunta hay que seguir el pase por varios sistemas. El requerimiento puede estar en Jira; la revisión de código, en GitLab; las pruebas y la compilación, en Jenkins; el paquete, en Nexus; y la aprobación, en ServiceNow. Por último, el registro de despliegue muestra qué llegó a producción. Cada herramienta guarda una parte de la historia. La evidencia cobra sentido cuando se relacionan esos registros y se detecta si falta alguno.

Ahí entran las herramientas de auditoría. El equipo de desarrollo usa distintas plataformas para entregar software y ejecutar controles. Auditoría utiliza los registros que dejan, junto con SQL, hojas de cálculo o herramientas de análisis, para comprobar cómo funcionaron esos controles en las versiones reales. El COBIT for DevOps Audit Program de ISACA cubre aspectos de planificación, despliegue, monitoreo y gestión. Las Normas Globales de Auditoría Interna del IIA requieren información relevante, confiable y suficiente para sustentar una conclusión.

Qué aporta cada herramienta

Parte del pase	Ejemplos	Qué busca el auditor
Solicitud y aprobación	Jira u otra herramienta de planificación; ServiceNow u otro sistema de gestión de cambios	El motivo del cambio, los riesgos, las pruebas documentadas, quién aprobó el pase y si hubo alguna excepción autorizada.
Código, controles y paquete	GitLab o GitHub; Jenkins u otra plataforma de integración y entrega continuas (CI/CD); Veracode u otro analizador; Nexus u otro repositorio de artefactos	Si el commit revisado corresponde a la compilación, los controles requeridos, el paquete guardado y el despliegue.
Resultado en producción	Registros de despliegue, monitoreo de la aplicación y, cuando aplique, AWS CloudTrail	Qué versión se desplegó, quién o qué hizo el cambio y si algún pase quedó fuera del proceso aprobado.
Análisis de auditoría	SQL, scripts, hojas de cálculo o Caseware IDEA	Qué registros coinciden entre sistemas, qué identificadores se repiten y qué casos necesitan revisión.

La última fila suele recibir menos atención. Los paneles de cada sistema pueden verse bien por separado, aunque sus datos no cuadren entre sí. Caseware IDEA permite relacionar conjuntos de datos y encontrar duplicados o registros faltantes; con SQL se pueden hacer comparaciones similares. Luego toca investigar qué significa cada diferencia.

Seguir un pase desde producción hasta el requerimiento

Pensemos en una actualización de un portal para clientes. El equipo registra el requerimiento en Jira, revisa un merge request en GitLab, compila y prueba un ZIP en Jenkins, lo guarda en Nexus, obtiene aprobación en ServiceNow y lo despliega. La secuencia suena normal. Lo que interesa en auditoría es confirmar que todos esos registros correspondan a la misma versión.

Yo comenzaría con la lista de lo que realmente se desplegó, obtenida de una fuente distinta a los tickets de cambio. Esa lista debe contemplar los pases de emergencia, los despliegues manuales y las aplicaciones que siguen otro proceso. Si se parte únicamente de los tickets aprobados, un despliegue sin ticket podría quedar fuera de la revisión desde el principio.

Para cada pase seleccionado, se puede reconstruir el recorrido hacia atrás:

Pregunta	Registros que se comparan	Motivo para investigar
¿Por qué se hizo este pase?	Requerimiento, ticket de cambio e historial de aprobaciones	El ticket describe otra cosa o se aprobó después del despliegue sin seguir un proceso de emergencia autorizado.
¿Se revisó ese código?	Merge request, SHA del commit, revisores y reglas de las ramas	El commit desplegado no es el que se revisó.
¿Corrieron los controles requeridos?	Pipeline del commit, pruebas y resultados de análisis	Una verificación requerida falló, se omitió o se dispensó sin aprobación.
¿Es el paquete aprobado?	Registro de compilación, digest del artefacto, ticket y registro de despliegue	El paquete desplegado tiene un digest distinto al que se construyó y aprobó.
¿Qué pasó después?	Monitoreo, incidentes, reversión y cierre del cambio	Se cerró un pase fallido sin darle el seguimiento requerido.

Una etiqueta como 2.4.1 ayuda a relacionar registros, pero se puede volver a usar. Si los sistemas guardan un digest criptográfico, este permite comparar con mayor precisión el contenido del paquete construido y el desplegado. Si no coinciden, hay que averiguar por qué. Puede tratarse de una nueva compilación legítima que quedó mal documentada o de un paquete que cambió después de la aprobación. La diferencia, por sí sola, no cuenta toda la historia.

También conviene hacer el recorrido al revés: tomar tickets aprobados y buscar su implementación. A veces un ticket figura como «completado» aunque el cambio nunca haya llegado a producción. Revisar en ambos sentidos ayuda a ver el panorama completo.

¿Se puede confiar en esos registros?

Una cadena de evidencia puede verse completa aunque alguien tenga acceso para cambiar las reglas y borrar el rastro. ¿Quién puede modificar la protección de las ramas o la configuración del pipeline? ¿Una misma persona puede aprobar su propio código, saltarse un análisis fallido, reemplazar el paquete o desplegar fuera del proceso? Las cuentas de servicio también cuentan. Tener cuatro cuentas distintas no garantiza separación de funciones si una sola persona controla las cuatro.

Los registros de auditoría del repositorio pueden mostrar cambios de acceso y configuración, según los eventos que guarde la plataforma y el tiempo que se conserven. En AWS, CloudTrail puede añadir contexto sobre actividad relevante en la cuenta. Su alcance depende de los tipos de eventos recopilados y de los servicios utilizados; no muestra automáticamente cada despliegue de la aplicación ni el digest del paquete. Por eso hay que compararlo con los registros de despliegue.

Los reportes de seguridad también necesitan contexto. El análisis estático de seguridad de aplicaciones (SAST) busca determinadas debilidades en el código. El análisis de composición de software (SCA) revisa problemas conocidos en las dependencias. Si el pase incluye definiciones de infraestructura versionadas, también puede corresponder un análisis de infraestructura como código. Para cada control requerido hay que verificar qué repositorio y versión cubrió, si hubo exclusiones o ejecuciones fallidas y quién aceptó los hallazgos pendientes. Un reporte sin hallazgos dice poco si nunca se analizó la aplicación. Del mismo modo, un pipeline exitoso demuestra que pasaron los controles configurados para esa ejecución; no dice qué ocurrió con un pase hecho por fuera.

Algunos equipos también conservan una lista de componentes de software (SBOM), un digest del paquete o información firmada sobre cómo se construyó. Esos registros pueden fortalecer la evidencia si forman parte del proceso, pero cada uno responde a una pregunta distinta. El SBOM identifica componentes; el digest ayuda a comparar paquetes; la procedencia verificada puede ayudar a establecer cómo se hizo la compilación. Todavía hay que comprobar la autorización y los controles requeridos. Qué registros pesan más dependerá de la tecnología y del riesgo del cambio.

Convertir los registros en una prueba de auditoría

Para revisar un periodo completo, se pueden exportar los despliegues a producción, los tickets y los resultados del pipeline y compararlos con SQL, una hoja de cálculo o una herramienta de análisis de auditoría. Los pases sin ticket, las aprobaciones posteriores al despliegue, las excepciones repetidas y las compilaciones sin un identificador que las conecte con el cambio son casos para investigar. Antes de informar que «el 98 % de los despliegues tenía aprobación», hay que verificar que el total incluya los pases realizados fuera del pipeline habitual. Ese total importa tanto como el porcentaje.

En una muestra de esos casos, el auditor vuelve a los registros originales, confirma quién hizo qué y cuándo, revisa la política vigente en ese momento y consulta las dudas con la persona responsable del control. Las capturas de pantalla ayudan a localizar información; cuando están disponibles, son los registros originales los que deben respaldar la conclusión.

Los equipos de desarrollo pueden monitorear las compilaciones y los despliegues a diario. Auditoría interna puede usar esa información para hacer pruebas con mayor frecuencia y mantener su evaluación independiente del monitoreo de la gerencia. La guía del IIA sobre auditoría y monitoreo continuos explica esa diferencia.

Conclusión

Un despliegue exitoso es apenas el punto de partida. Para evaluar los controles hay que relacionar la versión en producción con su requerimiento, el código revisado, las pruebas, la aprobación, el paquete y el resultado. Jira, GitLab, Jenkins, Nexus, ServiceNow, los registros de producción y las herramientas de análisis pueden aportar piezas. La prueba está en comprobar si todas cuentan la misma historia, incluidos los pases que no siguieron la ruta habitual.

Referencias

1. The Institute of Internal Auditors (IIA). Global Internal Audit Standards, Standard 14.1: Gathering Information for Analyses and Evaluation.
2. ISACA. COBIT for DevOps Audit Program.
3. The IIA. Continuous Auditing and Monitoring.
4. Caseware. Introduction to IDEA Data Analysis.
5. GitHub. Reviewing the Audit Log for Your Organization; GitLab. Audit Events.
6. AWS. Understanding CloudTrail Events y Logging Data Events.
7. NIST. Secure Software Development Framework, SP 800-218.
8. SLSA. Verifying Artifacts and Build Provenance.