Glosario de Seguridad y DevSecOps para Auditores
Este glosario explica los términos técnicos clave en lenguaje sencillo, adaptado para auditores, responsables de cumplimiento y gestores de riesgos. Para cada término, explicamos qué es, por qué les importa a los auditores y qué evidencias buscar.
CI/CD (Integración Continua / Entrega Continua)
Qué es: Un sistema automatizado que construye, prueba e implementa software cada vez que los desarrolladores realizan cambios. Piense en él como una línea de montaje digital para el software: el código entra por un extremo y el software probado y empaquetado sale por el otro.
Por qué les importa a los auditores: Los pipelines CI/CD son la capa de aplicación de controles para la entrega de software. Si los controles de seguridad no están integrados en este pipeline, es probable que no se apliquen en absoluto. Bajo DORA y NIS2, los sistemas CI/CD se consideran sistemas TIC regulados.
Evidencias a buscar: Registros de ejecución del pipeline con marcas de tiempo, registros de finalización obligatoria de etapas, flujos de trabajo de aprobación antes de la implementación en producción.
Pipeline
Qué es: Una secuencia de pasos automatizados (construcción, prueba, análisis, implementación) por los que el código debe pasar antes de llegar a producción. Cada paso puede aplicar una puerta de seguridad.
Por qué les importa a los auditores: La arquitectura del pipeline determina si los controles de seguridad son obligatorios u opcionales. Un pipeline bien diseñado impide que el código no aprobado llegue a producción.
Evidencias a buscar: Archivos de configuración del pipeline que muestren etapas obligatorias, registros de aprobación/rechazo de puertas, registros de implementaciones bloqueadas.
SAST (Pruebas de Seguridad de Aplicaciones Estáticas)
Qué es: Análisis automatizado del código fuente para encontrar vulnerabilidades de seguridad antes de que se ejecute el software. Lee el código como lo haría un revisor, buscando patrones de vulnerabilidades conocidos.
Por qué les importa a los auditores: SAST proporciona evidencia de que las pruebas de seguridad se realizan de forma temprana en el desarrollo. Demuestra que la organización identifica vulnerabilidades de forma proactiva en lugar de descubrirlas en producción.
Evidencias a buscar: Registros de análisis con marcas de tiempo, aplicación de políticas que muestren compilaciones bloqueadas por hallazgos críticos, informes de tendencias que muestren tasas de remediación a lo largo del tiempo, procesos documentados de supresión/excepción.
DAST (Pruebas de Seguridad de Aplicaciones Dinámicas)
Qué es: Pruebas automatizadas de una aplicación en ejecución mediante la simulación de ataques reales. A diferencia de SAST (que lee el código), DAST prueba la aplicación como lo haría un atacante, desde el exterior.
Por qué les importa a los auditores: DAST valida que las aplicaciones implementadas son resilientes ante patrones de ataque conocidos. Complementa a SAST al probar el comportamiento en el mundo real, no solo el código.
Evidencias a buscar: Informes de análisis DAST con vulnerabilidades identificadas y clasificaciones de gravedad, plazos de remediación, programas de análisis recurrentes, integración con registros del pipeline CI/CD.
SCA (Análisis de Composición de Software)
Qué es: Análisis automatizado de bibliotecas y dependencias de terceros utilizadas en el software. La mayoría de las aplicaciones modernas son un 70-90% de código de terceros — SCA comprueba si ese código tiene vulnerabilidades conocidas o riesgos de licencia.
Por qué les importa a los auditores: El riesgo de componentes de terceros es una preocupación clave bajo el Artículo 28 de DORA y los requisitos de la cadena de suministro de NIS2. SCA proporciona visibilidad de la cadena de suministro de software.
Evidencias a buscar: Inventarios de dependencias, informes de vulnerabilidades para componentes de terceros, comprobaciones de cumplimiento de licencias, bloqueo automatizado de componentes con vulnerabilidades críticas.
SBOM (Lista de Materiales de Software)
Qué es: Un inventario completo y legible por máquina de cada componente (bibliotecas, marcos, dependencias) incluido en una aplicación de software. Piense en él como una etiqueta nutricional para el software.
Por qué les importa a los auditores: Los SBOMs son cada vez más obligatorios por regulación. Permiten la trazabilidad de los componentes de la cadena de suministro y la evaluación rápida del impacto cuando se divulgan nuevas vulnerabilidades.
Evidencias a buscar: Archivos SBOM generados (formato SPDX o CycloneDX), generación automatizada de SBOM en pipelines CI/CD, registros de retención y versionado de SBOM.
IAST (Pruebas de Seguridad de Aplicaciones Interactivas)
Qué es: Un enfoque de pruebas híbrido que monitoriza las aplicaciones desde dentro durante las pruebas. Un agente se integra en la aplicación y observa las rutas de ejecución de código reales para identificar vulnerabilidades con alta precisión.
Por qué les importa a los auditores: IAST proporciona resultados muy precisos con menos falsos positivos que SAST o DAST por separado, lo que significa que los hallazgos son más accionables y auditables.
Evidencias a buscar: Registros de implementación del agente IAST, informes de ejecución de pruebas, hallazgos de vulnerabilidades correlacionados con rutas de código específicas.
RASP (Autoprotección de Aplicaciones en Tiempo de Ejecución)
Qué es: Un agente de seguridad en tiempo de ejecución integrado dentro de la aplicación que detecta y bloquea ataques en tiempo real. A diferencia de un firewall (que protege el perímetro), RASP protege desde dentro de la aplicación.
Por qué les importa a los auditores: RASP demuestra protección en tiempo de ejecución: un control detectivo y correctivo que opera de forma continua, no solo durante las fases de prueba.
Evidencias a buscar: Configuración de implementación de RASP, registros de ataques bloqueados, registros de integración de alertas/incidentes, informes de cobertura.
Contenedor / Imagen / Registro
Qué es: Un contenedor es un paquete ligero y aislado que agrupa una aplicación con todo lo que necesita para ejecutarse. Una imagen es la plantilla utilizada para crear contenedores. Un registro es el repositorio donde se almacenan y distribuyen las imágenes.
Por qué les importa a los auditores: Los contenedores son la unidad de implementación estándar en los entornos modernos. Las imágenes sin firmar o sin analizar representan un riesgo en la cadena de suministro. Los controles de acceso al registro determinan quién puede implementar qué.
Evidencias a buscar: Informes de análisis de imágenes, registros de firma/verificación de imágenes, políticas de control de acceso al registro, políticas de actualización de imágenes base.
IaC (Infraestructura como Código)
Qué es: Gestión de la infraestructura (servidores, redes, bases de datos) a través de archivos de código en lugar de configuración manual. Los cambios en la infraestructura pasan por el mismo pipeline que el código de la aplicación.
Por qué les importa a los auditores: IaC hace que los cambios de infraestructura sean trazables, revisables y auditables: los mismos controles de gobernanza que se aplican al código pueden aplicarse a la infraestructura.
Evidencias a buscar: Plantillas IaC en control de versiones, registros de aprobación de cambios, informes de detección de desviaciones, análisis de seguridad de plantillas IaC.
Gestión de Secretos
Qué es: La práctica de almacenar, distribuir y rotar de forma segura credenciales sensibles (claves de API, contraseñas, certificados, tokens) utilizadas por aplicaciones y pipelines.
Por qué les importa a los auditores: Los secretos expuestos son uno de los fallos de seguridad más comunes y graves. Una gestión adecuada de secretos demuestra madurez en el control de acceso y reduce el riesgo de compromiso de credenciales.
Evidencias a buscar: Implementación de bóveda/gestor de secretos centralizado, políticas de rotación automatizada, sin secretos codificados en el código (verificado mediante análisis), registros de auditoría de acceso.
Artefacto
Qué es: Cualquier resultado producido por el pipeline CI/CD: código compilado, imágenes de contenedores, paquetes, documentación. Los artefactos son lo que se implementa en producción.
Por qué les importa a los auditores: La integridad de los artefactos garantiza que lo que se probó es exactamente lo que se implementa. Los artefactos manipulados o sin firmar representan un riesgo crítico en la cadena de suministro.
Evidencias a buscar: Registros de firma de artefactos, metadatos de procedencia, sumas de verificación/hashes, almacenamiento inmutable de artefactos, trazabilidad de implementación hasta ejecuciones específicas del pipeline.
Policy-as-Code
Qué es: Codificación de políticas de seguridad y cumplimiento como reglas legibles por máquina que son aplicadas automáticamente por el pipeline CI/CD. En lugar de un documento de política en PDF, la política se convierte en código ejecutable.
Por qué les importa a los auditores: Policy-as-code transforma las políticas de documentos aspiracionales en controles aplicados. Proporciona evidencia de que las políticas no solo están escritas sino que realmente se aplican.
Evidencias a buscar: Archivos de definición de políticas en control de versiones, registros de aplicación que muestren resultados de evaluación de políticas, registros de implementaciones bloqueadas por violaciones de políticas.
Shift-Left
Qué es: Trasladar las pruebas de seguridad y los controles hacia etapas más tempranas del ciclo de vida del desarrollo de software: desde la post-implementación (derecha) hasta las fases de diseño y codificación (izquierda). El objetivo es detectar problemas cuando son más baratos y fáciles de solucionar.
Por qué les importa a los auditores: Shift-left es evidencia de una postura de seguridad proactiva y preventiva en lugar de reactiva. Las regulaciones esperan cada vez más que la seguridad esté integrada en todo el SDLC, no añadida al final.
Evidencias a buscar: Requisitos de seguridad en documentos de diseño, SAST integrado en flujos de trabajo de desarrolladores, registros de modelado de amenazas, registros de formación en seguridad para desarrolladores.
DevSecOps
Qué es: Un modelo operativo que integra la seguridad en cada fase del desarrollo y la entrega de software. Define roles, responsabilidades y controles automatizados para garantizar que la seguridad sea continua, no una fase o equipo separado.
Por qué les importa a los auditores: DevSecOps es el marco de gobernanza que hace que la seguridad CI/CD sea sostenible. Determina quién es responsable de qué, cómo se gestionan las excepciones y cómo se aplican los controles.
Evidencias a buscar: Roles y responsabilidades definidos (RACI), configuraciones de puertas de seguridad, flujos de trabajo de aprobación de excepciones/supresiones, métricas de seguridad y cadencia de informes.
Segregación de Funciones (SoD)
Qué es: Garantizar que ninguna persona pueda tanto desarrollar código como aprobar su implementación en producción. Diferentes roles gestionan diferentes etapas del proceso de entrega.
Por qué les importa a los auditores: La SoD es un control fundamental requerido por prácticamente todos los marcos de cumplimiento. Previene el fraude, reduce el riesgo de amenazas internas y garantiza una revisión independiente.
Evidencias a buscar: Configuraciones RBAC, registros de flujos de trabajo de aprobación que muestren aprobadores distintos de los autores del código, reglas de protección de ramas, matrices de permisos de implementación.
RBAC (Control de Acceso Basado en Roles)
Qué es: Un modelo de control de acceso donde los permisos se asignan a roles (por ejemplo, desarrollador, revisor, deployer) en lugar de a usuarios individuales. Los usuarios heredan permisos a través de su asignación de rol.
Por qué les importa a los auditores: RBAC es la base para la segregación de funciones y el principio de mínimo privilegio. Proporciona un modelo de acceso estructurado y auditable.
Evidencias a buscar: Definiciones de roles y matrices de permisos, registros de asignación de usuarios a roles, revisiones periódicas de acceso, monitoreo de roles privilegiados.
Este glosario se mantiene como referencia viva. Los términos se definen desde la perspectiva del auditor, centrados en la verificación del control, no en los detalles de implementación. Para orientación técnica de implementación, visite secure-pipelines.com.
