Las organizaciones tienen más visibilidad que nunca. Las crecientes pilas de tecnología brindan una mayor cobertura, y los equipos de seguridad de red adoptan cada vez más la inteligencia artificial y la automatización para ayudar con las tareas rutinarias y reducir el esfuerzo manual.

Pero persisten los mismos desafíos. Las interrupciones aún duran horas y causan importantes pérdidas financieras, interrupciones operativas e impacto reputacional. La respuesta a las amenazas y el tiempo medio de remediación (MTTR) siguen siendo lentos. Las configuraciones erróneas y los errores humanos siguen generando incidentes importantes. Y, a pesar de las promesas de la IA, los equipos siguen abrumados y agotados.

La detección no es el problema. Tampoco lo son las herramientas. Hoy en día, el verdadero problema es la ejecución, es decir, el trabajo que se realiza entre herramientas.

La capa operativa oculta que la mayoría de las organizaciones pasan por alto

Cada vez que se activa una alerta, los equipos de seguridad de la red deben:

• Reúna contexto entre sistemas
• Validar propiedad y gravedad
• Billetes de ruta a las personas adecuadas.
• Solicitar aprobaciones
• Implementar cambios manualmente
• Registrar evidencia

Este trabajo operativo abarca múltiples sistemas y entornos, lo que requiere que los analistas cambien de contexto entre:

• SIEM
• Cortafuegos
• Sistemas de gestión de identidades y accesos (IAM)
• ITSM
• Plataformas de monitoreo
• Entornos de nube, locales e híbridos
• Aplicaciones de mensajería y colaboración

Esto no sólo requiere mucho tiempo y trabajo. Los procesos manuales también aumentan las oportunidades de error humano, incluidas inconsistencias, pasos omitidos y brechas de cumplimiento, lo que introduce riesgos que pueden agravarse rápidamente.

Los recientes cambios en la industria no han hecho más que empeorar el problema. La infraestructura distribuida, la expansión de API y las herramientas cada vez más interconectadas han ampliado la cantidad y la complejidad de los sistemas que los equipos deben coordinar. La velocidad de los ataques está aumentando y las amenazas se están volviendo más sofisticadas. Al mismo tiempo, la IA está acelerando las operaciones y aumentando las expectativas de escala y velocidad, lo que somete a los equipos a una mayor presión para realizar entregas con una capacidad limitada.

¿La conclusión clave? Aunque los entornos actuales pueden estar más conectados técnicamente, los flujos de trabajo operativos subyacentes siguen estando fragmentados, lo que genera cuellos de botella, ralentiza los tiempos de respuesta y limita el impacto de la seguridad en el negocio.

3 lugares donde el trabajo entre herramientas genera riesgo

Cuando los equipos coordinan manualmente el trabajo entre sistemas, personas y herramientas, las operaciones pueden fallar rápidamente. A continuación se presentan tres flujos de trabajo críticos en los que los procesos desconectados ponen en riesgo a su organización.

1. Triaje de alertas y respuesta a incidentes

La detección puede estar automatizada, pero la investigación y la coordinación normalmente no lo están. Los equipos deben recopilar manualmente el contexto en todos los sistemas para enriquecer las alertas y descartar falsos positivos, lo que aumenta el tiempo de investigación y utiliza recursos valiosos que podrían invertirse mejor en problemas más complejos.

Estos procesos lentos y manuales conducen a:

• Retrasos para identificar, escalar, contener y remediar problemas
• Amenazas perdidas que se convierten en verdaderos incidentes de seguridad
• Fatiga de alerta eso conduce a una mala calidad del análisis, a la pérdida de verdaderos aspectos positivos y al agotamiento del equipo.

2. Gestión de acceso y cambios

Los procesos sensibles a la seguridad todavía dependen en gran medida de los humanos como capa de integración. Las solicitudes de acceso y los cambios de red requieren aprobaciones manuales, lo que puede generar validaciones inconsistentes y lagunas en la aplicación de políticas. La seguridad y la TI a menudo trabajan en sistemas separados, lo que genera trabajo duplicado, retrasos en el aprovisionamiento y poca visibilidad de los cambios.

A escala, esto puede causar:

• Acceso con privilegios excesivos que viola los principios de privilegio mínimo y confianza cero
• Configuraciones erróneas que crean vulnerabilidades e interrupciones de seguridad
• Brechas de auditoría y cumplimiento que exponen a su organización a riesgos regulatorios

3. Operaciones híbridas y multiambientales

Trabajar en tecnología fragmentada y entornos híbridos añade complejidad y gastos operativos, ya que los analistas deben cambiar entre diferentes herramientas y modelos de propiedad. Los procesos inconsistentes y las brechas de visibilidad entre los equipos dificultan mantener la responsabilidad, hacer cumplir los estándares y ejecutar de manera confiable en todos los sistemas.

Esta fragmentación puede resultar en:

• Deriva de configuración que crea inestabilidad en la red y riesgos de cumplimiento
• Respuestas retrasadas a amenazas e incidentes
• Brechas de seguridad debido a la aplicación inconsistente de políticas en todos los entornos

Qué están haciendo de manera diferente las organizaciones con visión de futuro

La solución no es reemplazar las herramientas. Está orquestando cómo el trabajo se mueve a través de ellos.

Para ello, las organizaciones están adoptando flujos de trabajo inteligentes. Los flujos de trabajo inteligentes son la capa operativa que conecta sistemas, equipos, aprobaciones, automatización y toma de decisiones en todos los entornos. Combinan tres tipos esenciales de flujo de trabajo:

• Automatización determinista para manejar tareas altamente predecibles, confiables y controladas
• AI Evaluar el contexto, tomar decisiones y ejecutar tareas de forma autónoma.
• Humanos para manejar tareas de alto impacto y mucho en juego que requieren juicio y creatividad

A diferencia de la automatización por sí solaque solo maneja tareas discretas y aisladas, los flujos de trabajo inteligentes permiten a los equipos de seguridad de red orquestar procesos completos de principio a fin, al mismo tiempo que brindan la flexibilidad, el control y la supervisión necesarios para aplicar el enfoque correcto a la tarea correcta.

¿Cómo es un flujo de trabajo inteligente en la práctica?

Considere el proceso de clasificación de alertas y respuesta a incidentes mencionado anteriormente. Usando flujos de trabajo inteligentes:

• Una herramienta de monitoreo detecta actividad inusual y crea una alerta
• La IA extrae contexto de múltiples sistemas para clasificar, enriquecer y priorizar la alerta según la gravedad y el riesgo.
• Si la alerta cumple condiciones específicas predefinidas, el flujo de trabajo activa automáticamente acciones, como procesos de contención o remediación.
• Si se requiere criterio humano, el flujo de trabajo dirige el problema al analista apropiado para una investigación o aprobación más profunda.
• Todas las acciones, decisiones y pruebas se registran automáticamente para respaldar los requisitos de auditoría y cumplimiento.

Antes, el trabajo entre herramientas provocaba retrasos, amenazas perdidas y fatiga de alertas. Ahora, los flujos de trabajo inteligentes manejan el proceso de un extremo a otro, lo que permite a los equipos pasar de la detección a la ejecución más rápidamente, reducir el MTTR y aliviar la tensión de los analistas.

Cómo los flujos de trabajo inteligentes mejoran la seguridad de la red

Para los equipos de seguridad de redes en particular, los flujos de trabajo inteligentes ofrecen una serie de beneficios:

• Normalización reduce las inconsistencias, los pasos omitidos y los errores, asegurando que las respuestas sigan protocolos y guías definidos en toda la organización
• Registro automático de pruebas elimina el esfuerzo manual y mejora la auditabilidad
• Flujos de trabajo compartidos proporcionar visibilidad, alineación y responsabilidad multifuncionales
• Carga operativa reducida alivia la fatiga del analista y recupera tiempo para trabajos de seguridad de alto impacto, como investigaciones o estrategias complejas
• Ejecución consistente fortalece la postura de seguridad y reduce el riesgo
• Coordinación más rápida reduce los tiempos de respuesta y mejora la resiliencia operativa

Todo esto permite que los equipos de seguridad de redes operen a escala, ampliando su capacidad sin necesidad de agregar personal.

Cerrando la brecha entre detección y ejecución

El mayor riesgo operativo en las redes modernas no son las herramientas ni la visibilidad, sino la brecha entre la detección y la ejecución.

Las organizaciones que mejoran la seguridad y la resiliencia operativa no se limitan a añadir más tecnología. En cambio, mejoran la forma en que se mueve el trabajo en su entorno, utilizando flujos de trabajo inteligentes para orquestar el trabajo entre herramientas.

A medida que los entornos de red y seguridad se vuelven más complejos, esta coordinación operativa será tan crucial como la visibilidad misma, lo que permitirá a los equipos operar de forma segura, consistente y a escala.

Más información en Tines’ guía definitiva para la gestión de operaciones de red.

Investigadores de ciberseguridad han revelado detalles de una nueva campaña automatizada llamada megalodón eso ha impulsado 5.718 confirmaciones maliciosas a 5.561 repositorios de GitHub en un período de seis horas.

«Utilizando cuentas desechables e identidades de autor falsificadas (build-bot, auto-ci, ci-bot, pipeline-bot), el atacante inyectó flujos de trabajo de GitHub Actions que contienen cargas útiles bash codificadas en base64 que filtran secretos de CI, credenciales de nube, claves SSH, tokens OIDC y secretos de código fuente a un servidor C2 en 216.126.225[.]129:8443», SeguridadSegura dicho en un informe.

La lista completa de datos recopilados por el malware se encuentra a continuación:

• Variables de entorno CI, /proc/*/environ y entorno PID 1
• Credenciales de servicios web de Amazon (AWS)
• Tokens de acceso a Google Cloud
• Credenciales de rol de instancia obtenidas consultando los puntos finales de AWS IMDSv2, metadatos de Google Cloud y Microsoft Azure Instance Metadata Service (IMDS)
• Claves privadas SSH
• Configuraciones de Docker y Kubernetes
• Fichas de bóveda
• Credenciales de terraforma
• Historia del caparazón
• Claves API, cadenas de conexión de bases de datos, JWT, claves privadas PEM y tokens de nube que coinciden con más de 30 patrones secretos de expresiones regulares.
• URL y token de solicitud de token OIDC de GitHub Actions
• GITHUB_TOKEN, tokens GitLab CI/CD y tokens Bitbucket
• Archivos .env, credenciales.json, service-account.json y otros archivos de configuración

Uno de los paquetes afectados es @tiledesk/tiledesk-server, que incluye una carga útil bash codificada en Base64 dentro de un archivo de flujo de trabajo de GitHub Actions. En total, se enviaron 5.718 confirmaciones a 5.561 repositorios distintos el 18 de mayo de 2026, entre las 11:36 a. m. y las 5:48 p. m. UTC.

«El atacante rotó entre cuatro nombres de autores (build-bot, auto-ci, ci-bot, pipeline-bot) y siete mensajes de confirmación, todos imitando el mantenimiento rutinario de CI», dijo SafeDep. «El atacante utilizó cuentas de GitHub desechables con nombres de usuario aleatorios de 8 caracteres (por ejemplo, rkb8el9r, bhlru9nr, lo6wt4t6), configuró git config para falsificar la identidad del autor y utilizó PAT comprometidas o claves de implementación».

Se han observado dos variantes de carga útil como parte de la campaña a gran escala: SysDiag, una variante masiva que agrega un nuevo flujo de trabajo que se activa en cada solicitud push y pull, y Optimize-Build, una variante específica que se activa solo en envío_flujo de trabajoun activador de GitHub Actions que permite a los usuarios ejecutar manualmente un flujo de trabajo bajo demanda. En el caso de Tiledesk, el enfoque dirigido se utiliza para dirigirse a los ejecutores de CI/CD, y no cuando está instalado el paquete npm.

«La compensación es alcance: encendido: empuje garantizaría la ejecución en cada compromiso para dominar, alcanzando más objetivos sin intervención», agregó SafeDep. «Workflow_dispatch sacrifica eso por la seguridad operativa. Con más de 5700 repositorios comprometidos, incluso una pequeña fracción que produzca un GITHUB_TOKEN utilizable le da al atacante suficientes objetivos para la activación bajo demanda».

El resultado es que una vez que el propietario de un repositorio fusiona la confirmación, el malware se ejecuta dentro de sus canales de CI/CD y se propaga aún más, lo que permite el robo de credenciales y secretos a escala.

«Hemos entrado en una nueva era de ataques a la cadena de suministro, y el compromiso de TeamPCP con GitHub fue solo el comienzo», Moshe Siman Tov Bustan de OX Security. dicho. «Lo que viene a continuación es una ola interminable, un tsunami de ciberataques a desarrolladores de todo el mundo».

El desarrollo se produce cuando TeamPCP ha utilizado como arma la cadena de suministro de software interconectada para corromper cientos de herramientas de código abierto, abriéndose camino a través de varios ecosistemas y extorsionando a las víctimas para obtener ganancias en algunos casos. GitHub, propiedad de Microsoft, se ha convertido en la última incorporación a la larga lista de víctimas del grupo, que también incluye a TanStack, Grafana Labs, OpenAI y Mistral AI.

Los ataques de TeamPCP han impulsado una explotación cíclica de proyectos populares de código abierto, donde un compromiso alimenta al siguiente, permitiendo que el malware se propague como la pólvora en forma de gusano. El grupo también parece estar motivado financieramente y ha establecido asociaciones con BreachForums y otros grupos de extorsión como LAPSUS$ y VECT.

Es más, el grupo también parece tener motivaciones geopolíticas, como lo demuestra el despliegue de malware limpiador al detectar máquinas ubicadas en Irán e Israel.

Las consecuencias de la ola de ataques del TeamPCP y la Mini gusano Shai-Hulud tiene incitado npm para invalidar tokens de acceso granular con acceso de escritura que omite la autenticación de dos factores (2FA). NPM también insta a los usuarios a cambiar a Publicación confiable para reducir la dependencia de dichos tokens.

«Al quemar cada token bypass-2FA en la plataforma, npm corta las credenciales que el gusano ya ha recopilado», afirma la empresa de seguridad de aplicaciones Socket. dicho. «Los mantenedores emiten otros nuevos. El gusano, todavía activo en la naturaleza, vuelve a recolectarlos. El reinicio da un respiro. No cierra el agujero subyacente».

Los grupos de actividades como Megalodon y TeamPCP implican comprometer paquetes legítimos para distribuir malware. Por el contrario, una cuenta desechable llamada «polimercadodev» publica nueve paquetes npm maliciosos que se hacen pasar por herramientas CLI comerciales de Polymarket en una ventana de 30 segundos para robar las claves privadas de Ethereum/Polygon de las víctimas a través de un gancho posterior a la instalación.

Al momento de escribir este artículo, todavía están disponibles para descargar desde npm. Los nombres de los paquetes están a continuación:

• polimercado-trading-cli
• terminal-polimercado
• comercio-polimercado
• polimercado-auto-comercio
• comercio de copias de polimercado
• robot-polimercado
• código-claude-polimercado
• agente-ai-polimercado
• comerciante-polimercado

«Durante la instalación, un script posterior a la instalación muestra un mensaje de incorporación de billetera falsa que solicita al usuario que pegue su clave privada, afirmando que ‘permanece cifrada’», SafeDep dicho. «El script PUBLICA la clave sin formato en texto plano a un trabajador de Cloudflare en hxxps://polymarketbot.polymarketdev.workers[.]dev/v1/billetera/claves.»

«El atacante creó una CLI comercial funcional en torno a una operación de robo de credenciales. La ingeniería social lleva el ataque: el mensaje posterior a la instalación parece una incorporación de billetera estándar, el enmascaramiento imita la entrada segura y el repositorio de GitHub proporciona credibilidad falsa»

Cisco ha implementado actualizaciones para una falla de seguridad de máxima gravedad que afecta la carga de trabajo segura y que podría permitir que un atacante remoto no autenticado acceda a datos confidenciales.

Seguimiento como CVE-2026-20223 (Puntuación CVSS: 10.0), la vulnerabilidad surge de una validación y autenticación insuficientes al acceder a los puntos finales de la API REST.

«Un atacante podría aprovechar esta vulnerabilidad si puede enviar una solicitud API diseñada a un punto final afectado», Cisco dicho. «Un exploit exitoso podría permitir al atacante leer información confidencial y realizar cambios de configuración a través de los límites de los inquilinos con los privilegios del usuario administrador del sitio».

La deficiencia afecta al software Cisco Secure Workload Cluster en SaaS y en implementaciones locales, independientemente de la configuración del dispositivo. Cisco dijo que no existen soluciones alternativas para abordar la vulnerabilidad.

El problema se ha solucionado en las siguientes versiones:

• Cisco Secure Workload versión 3.9 y anteriores (migrar a una versión fija)
• Cisco Secure Workload versión 3.10 (corregido en 3.10.8.3)
• Cisco Secure Workload versión 4.0 (corregido en 4.0.3.17)

El especialista en equipos de redes dijo que encontró la vulnerabilidad durante las pruebas de seguridad internas y que no hay evidencia de que haya sido explotada en la naturaleza.

La divulgación se produce una semana después de que Cisco revelara que un actor de amenazas conocido como UAT-8616 había explotado otra falla de derivación de autenticación de máxima gravedad en el controlador Catalyst SD-WAN (CVE-2026-20182, puntuación CVSS: 10.0) para obtener acceso no autorizado a sistemas SD-WAN.

Los atacantes de la cadena de suministro no sólo intentan introducir código malicioso en software confiable. Están intentando robar el acceso que hace posible el software confiable. Recientemente, tres campañas separadas llegaron a npm, PyPI y Docker Hub en un período de 48 horas, y las tres apuntaron a secretos de entornos de desarrollador y canalizaciones de CI/CD, incluidas claves API, credenciales de nube, claves SSH y tokens. Esta es una preocupación constante y se propaga a sí misma, como se ve en ataques como las campañas del «mini Shai Hulud».

Ese patrón debería cambiar la forma en que los equipos de seguridad piensan sobre la cadena de suministro de software.

Tradicionalmente, la seguridad se centraba en sistemas compartidos como repositorios de código fuente, plataformas CI/CD, registros de artefactos, administradores de paquetes y entornos de nube. El objetivo era proteger las cargas de trabajo y los datos de producción. Es absolutamente necesario que nos centremos en estos ámbitos, pero el panorama es incompleto.

La entrega de software moderno comienza antes de que el código llegue a Git. Comienza en la estación de trabajo del desarrollador, donde se escribe el código, se instalan las dependencias, se prueban las credenciales, se solicita a los asistentes de IA, se crean contenedores y comienzan las acciones confiables.

Las estaciones de trabajo de los desarrolladores son una parte real de la cadena de suministro de software. Tratarlos como «simples» puntos finales comunes deja brechas entre la seguridad de los puntos finales, la seguridad de la identidad, la seguridad de las aplicaciones y la gobernanza de la cadena de suministro.

Los ataques a la cadena de suministro se han convertido en operaciones de recolección de credenciales

Los incidentes recientes siguen apuntando a la misma verdad operativa. Los atacantes pueden utilizar paquetes envenenados, imágenes comprometidas, bots de dependencia, flujos de trabajo maliciosos o herramientas de desarrollo vulnerables, pero el objetivo recurrente es el acceso.

Eventos como las campañas TeamPCP y Shai-Hulud muestran cómo los ataques a la cadena de suministro convergen cada vez más en torno al robo de credenciales. En la campaña TeamPCP, los atacantes utilizaron paquetes comprometidos y herramientas de desarrollo para recolectar tokens, credenciales de nube, claves SSH, archivos de configuración npm y variables de entorno.

Shai-Hulud impulsó el mismo patrón aún más, convirtiendo los entornos de desarrolladores infectados en puntos de recopilación de credenciales que expusieron miles de secretos en GitHub, servicios en la nube, registros de paquetes y sistemas internos.

Esto no es sólo una manipulación del software. Se trata de una recopilación de credenciales en puntos en los que los desarrolladores y la automatización ya tienen confianza.

La cadena de suministro queda expuesta cuando los atacantes obtienen acceso a credenciales y contexto que les permiten alterar, publicar, construir, implementar o hacerse pasar por sistemas de software confiables. Los paquetes modificados y publicados en un ataque moderno a la cadena de suministro permanecen activos durante horas, mientras que las herramientas de automatización combinan actualizaciones maliciosas en minutos.

El hilo conductor de muchos de los ataques recientes han sido los secretos, ya sea como vector de acceso inicial o como objetivo de recopilación.

La ruta del atacante ahora pasa por el contexto del lado del desarrollador

La estación de trabajo del desarrollador es valiosa porque concentra el contexto. A menudo contiene repositorios locales, archivos .env, historial de shell, claves SSH, credenciales y configuraciones del administrador de paquetes, scripts de compilación, registros de depuración y sesiones del navegador. Esas piezas se vuelven mucho más peligrosas cuando se ven juntas.

Un token de acceso único puede parecer limitado de forma aislada. Un token que se encuentra junto a un control remoto de Git, un script de implementación, un archivo README, un perfil de nube y una configuración de CI le indica al atacante dónde encaja el token y qué podría desbloquear. En la campaña Shai-Hulud 2.0, por ejemplo, las credenciales de GitHub dominaron las credenciales expuestas y exfiltradas, cada una con potencial acceso de administrador a repositorios y flujos de trabajo de CI.

El compromiso local no es sólo un problema de dispositivo. Puede servir como mapa para el control de fuentes, cuentas en la nube, flujos de trabajo de publicación de paquetes, sistemas CI/CD, API internas e infraestructura adyacente a la producción.

Autoridad de entrega de software de Developer Machines Concentrate

Una computadora portátil estándar para empleados puede exponer datos corporativos. Una estación de trabajo de desarrollador puede exponer la capacidad de cambiar el software. Esa distinción es fundamental al considerar la seguridad de los terminales.

Los desarrolladores suelen necesitar un acceso amplio para realizar su trabajo. Clonan repositorios privados, se autentican en servicios en la nube, publican paquetes, acceden a entornos de prueba e interactúan con múltiples herramientas internas. Sus máquinas se convierten en una intersección funcional de código fuente, credenciales, automatización y autoridad de entrega.

Si bien no todos los desarrolladores tienen acceso a la producción, muchos sí tienen acceso suficiente para influir en los sistemas que eventualmente producirán resultados de producción. Un token de registro puede afectar a los paquetes. Un token de GitHub puede afectar repositorios o flujos de trabajo. Un perfil de nube puede exponer la infraestructura. Una credencial CI/CD puede afectar el comportamiento de la compilación.

A la junta y a los auditores no les importa si un desarrollador almacenó un secreto localmente. En realidad, el riesgo empresarial es que una exposición local proporcione a los atacantes un camino hacia los sistemas que crean, modifican, publican u operan software.

Ese cambio cambia las preguntas que los equipos de seguridad deberían plantearse:

• ¿Puede identificar qué credenciales se pueden utilizar desde las estaciones de trabajo de los desarrolladores?
• ¿Puede limitar el valor y la vida útil de esas credenciales?
• ¿Puede detectar material confidencial antes de que ingrese al historial de Git, registros de CI, tickets, artefactos o chat?
• ¿Puede revocar y rotar el acceso rápidamente cuando sospecha que la estación de trabajo está comprometida?
• ¿Puedes notar la diferencia entre exposición local de bajo impacto y credenciales con privilegios similares a los de administrador?

Esas preguntas se sitúan entre AppSec, endpoints, identidad, plataforma y seguridad en la nube. Independientemente de cómo decida coordinar su organización, debe comprender cómo se conecta el comportamiento de los desarrolladores con los sistemas de entrega.

La automatización y la inteligencia artificial hacen que la superficie de exposición sea más delgada y rápida

La automatización ha comprimido el tiempo entre el compromiso y el impacto. Los robots de actualización de dependencias pueden abrir y fusionar cambios rápidamente. Los sistemas CI/CD pueden ejecutar flujos de trabajo confiables automáticamente. Los administradores de paquetes pueden ejecutar scripts de instalación. Los agentes de IA y los asistentes de codificación pueden leer archivos, llamar a herramientas, generar comandos, inspeccionar resultados y mover el contexto entre sistemas.

La automatización no es intrínsecamente insegura, pero normalmente cualquier automatización hereda la confianza, especialmente si se presenta en forma de agencia. Si una actualización de dependencia maliciosa parece rutinaria, un flujo de trabajo automatizado puede hacerla avanzar más rápido de lo que un revisor humano puede entender lo que sucedió.

IA en el circuito

El desarrollo asistido por IA añade otro conjunto de puntos de transferencia. Los datos confidenciales pueden aparecer en mensajes, salidas de terminales, llamadas a herramientas, código generado, memoria del agente, registros y configuración local copiados en una sesión de depuración. La cuestión es más amplia que si un proveedor de modelos almacena indicaciones. El problema más importante es que el contexto de desarrollo local ahora fluye a través de sistemas más semiautomatizados.

Los equipos de seguridad deben evaluar el riesgo de la codificación de IA a través de la misma lente que utilizan para el riesgo de la cadena de suministro. Los equipos deben responder: ¿qué fuentes y datos puede leer la herramienta? ¿Qué puede ejecutar? ¿A dónde va la producción? ¿Qué credenciales hay cerca? Y, quizás lo más importante, ¿qué confianza hereda el flujo de trabajo?

Los controles posteriores siguen siendo importantes, pero ya es demasiado tarde por sí solos

El escaneo de repositorios, la protección de sucursales, la política de CI/CD, la firma de artefactos, el análisis de dependencias y los controles de tiempo de ejecución siguen siendo esenciales. Crean puntos de cumplimiento compartidos y ayudan a los equipos a controlar el software a escala.

El problema ahora es el momento oportuno, gracias a la velocidad de los ataques modernos. Los atacantes ahora aprovechan las herramientas impulsadas por IA para explotar todos y cada uno de los secretos a los pocos segundos de ser descubiertos.

Las barandillas reducen la exposición potencial y el radio de explosión. La captura de material confidencial mientras un desarrollador edita un archivo, prepara una confirmación, ejecuta un comando local, instala una dependencia o interactúa con un asistente de inteligencia artificial mantiene el impacto al mínimo.

Los programas maduros distinguen entre acciones que deberían bloquearse, acciones que deberían dar advertencias y acciones que simplemente deberían generar telemetría para una investigación más profunda. El objetivo no es sepultar a los desarrolladores en fricciones.

Trate la estación de trabajo como un límite de la cadena de suministro local

La cadena de suministro de software moderna no comienza cuando se envía código. Comienza donde el código, las credenciales, la automatización y la confianza se unen por primera vez.

Es hora de tratar la estación de trabajo del desarrollador como un límite de la cadena de suministro local. Ese límite incluye el IDE, la terminal, el cliente Git, el administrador de paquetes, las herramientas de contenedor, la CLI en la nube, el sistema de compilación local, las prácticas de manejo de secretos, los asistentes de IA y los agentes de automatización. Es el lugar donde la acción de los desarrolladores individuales se convierte en un riesgo de entrega de software organizacional.

El 23 de marzo, el Senado confirmó al senador Markwayne Mullin como el próximo secretario de seguridad nacional, lo que marca un paso importante en el fortalecimiento del liderazgo durante un momento crítico para la seguridad de nuestra nación.

Pero sólo la mitad del trabajo está hecho.

La Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA), la principal agencia civil de ciberdefensa del gobierno federal, aún carece de un director confirmado por el Senado. A medida que aumentan las amenazas cibernéticas globales, esta prolongada brecha de liderazgo plantea un riesgo creciente para la seguridad nacional.

Como Director Ejecutivo de la Coalición Nacional de Seguridad Tecnológica (NTSC), represento a los Directores de Seguridad de la Información que son responsables de proteger los sistemas que sustentan la economía y la infraestructura crítica de Estados Unidos. En todos los sectores, energía, atención médica, servicios financieros, manufactura y transporte, existe una preocupación común: el panorama de amenazas se está volviendo más agresivo y nuestras defensas deben mantenerse a la vanguardia.

Nuestros enemigos no están esperando.

Desde el inicio del conflicto con Irán, los expertos en ciberseguridad han informado de un aumento de la actividad cibernética maliciosa dirigida a los sistemas estadounidenses y aliados. Los actores vinculados a Irán han demostrado su capacidad para perturbar operaciones y explotar vulnerabilidades. Mientras tanto, China continúa su esfuerzo a largo plazo para infiltrarse en las redes estadounidenses y posicionarse para una posible interrupción de la infraestructura crítica. Rusia y sus grupos afiliados siguen siendo persistentes, investigando las debilidades de los sistemas occidentales y ejerciendo una presión constante.

Ésta es la realidad del conflicto moderno. Las operaciones cibernéticas se han convertido en un ámbito principal de competencia. En algunos casos, pueden rivalizar con los efectos de la acción militar tradicional, perturbando las economías, las comunicaciones y la seguridad pública únicamente a través del código.

El liderazgo es importante en este entorno.

CISA desempeña un papel clave en la coordinación de la ciberdefensa federal, compartiendo inteligencia sobre amenazas con el sector privado y apoyando a los gobiernos estatales y locales. Sirve como vínculo entre el gobierno y la industria para proteger la infraestructura digital del país. Sin un director confirmado por el Senado, la capacidad de la agencia para establecer prioridades, coordinar esfuerzos y responder rápidamente es limitada.

Ese desafío es cada vez más urgente. El plan presupuestario del presidente para el año fiscal 2027 propone recortes significativos a la financiación de CISA. En un momento en que la agencia enfrenta una presión operativa cada vez mayor, la escasez de recursos hace que un liderazgo fuerte y constante sea aún más crucial.

Éste es el momento en que el liderazgo del secretario Mullin es fundamental.

Como ex miembro del Senado, el secretario Mullin comprende la institución, su dinámica y cómo generar consenso. Está en una posición única para conectarse con colegas anteriores y ayudar a avanzar en el nombramiento de Sean Plankey como Director de CISA.

Plankey está altamente calificado y es ampliamente respetado en la comunidad de la ciberseguridad. Su experiencia en la Guardia Costera de EE. UU., en el Departamento de Energía que protege la infraestructura energética del país y en el sector privado le proporciona una comprensión clara tanto del panorama de amenazas como de la importancia de la colaboración público-privada. En un momento en que la coordinación entre el gobierno y la industria es vital, estas cualidades son esenciales.

El Senado ya ha dado señales de que se toma en serio las ciberamenazas. Recientemente confirmó Teniente general Joshua Rudd para liderar el Comando Cibernético de EE. UU. y servir como director de la Agencia de Seguridad Nacional, asegurando un liderazgo sólido del equipo de defensa cibernética militar de Estados Unidos.

Ahora necesita hacer lo mismo en el lado civil.

Confirmar a Plankey es importante porque la principal agencia civil de ciberdefensa del país necesita un liderazgo establecido para combatir a los adversarios que ya están dentro de nuestras redes, investigando nuestros sistemas y preparándose para la siguiente fase del conflicto.

La brecha de liderazgo en CISA ya ha durado bastante.

El secretario Mullin debe comprometerse. El Senado necesita actuar. Y Sean Plankey debería ser confirmado sin más demora.

Las ciberdefensas de Estados Unidos dependen de ello.

Chris Sullivan es el director ejecutivo de la Coalición Nacional de Seguridad Tecnológica, una organización no partidista y sin fines de lucro que actúa como voz de defensa de los directores de seguridad de la información en todo el país.

Dado que la fuerza laboral de ciberseguridad del país aún experimenta una gran escasez, un grupo bipartidista y bicameral de legisladores está presionando para reclutar al Departamento de Trabajo para ayudar a abordar el problema.

La Ley Cyber ​​Ready Workforce ordenaría al DOL que establezca un programa de subvenciones que apoye la “creación, implementación y expansión de programas de aprendizaje registrados en ciberseguridad”, según un presione soltar anunciando la presentación del proyecto de ley esta semana.

«A medida que los ataques cibernéticos se vuelven más comunes y complejos, debemos asegurarnos de contar con trabajadores con la capacitación y las habilidades necesarias para proteger nuestra infraestructura cibernética y los datos personales de los estadounidenses», dijo en un comunicado el senador Jacky Rosen, demócrata por Nevada, uno de los copatrocinadores del proyecto de ley. «Esta legislación bipartidista ayudará a llenar los vacíos en nuestra fuerza laboral de ciberseguridad y abrirá la puerta a más empleos de vanguardia y bien remunerados para los nevadenses, independientemente de si tienen o no un título universitario».

Otro copatrocinador, la senadora Marsha Blackburn, dijo en un comunicado que la legislación brindaría “apoyo específico” a empresas, universidades y organizaciones sin fines de lucro que necesiten más protección cibernética. La «grave escasez de talento» en el ámbito cibernético del país «representa una grave amenaza a nuestra seguridad nacional y crecimiento económico», dijo el republicano de Tennessee.

La introducción de la legislación el martes no es obra de Rosen y Blackburn primer bocado en la manzana, pero esfuerzos previos estancado en el Senado. Esta vez, los senadores agregaron un par de copatrocinadores de la Cámara: los representantes Susie Lee, demócrata por Nevada, y Brian Fitzpatrick, republicano por Pensilvania. – al campo. También llega en un momento en que la administración Trump ha ordenado al DOL que hacer más con aprendizajes y tecnología.

Lee dijo en un declaración que sólo en Nevada faltan 4.000 profesionales de ciberseguridad. Algunas estimaciones sitúan el déficit de mano de obra cibernética a nivel nacional en casi medio millón empleos.

«Lo sepas o no, la ciberseguridad… nos afecta a todos, desde nuestras pequeñas empresas hasta las redes de servicios públicos y nuestra seguridad nacional. Pero no tenemos suficiente talento para cubrir estos puestos de trabajo». dijo Lee. «Este proyecto de ley ayudará a garantizar que no nos quedemos atrás en lo que respecta a la ciberseguridad, y al mismo tiempo pondrá a Nevada a la vanguardia de los empleos del futuro de alta demanda, alto impacto y bien remunerados».

Según un hoja informativa publicada en el sitio web del Congreso de Leeel proyecto de ley pide al Departamento de Trabajo que otorgue subvenciones a “intermediarios de la fuerza laboral” que aumentarán el número de programas de aprendizaje en ciberseguridad registrados.

Los fondos de subvenciones deben utilizarse para desarrollar planes de estudio y proporcionar instrucción técnica. También podría destinarse a programas de marketing y contratación, servicios de apoyo como asesoramiento y tutoría profesional, y asistencia para gastos como transporte, vivienda y cuidado infantil.

La legislación también alienta a los beneficiarios de subvenciones a conectarse y colaborar con intermediarios de la fuerza laboral en entornos empresariales, sin fines de lucro y académicos. La coordinación de recursos en los programas de aprendizaje cibernético debería garantizar que las inversiones federales no se destinen a esfuerzos duplicados, según la hoja informativa.

«La continua escasez de profesionales en ciberseguridad ha expuesto a nuestra nación a graves vulnerabilidades, amenazando nuestra economía y seguridad nacional», dijo Fitzpatrick en un comunicado. «Ahora, más que nunca, es necesaria una fuerza laboral de ciberseguridad sólida para proteger nuestros intereses en el país y en el extranjero».

Abordar la escasez de mano de obra en materia de ciberseguridad ha sido una prioridad para muchos legisladores en los últimos años, y la legislación busca establecer becas cibernéticas en universidades de dos años e instituciones que atienden a minorías, crear nuevas programas federales de capacitación cibernéticadar dinero a CISA para esfuerzos de reclutamiento de minorías y más.

La Inteligencia Artificial (IA) ya no es sólo una herramienta con la que hablamos; es una herramienta que hace cosas para nosotros. estos se llaman Agentes de IA. Pueden enviar correos electrónicos, mover datos e incluso administrar software por su cuenta.

Pero hay un problema. Si bien estos agentes agilizan el trabajo, también abren una nueva «puerta trasera» para los piratas informáticos.

El problema: «El empleado invisible»

Piense en un agente de IA como un empleado nuevo que tiene las llaves de todas las oficinas de su edificio pero no tiene una etiqueta con su nombre.

Como estos agentes actúan por su cuenta, a menudo tienen acceso a información confidencial que nadie está mirando. Los piratas informáticos se han dado cuenta de esto. Ya no necesitan descifrar su contraseña, solo necesitan engañar a su agente de IA para que haga el trabajo por ellos.

Si su empresa utiliza IA para automatizar tareas, podría estar en riesgo. Las herramientas de seguridad tradicionales se crearon para proteger a los humanos, no a los «trabajadores digitales».

En nuestro próximo seminario web, Más allá del modelo: la superficie de ataque ampliada de los agentes de IARahul Parwani, jefe de producto de seguridad de IA en ariadesglosará exactamente cómo los piratas informáticos se dirigen a estos agentes y, lo que es más importante, cómo puede detenerlos.

Lo que aprenderás

• La «materia oscura» de la identidad: Por qué los agentes de IA suelen ser invisibles para su equipo de seguridad y cómo encontrarlos.
• Cómo se engaña a los agentes: Descubra cómo una simple «mala idea» oculta en un documento puede hacer que un agente de IA filtre los secretos de su empresa.
• El plan de seguridad: Pasos sencillos para brindarles a sus agentes de IA el poder que necesitan sin darles el «Modo Dios» sobre sus datos.

¿Quién debería asistir?

Si es un líder empresarial, un profesional de TI o cualquier persona responsable de mantener seguros los datos de la empresa, esta sesión es para usted. No es necesario ser un experto en codificación para comprender estos riesgos.

No permita que su IA se convierta en su mayor agujero de seguridad.

📅 Guarde su lugar hoy: Regístrese para el seminario web aquí.

El actor de amenazas norcoreano conocido como UNC4899 Se sospecha que está detrás de una sofisticada campaña de compromiso en la nube dirigida a una organización de criptomonedas en 2025 para robar millones de dólares en criptomonedas.

La actividad se ha atribuido con moderada confianza al adversario patrocinado por el estado, al que también se le rastrea bajo los criptoónimos Jade Sleet, PUKCHONG, Slow Pisces y TraderTraitor.

«Este incidente se destaca por su combinación de ingeniería social, explotación de mecanismos de transferencia de datos entre pares (P2P) de dispositivos personales a corporativos, flujos de trabajo y eventual giro a la nube para emplear técnicas de vivir fuera de la nube (LOTC)», señaló el gigante tecnológico en su informe. Informe sobre horizontes de amenazas en la nube del primer semestre de 2026 [PDF] compartido con The Hacker News.

Al obtener acceso al entorno de la nube, se dice que los atacantes abusaron de los flujos de trabajo legítimos de DevOps para recopilar credenciales, romper los límites de los contenedores y alterar las bases de datos de Cloud SQL para facilitar el robo de criptomonedas.

La cadena de ataque, dijo Google Cloud, representa una progresión de lo que comenzó con el compromiso del dispositivo personal de un desarrollador en su estación de trabajo corporativa, antes de saltar a la nube para realizar modificaciones no autorizadas a la lógica financiera.

Todo comenzó cuando los actores de amenazas utilizaron estrategias de ingeniería social para engañar al desarrollador para que descargara un archivo como parte de una supuesta colaboración en un proyecto de código abierto. Luego, el desarrollador transfirió el mismo archivo al dispositivo de su empresa a través de AirDrop.

«Utilizando su entorno de desarrollo integrado (IDE) asistido por IA, la víctima interactuó con el contenido del archivo y finalmente ejecutó el código Python malicioso incrustado, que generó y ejecutó un binario que se hacía pasar por la herramienta de línea de comandos de Kubernetes», dijo Google.

Luego, el binario se puso en contacto con un dominio controlado por el atacante y actuó como una puerta trasera para la máquina corporativa de la víctima, brindando a los atacantes una forma de pasar al entorno de Google Cloud probablemente usando sesiones autenticadas y credenciales disponibles. A este paso le siguió una fase inicial de reconocimiento destinada a recopilar información sobre diversos servicios y proyectos.

El ataque pasó a la siguiente fase con el descubrimiento de un anfitrión bastióncon el adversario modificando su atributo de política de autenticación multifactor (MFA) para acceder a él y realizar reconocimiento adicional, incluida la navegación a pods específicos dentro del entorno de Kubernetes.

Posteriormente, UNC4899 adoptó un enfoque de vivir fuera de la nube (LotC) para configurar mecanismos de persistencia alterando las configuraciones de implementación de Kubernetes para ejecutar un comando bash automáticamente cuando se crean nuevos pods. El comando, por su parte, descargaba una puerta trasera.

Algunos de los otros pasos llevados a cabo por el actor de amenazas se enumeran a continuación:

• Los recursos de Kubernetes vinculados a la solución de plataforma CI/CD de la víctima se modificaron para inyectar comandos que mostraban los tokens de la cuenta de servicio en los registros.
• El atacante obtuvo un token para una cuenta de servicio CI/CD con altos privilegios, lo que le permitió escalar sus privilegios y realizar movimientos laterales, apuntando específicamente a un módulo que manejaba políticas de red y equilibrio de carga.
• El token de la cuenta de servicio robado se utilizó para autenticarse en el pod de infraestructura confidencial que se ejecuta en modo privilegiado, escapar del contenedor e implementar una puerta trasera para acceso persistente.
• El actor de amenazas llevó a cabo otra ronda de reconocimiento antes de centrar su atención en una carga de trabajo responsable de administrar la información del cliente, como las identidades de los usuarios, la seguridad de la cuenta y la información de la billetera de criptomonedas.
• El atacante lo usó para extraer credenciales de bases de datos estáticas que estaban almacenadas de forma insegura en las variables de entorno del pod.
• Luego se abusó de las credenciales para acceder a la base de datos de producción a través de Cloud SQL Auth Proxy y ejecutar comandos SQL para realizar modificaciones en la cuenta de usuario. Esto incluyó restablecimientos de contraseñas y actualizaciones de semillas de MFA para varias cuentas de alto valor.
• El ataque culminó con el uso de cuentas comprometidas para retirar con éxito varios millones de dólares en activos digitales.

El incidente «destaca los riesgos críticos planteados por los métodos de transferencia de datos P2P de persona a empresa y otros puentes de datos, modos de contenedores privilegiados y el manejo no seguro de secretos en un entorno de nube», dijo Google. «Las organizaciones deben adoptar una estrategia de defensa en profundidad que valide rigurosamente la identidad, restrinja la transferencia de datos en los puntos finales y aplique un aislamiento estricto dentro de los entornos de ejecución de la nube para limitar el radio de explosión de un evento de intrusión».

Para contrarrestar la amenaza, se recomienda a las organizaciones implementar acceso contextual y MFA resistente al phishing, asegurarse de que solo se implementen imágenes confiables, aislar los nodos comprometidos para que no establezcan conectividad con hosts externos, monitorear procesos de contenedores inesperados, adoptar una gestión sólida de secretos, aplicar políticas para deshabilitar o restringir el intercambio de archivos entre pares mediante AirDrop o Bluetooth y montar medios externos no administrados en dispositivos corporativos.