Packagist procesa cerca de 100 millones de instalaciones de paquetes por día entre unos 400.000 paquetes. Hasta ahora, un cambio de propietario, de URL del repositorio, de mantenedor o de release podía ocurrir sin una huella pública duradera para los equipos que dependen de ese código.
El transparency log proyectado registra eventos que afectan la cadena de dependencias PHP. Incluye ownership, URLs, mantenedores, releases, versiones eliminadas y cambios en los tags Git subyacentes. También contempla eventos de cuenta, como cambios de autenticación de dos factores y restablecimientos de contraseña.
El registro estará disponible mediante interfaz web y API. Los investigadores podrán reconstruir incidentes con evidencia histórica y las empresas podrán vigilar los paquetes que realmente instalan. PHP Foundation coordina el trabajo con financiación de Sovereign Tech Agency y sigue el nivel 3 de los principios de seguridad de repositorios de OpenSSF.
Sin suscriptor, el log es archivo muerto
El anuncio describe interfaz web y API. La implementación sigue por etapas: los eventos restantes y las interfaces públicas entran poco a poco. El valor para un equipo de producto no nace el día del post. Nace cuando alguien se suscribe al recorte que importa y responde a un evento.
Definan el recorte a partir de composer.lock, no de los 400 mil paquetes. Paquetes directos y transitivos que realmente instalan. Ownership, URL de source, mantenedor y tag git de esos nombres. La cuenta de un maintainer famoso que no usan puede quedar fuera. El volumen de ruido de un registro público es lo que mata la adopción de alerta.
Nombren un dueño. Seguridad, plataforma o el equipo que ya mira Dependabot. Sin dueño, el webhook cae en el canal abierto del equipo y vira wallpaper. Con dueño, el evento vira cola: triaje, ticket o silencio justificado.
Aparecerán herramientas de terceros. Trátenlas como cualquier otro sensor: el log público es la fuente, el vendor es el filtro. Si el filtro desaparece, aún necesitan consultar la API. No tercericen la única copia de la política.
El cambio de dueño y de URL merecen prioridad
Un release nuevo es el evento más común y el menos informativo por sí solo. Composer ya muestra el bump en el lockfile de la PR. Lo que añade el transparency log es lo que el lockfile no cuenta: el paquete cambió de dueño, el GitHub apuntado se movió, un maintainer salió, un tag fue reescrito, el 2FA de la cuenta que publica se apagó.
Esos eventos tienen mayor densidad de riesgo. El compromiso clásico de cadena toma la cuenta, apunta el source a un fork y publica una versión que el semver acepta. Si sus alertas tratan "nuevo tag 1.4.3" igual que "ownership transferido", el canal explota el primer día laboral y alguien silencia el resto.
Armen la política en dos capas. Capa A, despertar a alguien: transferencia de ownership, cambio de URL, baja de maintainer, alteración de un tag ya publicado, 2FA desactivado en la cuenta que publica. Capa B, registro para auditoría: releases y bajas de versión, para reconstruir la línea de tiempo después. La capa B puede ir a un índice. La capa A va al pager o al checklist de la PR.
Reset de contraseña y 2FA son eventos de cuenta, no de paquete. Correlacionen con los paquetes que esa cuenta controla. Sin ese cruce, la señal queda abstracta.
La alerta en el pipeline necesita filtrar el release rutinario
El lugar operativo natural es el CI que ya lee composer.lock. En una PR que actualiza una dependencia, consulten el log de ese paquete en el intervalo desde el último lock conocido. Si hay un evento de capa A, la PR no mezcla "bump de patch" con "el source cambió". El revisor ve el hecho junto al diff.
Fuera de la PR, un job diario sobre el lock de producción captura lo que nadie actualizó. Un paquete abandonado que cambia de dueño sin bump es el caso que el Dependabot clásico deja pasar. El log existe para ese silencio.
Calibren el volumen. Si el job emite decenas de líneas al día, la regla está demasiado ancha o el recorte incluye paquetes de dev que no van a producción. Separe require de require-dev. Producción primero.
Packagist avisa que la cobertura crece por incrementos. El job debe tolerar un evento aún no emitido, sin tratar la ausencia como "no pasó nada en el mundo". Un log incompleto es mejor que el silencio total; aun así, documenten qué ya está cubierto.
Pin y hash siguen siendo la defensa de instalación
Un registro público no impide que composer update baje el tarball. Pin de versión, composer.lock commiteado, composer audit y revisión de diff siguen siendo el control que obedece la máquina de build. El log alimenta la pregunta "¿debemos instalar esto ahora?" y la pregunta posterior "¿cuándo cambió de manos este paquete?".
La investigación de incidente gana historia. En vez de una captura de la página del paquete, el equipo puede pedir a la API los eventos entre dos fechas. Eso es lo que el nivel 3 de OpenSSF pide a los repositorios: capacidad de ver qué cambió. Npm y PyPI ya caminaron en esa dirección. PHP llega con financiación de Sovereign Tech Agency y coordinación de PHP Foundation. El siguiente bloque anunciado, ownership organizacional, ataca la cuenta compartida que hoy impide un 2FA real.
Nada de eso sustituye el hábito de no hacer update ciego en un paquete que autentica usuarios. El log vuelve el hábito verificable. Sin suscriptor, sin recorte y sin distinción entre bump y cambio de dueño, el registro público queda disponible para el investigador e invisible para el equipo que, en agregado, instala 100 millones de veces al día, y en este proyecto instala cero veces con alerta.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
