El modelo clásico consistía en construir durante meses y pasar una auditoría de seguridad al final. Fallaba por una razón estructural: cuando los hallazgos llegan, la fecha de salida ya está comprometida y arreglar un problema de diseño supone rehacer trabajo. Así que se documenta el riesgo, se acepta y se sale igual. La auditoría acaba siendo un trámite que genera papel y no seguridad.
La alternativa no es auditar más, es auditar continuamente y en automático. Pero eso tiene su propia trampa, y es la que hace fracasar la mayoría de las iniciativas: si cada comprobación bloquea el trabajo, el equipo aprende a saltárselas.
Qué automatizar y dónde
Secretos, antes de confirmar el código. Un análisis en el gancho de pre-commit evita que una credencial entre en el historial. Una vez está en el repositorio, ya no basta con borrarla: hay que rotarla, porque el historial es público para todo el que tenga acceso.
Dependencias, en cada cambio. Es de donde viene la mayor parte del riesgo real. No solo la comprobación automática de vulnerabilidades conocidas: también revisar qué se está añadiendo. Una biblioteca nueva con tres estrellas y un mantenedor es una decisión de seguridad, no solo técnica.
Infraestructura como código, antes de aplicar. Aquí es donde más se gana. Detectar un bucket abierto o un grupo de seguridad con acceso desde cualquier origen mientras es una línea en una propuesta de cambio cuesta un minuto; detectarlo en producción cuesta una notificación de brecha.
Imágenes de contenedor, al construirlas. Y una medida más eficaz que cualquier escáner: partir de imágenes mínimas. Lo que no está instalado no es vulnerable.
Qué bloquea y qué solo avisa
Este es el criterio que decide si la iniciativa sobrevive. Si todo bloquea, en dos semanas alguien pedirá una excepción, se concederá, y a partir de ahí las excepciones serán el procedimiento normal.
Nuestro criterio: bloquean los secretos expuestos, las vulnerabilidades críticas con exploit conocido y las configuraciones de infraestructura que abren acceso público no declarado. Todo lo demás informa, se registra y entra en el trabajo pendiente con una fecha. Sin fecha, «informar» es sinónimo de «ignorar».
Igual de importante: el mensaje de un bloqueo tiene que explicar qué se ha encontrado y cómo se arregla. Un fallo que solo dice que el análisis no ha pasado genera frustración y ninguna corrección.
Los secretos, fuera del código
Ningún secreto en el repositorio, ninguno en variables de entorno de imágenes, ninguno en un canal de chat. Un gestor de secretos con rotación automática, y donde sea posible, credenciales de corta duración emitidas en el momento en lugar de claves permanentes.
El indicador de si esto funciona es sencillo: si mañana hay que rotar una credencial que usan doce servicios, ¿cuánto se tarda? Si la respuesta se mide en días, el problema no es de herramientas sino de diseño.
Lo que ninguna herramienta arregla
Se puede comprar la mejor plataforma del mercado y seguir teniendo un problema de seguridad, porque la pieza que falta no se instala: es que el equipo pueda decir «esto no me parece seguro» sin que se lea como poner trabas.
En los equipos donde esto funciona, la seguridad se trata como cualquier otro requisito de calidad: se estima, se prioriza y se discute en la misma mesa que el resto. Cuando vive en un departamento aparte que llega al final con una lista de objeciones, el resultado es previsible.
¿Quieres revisar cómo está tu cadena de entrega? Hablemos →
Sigue leyendo
- Un pipeline de CI/CD en GitHub Actions listo para producción
- Cuatro métricas para saber si tu DevOps funciona de verdad
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.