Los registros públicos de paquetes (npm, PyPI, Maven Central, NuGet) funcionan con un modelo de confianza que crea una vulnerabilidad específica y poco valorada en la cadena de suministro: una vez que un paquete se consolida como legítimo y de uso generalizado, la confianza asociada a ese paquete se extiende a todas las versiones futuras que publique quien controle la cuenta de publicación en ese momento. Un paquete creado por un desarrollador de confianza en 2019, descargado millones de veces y validado por miles de desarrolladores a lo largo de años de uso puede convertirse en un vector de distribución de código malicioso en 2024 si la cuenta que publica las nuevas versiones se ve comprometida o se transfiere a un actor malicioso.
El mecanismo de toma de control de cuentas es la amenaza más directa. Las cuentas de los registros de paquetes pueden verse comprometidas mediante robo de credenciales, phishing o ingeniería social dirigida al mantenedor del paquete, exactamente igual que cualquier otra cuenta. El repositorio de GitHub del paquete event-stream, un paquete de npm muy utilizado, se vio comprometido mediante un ataque de ingeniería social en el que el desarrollador original, desbordado por la carga de mantenimiento, transfirió la titularidad a un actor malicioso que publicó una versión con una puerta trasera. La versión maliciosa se descargó 8 millones de veces antes de que se descubriera el ataque.
La vulnerabilidad de la sucesión de mantenedores es el riesgo con más matices. Los paquetes de código abierto suelen estar mantenidos por desarrolladores individuales que, con el tiempo, pueden dejar de estar disponibles, agotarse o estar dispuestos a transferir la responsabilidad del mantenimiento. Cuando un paquete se transfiere a un nuevo mantenedor, en especial a uno sin reputación consolidada en la comunidad de código abierto, la confianza ya establecida en el paquete la hereda alguien cuyo código no se ha sometido al mismo escrutinio que le valió al mantenedor original su reputación. Basta una sola actualización de versión publicada por un nuevo mantenedor para entregar código malicioso a todos los que confían en el paquete.
Por qué es importante
El modelo de confianza de los registros de paquetes es importante para TPRM porque los productos de software de sus proveedores se construyen sobre paquetes cuya fiabilidad no depende de su legitimidad pasada, sino de la seguridad actual de las cuentas de sus mantenedores. Un proveedor que no ha implementado controles contra la toma de control de cuentas, que no supervisa los cambios inesperados de mantenedor en sus dependencias y que no verifica la legitimidad de las actualizaciones de versión menor antes de incorporarlas está expuesto a un compromiso de la cadena de suministro a través de un vector que el análisis de vulnerabilidades de la SCA no aborda.
- Legitimidad del paquete aceptada como una propiedad estática: un mantenedor comprometido no es detectable mediante la CVE
- Seguridad de las cuentas de los mantenedores no evaluada en la revisión de paquetes del proveedor
- Cambios repentinos de mantenedor en las dependencias sin supervisar
- Actualizaciones de versión menor no sometidas a la misma revisión que las dependencias principales
- Riesgo de la cadena de suministro por toma de control de cuentas ausente del modelo de seguridad del proveedor
Cómo se ve una buena práctica
Los programas maduros de confianza en registros de paquetes implementan una supervisión continua de los cambios de mantenedor en las dependencias críticas, exigen autenticación multifactor en las cuentas de publicación de paquetes, fijan las dependencias en versiones específicas con verificación de hash y revisan los cambios de código de las actualizaciones de versión menor antes de incorporarlas a producción.
- Fijación de dependencias: especificación de la versión exacta y del hash que impide actualizaciones inesperadas
- Supervisión de cambios de mantenedor: alertas ante cambios de titularidad en paquetes críticos
- Requisito de MFA en las cuentas de publicación: protección de cuentas por parte del proveedor
- Revisión de las actualizaciones de versión menor: revisión de las diferencias de código antes de incorporar las actualizaciones
- Aplicación obligatoria de archivos de bloqueo: impide que la resolución de dependencias tome versiones inesperadas
Herramientas
Supervisión de registros: Socket.dev para detectar cambios de mantenedor; Snyk para supervisar las actualizaciones de dependencias
Socket.dev ofrece supervisión en tiempo real de las señales de riesgo de la cadena de suministro en los registros de paquetes, incluidos los cambios en las cuentas de los mantenedores, las nuevas cuentas de publicación y los cambios de código sospechosos en las actualizaciones de paquetes. Para los profesionales de TPRM, preguntar si los proveedores supervisan los cambios de mantenedor en sus dependencias críticas con herramientas como Socket.dev es una pregunta específica sobre la defensa contra la toma de control de cuentas.
Seguridad de la publicación de paquetes: autenticación de dos factores obligatoria en npm; requisito de TOTP para publicar en PyPI
Las protecciones de publicación de los registros de paquetes (requisitos de MFA, rotación de tokens de publicación y controles de acceso) reducen el riesgo de toma de control de cuentas. Para los profesionales de TPRM, preguntar si las cuentas de publicación de paquetes del proveedor usan MFA y tokens específicos de publicación en lugar de contraseñas de cuenta es una pregunta específica sobre la seguridad de las cuentas de los mantenedores.
Desafíos de gobernanza
El desafío de gobernanza de la confianza en los registros de paquetes es el problema del volumen de dependencias. Un proyecto de software moderno puede tener miles de dependencias transitivas, cada una con sus propias cuentas de mantenedor. La supervisión continua de los cambios de mantenedor en todas las dependencias solo es viable con herramientas automatizadas. La solución de gobernanza es una supervisión por niveles: supervisión exhaustiva de las dependencias directas y de las dependencias transitivas de mayor uso, y detección automatizada de anomalías para el resto del árbol de dependencias.
- Implemente la fijación de dependencias y la aplicación obligatoria de archivos de bloqueo
- Supervise los cambios de mantenedor en las dependencias directas críticas
- Exija MFA en todas las cuentas de publicación de paquetes: protección de cuentas por parte del proveedor
- Revise los cambios de código en las actualizaciones de versión menor de las dependencias críticas
- Incluya la seguridad de las cuentas de los mantenedores en la evaluación de la cadena de suministro de software de los proveedores
Si usted forma parte de un equipo pequeño
Active la aplicación obligatoria de archivos de bloqueo en sus aplicaciones de producción: npm ci en lugar de npm install, pip install con hashes en el archivo de requisitos, o el equivalente en el ecosistema de su lenguaje. Esto impide cambios inesperados de versión de los paquetes incluso si se compromete la cuenta de un mantenedor y se publica una nueva versión. Después, configure Socket.dev o una supervisión equivalente de sus dependencias directas para que le alerte cuando cambie la titularidad del mantenedor. Esos dos controles abordan los modos de falla más críticos de la confianza en los registros.
- Active la aplicación obligatoria de archivos de bloqueo en las aplicaciones de producción
- Configure la supervisión de cambios de mantenedor para las dependencias directas
- Exija MFA en todas las cuentas internas de publicación de paquetes
- Revise los cambios de código en las actualizaciones de versión menor de los paquetes críticos
Qué exigir
Pregunte directamente:
“¿Supervisan sus dependencias críticas en busca de cambios inesperados de mantenedor? ¿Sus cuentas de publicación de paquetes utilizan MFA y tokens específicos de publicación? ¿Y cómo verifican la integridad de las actualizaciones de versión menor antes de incorporarlas a su compilación?”
Evidencia que debe esperar
- Implementación de la supervisión de cambios de mantenedor
- MFA en las cuentas de publicación de paquetes
- Fijación de dependencias y aplicación obligatoria de archivos de bloqueo
- Proceso de revisión de las actualizaciones de versión menor
A un proveedor que confirma la gestión de dependencias se le debe preguntar por la seguridad de las cuentas de los mantenedores y la supervisión de cambios. La gestión de dependencias cubre qué versiones se utilizan. La seguridad de las cuentas de los mantenedores determina si esas versiones pueden verse comprometidas sin que se explote ninguna vulnerabilidad.
Cómo demostrarlo
- Registros de supervisión de cambios de mantenedor
- Aplicación obligatoria de MFA en las cuentas de publicación
- Implementación de la aplicación obligatoria de archivos de bloqueo
- Proceso de revisión de las actualizaciones de versión menor
Conclusión clave
Paquete: legítimo, bien revisado, 14,000 descargas semanales. Mantenedor: el desarrollador original transfirió la titularidad tras un ataque de ingeniería social. Nuevo mantenedor: publicó una corrección de errores con código de recolección de credenciales. Desarrollador de la empresa: instaló la nueva versión, revisó la README, revisó el número de descargas, revisó GitHub. No revisó el historial del mantenedor. No revisó las diferencias de código de la nueva versión. Paquete válido. Mantenedor comprometido. Actualización maliciosa. La aplicación obligatoria de archivos de bloqueo habría impedido la adopción automática de la nueva versión. La supervisión de cambios de mantenedor habría señalado la transferencia de titularidad. La MFA en la cuenta original habría impedido que la ingeniería social tuviera éxito. Tres controles para el mismo modelo de amenaza.