Escaneo en cada commit: qué ocurre entre el push y la corrección terminada

Qué ocurre de verdad en cada commit

La frase suena a una herramienta que radiografía toda la aplicación en cada push. Ningún escáner trabaja así, ni debería, porque un escaneo completo por commit tarda minutos y frena a los desarrolladores. Lo que ocurre en realidad es escalonado. El cambio en sí se comprueba de inmediato. Su efecto sobre el resto del código se evalúa en contexto. Y la base de código en su conjunto se recorre a su propio ritmo, para que también se encuentre lo que no nació en este commit.

Ese escalonamiento es la diferencia entre un escáner que los desarrolladores sufren y uno que dejan de notar al cabo de una semana. Nuestra página sobre seguridad del código nombra los tres niveles; aquí sigue lo que ocurre en cada uno.

Nivel uno: el control inmediato

Llega el push y en segundos las líneas cambiadas se comprueban en tres aspectos: contraseñas, claves y tokens escritos en el código; funciones y patrones inseguros conocidos; llamadas peligrosas como comandos del sistema sin comprobar. El resultado está antes de que el código siga adelante. Quien sube un secreto se entera mientras aún tiene el editor abierto, no en la próxima fecha de auditoría.

El control inmediato es deliberadamente estrecho. Conoce patrones, no intenciones. Lo que notifica aún no es un hallazgo, sino un candidato.

Nivel dos: la comprobación en contexto

Ahora el cambio ya no se mira aislado, sino en el contexto de la base de código. ¿La nueva llamada lleva de verdad a un punto donde las entradas llegan sin comprobar? ¿El control de acceso ausente está en un lugar alcanzable desde fuera o en un módulo auxiliar interno? Aquí se decide si un candidato es un riesgo real o no. La evaluación sigue el riesgo real, no la cantidad de resultados.

En este nivel ocurre lo que los escáneres no pueden hacer solos: una persona ve cada candidato antes de que se convierta en hallazgo y descarta lo que en el caso concreto no es explotable. El resultado es una prioridad clara en lugar de una lista interminable. Quien alguna vez ha recibido 400 avisos de los que 380 no significaban nada sabe por qué este paso es el más importante.

Nivel tres: el repaso completo

El tercer nivel no trabaja por commit, sino sobre toda la base de código, porque mucho de lo peligroso no nació en el commit actual. Todas las dependencias se contrastan con las vulnerabilidades conocidas. El historial del repositorio se recorre en busca de secretos antiguos, porque una clave subida hace dos años y borrada después sigue estando en el historial. Y la configuración se comprueba en busca de valores por defecto inseguros.

De este nivel salen los hallazgos que con más frecuencia encabezan el primer informe a las 48 horas: no el error de ayer, sino la biblioteca de hace dieciocho meses.

Por qué la corrección es la medida, no la alerta

Un informe lleno de hallazgos que nadie trabaja no es protección. Por eso el proceso no termina con una notificación. Para un hallazgo crítico, corregir significa: el secreto se rota, no solo se elimina del código, porque una clave publicada una vez sigue siendo válida hasta que se invalida. La biblioteca vulnerable se actualiza. El patrón peligroso se neutraliza. Y cada una de esas medidas se documenta con el hallazgo y la fecha.

Que un secreto rotado es la única corrección real lo describimos con detalle en nuestro artículo sobre secretos en el código. Para las dependencias rige el mismo principio: mientras la versión antigua siga en marcha, el hallazgo no está cerrado, por muchas veces que se haya notificado.

El camino hasta ahí

El día 0 se conectan los repositorios y el inventario se escanea por primera vez. A las 48 horas está el primer hallazgo, ordenado por lo que es real y crítico. En la primera semana se limpia. Después, los tres niveles actúan en cada commit. La puerta de entrada es el análisis de código gratuito, sin compromiso y en tu propio entorno si lo prefieres.

Preguntas frecuentes