npm evoluciona las configuraciones de publicación de confianza, mientras GitHub añade una condición de fusión vinculada a los secretos expuestos. Estos dos anuncios no constituyen un bloqueo único: hay que examinar por separado los permisos de fusión, las identidades de publicación y la aprobación de difusión.
Dos anuncios, dos puntos de decisión
El 3 de septiembre de 2026, npm anunció la disponibilidad general de varias configuraciones de publicación de confianza por paquete. Son independientes y aditivas: coincidir con una puede ser suficiente, sin un orden de evaluación garantizado. La puesta en espera se propone por defecto; la publicación directa es una opción propia de cada configuración. La aprobación de un paquete en espera es posible después de que finalice el análisis de software malicioso. Este análisis ya existía. [anuncio de npm]
El 9 de septiembre, GitHub presentó en vista previa pública una regla para clientes de GitHub Secret Protection o GitHub Advanced Security: antes de la fusión, el análisis del último commit de la pull request debe haber terminado y no debe permanecer abierta ninguna alerta pertinente introducida por los commits de la pull request. Las categorías detectadas se pueden configurar y los permisos para eludir la regla deben examinarse. Esta regla completa la protección al enviar el código, sin sustituirla. [anuncio de GitHub]
Describir cada permiso antes de la cadena de entrega
CI/CD designa la integración y la entrega continuas: la cadena que construye, controla y distribuye software. Una pull request es una propuesta de modificación; un workflow es un conjunto de etapas automatizadas. OIDC, OpenID Connect, permite aquí identificar el workflow mediante un token de corta duración. Esta identidad no describe por sí sola todas las autorizaciones del equipo.
La revisión propuesta por Partitech comienza por las rutas posibles: repositorio, workflow, entorno, responsable y posibilidad de publicación directa. Una configuración adicional debe tener un propietario y una justificación. Conserve también las cuentas y los mecanismos que pueden eludir la ruta nominal, en lugar de limitar el inventario al archivo de automatización más visible.
| Ruta o acción | Identidad / repositorio / workflow | Entorno y criterios | Publicación directa o excepción | Propietario y prueba |
|---|---|---|---|---|
| Fusión de GitHub | Por inventariar | Por recopilar | Excepción por examinar | Por designar / adjuntar |
| Configuración stable | Por inventariar | Por recopilar | Por verificar | Por designar / adjuntar |
| Configuración prepublication | Por inventariar | Por recopilar | Por verificar | Por designar / adjuntar |
| Aprobación del paquete en espera | Por inventariar | Por recopilar | Por documentar | Por designar / adjuntar |
Un modelo O entre configuraciones, no una doble validación
En este ejemplo ficticio, A designa la configuración del workflow stable y B la de prepublication. La tabla ilustra únicamente la coincidencia del token OIDC con las configuraciones. No sustituye los demás controles y no significa que el paquete se haga público de inmediato.
| Configuración A satisfecha | Configuración B satisfecha | Ruta OIDC correspondiente |
|---|---|---|
| No | No | No |
| Sí | No | Sí |
| No | Sí | Sí |
| Sí | Sí | Sí |
La aprobación humana del paquete puesto en espera es una etapa distinta: no es el segundo término de esta condición O. Durante la revisión, pregunte para cada ruta qué pruebas se conservan, quién puede modificar sus criterios y qué decisión justifica una posible publicación directa.
Vincular las pruebas sin confundir los controles
Una alerta cerrada no acredita la revocación de un secreto. Según el proveedor afectado, documente la revocación o la rotación, compruebe los usos afectados y conserve la decisión de tratamiento. La ausencia de alerta solo significa que no hay ninguna alerta pertinente abierta dentro del perímetro controlado; no demuestra una detección exhaustiva.
El diseño propuesto separa la revisión de modificación, el análisis de secretos, las pruebas de aplicación, la identidad npm, la puesta en espera y la aprobación. Cada etapa conserva su propietario y su prueba. No se presupone ningún encadenamiento atómico entre fusión y publicación. El principio de confianza explícita se relaciona con nuestro artículo sobre las escrituras de agentes y su entorno aislado, pero los permisos estudiados aquí son los de la entrega GitHub/npm.
Para un piloto autorizado y aislado, prepare identidades ficticias y un paquete de demostración: ninguna configuración coincidente, una coincidencia, varias coincidencias, análisis aún en curso y excepción de fusión. Defina lo que debería aceptarse o rechazarse en cada etapa y, después, recopile los resultados realmente obtenidos. Ninguno de estos escenarios se ha ejecutado para este artículo; no se necesita ningún secreto real ni paquete de producción para la preparación documental.
El entregable de la revisión es la matriz de rutas, acompañada de los propietarios, las excepciones y las pruebas que faltan. Vuelva a examinarla después de cada cambio de workflow. La vista previa de GitHub, los límites de detección y las autorizaciones residuales siguen siendo puntos que vigilar; el número de controles no mide por sí solo la seguridad de la entrega.