Amazon Threat Intelligence liga con confianza media cuatro compromisos de paquetes npm a un grupo vinculado a Pyongyang, GitHub lleva las pull requests apiladas a vista previa pública, estrena una sintaxis propia para referenciar acciones dentro de un mismo repositorio, y actualiza Copilot tanto en Visual Studio como en su CLI.
Amazon Threat Intelligence liga con confianza media cuatro compromisos de paquetes npm —incluido el de axios, ya atribuido antes— a un mismo grupo vinculado a Pyongyang.
Amazon Threat Intelligence documentó, en una entrada de su blog de seguridad publicada el 30 de julio de 2026, que atribuye con «confianza media» los compromisos de los paquetes npm debug y chalk —ocurridos en septiembre de 2025— y de un paquete identificado como typo-crypto —comprometido en marzo de 2025— a un mismo actor vinculado a Corea del Norte, rastreado por la industria bajo los nombres Sapphire Sleet, Stardust Chollima, BlueNoroff, CageyChameleon y Alluring Pisces, según el propio comunicado de la compañía. El mismo patrón operativo, sostiene Amazon, reapareció en marzo de 2026 en el compromiso de axios, la librería de JavaScript con más de 100 millones de descargas semanales, un caso que ya había sido atribuido públicamente a ese grupo. La diferencia de certeza importa: Microsoft había atribuido con «alta confianza» el compromiso de Mastra AI, otro ataque de la misma familia documentado en su propio blog de seguridad en junio, mientras que Amazon califica de confianza media sus vínculos con los casos de debug, chalk y typo-crypto y es, según constató The Register, la única fuente pública de esas tres atribuciones —ningún otro investigador las había conectado antes con este grupo—. El método de ataque, en los cuatro casos, fue el mismo: los atacantes ingeniaron socialmente a un mantenedor de confianza del paquete y luego publicaron una actualización con código malicioso, de acuerdo con Amazon. Amazon no ha publicado evidencia técnica completa que permita a terceros verificar de forma independiente los tres vínculos de menor confianza, y The Register señaló que la atribución de axios se hizo dentro de los dos días posteriores al hallazgo, mientras que los otros dos casos se atestiguaron entre diez y dieciséis meses después de ocurridos. Costa Rica no publica cifras propias de cuántas aplicaciones locales dependen de debug, chalk o axios, pero los tres paquetes son dependencias transitivas casi universales en proyectos de Node.js; los equipos ticos que auditen su cadena de suministro deberían revisar si alguna de esas librerías se instaló durante las ventanas de compromiso que documenta Amazon, más allá de si la atribución a Corea del Norte se confirma con el tiempo.
GitHub anunció el 30 de julio de 2026, en su registro de cambios, la vista previa pública de las pull requests apiladas: una serie ordenada de solicitudes de extracción donde cada una representa una capa enfocada de un cambio más grande, revisable de forma independiente y fusionable en una sola operación, según el propio anuncio de la compañía. La función construye una cadena de ramas —la rama A apunta a main, la B apunta a A, la C apunta a B— y cada eslabón puede aprobarse y verificarse por separado antes de fusionar el conjunto completo con un solo clic. La vista previa está disponible para cualquier repositorio sin necesidad de aprobación ni de un plan empresarial: basta instalar una extensión de la CLI de GitHub, según describió la cobertura de ITBrief Asia. La función busca resolver un problema habitual de flujo de trabajo: pull requests únicas y extensas que tardan en revisarse, o cambios repartidos en varias ramas que el propio equipo debe reordenar (rebase) a mano cada vez que la rama base avanza; GitHub sostiene que la nueva opción se integra al flujo de revisión existente, con las mismas reglas de verificación y fusión ya configuradas. GitHub no ha anunciado, al cierre de esta edición, una fecha para la disponibilidad general de la función más allá de la vista previa pública. Costa Rica no publica cifras propias de adopción de GitHub, pero la plataforma es la opción dominante de control de versiones entre agencias y empresas de desarrollo locales; los equipos que ya dividan cambios grandes en varias ramas manuales pueden probar hoy mismo la extensión de CLI sin esperar autorización adicional.
GitHub publicó el 30 de julio de 2026, en su registro de cambios, una nueva sintaxis para que un flujo de trabajo de Actions haga referencia a una acción o a otro flujo de trabajo reutilizable que vive en el mismo repositorio, según el propio anuncio de la compañía. Un valor de uses: que empieza con $/ se resuelve automáticamente al propio repositorio del flujo de trabajo, en el commit exacto que se está ejecutando, sin necesidad de un paso de checkout, y funciona en pasos de flujo de trabajo, pasos de acciones compuestas, composición anidada y llamadas a flujos de trabajo reutilizables. Antes de este cambio, referenciar una acción definida en el propio repositorio implicaba elegir entre depender de la sintaxis ./ junto con un checkout adicional, o fijar una versión codificada a mano —una carga de mantenimiento que, en la práctica, anulaba en silencio el anclaje por hash de commit (SHA pinning) que muchos equipos de seguridad exigen para sus canalizaciones—. Con la nueva sintaxis, las acciones y flujos de trabajo hermanos dentro de un mismo repositorio siguen automáticamente la misma referencia que ya se está ejecutando, incluso cuando quien invoca el flujo fija un SHA completo. La función requiere que el ejecutor (runner) de GitHub Actions esté en la versión 2.336.0 o superior, y GitHub ya la señala como la forma recomendada de componer acciones y flujos de trabajo dentro de un mismo repositorio. La información de esta nota proviene únicamente del registro de cambios de GitHub, sin cobertura cruzada de otros medios al cierre de esta edición. Costa Rica no publica cifras propias de adopción de GitHub Actions, pero la herramienta es la opción de integración continua más común entre agencias y empresas de desarrollo locales que ya usan GitHub; los equipos que mantengan acciones internas propias pueden simplificar sus flujos hoy mismo actualizando el ejecutor a la versión mínima requerida.
GitHub publicó el 30 de julio de 2026, en su registro de cambios, la actualización de julio de GitHub Copilot dentro de Visual Studio, apenas dos días después de que Microsoft llevara Visual Studio 2026 a disponibilidad general. La entrega central del mes es un nuevo agente construido sobre el SDK de GitHub Copilot, con experiencia incorporada de los equipos de .NET y Azure para tareas específicas de esas plataformas, según describe el propio anuncio de la compañía. La actualización también amplía las formas en que los equipos pueden adaptar Copilot a su flujo de trabajo dentro del IDE, aunque GitHub no detalla, en el anuncio, cifras de adopción del agente durante su fase de vista previa ni una fecha para que deje ese estado. La secuencia de anuncios —disponibilidad general de Visual Studio 2026 el 28 de julio, seguida por esta actualización de Copilot dos días después— confirma que Microsoft sigue empujando la integración de asistencia de código dentro del IDE como el eje central de esta versión, más que mejoras aisladas de rendimiento. GitHub no ha publicado, al cierre de esta edición, una fecha de disponibilidad general para el nuevo agente. La información de esta nota proviene únicamente del registro de cambios de GitHub, sin cobertura cruzada de otros medios. Costa Rica no publica cifras propias de adopción de Visual Studio ni de Copilot, pero ambas herramientas son opciones habituales entre empresas de desarrollo .NET y zonas francas tecnológicas que operan en el país; esos equipos ya pueden probar el nuevo agente en vista previa sin esperar una versión estable.
— El nuevo agente, construido sobre el SDK de Copilot y con experiencia incorporada de los equipos de .NET y Azure, llega apenas dos días después de que Visual Studio 2026 alcanzara disponibilidad general.
cat /feed/herramientasdevcopilotcli.md
La versión 1.0.76 de Copilot CLI permite activar o desactivar, de forma independiente, cada plugin, agente, servidor LSP y hook configurado dentro del propio comando de administración.
> GitHub publicó la versión 1.0.76 de Copilot CLI el 29 de julio de 2026, según el registro de versiones del propio repositorio github/copilot-cli en GitHub. La entrega suma controles para habilitar o deshabilitar, de forma independiente, cada plugin, instrucción, agente, servidor LSP (Language Server Protocol) y hook configurado dentro del comando /plugins, según describe la cobertura de Releasebot sobre el ciclo de lanzamientos de GitHub.
> El cambio responde a una necesidad práctica de gobierno de herramientas: a medida que Copilot CLI acumula más superficies configurables —plugins de terceros, agentes personalizados, servidores LSP—, los equipos de desarrollo necesitan poder desactivar una pieza puntual sin desmontar toda la configuración del comando. GitHub no detalla, en el registro de versiones, cuántos usuarios ya combinan varios de estos componentes en una misma instalación.
> GitHub no ha publicado cifras de cuántos usuarios de Copilot CLI ya usan los nuevos controles de plugins. Costa Rica no tiene cifras propias de adopción de Copilot CLI, pero la herramienta es una opción cada vez más común entre desarrolladores locales que automatizan tareas desde la terminal; los equipos que ya dependan de plugins de terceros pueden actualizar hoy mismo sin esperar cambios adicionales.
Entre el 29 y el 30 de julio, GitHub y Amazon publicaron anuncios que combinan herramientas de colaboración más granulares con una atribución a la cadena de suministro que aún depende de una sola fuente.
Esta edición documentó, el 30 de julio de 2026, cuatro desarrollos que GitHub y Amazon publicaron el mismo día o en las 48 horas previas: Amazon Threat Intelligence atribuyendo, con confianza media, cuatro compromisos de paquetes npm —debug, chalk, typo-crypto y axios— a un mismo grupo vinculado a Corea del Norte; GitHub llevando las pull requests apiladas a vista previa pública; una nueva sintaxis de Actions para referenciar el propio repositorio sin depender de checkout ni de versiones codificadas a mano; y dos actualizaciones separadas de Copilot, en Visual Studio y en su CLI, ambas centradas en dar a los equipos más control granular sobre lo que la herramienta puede hacer. Ninguno de los cuatro casos comparte vector técnico, pero los cuatro apuntan a una misma tensión: la industria sigue construyendo herramientas de colaboración y automatización más granulares —flujos de trabajo propios, pull requests en capas, plugins que se activan o desactivan por separado— mientras la atribución de quién ataca la cadena de suministro de código abierto sigue dependiendo, en varios de sus casos más recientes, de una sola fuente y de meses de retraso entre el compromiso y su reconocimiento público. Para equipos de desarrollo en Costa Rica, la lista de esta edición es concreta: revisar si alguna aplicación local instaló debug, chalk o axios durante las ventanas de compromiso que documenta Amazon; actualizar el ejecutor de GitHub Actions a la versión 2.336.0 si se quiere usar la sintaxis $/; y probar, sin esperar disponibilidad general, tanto las pull requests apiladas como los nuevos controles de plugins de Copilot CLI.