¿Cuándo debe un hallazgo de seguridad romper la build y cómo gestionas los falsos positivos?
Respuesta breve
Rompe la build solo ante hallazgos de alta confianza, alta severidad y recién introducidos; avisa (sin bloquear) en todo lo demás para que los desarrolladores sigan confiando en el gate. Gestiona los falsos positivos con reglas afinadas, baselining de los problemas preexistentes y supresiones documentadas, acotadas en el tiempo y revisadas, en lugar de desactivar los escáneres. Un gate que avisa en falso acaba ignorándose o esquivándose, así que la calidad de la señal lo es todo.
Un security gate solo aporta valor si los desarrolladores lo respetan. Lo difícil de DevSecOps no es ejecutar escáneres, sino decidir qué debería detener de verdad un release.
Qué debe romper la build
Reserva un fallo duro para los hallazgos que sean simultáneamente:
- De alta severidad — explotables, con impacto real.
- De alta confianza — baja tasa de falsos positivos para esa regla.
- Recién introducidos — añadidos por este cambio, no heredados.
Todo lo demás debería avisar en lugar de bloquear: visible en el PR, registrado, pero sin detener el pipeline. Así la señal de "stop" del gate sigue siendo rara y significativa.
El problema de los falsos positivos
Este es el quid. Un escáner que bloquea builds por ruido entrena a los desarrolladores para desconfiar de él: aprobarán supresiones de forma automática, exigirán desactivarlo o lo rodearán. La calidad de la señal determina si la herramienta de seguridad sobrevive al contacto con un equipo real. El ruido se gestiona así:
- Afinando las reglas a la base de código y al lenguaje.
- Estableciendo un baseline de los problemas preexistentes cuando incorporas escaneo a un repositorio heredado, para que el primer día no sea un muro de rojo por código que nadie tocó; luego se previenen los nuevos y se reduce el backlog de forma deliberada.
- Supresiones auditables — cuando un hallazgo es realmente un falso positivo o un riesgo aceptado, registra una excepción documentada, revisada y acotada en el tiempo (con autor y justificación) en lugar de desactivar el control. El modo de fallo es el
// nosecsilencioso por todas partes.
El bucle de retroalimentación
Los hallazgos deben aparecer donde los desarrolladores ya trabajan — el pull request — con una guía de remediación clara. La retroalimentación rápida, precisa y en contexto es lo que hace que el shift left realmente cuaje.
Qué buscan los entrevistadores
Quieren el umbral de severidad + confianza + novedad, un reconocimiento honesto de la fatiga por falsos positivos y supresiones que sigan siendo auditables en lugar de convertirse en un interruptor de apagado silencioso.
Posibles preguntas de seguimiento
- ¿Por qué es importante el baselining al añadir escaneo a una base de código heredada?
- ¿Qué le pasa a la eficacia de un gate cuando tiene demasiados falsos positivos?
- ¿Cómo haces que una supresión sea auditable en lugar de un bypass silencioso?