Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Un paquete abandonado sigue estando disponible para su instalación a través de Packagist, a pesar de los CVE pendientes y todo lo demás, ya que la corrección de paquetes nunca ha sido tarea de Packagist.
- SecureChain recompila y revisa los paquetes PHP antes de su instalación, y luego sigue aplicandoles parches a medida que el mantenimiento del desarrollador original se ralentiza y se detiene.
- Puedes hacer que toda tu configuración de Composer pase por SecureChain, o enviar solo los paquetes que lo necesiten.
- Private Packagist aloja y replica tus paquetes, mientras que SecureChain aplica parches a aquellos que ya nadie mantiene.
Un paquete de Composer abandonado con un CVE abierto te pone en una situación incómoda. Probablemente no vaya a llegar ninguna corrección del desarrollador original, y tus opciones son crear una bifurcación por tu cuenta, sustituirlo o documentar un control compensatorio y esperar que el auditor lo acepte. Una alternativa a Packagist basada en aplicar parches que cumplen con los requisitos. SecureChain recompila y revisa los paquetes de PHP antes de que lleguen a tu entorno de compilación, y luego sigue proporcionando correcciones bajo un acuerdo de nivel de servicio (SLA) mucho después de que el mantenedor original haya dejado de dar señales de vida, ya sea en sustitución de Packagist o de forma complementaria.
A continuación te explicamos qué incluye realmente esa cobertura y cómo encaja con el flujo de trabajo de Composer que ya utilizas.
Por qué los equipos buscan una alternativa a Packagist
Packagist hace lo para lo que fue creado. Indexa los repositorios de paquetes e indica a Composer de dónde debe obtener el código, y esa parte la hace bien. Lo que nunca se diseñó para hacer es solucionar ningún problema. Cuando un responsable deja de publicar actualizaciones, Composer sigue resolviendo sin problemas una versión vulnerable existente a través de los metadatos de Packagist, los CVE y todo lo demás.
Este panorama sí que ha cambiado este año. Composer 2.10, lanzado a finales de mayo, bloquea las versiones marcadas como malware durante la resolución y, de nuevo, durante la instalación a partir de un archivo de bloqueo existente, y agrupa los avisos, los paquetes abandonados y el malware en una única política de dependencias. Packagist siguió sus pasos en julio al hacer inmutables las versiones estables publicadas, de modo que una versión reetiquetada ya no puede sustituir silenciosamente lo que ya has bloqueado. Ambos cambios suponen mejoras reales, y ninguno de ellos genera un parche. Bloquear una versión defectuosa sigue dejándote con un paquete abandonado con un CVE abierto y sin nadie en la cadena de desarrollo que lo solucione.
Ese suele ser el momento en el que un equipo empieza a buscar una alternativa a Packagist en lugar de una solución provisional puntual. La distinción es importante. Una solución provisional resuelve un único problema detectado en una auditoría. Una alternativa basada en la aplicación de parches parte de la base de que esto seguirá ocurriendo, y no solo con el paquete abandonado que tienes ahora mismo sobre la mesa. Para saber más sobre por qué las dependencias de Composer nunca tienen una fecha de fin de vida útil como la tiene PHP, consulta el artículo «Tus dependencias de Composer no se retiran solo porque PHP lo haya hecho», que profundiza en lo que eso significa para los paquetes que siguen ejecutándose en tu aplicación.
PHP tampoco es una excepción en este sentido. Los incidentes en la cadena de suministro que se produjeron en varios ecosistemas de código abierto en 2026 han dado a los equipos motivos para replantearse la confianza en los registros, y esta tendencia no se ha limitado a un solo lenguaje.
Cómo SecureChain sigue aplicando parches tras la retirada de Upstream
SecureChain aborda esto como un problema del ciclo de vida, en lugar de una solución puntual. Cada paquete PHP que ofrece se recompila desde el código fuente en un entorno aislado antes de que esté disponible para su instalación, por lo que lo que se incluye en tu compilación se verifica de principio a fin, en lugar de tomarse directamente de un artefacto de origen que nadie ha recompilado ni comprobado. Los paquetes también se analizan en busca de malware conocido y patrones de código sospechosos, y cualquier elemento que no supere la inspección se bloquea antes de que te llegue, en lugar de señalarse a posteriori.
El trabajo no se detiene una vez que un paquete supera esa primera comprobación. Mientras el desarrollador original siga lanzando versiones, los componentes activos se supervisan y se actualizan conforme al SLA a medida que surgen nuevas vulnerabilidades (CVE), tal y como cabría esperar de un mantenedor que sigue prestando atención. Una vez que el desarrollador original deja de estar activo, TuxCare se encarga directamente del mantenimiento del paquete y, aproximadamente seis meses después de la última versión del desarrollador original, el servicio «Endless Lifecycle Support» toma el relevo y sigue proporcionando correcciones mientras se siga utilizando el paquete, independientemente de si el mantenedor original vuelve o no.
Esa brecha, entre detectar un problema y solucionarlo realmente, es donde muchas herramientas de la cadena de suministro se quedan cortas. Para los equipos que necesitan demostrar su trabajo, SecureChain también genera un historial de procedencia SLSA de nivel 3, una SBOM y datos VEX, de modo que hay un registro que respalda la afirmación de que «esto se ha corregido», en lugar de una simple afirmación que hay que aceptar sin más.
Cómo se integra SecureChain con Packagist
Nada de esto implica tener que cambiar la forma en que tu equipo ya trabaja con Composer. SecureChain es un repositorio compatible con Composer al que puedes dirigir el tráfico en lugar de al Packagist público o junto a él, y tú decides qué parte de tu tráfico pasa por él.
Algunos equipos canalizan toda su configuración de Composer a través de SecureChain, de modo que todo lo que descargan se vuelve a compilar y se somete a un filtro antes de la instalación, en lugar de limitarse únicamente a los paquetes abandonados. Otros adoptan un enfoque más restrictivo y envían solo los paquetes que saben que están abandonados o son de alto riesgo, mientras que el resto se obtiene de Packagist exactamente igual que hasta ahora. Cualquier elemento que no figure ya en el catálogo puede añadirse previa solicitud. En cualquier caso, los desarrolladores siguen ejecutando el mismo composer install y composer update comandos que ya conocen y, una vez configurado el repositorio, el flujo de trabajo diario sigue siendo el mismo.
Lo que cambia es lo que ocurre detrás de esos comandos para todo lo que se canaliza a través de SecureChain. En lugar de que Composer descargue desde dondequiera que apunte la metadatos de Packagist —un repositorio de origen o un archivo de distribución —, lo obtiene de un repositorio en el que el paquete ya ha sido recompilado, revisado y parcheado. Tu archivo de bloqueo sigue registrando las versiones y las referencias que Composer ha resuelto. La diferencia radica en su procedencia: un paquete recompilado y mantenido que se sirve desde el repositorio de TuxCare, en lugar de lo que te habría proporcionado la ruta habitual del desarrollador original.
Cómo integrar SecureChain en tu pila de Composer
Si en tu última auditoría se detectaron dos o tres paquetes abandonados con avisos pendientes, ese es un punto de partida concreto y bien delimitado, no una razón para rediseñar por completo tu configuración de dependencias. Si la lista de paquetes abandonados es más extensa, la primera pregunta más útil es cuáles de esos paquetes pueden parchearse de forma realista, ya que eso determina qué parte de tu configuración de Composer tiene sentido canalizar a través de SecureChain desde el primer día.
SecureChain no es un sustituto de Private Packagist, y conviene no confundir ambos. Private Packagist, de Packagist Conductors —la empresa responsable de Composer y Packagist.org—, se encarga del alojamiento privado de paquetes, la creación de réplicas y los controles de distribución, y ha incorporado una gran cantidad de herramientas propias de seguridad para la cadena de suministro durante el último año. Lo que no hace es aplicar correcciones retroactivamente a una dependencia cuyo responsable dejó de responder hace años. Un equipo cuya principal necesidad sea el alojamiento privado encontrará allí una mejor solución, y utilizar ambos es una opción perfectamente razonable, ya que ninguno de los dos realiza la función del otro.
Si los paquetes de PHP son el ámbito en el que te falta cobertura, echa un vistazo a SecureChain para PHP para ver cómo funciona con más detalle, o solicita un presupuesto para que te expliquemos qué cubriría en tu entorno específico.
PREGUNTAS FRECUENTES
¿Qué es una alternativa a Packagist?
Una alternativa a Packagist es un repositorio compatible con Composer que se utiliza en lugar del Packagist público, o junto a él. Los equipos recurren a uno de ellos cuando necesitan algo que el Packagist público no ofrece, como un alojamiento privado, una distribución controlada, controles de seguridad más estrictos o la aplicación continua de parches para paquetes que ya nadie mantiene.
¿Qué es lo que corrige realmente SecureChain?
SecureChain corrige las vulnerabilidades a lo largo de todo el ciclo de vida de un paquete PHP. Los paquetes activos se actualizan en virtud del SLA; TuxCare se encarga de su mantenimiento directamente una vez que cesa la actividad del desarrollador original, y el servicio «Endless Lifecycle Support» ofrece cobertura a largo plazo a partir de ese momento, mientras se siga utilizando el paquete.
¿Tengo que sustituir Packagist por completo para utilizar SecureChain?
No. Puedes redirigir todo tu entorno de Composer a través de SecureChain, o bien redirigir paquetes concretos, mientras que el resto sigue resolviéndose desde Packagist como de costumbre.
¿Esto sustituye a Private Packagist?
No, resuelven problemas distintos. Private Packagist ofrece alojamiento privado de paquetes, creación de réplicas y controles de distribución, mientras que SecureChain aplica parches a los paquetes cuyo mantenedor original ha dejado de corregir vulnerabilidades.
¿Tendrán los desarrolladores que cambiar la forma en que utilizan Composer?
No. Una vez configurado el repositorio, los comandos y los flujos de trabajo de Composer siguen siendo los mismos. Lo que cambia es lo que hay detrás de los paquetes que se instalan.
