Seguridad del código sin YAML: así escala GitLab el escaneo

A medida que una organización crece, configurar a mano los escáneres de seguridad de cada proyecto se vuelve inmanejable. GitLab 19.0 propone una solución: los perfiles de configuración de seguridad. Con ellos se pueden activar SAST, el escaneo de dependencias y la detección de secretos con un solo clic en todos los proyectos a la vez, sin necesidad de editar archivos YAML.

Por qué la configuración manual no escala

Al principio, la configuración manual funciona bien: un equipo, unos pocos repositorios y un security engineer que se lo sabe todo de memoria. Pero cuando aumentan los equipos y los proyectos, el modelo empieza a desmoronarse. La AI acelera el ritmo de desarrollo, pero la cobertura de seguridad se queda atrás todavía más rápido.

Los problemas que aparecen son típicos y dolorosos. Los equipos copian la configuración de escaneo de cualquier sitio: el SAST de un servicio de backend se ejecuta con un conjunto de reglas y el del frontend, con otro completamente distinto. El escaneo de dependencias se añade a los proyectos nuevos, pero se olvida en los antiguos. Alguien edita .gitlab-ci.yml para corregir un error del pipeline, elimina por accidente un escáner de seguridad y nadie se da cuenta hasta que se produce un incidente.

Sin una gestión centralizada es imposible comprobar que todos los proyectos siguen la misma política de seguridad. El security team se ve obligado a revisar cada proyecto manualmente y a perseguir configuraciones, en lugar de centrarse en analizar vulnerabilidades reales.

Qué son los perfiles de configuración

Un perfil de configuración es un conjunto de reglas y triggers que determinan cómo y cuándo se ejecutan los escáneres de seguridad. En lugar de configurar a mano .gitlab-ci.yml en cada proyecto, creas el perfil una sola vez a nivel de grupo y lo aplicas a todos los proyectos con una única acción.

GitLab ofrece perfiles predefinidos para tres tipos de escáneres:

• SAST (Static Application Security Testing): busca vulnerabilidades en el código fuente de la aplicación
• Escaneo de dependencias: detecta vulnerabilidades en las bibliotecas y paquetes utilizados
• Detección de secretos: intercepta claves de API, contraseñas y tokens antes de que lleguen al repositorio

Cada perfil incluye ajustes verificados y recomendados que se ajustan a las mejores prácticas del sector. Esto significa que se puede activar un escaneo de seguridad completo en minutos, sin escribir una sola línea de YAML y sin conocer a fondo cada escáner.

Cómo funcionan los triggers de escaneo

El escaneo se ejecuta automáticamente en tres escenarios.

El primero, al crear una merge request. El escáner muestra solo las vulnerabilidades nuevas que ha introducido ese código, para que el desarrollador se centre precisamente en sus propios errores y no se distraiga con problemas antiguos que ya existían antes de su pull request.

El segundo escenario se da cuando los cambios se fusionan en la rama principal. En ese momento, el security team obtiene una visión completa del estado de seguridad de todo el código base y puede seguir el progreso de las mejoras.

El tercero: la detección de secretos funciona en tiempo real. Si un desarrollador intenta hacer push de una clave de API o una contraseña, el push se bloquea directamente a nivel de git antes de que el secreto llegue al repositorio y al historial de commits. Así se evitan situaciones en las que los secretos acaban en un historial público y obligan a una costosa rotación.

De cero a cobertura total en unos pocos clics

Para empezar, el security team accede a la sección Security inventory de su grupo, selecciona todos los proyectos (o solo algunos concretos) y aplica los perfiles por defecto desde el menú Bulk Actions.

GitLab muestra de inmediato el estado de la cobertura: una barra verde indica que el escáner está totalmente activo; una parcial, que no funcionan todos los triggers; y una gris, que el escáner aún no está configurado.

Los perfiles predefinidos empiezan a funcionar de inmediato. El primer escaneo se ejecutará con la siguiente merge request o el siguiente push a la rama principal.

Qué significa esto

Las organizaciones ya no tienen que elegir entre velocidad de desarrollo y seguridad. Los perfiles de configuración permiten escalar ambas a la vez: los equipos despliegan código nuevo más rápido, pero con la garantía de que todos los proyectos pasan el mismo conjunto de comprobaciones de seguridad críticas. Esto resulta especialmente importante en grandes organizaciones, donde el desarrollo avanza en paralelo en decenas o cientos de proyectos simultáneamente.