¿Por qué importan los lockfiles, el fijado y la confusión de dependencias en el build?
Respuesta breve
Los lockfiles fijan las versiones y hashes exactos de las dependencias para que cada build resuelva los mismos bytes verificados — haciendo los builds reproducibles y bloqueando actualizaciones maliciosas silenciosas. Fijar por digest, verificar los hashes de integridad y acotar los paquetes internos a un registro privado también defienden contra la confusión de dependencias, donde un atacante publica un paquete público de versión superior que coincide con un nombre interno para secuestrar la resolución. El principio: nunca dejar que el build descargue silenciosamente código no verificado.
Un build que descarga las dependencias de nuevo cada vez es solo tan confiable como lo que el registro de paquetes haya servido en ese minuto. Los lockfiles y el fijado quitan esa incertidumbre del build.
Lockfiles: builds reproducibles y verificados
Un lockfile (package-lock.json, yarn.lock, poetry.lock, go.sum) registra la versión exacta de cada dependencia — directa y transitiva — más un hash de integridad del contenido de cada paquete. Dos consecuencias importan para la seguridad:
- Reproducibilidad. Cada build, en cada máquina, resuelve el árbol de dependencias idéntico. Lo que probaste es lo que entregas.
- Detección de manipulación. Como el lockfile almacena hashes de contenido, si un registro sirve bytes diferentes para la misma versión (un paquete comprometido, un MITM), la comprobación del hash falla y el build se detiene. Fijar solo la versión no basta — el hash es lo que prueba que obtuviste el mismo código.
Confusión de dependencias
Este es el ataque que hace esencial el acotamiento. Si tu build resuelve nombres de paquetes contra un registro privado (para paquetes internos) y el público, un atacante puede publicar un paquete público con el mismo nombre que tu paquete interno pero un número de versión superior. La resolución ingenua prefiere la versión superior y descarga el código del atacante en tu build. Defensas: acotar los paquetes internos a un registro/espacio de nombres privado, configurar la resolución para que los nombres internos nunca caigan al público, y verificar los hashes de integridad.
La tensión con los parches
Fijar todo significa que dejas de recibir actualizaciones — incluidas las correcciones de seguridad. La respuesta no es dejar de fijar; es fijar más automatizar actualizaciones controladas (p. ej. Dependabot/Renovate) que suban las versiones mediante revisión y CI, para que obtengas los parches deliberadamente en vez de silenciosamente.
Lo que buscan los entrevistadores
Quieren el enfoque de reproducibilidad-más-integridad, una explicación correcta de la confusión de dependencias y el acotamiento de registros, y la madurez para conciliar el fijado con mantenerse parcheado mediante actualizaciones automatizadas y revisadas.
Posibles preguntas de seguimiento
- ¿Cómo secuestra realmente la resolución un ataque de confusión de dependencias?
- ¿Cuál es la tensión entre fijar versiones y obtener parches de seguridad?
- ¿Por qué importan los hashes de integridad de un lockfile aunque la versión esté fijada?