La ampliación de Dependabot más allá de npm, construida sobre datos públicos de OpenSSF, abre una edición que también cubre cuatro versiones candidatas de pnpm 12, la llegada de un motor JavaScript experimental a Deno, el salto de reglas de Ruff y una corrección de seguridad sin detalles públicos en Cloudflare Workers.
La expansión, construida sobre el repositorio público de OpenSSF que documenta paquetes maliciosos desde 2023, lleva las alertas de Dependabot más allá de npm hacia PyPI, Maven, RubyGems, NuGet, Go, crates.io y Composer.
GitHub explicó, en una entrada de su blog de seguridad citada por Help Net Security el 10 de agosto de 2026, que el Advisory Database ahora incorpora los reportes de paquetes maliciosos del repositorio malicious-packages de OpenSSF, un feed público en formato OSV que arrancó en 2023 y que, según la propia entrada de GitHub, acumula más de 15.000 reportes. Con esa integración, las alertas de malware y los avisos de Dependabot que dependen de ellas pasan a cubrir ocho ecosistemas de paquetes —npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io y PHP Composer—, frente a la cobertura anterior, limitada solo a npm desde marzo de 2026. La función sigue siendo opcional: cada organización, repositorio o cuenta empresarial debe activarla desde su configuración de seguridad, según documenta el registro de cambios de GitHub del 28 de julio que introdujo la funcionalidad de base. Que el feed de OpenSSF exista desde 2023 con miles de reportes acumulados matiza el alcance real del anuncio: gran parte del valor no es una capacidad de detección nueva, sino la integración de datos públicos que ya circulaban fuera de GitHub y que ningún proyecto fuera de npm podía consultar automáticamente desde dentro de su flujo de Dependabot. La ampliación llega, además, apenas días después de que esta sección documentara la campaña de malware Flooding Dropper, que Sonatype vinculó a 846 paquetes de npm, y la propagación previa del gusano ChainDrop —dos incidentes ocurridos en el único ecosistema que ya tenía cobertura de malware desde marzo, lo que deja abierta la pregunta de cuánto reduce el riesgo real una alerta que sigue dependiendo de que cada organización la active por su cuenta. GitHub no precisó, en las fuentes consultadas para esta nota, qué porcentaje de repositorios activos ya activó las alertas de malware desde que llegaron a npm en marzo. Costa Rica no publica cifras propias de adopción de esta función, pero empresas de zonas francas tecnológicas que trabajan con Python, Java, .NET o PHP —los ecosistemas que hoy suman cobertura— deberían revisar la configuración de seguridad de sus repositorios y activar las alertas de malware de forma explícita, en lugar de asumir que la ampliación las protege automáticamente.
El repositorio de pnpm en GitHub publicó, entre el 5 y el 9 de agosto de 2026, cuatro versiones candidatas de la rama 12 más la versión estable 11.21.0, según las notas de lanzamiento del propio proyecto. La primera candidata (RC0, 5 de agosto) hace que comandos como pnpm setup, pnpm self-update o cualquier operación que modifique la instalación global fallen con el error ERR_PNPM_SUDO_NOT_SUPPORTED al ejecutarse con sudo, en lugar de operar en silencio sobre el directorio del usuario root en vez del que invocó el comando. La segunda (RC1, 7 de agosto) cambia cómo se resuelven las dependencias de Git alojadas en GitHub, GitLab o Bitbucket: pnpm ahora las trata como una identidad y no como una elección de transporte, resolviéndolas siempre a través de la URL HTTPS canónica del repositorio, de modo que el archivo de bloqueo (lockfile) nunca guarda una URL SSH para ellas —"esto elimina el sondeo de red que antes decidía entre HTTPS y SSH en el momento de la resolución, lo que podía registrar un transporte que solo funcionaba en la máquina que hizo esa resolución", según las propias notas de lanzamiento. La tercera candidata (RC2, 9 de agosto) suma el ajuste globalShims, que permite que un ejecutable instalado de forma global —Node.js, Deno o Bun, por defecto— siga la versión que exige cada proyecto en lugar de una versión fija del sistema; la cuarta (RC3, el mismo día) corrige un error de esa función en sistemas POSIX. La versión estable 11.21.0 retomó, sin esperar a la 12, la selección interactiva de grupos en pnpm update --global --interactive y la advertencia al usar sudo. El cambio de sudo cierra una categoría de error conocida —comandos que, sin avisar, escribían en el directorio del usuario equivocado—, y el ajuste de dependencias de Git resuelve una falla de integración continua real: una resolución SSH que funcionaba en la máquina de un desarrollador pero rompía corredores de CI sin llaves configuradas. Pero ambos cambios son también, en la práctica, rupturas de compatibilidad: cualquier flujo de integración continua que hoy ejecute pnpm dentro de un contenedor Docker como usuario root —una configuración común— empezará a fallar en la versión 12 si sigue invocando pnpm con sudo, y cualquier proyecto con dependencias privadas de Git que dependa de una URL SSH específica debe confirmar que esa resolución sigue funcionando bajo el nuevo esquema de identidad. pnpm 12 sigue en fase de candidato de lanzamiento al cierre de esta edición, sin fecha pública de versión estable en las notas consultadas. La información de esta nota proviene únicamente de las notas de lanzamiento oficiales de pnpm en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de pnpm, pero el gestor de paquetes es común en monorepos de equipos de plataforma de zonas francas tecnológicas del país, que deberían auditar sus flujos de integración continua en busca de comandos sudo pnpm y confirmar el acceso a sus dependencias privadas de Git antes de adoptar la versión 12.
cat /feed/herramientasdevdeno.md
La versión, publicada el 6 de agosto, añade una bandera --unscoped para renombrar paquetes, un modo --members para tareas de workspace y soporte experimental para QuickJS como alternativa a V8.
> > deno --version
> El proyecto Deno publicó el 6 de agosto de 2026 la versión 2.9.5 del runtime, con más de 60 cambios según su propio registro de lanzamientos en GitHub. Entre las novedades: la bandera --unscoped, que permite referirse a un paquete con alcance (scope) mediante un alias sin ese prefijo; la bandera --members, para ejecutar tareas en varios miembros de un workspace a la vez; la incorporación de textStream() a las interfaces Blob y Body; y, como cambio de mayor calado, soporte experimental inicial para un backend basado en QuickJS como alternativa al motor V8 que impulsa Deno desde su creación. La misma versión suma decenas de correcciones de compatibilidad con Node.js en streams, TLS, HTTP/2, DNS y sistema de archivos.
> > deno --why
> La identidad de Deno como runtime se apoyó siempre en un solo motor, V8, integrado de forma estrecha con el resto del sistema. Sumar un backend experimental basado en QuickJS —un motor mucho más liviano, pensado para entornos con recursos limitados— abre la puerta a casos de uso como incrustar Deno en dispositivos o procesos con memoria restringida, pero también introduce el riesgo de que el comportamiento de una aplicación varíe según el motor activo, algo que el propio proyecto reconoce al marcar la función como experimental y no apta para producción.
> > deno --next
> El registro de lanzamientos consultado para esta nota no fija una fecha de estabilización para el backend de QuickJS. La información de esta nota proviene únicamente de las notas de lanzamiento oficiales de Deno en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Deno, que sigue siendo marginal frente a Node.js entre los equipos de backend de zonas francas tecnológicas del país; los equipos que sí lo usan pueden probar --unscoped y --members sin riesgo, pero deberían tratar el backend de QuickJS como una función de laboratorio, no de despliegue.
Astral, la empresa detrás de las herramientas de Python escritas en Rust, publicó cuatro versiones de uv entre el 28 de julio y el 7 de agosto de 2026 (0.12.0, 0.12.1, 0.12.2 y 0.12.3) y tres de Ruff entre el 23 de julio y el 7 de agosto (0.16.0, 0.16.1 y 0.16.2), según las notas de lanzamiento de ambos proyectos en GitHub. El cambio más visible llegó con Ruff 0.16.0, el 23 de julio: la cantidad de reglas de lint activas por defecto subió de 59 a 413, según el propio registro de cambios, además de sumar formateo de bloques de código Python dentro de archivos Markdown. En uv, la versión 0.12.2, del 5 de agosto, sumó soporte para el candidato de lanzamiento Python 3.15.0rc1 y para la versión de mantenimiento 3.14.7, además de un nuevo comando uv tool audit para revisar herramientas instaladas; la 0.12.3, del 7 de agosto, agregó CPython 3.13.15 y mejoras de rendimiento en el descubrimiento de entornos de trabajo en Linux, según las notas de esa versión. Un salto de 59 a 413 reglas activas por defecto no es un ajuste menor: cualquier proyecto que actualice Ruff sin fijar su configuración de reglas puede ver decenas de advertencias nuevas de golpe en su integración continua, un tipo de cambio disruptivo que rara vez se comunica con el mismo relieve que una función nueva. uv, por su parte, sigue de cerca el calendario de versiones candidatas de Python —una práctica que acorta el tiempo entre el lanzamiento oficial de una versión y su disponibilidad práctica para instalar, pero que también expone a quien la use a probar contra un intérprete todavía no estable. La información de esta nota proviene únicamente de las notas de lanzamiento oficiales de uv y Ruff en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Python sigue siendo uno de los lenguajes más usados en equipos de datos y fintech de zonas francas tecnológicas costarricenses, que deberían fijar la versión de Ruff en su configuración de integración continua antes de actualizar a la rama 0.16.x sin revisar antes las reglas nuevas, y reservar cualquier prueba contra Python 3.15.0rc1 para entornos de desarrollo, no de producción.
Cloudflare publicó el 8 de agosto de 2026 la versión 1.20260808.1 de workerd, el runtime de código abierto que sostiene Cloudflare Workers, según el propio registro de cambios del proyecto en GitHub. El cambio principal marca ctx.abort() —el método que permite terminar de forma forzada un Worker sin estado (stateless)— como función estable, dejando atrás su condición experimental. La misma versión incluye, según las notas de lanzamiento, "relanzar la corrección y la prueba de regresión para vuln-187", sin que el proyecto detalle públicamente en qué consistía esa falla ni su severidad. workerd publica versiones con numeración de fecha casi a diario —el historial del proyecto muestra al menos una versión entre el 2 y el 10 de agosto de 2026 cada día—, un ritmo que refleja qué tan activo está el desarrollo del motor, pero que también deja a los desarrolladores externos con registros de cambios mínimos para tomar decisiones de seguridad: la referencia a "vuln-187" no incluye identificador CVE, puntuación de severidad ni explicación técnica, a diferencia de las asesorías que GitHub publica para dependencias de terceros en su Advisory Database. Esa es la cara menos visible de un producto que ejecuta código de miles de aplicaciones de borde (edge) todos los días. Cloudflare no respondió, en las fuentes consultadas para esta nota, si planea documentar vuln-187 con más detalle en una entrada de blog de seguridad separada. La información de esta nota proviene únicamente del registro de lanzamientos de workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de uso de Cloudflare Workers, pero la plataforma es una opción común para funciones de borde entre equipos que ya usan Cloudflare como red de entrega de contenido, a los que conviene revisar el registro de cambios de workerd antes de asumir que una corrección de seguridad sin CVE público no aplica a su despliegue.
— La versión 1.20260808.1 de workerd, el motor de código abierto de Cloudflare Workers, retira la etiqueta experimental de ctx.abort() y suma, sin más detalle público, la corrección de una falla identificada como vuln-187.
Entre la ampliación de la detección de malware a ocho ecosistemas y una ronda de versiones candidatas en pnpm, esta edición documenta cinco desarrollos recientes en el ecosistema de programación.
Esta edición documentó cinco desarrollos entre el 23 de julio y el 10 de agosto de 2026: la ampliación de la detección de malware de Dependabot, en GitHub Advisory Database, de npm a ocho ecosistemas de paquetes mediante datos públicos de OpenSSF; cuatro versiones candidatas de pnpm 12 —más la estable 11.21.0— que bloquean instalaciones globales con sudo y cambian la resolución de dependencias de Git; la versión 2.9.5 de Deno, con un backend experimental basado en QuickJS como alternativa a V8; el salto de 59 a 413 reglas de lint activas por defecto en Ruff 0.16, junto con el soporte de uv para el candidato de lanzamiento de Python 3.15; y una corrección de seguridad sin detalles públicos en workerd, el motor de Cloudflare Workers. El hilo que atraviesa esta sección desde finales de julio —la seguridad de la cadena de suministro de software, abierta con el gusano ChainDrop y la campaña Flooding Dropper en npm— sigue vivo hoy, pero cambia de forma: en lugar de otro ataque activo, la jornada trajo la respuesta institucional de GitHub, que amplía su cobertura de detección justo cuando ambos incidentes recientes ocurrieron en el único ecosistema que ya tenía esa protección desde marzo. El resto de la edición documenta el ritmo ordinario de la ingeniería de herramientas —pnpm, Deno, Ruff, uv, workerd—, que rara vez hace titulares grandes pero define, versión a versión, cómo se instalan dependencias y se ejecuta código en producción. Para equipos de desarrollo en Costa Rica, la lista de esta semana suma tareas nuevas: activar de forma explícita las alertas de malware de Dependabot en repositorios que usen Python, Java, .NET o PHP; auditar los flujos de integración continua en busca de comandos sudo pnpm antes de adoptar la versión 12; fijar la versión de Ruff en la configuración de integración continua antes de actualizar a la rama 0.16.x; y revisar el registro de cambios de workerd antes de asumir que una corrección de seguridad sin CVE público no aplica a un despliegue en Cloudflare Workers.