Durante años, los contenedores se han vendido como "aislamiento liviano": empaqueta tu app, córrela en cualquier lado y duerme tranquilo porque el código malicioso no puede tocar el host. Esa historia es _mayormente_ cierta—hasta que el kernel decide tener un mal día. Con una seguidilla constante de CVEs del kernel de Linux y bugs de escalada de privilegios local (LPE), es razonable preguntarse: **¿sigue siendo un contenedor un límite de seguridad significativo, o solo un`chroot` muy confiado con presupuesto de marketing?** ## Cómo aíslan los contenedores en realidad Cuando ejecutas `docker run`, no estás arrancando un SO diminuto. Estás llamando a `clone(2)` con un montón de flags. El kernel crea un proceso hijo con nuevos namespaces: mount, PID, user, network, IPC, UTS y cgroup. Obtienes un sistema de archivos raíz falso, un usuario root falso y una red falsa. **Se siente como una VM. No lo es.** Bajo el capó, `runc` (u otro runtime OCI) usa flags como `CLONE_NEWNS`, `CLONE_NEWPID`, `CLONE_NEWUSER` y `CLONE_NEWNET`. El PID 1 del contenedor no es más que un proceso en el host, oculto por un namespace de PID. Su usuario `root` a menudo se mapea a un UID sin privilegios mediante un namespace de usuario. Su `/etc` es un namespace de montaje. Todo es truco del kernel. **Cada syscall sigue llegando al mismo kernel del host.** **Ese kernel compartido es la gracia. También es el problema.** ## El kernel es el límite El kernel media todo: archivos, memoria, red, dispositivos. La interfaz de syscalls no es privilegiada; cualquier proceso puede llamar a `open`, `read`, `write`, `splice`, `io_uring` y amigos. Se supone que el kernel verifica permisos y te mantiene en tu carril. **Si un bug te permite confundir al kernel, puedes salirte de ese carril y llegar a root.** _**Dirty COW (CVE-2016-5195)**_ fue la llamada de atención: una _race condition_ en copy-on-write permitía escalada de privilegios local universal. En ese entonces, un bug de ese tamaño se sentía como un evento anual. Parcheabas, seguías adelante y rezabas para que nadie posea un zero-day. Ahora, la investigación de vulnerabilidades asistida por IA **ha puesto ese modelo patas arriba**. LPEs recientes reportadas con nombres como Copy Fail y Dirty Frag muestran sobrescrituras de page-cache y bugs de socket splicing que pueden convertir un escape de contenedor en una toma de control del host. Los nombres son ridículos; el impacto no. **Un malware corriendo dentro de un contenedor puede explotar un bug del kernel, escalar a root y, de repente, está en el host.** El límite del contenedor se vuelve decorativo. How the Linux kernel copyfail vulnerability impacts kubernetes: What you need to know and what you can docopy fail in kubernetes: when your pod escapes to the host with four bytes if you thought containers were a security boundary, cve-2026-31431 (“copy fail”) has some unfortunate news for you. discovered by xint, this linux kernel vulnerability lets an unprivileged local user overwrite four controlled bytes inSREDevOps.orgNicolás Georger Leer más sobre CopyFail en Kubernetes El gráfico de CVEs del kernel no va a la baja. Si ejecutas código no confiable en un contenedor común, estás compitiendo contra el ciclo de parches. A veces ganas. A veces gana el atacante. Como argumenta el análisis reciente de Depth First, el límite del contenedor ya no es algo con lo que puedas contar. ## Kubernetes no cambia la matemática Kubernetes orquesta contenedores. No agrega aislamiento por hardware. Programa pods en nodos, y esos pods comparten un kernel. La _multi-tenencia_ sobre el mismo kernel es una decisión de confianza. Si los inquilinos ejecutan código arbitrario, un exploit del kernel puede comprometer el nodo y todos los contenedores que están en él. Por esto los proveedores de nube a menudo aíslan a los inquilinos a nivel de VM, no solo a nivel de contenedor. También es por esto que las plataformas serverless y las ofertas de Kubernetes administrado suelen usar microVMs o runtimes sandboxeados bajo el capó. Kubernetes es un gran orquestador. No es un límite de seguridad. ## MicroVMs: devolviendo el hardware al juego Una microVM es una máquina virtual real, solo que pequeña y rápida. Usa un VMM (Virtual Machine Monitor) como Firecracker o Cloud Hypervisor, que habla con KVM. La CPU impone el aislamiento de memoria. Un guest comprometido no puede tocar el host a menos que el atacante encuentre un bug del hipervisor. Esa es una superficie de ataque mucho más pequeña que todo el kernel de Linux. KVM no es invencible _—el_ KVM CTF_de Google ha pagado grandes recompensas por escapes—_ pero la tasa de bugs es órdenes de magnitud menor que la de LPEs del kernel. Proyectos como Firecracker (usado por AWS Lambda y Fargate), Kata Containers y gVisor (un kernel en espacio de usuario que intercepta syscalls) ofrecen un aislamiento más fuerte para cargas de trabajo no confiables. Enfoque | Mecanismo de aislamiento | Superficie de ataque | Uso típico ---|---|---|--- Contenedores | Namespaces + cgroups | Kernel del host | Cargas de trabajo confiables, empaquetado MicroVMs | Virtualización por hardware (KVM) | Hipervisor + VMM | Código multitenant no confiable gVisor | Kernel en espacio de usuario | Superficie de syscalls de gVisor | Sandboxing, serverless ## Qué hacer si ejecutas código no confiable Si tu modelo de amenaza incluye código malicioso, los contenedores por sí solos no son suficientes. Aquí tienes una lista práctica: * Usa microVMs o runtimes en sandbox para cargas de trabajo multi-tenant o no confiables. * En Kubernetes, usa `RuntimeClass` para seleccionar Kata Containers, Firecracker o gVisor para pods sensibles. * Aplica hardening en los contenedores de todas formas: quita capabilities, habilita seccomp, AppArmor/SELinux, rootfs de solo lectura y ejecuta como non-root. * Separa zonas de confianza: nodos distintos para inquilinos distintos. * Aplica parches a los kernels rápido, pero no confíes en ganar la carrera. * Monitorea CVEs y ten un plan de respuesta a incidentes que asuma que el escape es posible. Los contenedores siguen siendo excelentes para empaquetado, densidad y orquestación. No son un límite de seguridad fuerte contra exploits del kernel. Si necesitas un límite, pon un hipervisor o un kernel en espacio de usuario en el medio. El kernel es código. El código tiene bugs. La IA los está encontrando más rápido. Elige tus límites en consecuencia. ## Referencias * Página de manual de namespaces de Linux * Página de manual de clone(2) * KVM * microVM Firecracker * Kata Containers * gVisor * CVE-2016-5195: Dirty COW * Blog de seguridad de Google – KVM CTF * Depth First

Si tu servidor web todavía usa una configuración heredada de 2015, no hace falta que una IA rebelde quiera dominar el mundo: probablemente ya dejaste la puerta entreabierta para cualquier bot de Shodan. La herramienta de Vulnerable.cl no evitará la singularidad, pero al menos puede ayudarte a que tu `nginx.conf` o tu `apache2.conf` no sean el equivalente digital de un candado de papel. Este artículo explica por qué conviene auditar Nginx y Apache, qué patrones de configuración suelen generar vulnerabilidades y cómo usar una herramienta que analiza todo localmente, sin subir tu configuración a ningún servidor. ## Por qué importa auditar la configuración de un servidor web Nginx y Apache son la puerta de entrada de la mayoría de las aplicaciones web. Una mala configuración de seguridad figura en el OWASP Top 10 2021 como A05: Security Misconfiguration. No se trata solo de parches: directivas débiles, headers ausentes, TLS obsoleto o permisos excesivos pueden exponer información sensible, facilitar ataques de clicjacking, permitir _sniffing_ de MIME o abrir rutas internas que no deberían ser públicas. La auditoría de hardening no es un trámite único. Cada vhost, cada `location`, cada `Directory` y cada reverse proxy puede introducir una desviación nueva. Por eso conviene revisar la configuración efectiva, no solo la plantilla base. ## Los sospechosos de siempre La herramienta de Vulnerable.cl se enfoca en varios problemas comunes. Estos son los más rentables si quieres cerrar brechas rápido. ### Headers "flojos" Los headers HTTP de seguridad son baratos de implementar y su ausencia es fácil de detectar. Los principales que deberías evaluar: Header | Objetivo ---|--- `Strict-Transport-Security` | Forzar HTTPS y evitar degradación a HTTP. `X-Content-Type-Options` | Evitar el _MIME sniffing_. `X-Frame-Options` o `Content-Security-Policy: frame-ancestors` | Prevenir clicjacking. `Referrer-Policy` | Limitar la fuga de información en la URL de referencia. `Permissions-Policy` | Restringir APIs del navegador como cámara, micrófono o geolocalización. `Content-Security-Policy` | Reducir el impacto de inyecciones de contenido. Ejemplo básico para Nginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "DENY" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always; Para Apache, con `mod_headers`: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" Header always set X-Content-Type-Options "nosniff" Header always set X-Frame-Options "DENY" Header always set Referrer-Policy "strict-origin-when-cross-origin" Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()" La `Content-Security-Policy` conviene definirla por aplicación, no copiarla de un blog sin entenderla. Una CSP mal hecha puede romper recursos legítimos y no aporta seguridad real. ### TLS a medias TLS 1.0 y TLS 1.1 están oficialmente deprecados según la RFC 8996. Si tu servidor todavía los acepta, no estás “manteniendo compatibilidad”: estás ofreciendo una vía de downgrade. Lo mismo aplica para cifrados RC4, `SSLv3` o suites exportables. En Nginx, una base moderna sería: ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_tickets off; En Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 SSLHonorCipherOrder off No copies estos fragmentos sin contexto: usa el generador de configuraciones SSL de Mozilla para obtener una configuración coherente con tu versión de servidor y tus clientes. ### Permisos raros Activar el listado de directorios, permitir acceso a archivos ocultos o dejar expuestos `.git`, `.env`, backups o archivos de configuración es regalar información. En Nginx, `autoindex off` debería ser la norma y conviene denegar explícitamente los dotfiles: autoindex off; location ~ /\. { deny all; } location ~ ^/(\.git|\.env|backup) { deny all; } En Apache: Options -Indexes <FilesMatch "^\.|\bbackup\b"> Require all denied </FilesMatch> Los permisos del sistema de archivos también importan: los archivos de configuración no deberían ser legibles por cualquier usuario del equipo. Un `chmod 640` y un propietario `root:root` son una base más limpia que un `chmod 777`. ### Configuraciones heredadas de 2015 La herencia no es vintage: es deuda técnica con exploits. Apache 2.2 dejó sintaxis como `Allow from all`, `Order allow,deny` y `Deny from all`. Apache 2.4 usa `Require all granted` o `Require all denied`. Nginx también tuvo cambios: el clásico `ssl on;` desapareció en favor de `listen 443 ssl;`. Si tu configuración mezcla sintaxis antigua con módulos modernos, las herramientas estáticas saltarán con avisos. A veces no es explotable directamente, pero indica que nadie revisó la configuración desde que el servidor se puso en producción. ## Análisis local: por qué es importante Vulnerable.cl plantea un punto interesante: el análisis ocurre en tu navegador. No hay backend, no hay cuentas, no se sube ni se guarda nada. La configuración nunca sale de tu equipo. Eso importa porque un `nginx.conf` puede contener rutas internas, IPs, cabeceras de autenticación, certificados o vhosts que no quieres pegar en un servicio web cualquiera. Si el análisis fuera remoto, estarías compartiendo un mapa de tu infraestructura. Al ejecutarse como JavaScript local, reduces la superficie de exposición. Eso sí: si tu paranoia es nivel productivo, abre las DevTools y revisa la pestaña de red antes de pegar el archivo. Verifica que no haya llamadas salientes. La herramienta se presenta como local, pero en seguridad siempre conviene confirmar. ## Cómo usar Vulnerable.cl El flujo es simple: 1. Ve a Vulnerable.cl/hardening/hardening.html. 2. Pega tu `nginx.conf`, tu `apache2.conf` o fragmentos relevantes de `.htaccess`. 3. Revisa los hallazgos y las recomendaciones. 4. Aplica solo los cambios que entiendas. 5. Valida la sintaxis antes de recargar: # Nginx nginx -t && systemctl reload nginx # Apache apachectl configtest && systemctl reload apache2 No apliques configuraciones de hardening a ciegas. Un header mal puesto puede romper un frontend, un CSP demasiado estricto puede bloquear recursos legítimos y un TLS moderno puede dejar fuera clientes viejos que tu negocio aún necesita. ## Limitaciones y verificación real Una herramienta que analiza el archivo de configuración no reemplaza una auditoría activa. No puede, por ejemplo, comprobar el handshake TLS real, detectar permisos incorrectos en el sistema de archivos ni simular un ataque. Es una primera capa de revisión. Para complementar, usa: * Mozilla Observatory para evaluar headers y TLS desde fuera. * SSL Labs para el análisis del protocolo. * OWASP Secure Headers Project para entender cada header. * Los benchmarks CIS de Apache y Nginx para una base más formal. También conviene extraer la configuración efectiva con `nginx -T` o `apachectl -S`. A veces un archivo parece limpio, pero un include secundario introduce una directiva que lo cambia todo. ## Conclusión En ciberseguridad no se compite, se colabora. La propuesta de Vulnerable.cl —hecha en Chile y liberada para la comunidad— va en esa línea: una herramienta gratuita que respeta la privacidad de tu configuración y te entrega una revisión rápida de hardening. La próxima vez que digas “vulnerable”, que sea `.cl`. Y si una IA decide actuar por cuenta propia, al menos que no encuentre tu `nginx.conf` con `autoindex on`, TLS 1.0 y un `.env` servido como descarga. ## Referencias * Vulnerable.cl - hardening de servidores * Vulnerable.cl * OWASP Top 10 2021: A05 Security Misconfiguration * OWASP Secure Headers Project * Mozilla SSL Configuration Generator * RFC 8996: Deprecating TLS 1.0 and TLS 1.1 * Documentación de Apache mod_headers * Documentación de Apache mod_ssl * Mozilla Observatory * SSL Labs * Publicación original en LinkedIn

El gobierno chileno finalmente oficializó lo que el sector privado venía anticipando con inquietud: la entrada en vigencia de la Ley 21.719, sobre protección y tratamiento de datos personales, se posterga por un año. El proyecto ingresó al Senado con suma urgencia, en una movida que busca darle aire a la institucionalidad encargada de fiscalizar una de las normativas más relevantes de la era digital en Chile. Para quienes trabajamos en tecnología, esta prórroga no es solo una noticia legal: es una señal de que la privacidad dejará de ser un tema teórico para convertirse en un requisito operacional concreto. > La postergación de la Ley 21.719 es, en el fondo, un acto de realismo institucional. Montar una agencia reguladora, designar a sus consejeros, definir su presupuesto y ponerla a operar en menos de un año era una misión poco realista. Pero para la industria, la prórroga no debería leerse como una invitación a la inacción, sino como una oportunidad para llegar preparados. Gobierno de Chile postergaría implementación de la Ley de Protección de Datos PersonalesEl Ejecutivo ha sido incapaz de conformar el Consejo Directivo de la nueva Agencia de Protección de Datos Personales, el organismo encargado de fiscalizar el cumplimiento de la norma.SREDevOps.orgNicolás Georger ## Un aplazamiento anunciado El proyecto, del que dio cuenta la sesión del Senado del 1 de septiembre de 2026, modifica la Ley 21.719, que regula la protección y el tratamiento de los datos personales y crea la Agencia de Protección de Datos Personales. Según reportó Claudia Rivas en Diario Financiero, la iniciativa del Ejecutivo consta de un artículo único y dos artículos transitorios, y traslada la entrada en vigencia de la ley hasta el 1 de diciembre de 2027. El argumento oficial, defendido por el biministro de Economía, Daniel Mas, es que la nueva legislación debe operar con una institucionalidad preparada, reglas claras y condiciones que permitan su adecuado cumplimiento. En otras palabras: más vale tarde y funcionando, que temprano y a medias. Para una ley que crea una agencia reguladora desde cero, el plazo adicional no es un lujo; es una necesidad operativa. ## Qué cambia con el proyecto de ley ### Nuevas fechas clave El cambio principal es el desplazamiento de la fecha de entrada en vigencia al 1 de diciembre de 2027. Pero el proyecto también introduce hitos intermedios que las empresas deben tener en el radar: Hito | Fecha estimada ---|--- Publicación de la ley que posterga | Durante 2026 Primera designación de consejeros de la Agencia | A más tardar el 1 de diciembre de 2026 Entrada en vigencia de la Ley 21.719 | 1 de diciembre de 2027 Un artículo transitorio adicional es particularmente interesante: si a la fecha de publicación de esta reforma faltaran menos de 12 meses para la entrada en vigencia, la primera designación de consejeros deberá realizarse dentro de los 10 días siguientes a la publicación. Es una cláusula de contingencia que evita que el nombramiento quede a la deriva por demoras parlamentarias. ### Un Consejo Directivo más amplio El proyecto aumenta de tres a cinco los consejeros del Consejo Directivo de la Agencia de Protección de Datos Personales, y establece que este consejo se renovará parcialmente cada dos años. La ampliación busca darle mayor pluralidad y resiliencia al órgano rector, pero también implica un desafío de coordinación. Desde el nombramiento, los consejeros recibirán remuneración mensual, con dedicación exclusiva e incompatibilidades para evitar conflictos de interés. Esto es clave: una agencia de protección de datos cuyos directores sigan trabajando para las empresas reguladas sería un chiste de mal gusto. ### Financiamiento y transición El segundo artículo transitorio establece que el mayor gasto fiscal que represente la aplicación de la norma durante su primer año de vigencia se financiará con los recursos contemplados en el presupuesto del Ministerio de Economía y, de ser necesario, con cargo a la Partida Presupuestaria del Tesoro Público. En cristiano: la implementación no quedará sujeta a la improvisación presupuestaria, al menos sobre el papel. ## Qué significa para el sector tecnológico Para quienes trabajamos en SRE, DevOps, desarrollo de software o infraestructura, esta noticia tiene dos lecturas. La primera es que el plazo para adecuar sistemas, contratos y operaciones se extiende. La segunda, más importante, es que se acaba el tiempo de esperar a que la ley se materialice para recién empezar a mover fichas. La experiencia internacional —con el GDPR europeo como referente ineludible— muestra que las leyes de protección de datos no se cumplen con una política de privacidad bonita en el sitio web. Se cumplen con inventarios de datos, con mapas de flujo de información, con controles de acceso, con registros de actividades de tratamiento, con notificación de brechas en plazos perentorios y con un delegado de protección de datos que tenga poder real dentro de la organización. ### Privacidad como requisito técnico Para un equipo de ingeniería, la privacidad desde el diseño significa integrar protección de datos en cada etapa del ciclo de vida del software. Algunos ejemplos prácticos: * **Minimización de datos** : no almacenar información que no necesitas. Pregúntate: ¿realmente necesito el RUT para esta transacción? ¿Puedo usar un identificador seudonimizado? * **Cifrado** : en reposo y en tránsito, sin excepciones. Si un atacante obtiene una copia de seguridad, que no obtenga también datos personales legibles. * **Gestión de accesos** : privilegios mínimos, auditoría de accesos a bases de datos con PII y alertas ante accesos anómalos. * **Retención y borrado** : políticas automatizadas de eliminación de datos después del cumplimiento de su finalidad. El almacenamiento infinito es un riesgo, no una ventaja. * **Notificación de brechas** : tener un runbook claro para responder a incidentes de datos personales, incluyendo plazos de notificación a la autoridad y a los afectados. La postergación de la ley no elimina estas obligaciones; solo les cambia la fecha límite. Si tu organización aún no ha comenzado un análisis de brechas frente a la Ley 21.719, este es el momento de hacerlo. La próxima prórroga no está garantizada, y la historia regulatoria demuestra que las autoridades tienden a ser menos flexibles una vez que la institucionalidad está funcionando. ## Cómo usar este tiempo extra Sugiero convertir estos aproximadamente quince meses en un plan de trabajo concreto. Una buena hoja de ruta podría verse así: 1. **Inventario de datos** : identifica qué datos personales almacenas, de dónde provienen, a quién se los compartes y bajo qué base legal. 2. **Análisis de brechas** : compara tus prácticas actuales con los principios de licitud, finalidad, proporcionalidad y seguridad que exige la ley. 3. **Designación de un delegado** : aunque la ley aún no esté plenamente vigente, tener una persona responsable de privacidad desde antes facilita la transición. 4. **Actualización de contratos** : revisa acuerdos con proveedores que traten datos en tu nombre. Los encargados de tratamiento deben estar formalmente regulados. 5. **Implementación técnica** : despliega herramientas de clasificación de datos, cifrado, gestión de accesos y logging. La seguridad de los datos es un componente no funcional, no una feature. 6. **Pruebas y simulacros** : realiza ejercicios de respuesta a incidentes de brecha. El día que ocurra de verdad, no querrás descubrir que tu plan tiene fallas. Para los equipos de plataforma, la privacidad puede incorporarse como políticas como código, utilizando herramientas como Open Policy Agent (OPA) para enforce reglas de acceso a datos, o HashiCorp Vault para centralizar la gestión de secretos. La automatización es la mejor aliada: un control automatizado y probado vale más que mil manuales de procedimiento. ## Notas finales La postergación de la Ley 21.719 es, en el fondo, un acto de realismo institucional. Montar una agencia reguladora, designar a sus consejeros, definir su presupuesto y ponerla a operar en menos de un año era una misión poco realista. Pero para la industria, la prórroga no debería leerse como una invitación a la inacción, sino como una oportunidad para llegar preparados. La historia reciente de las regulaciones tecnológicas demuestra que las empresas que se toman en serio la privacidad desde el principio no solo evitan multas: construyen confianza con sus usuarios y reducen riesgos operativos. En un mundo donde los datos son el nuevo petróleo, la refinería debe cumplir con las normas ambientales. O, dicho sin metáforas: si no implementas la protección de datos porque la ley se atrasó, no te sorprendas cuando el regulador te atrase a ti con una sanción. El momento de actuar es ahora. La ley llegará en diciembre de 2027; la pregunta es si tu infraestructura estará lista. ## Referencias * Rivas, C. (2026, septiembre 1). _Gobierno ingresa al Congreso proyecto que posterga por un año la entrada en vigencia la Ley de Protección de Datos_. Diario Financiero. https://www.df.cl/economia-y-politica/congreso/gobierno-ingresa-al-congreso-proyecto-que-posterga-por-un-ano-la-entrada-en * SRE DevOps (2026). _Gobierno de Chile postergaría implementación de la Ley de Protección de Datos Personales_. https://www.sredevops.org/es/gobierno-de-chile-postergaria-implementacion-de-la-ley-de-proteccion-de-datos-personales.md * Biblioteca del Congreso Nacional de Chile. _Ley 21.719 sobre protección de datos personales_. https://www.bcn.cl/leychile

Cuando DHH dice que es momento de soñar en grande, conviene prestarle atención. Es el creador de Ruby on Rails, pasó años en `Basecamp/37signals` y ahora lidera Omarchy. El 20 de agosto de 2026, a través de Omarchy News, soltó su última idea: el futuro de la computación no debería estar encerrado en una caja de aluminio sellada. > Por supuesto, hay un detalle. Las fundaciones son tan buenas como su gobernanza. El anuncio no incluye un presupuesto público, una lista del directorio, ni una hoja de ruta a cinco años. Eso está bien para el día uno. Pero la prueba real vendrá después: ¿la fundación realmente financiará a mantenedores independientes sin ataduras? ¿Defenderá su marca registrada de la manera que una comunidad querría? ¿Gastará dinero en cosas aburridas como honorarios legales e infraestructura de CI, o terminará siendo solo marketing? El anuncio es muy de él: breve, directo y sin pedir permiso. Según escribe, Omarchy Quattro les dio a las personas _"la oportunidad de experimentar cómo se ve el computador maleable del futuro, y les encanta (¡muchísimo!)."_ Así que ahora siente una _"obligación moral"_ de hacer que ese futuro sea accesible para todos. Por eso está creando la **Fundación Omacom** , una organización sin fines de lucro que tendrá las marcas registradas, financiará la infraestructura, promoverá el proyecto y apoyará a los desarrolladores y proyectos de código abierto de los que Omarchy depende. **Y sí, viene con $8 millones incluidos.** ### La pregunta de los ocho millones La fundación arranca con ocho Patrocinadores Fundadores, cada uno poniendo un millón de dólares. La lista no es casualidad. Incluye a Tobi Lütke de Shopify, Patrick Collison de Stripe, Michael Dell de Dell Technologies, Jack Dorsey de Block, Matthew Prince de Cloudflare, Brendan Iribe de Sesame y Oculus, Jason Fried de 37signals, y el propio DHH. Patrocinador | Rol | Organización ---|---|--- Tobi Lütke | CEO | Shopify Patrick Collison | CEO | Stripe Michael Dell | Presidente y CEO | Dell Technologies Jack Dorsey | Block Head y Presidente | Block Matthew Prince | CEO | Cloudflare Brendan Iribe | Cofundador | Sesame y Oculus Jason Fried | CEO | 37signals DHH | Fundador | Omarchy La lista dice algo importante: no son inversores de cripto buscando una salida rápida. Son gente que ha construido empresas enormes sobre el código abierto y las herramientas para desarrolladores. Varios son casi vecinos del mundo de DHH: Shopify corre sobre Rails, Stripe tiene raíces profundas en Ruby, 37signals es Rails, y Cloudflare sabe bastante de correr Linux a escala. Como dice DHH: _"Es una suma ridícula de dinero, así que pienso asegurarme de que dure mucho tiempo y que le saquemos el máximo provecho. Pero tan importante como el colchón increíble es el voto de confianza que representan estos compromisos."_ ### Qué compra realmente una fundación Una fundación sin fines de lucro no es una startup. No tiene accionistas, ni eventos de liquidez, ni una tabla de capitalización amigable con el fundador. Y ese es el punto. Una fundación puede tener marcas registradas y defenderlas. Puede financiar infraestructura que ninguna empresa individual pueda poseer. Puede apoyar a los mantenedores de código abierto que de otra manera terminarían agotados o comprados. La misión de la Fundación Omacom es amplia a propósito: tener las marcas, financiar la infraestructura, promover el trabajo, y apoyar los proyectos y desarrolladores de los que Omarchy depende. En otras palabras, el trabajo poco glamoroso que mantiene vivo el software de código abierto. No se trata de un comunicado de prensa ingenioso. Se trata del fierro: protección legal, pipelines de compilación confiables, cuentas de hosting y pagarles a los mantenedores para que sigan haciendo su trabajo, en vez de buscar otro puesto en una gran tecnológica. El mundo del código abierto está lleno de fundaciones que hacen algo parecido. La Linux Foundation aloja miles de proyectos, la Cloud Native Computing Foundation pastorea Kubernetes, y Mozilla y Signal han demostrado que las organizaciones sin fines de lucro con misión pueden sobrevivir e incluso prosperar. Una fundación le da a un proyecto un hogar que no se puede arrebatar mediante una adquisición. Ocho millones no es dinero a escala Google. Pero para una fundación enfocada, es suficiente para construir un runway duradero, proteger la marca y financiar a la gente que importa. También le da a Omarchy la capacidad de hacer compromisos que ninguna startup respaldada por capital de riesgo podría hacer: "No necesitamos crecer a cualquier precio. Necesitamos construir el futuro en el que creemos." ### El Año de Linux en el Escritorio, otra vez Hay un chiste viejo en la industria: el Año del Escritorio Linux siempre es el próximo año. Ha estado "por llegar" durante décadas. Y aun así, aunque Linux literalmente energiza internet, la nube y la mayor parte de la infraestructura mundial, el escritorio típico de los consumidores sigue siendo Windows o macOS. Pero algo cambió. El escritorio Linux moderno no es la experiencia enojona y mal configurada de los aficionados de fines de los 90. Es la maravilla de ingeniería detrás del Steam Deck, la base predeterminada para WSL, y el único lugar donde un usuario todavía puede ser dueño de verdad de su entorno computacional. El hardware ya es suficientemente bueno. El software también. Lo que faltaba era un empujón coordinado con dinero real y apoyo institucional real. Y eso parece ser exactamente lo que Amacom quiere aportar. Escribe DHH: > "Vamos a hacer que la profecía del Año de Linux en el Escritorio se haga realidad. Todas las piezas ya están en su lugar. ¡Es hora de ir con todo!" La frase "computador maleable" está haciendo harto trabajo aquí. Sugiere un sistema que los usuarios pueden transformar, extender y de verdad poseer, no un sandbox curado por una empresa de plataforma de un billón de dólares. Es una visión casi violentamente opuesta al modelo de tienda de aplicaciones cerrada. También es, no por casualidad, la promesa original de Linux y el código abierto. Si Omarchy Quattro es un vistazo en funcionamiento de ese futuro, la fundación es el motor institucional para hacerlo duradero. Las marcas registradas, la infraestructura y las subvenciones no son emocionantes. Tampoco lo es el interior de un firewall. Pero sin ellos, la visión muere. ### La parte difícil Por supuesto, hay un detalle. Las fundaciones son tan buenas como su gobernanza. El anuncio no incluye un presupuesto público, una lista del directorio, ni una hoja de ruta a cinco años. Eso está bien para el día uno. Pero la prueba real vendrá después: ¿la fundación realmente financiará a mantenedores independientes sin ataduras? ¿Defenderá su marca registrada de la manera que una comunidad querría? ¿Gastará dinero en cosas aburridas como honorarios legales e infraestructura de CI, o terminará siendo solo marketing? DHH se ha ganado algo de escepticismo. Pero también se ha ganado una trayectoria de poner productos reales en el mundo y pensar a largo plazo. Y no está solo. La lista de patrocinadores no es un grupo de turistas aprovechadores. Es gente que entiende la infraestructura, las herramientas para desarrolladores y el valor de ser dueño de tu propio stack. ### Puntos clave En definitiva, la Fundación Omacom es una jugada audaz, extrañamente romántica para una industria que suele hablar del código abierto a través del lente de las licencias, las auditorías y los costos de adquisición de clientes. Es una apuesta a que el futuro de la computación debería ser abierto, maleable y propiedad de sus usuarios. ¿Funcionará? La historia dice que el escritorio Linux es un cementerio de hermosas ambiciones. Pero la historia también dice que cada gran cambio de plataforma viene de lugares improbables y de creyentes obstinados con el dinero y la arrogancia suficientes para hacerlo realidad. Ocho millones de dólares no hacen realidad la profecía por sí solos. Pero es suficiente para financiar un intento real. Y por primera vez en mucho tiempo, quizás el Año de Linux en el Escritorio no es una broma. Es una partida en el presupuesto de una organización sin fines de lucro. > Es hora de ir con todo. Fuente: La Fundación Omacom se lanza con $8 millones — DHH, Omarchy News, 20 de agosto de 2026

💬 __Los agentes pueden escribir más del código. Los ingenieros pasarán más tiempo revisando, clasificando y conduciendo.___****Pero si no puedes saber por qué un sistema está roto, no puedes arreglarlo.****___Si no puedes saber si un producto es realmente bueno, no puedes ser dueño del resultado.__ Elizabeth Stone, Chief Product and Technology Officer de Netflix, volvió al podcast de Lenny con un mensaje que resonará con cualquiera que sienta su trabajo amenazado y su futuro incierto : la IA ha creado una "fase de tormenta" para el trabajo en sí mismo. La solución no es meter la IA de vuelta en el cajón ni enterrar la confusión o los riesgos bajo más procesos. Es contratar y desarrollar más **pensadores sistémicos**. La conversación de Stone cubre escalafones profesionales, el _keeper’s test_ , la _densidad de talento_ , el futuro del entretenimiento y **por qué "todos pueden ser todo ahora" es a la vez una oportunidad y un dolor de cabeza para el liderazgo.** ## Conclusiones clave * La IA está produciendo una fase de tormenta antes de una fase de formación. Eso es normal, pero no significa que todos deberían estar desplegando en producción. * La excelencia en el oficio sigue siendo escasa. La gran ingeniería, la gran ciencia de datos y la gran creatividad siguen siendo difíciles de encontrar. * El pensamiento sistémico es la nueva especialización: personas que pueden abstraer a través de dominios de negocio en bloques de construcción reutilizables. * La especialización estrecha y profunda se está volviendo más riesgosa. Los generalistas y los especialistas adaptables tienen la ventaja. * La fluidez en IA es una capa extra sobre los escalafones profesionales, no una reescritura de cada nivel. * El sistema operativo de Netflix sigue siendo densidad de talento, tolerancia al riesgo y una negativa testaruda a dejar que el proceso reemplace al juicio. ## La fase de tormenta: todos pueden ser todo ahora Stone escucha la misma pregunta de los equipos dentro de Netflix que Lenny escucha de la industria en general: "¿Y ahora cuál es mi pega?" > "Cada vez que aparece una tecnología nueva, pasas por una fase de tormenta antes de la fase de formación. Estamos en medio de eso ahora mismo. No creo que eso signifique que debamos meter la IA de vuelta en la caja y decir: ‘No la usemos’." El desdibujamiento es real: los PMs pueden prototipar código. Los diseñadores pueden escribir PRDs. Los ingenieros pueden hacer producto. Los científicos de datos pueden generar análisis antes de que un ingeniero siquiera abra un ticket. ¿La visión de Stone? Algo de fluidez es sano, pero solo cuando el problema de negocio está claro: * Producto y diseño deberían poder moverse más rápido sin esperar a que ingeniería asigne recursos para un prototipo. * De todas formas, deberían trabajar con ingeniería en escalabilidad, seguridad y en cómo convertir la idea en producto. * Y un humano sigue siendo dueño del resultado. > "Puede ser que un agente haya escrito el código, o que yo haya ayudado con un análisis cuando esa no es realmente mi área, pero eso no quita la responsabilidad de las personas sobre lo que han creado." La respuesta no es "meter la IA de vuelta en la caja". Es invertir en datos de fuente de verdad, salvaguardas e infraestructura compartida para que la experimentación no se convierta en mil prototipos espagueti desconectados. ## El oficio sigue importando—especialmente cuando la IA escribe el primer borrador Si todos son creadores, ¿siguen existiendo funciones separadas? La respuesta de Stone es un sí enfático. > "Todavía veo una excelencia en el oficio que es muy importante y que no creo que vaya a desaparecer pronto. Sigo viendo que la gran ingeniería es escasa, la gran ciencia de datos es escasa y la gran creatividad es escasa." Ella ve ventajas comparativas que persisten: * Los **científicos de datos** son dueños de si los datos son confiables y de cómo interpretarlos. * Los **PMs** son dueños de si el problema fue planteado correctamente. * Los **ingenieros** son dueños de cómo escalan los sistemas, cómo se rompen y cómo se ve una producción de alta calidad. La IA puede ayudar a que todos hablen más de estos lenguajes, pero no reemplaza el juicio que viene del oficio profundo. ## El pensamiento sistémico es la nueva especialización El mayor cambio de contratación que Stone ve en Netflix no es "más ingenieros de IA" ni "menos PMs". Es una demanda por personas que puedan pensar a través de dominios. > "Necesitamos más pensadores sistémicos—personas que puedan mirar todos los dominios de negocio y abstraer eso en ‘estos son los bloques de construcción que vamos a necesitar’." En ingeniería, eso significa más inversión en infraestructura central, caminos comunes pavimentados y bloques de construcción compartidos. Netflix históricamente dejaba que los equipos locales construyeran lo que necesitaran para moverse rápido. En un mundo de agentes de IA, ese enfoque se convierte en una responsabilidad. Los agentes necesitan datos de fuente de verdad. Necesitan consistencia en control de acceso y seguridad. Necesitan formas de trabajo comunes. Así que Netflix está contratando más personas que puedan diseñar el río completo, no solo navegar un rápido. El mismo patrón aparece en el diseño. > "Me pongo muy nerviosa cuando hay diferentes lenguajes de diseño o diferentes tipos de interacciones de usuario y terminamos enviando Frankensteins, básicamente." Se espera cada vez más que los diseñadores construyan sistemas de diseño, plantillas y expresión de marca que permitan a los no diseñadores producir experiencias coherentes. El oficio no ha desaparecido; ha subido un nivel en la stack. ## El declive del especialista "estrecho" Stone tiene cuidado de no declarar extintos a los especialistas. Todavía hay lugares donde la experiencia profunda en un tema es esencial: codificación, sistemas de reproducción, marketplaces publicitarios y otros rincones de Netflix que requieren años de conocimiento acumulado. Pero como regla general, la era del especialista estrecho se ve limitada. > "Los días de la especialización muy estrecha y profunda me parecen más limitados." En comparación con hace cinco o diez años, Stone ve menos especialistas y más generalistas adaptables. También ve un problema de mentalidad en personas que quieren quedarse en un solo carril estrecho: > "Creo que la mentalidad ahora tiene que ser: ‘Puedo aprender eso rápido’. Y eso nos lleva de vuelta al pensamiento sistémico. Creo que los especialistas pueden aprender a tener una variedad más amplia de herramientas más fácilmente de lo que era posible en el pasado." El riesgo no es tener una especialidad. El riesgo es tratar tu especialidad como un refugio permanente. ## Cómo practicar el pensamiento sistémico: Detenerse y retroceder un paso A Stone le preguntan cómo desarrollar el pensamiento sistémico. Su consejo es refrescantemente práctico: > "Truco pequeño: Para cada problema que intentas resolver, detente, retrocede un paso y pregúntate: ‘¿Qué estoy asumiendo como cierto sobre el contexto más amplio?’" Por ejemplo, si te piden construir una feature para la experiencia de los miembros de Netflix, **haz una pausa antes de escribir una línea de código** : * ¿Qué problema más grande del consumidor está resolviendo esto? * ¿Qué estoy asumiendo sobre el contenido, los dispositivos o los casos de uso? * ¿Podría esto convertirse en una capacidad compartida para varios equipos? * ¿Cómo ayuda esto al negocio en general, no solo a mi equipo? * ¿El jefe de mi jefe seguiría pensando que este es el problema correcto? No necesitas resolver toda la estrategia de Netflix. Solo necesitas alejar el zoom un nivel, cuestionar tus supuestos y luego volver a entregar. > "No me quedaría mucho tiempo en el estado de cuestionamiento, porque te quedas atascado y no avanzas." ## Fluidez en IA como una capa adicional, no una reescritura del escalafón Netflix es conocida por no ser una empresa de "escalafón profesional" en el sentido tradicional de las grandes tecnológicas. Cuando agregaron niveles y expectativas, Stone no intentó reescribir cada peldaño para la IA. En cambio, Netflix agregó una **capa de fluidez en IA** en todos los roles y niveles. La fluidez en IA se ve distinta según la función y la etapa profesional, pero incluye: * Una mentalidad de experimentación. * Saber dónde la IA es útil y dónde no. * Construir cosas de verdad con IA. * Sentirse cómodo con la ambigüedad y el cambio rápido. Stone dice que la definición evoluciona casi mensualmente porque la tecnología avanza muy rápido. El objetivo no es forzar la IA en todo flujo de trabajo. Es desarrollar juicio sobre cuándo y cómo usarla. Netflix incluso cambió sus prácticas de entrevista: los candidatos pueden usar herramientas de IA en entrevistas de programación, porque así será el trabajo real. ## La excelencia como sistema operativo Lenny señala que el famoso culture deck de Netflix ahora suena exactamente como se describen los laboratorios de IA de frontera: alta agencia, autonomía, alta densidad de talento, decisiones de abajo hacia arriba y sueldos en el tope del mercado. Stone llama a esto "la excelencia como sistema operativo". > "La cultura de Netflix siempre ha sido la excelencia como sistema operativo. Es una resistencia a hacer lo que muchas grandes empresas harían, y se trata de sentirse cómodo en esa incomodidad muy a menudo." Los pilares, tal como los describe ella: * **La densidad de talento no es negociable.** No puedes empujar las decisiones hacia las profundidades de la organización a menos que la gente en todos los niveles sea excepcional. * **Comodidad con la toma de riesgos.** Netflix está dispuesto a ser imperfecto, moverse rápido y recuperarse rápido. * **Contexto, no control.** Los líderes deberían ayudar a las personas a ver el panorama completo, no microgestionar cada decisión. * **Resistencia al teatro de procesos.** Cuando las cosas salen mal, el instinto de agregar un nuevo proceso es fuerte. Stone dice que el mejor reflejo suele ser una retro sin culpables y un compromiso para mejorar. > "La inclinación de todos, cuando las cosas son difíciles y complicadas, es pensar que estás simplificando el problema al ponerle muchas restricciones alrededor. Pero en realidad va contra preguntarse: ‘¿Hay una forma más creativa de planificar, o de tomar decisiones de personal, o de tomar decisiones de priorización, que realmente nos lleve a mejores resultados?’" ## El keeper’s test no es solo una herramienta de despido El keeper’s test es conocido por ser esa prueba de si pelearías por mantener a alguien si dijera que se va. Stone dice que también es una herramienta de retroalimentación positiva. > "Es una puerta de entrada a una conversación que es muy positiva y edificante para las personas, pero el marco es: ‘¿Paso el keeper’s test?’" El lado difícil todavía existe. Si sientes alivio cuando alguien se va, probablemente esperaste demasiado para tener una conversación difícil. El keeper’s test es una forma de higiene: te obliga a revisar si tus estándares siguen siendo reales, o si solo estás reteniendo a alguien porque dejarlo ir sería incómodo. ## Contratar y desarrollar talento en un mundo de laboratorios de frontera La competencia por talento tecnológico de élite es brutal. Los laboratorios de frontera pueden ofrecer paquetes de compensación enormes y la oportunidad de entrenar modelos que nadie ha construido. Stone no ve a Netflix perdiendo esa pelea, porque Netflix ofrece algo diferente: * El punto dulce donde se encuentran tecnología, producto y entretenimiento. * Productos de consumo usados por cientos de millones de personas. * Un negocio global que abarca cine, TV, juegos, eventos en vivo y herramientas emergentes de IA. * La capacidad de dar forma al entretenimiento mismo. > "Hay muchísimas personas increíblemente talentosas que aman ese punto dulce—yo soy una de ellas—entre tecnología, producto y entretenimiento." Netflix también está contratando gente junior. Los programas para recién graduados y pasantes son ahora una parte central de la estrategia de talento. Las personas en etapas tempranas de carrera tienden a ser más nativas con las herramientas de IA y más fluidas en cómo están cambiando el entretenimiento y el comportamiento del consumidor. Pero todavía necesitan mentoría en el oficio. > "El dominio del oficio sigue siendo muy importante. Sigues teniendo la responsabilidad de revisar código, probar código, poder diagnosticar problemas y saber cómo se ve un buen producto." La preocupación de que "la gente junior nunca aprende porque la IA hace todo el trabajo" es real. La respuesta de Stone: las herramientas cambian, pero la responsabilidad no. ## Ingeniería en cinco años: entender más, escribir menos Lenny hace una pregunta que todo ingeniero está pensando: ¿la gente todavía necesitará entender código en cinco o diez años? Stone establece una distinción importante entre **escribir código** y **entender cómo funcionan los sistemas de software**. > "Hay una diferencia entre poder escribir líneas de código en un lenguaje particular, como Python o C++, y entender cómo funcionan el código, los sistemas computacionales y los productos. No creo que lo segundo vaya a desaparecer." Los agentes pueden escribir más del código. Los ingenieros pasarán más tiempo revisando, clasificando y conduciendo. Pero si no puedes saber por qué un sistema está roto, no puedes arreglarlo. Si no puedes saber si un producto es realmente bueno, no puedes ser dueño del resultado. Stone admite que el código generado por agentes puede ser difícil de seguir: > "Sé que estoy obteniendo mejor rendimiento con esto, pero no tengo idea de por qué. Y si esto se rompe, no tengo idea de cómo arreglarlo. Eso me hace sentir incómoda." Esa incomodidad, dice, es parte de la curva de aprendizaje actual. La próxima generación de ingeniería necesitará desarrollar fluidez para guiar agentes, no solo escribir código. ## El futuro del entretenimiento no es una sola cosa Stone espera que el entretenimiento siga fragmentándose en formatos, dispositivos y momentos del día. Netflix ya abarca cine, TV, juegos, eventos en vivo, podcasts y feeds verticales de formato corto como Clips. El resultado es un problema de descubrimiento. > "El futuro del entretenimiento no va a ser una sola cosa. Va a tener que ser más personalizado, más inmersivo y más interactivo, con esta sensación de: ‘Este es un mundo que puedo explorar en muchas direcciones distintas, dependiendo de lo que esté buscando en el momento’." El rol de Netflix es hacer que ese mundo se sienta fluido, no fragmentado. Eso es un desafío de producto e infraestructura tanto como de contenido. ### Las historias humanas siguen siendo la columna vertebral A pesar de todo el hype de la IA, Stone es escéptica del entretenimiento sin humanos al centro. > "Me cuesta imaginar un entretenimiento que no tenga a los humanos en el corazón. Contar historias es una y la misma cosa con la humanidad." La IA ayudará con la previsualización, la localización, los subtítulos, los efectos visuales e incluso con la reiluminación o el reencuadre de metraje después de un rodaje. Netflix recientemente adquirió **InterPositive** , una empresa de postproducción impulsada por IA cofundada por Ben Affleck, para llevar esas capacidades más allá. Pero el núcleo creativo sigue siendo un humano que dice: "Esta es la historia que necesito contar". ## La ventaja inicial de Netflix en IA: del Netflix Prize a InterPositive Netflix ha estado usando machine learning mucho antes de que la "IA" se convirtiera en un símbolo de estatus. El **Netflix Prize** en 2006 invitó a equipos de todo el mundo a mejorar el algoritmo de recomendación de la compañía en un 10%. Se convirtió en un campo de pruebas para el filtrado colaborativo y en un hito en el ML aplicado. Stone ve esa historia como una ventaja: > "Esto no es nuevo para nosotros. Especialmente para la personalización, la IA y el ML han sido centrales para entregar una gran experiencia a los miembros." Lo mismo ocurre en el lado creativo: la IA y el ML se han usado en efectos visuales, subtítulos, doblaje y generación de activos promocionales durante años. La IA generativa (GenAI) simplemente expande el lienzo. ## Referencias * Podcast de Lenny * Netflix Tech Blog * Cultura de Netflix — Empleos en Netflix * Netflix Prize — Wikipedia * Into Thin Air — Wikipedia * Liar’s Poker — Wikipedia

Para quienes trabajamos en infraestructura, ciberseguridad y gobernanza de datos, los plazos de cumplimiento regulatorio suelen ser el motor de largas noches de café, refactorización de bases de datos y acaloradas discusiones sobre cifrado en reposo. Sin embargo, en el ámbito político, los plazos parecen tener la flexibilidad de un entorno de desarrollo sin control de versiones. El biministro de Economía y Minería de Chile, **Daniel Mas** , confirmó que el Gobierno está evaluando postergar la entrada en vigencia de la esperada **Ley de Protección de Datos Personales (Ley 21.719)**. ¿La razón? El clásico cuello de botella del despliegue: la infraestructura humana no está lista. Específicamente, el Ejecutivo ha sido incapaz de conformar el Consejo Directivo de la nueva **Agencia de Protección de Datos Personales** , el organismo encargado de fiscalizar el cumplimiento de la norma. ## Una agencia sin directores La Ley 21.719, aprobada en 2024, tenía como _fecha de despliegue en producción_ el **1 de diciembre de 2026**. Esta normativa busca elevar los estándares de privacidad de Chile a un nivel equivalente al GDPR (Reglamento General de Protección de Datos de la Unión Europea), un paso crítico para la economía digital del país y su posicionamiento como hub tecnológico regional. No obstante, levantar una agencia estatal desde cero no es tan fácil como hacer un `docker compose up`. El proceso requiere la conformación de un Consejo Directivo de expertos, un trámite que se encuentra completamente estancado: * **Rechazo legislativo:** En mayo de 2026, el Senado rechazó la terna propuesta por el Presidente José Antonio Kast para integrar dicho consejo. * **Plazos vencidos:** En junio de 2026 expiró el plazo legal para nombrar a los consejeros (fijado por ley seis meses antes de la entrada en vigencia de la regulación). * **La solución política:** Ante la imposibilidad de cumplir con el calendario, el Gobierno evalúa enviar un proyecto de ley para modificar los plazos de implementación o, en su defecto, postergar únicamente la puesta en marcha de la Agencia fiscalizadora. ## El impacto en TI: Entre el limbo regulatorio y el alivio temporal Para los equipos de DevOps, SRE y CISO (Chief Information Security Officers) en Chile, esta noticia genera sentimientos encontrados. Por un lado, ofrece un respiro temporal; por el otro, introduce una molesta incertidumbre técnica. ### El dilema de la arquitectura de datos Muchas organizaciones locales y multinacionales ya estaban ejecutando costosos planes de migración y rediseño de arquitectura para cumplir con principios como: * **Privacidad por diseño y por defecto:** Modificación de pipelines de CI/CD para asegurar que los datos sensibles se anonimizen antes de llegar a entornos de staging o testing. * **Derechos ARCO (Acceso, Rectificación, Cancelación y Oposición):** Implementación de microservicios capaces de purgar por completo los datos de un usuario de múltiples bases de datos distribuidas (el siempre complejo "derecho al olvido"). * **Gobernanza de datos en la nube:** Restricciones de soberanía de datos y transferencias internacionales. Una postergación significa que los presupuestos asignados a estos proyectos de cumplimiento podrían congelarse o reasignarse, dejando a los equipos de seguridad con arquitecturas a medio migrar y "deuda técnica de cumplimiento". ### La paradoja de la inteligencia artificial El retraso de esta ley ocurre en un contexto complejo. Recientemente, se han levantado alertas sobre iniciativas que buscan flexibilizar el uso de contenidos para el entrenamiento de modelos de Inteligencia Artificial (IA) sin controles estrictos de propiedad intelectual o privacidad. Sin una Ley de Datos Personales robusta y activa, y sin una Agencia técnica que actúe como árbitro, el desarrollo y entrenamiento de modelos de machine learning en el país operará en un "Lejano Oeste" regulatorio. Esto expone a los ciudadanos a la explotación de sus datos y a las empresas a futuros dolores de cabeza cuando la ley finalmente entre en vigor y exija retroactividad o auditorías de sesgo y consentimiento. ## Recomendaciones para SREs y arquitectos de seguridad: No bajen la guardia Aunque el Gobierno decida presionar el botón de "pausa", la recomendación técnica para cualquier organización madura es **no detener los esfuerzos de cumplimiento**. La privacidad de los datos ya no es solo un requisito legal, sino una ventaja competitiva y una buena práctica de ingeniería. 1. **Sigan el estándar GDPR:** La Ley 21.719 está fuertemente alineada con el estándar europeo. Si diseñan sus sistemas pensando en GDPR, estarán cubiertos sin importar los cambios de última hora que decida el Congreso chileno. 2. **Automaticen la gobernanza:** Utilicen herramientas de infraestructura como código (IaC) como Terraform para definir políticas de acceso a datos (IAM) restrictivas y cifrado por defecto en sus buckets de almacenamiento (S3, Cloud Storage). 3. **Implementen observabilidad de seguridad:** No esperen a que la Agencia de Protección de Datos les exija reportar brechas en 72 horas. Establezcan alertas tempranas y flujos de respuesta a incidentes (IR) automatizados hoy mismo. La burocracia estatal puede retrasar las leyes, pero las amenazas de seguridad y las filtraciones de datos no respetan calendarios legislativos. ## Referencias * Gobierno evalúa postergar Ley de Datos Personales - Emol * Ley de Protección de Datos Personales (Ley 21719) - Biblioteca del Congreso Nacional de Chile * Kast impulsa una norma que abre la puerta al uso “sin control” de contenidos de la IA - El País Chile *

_"O cuando la computación dejó de ser un lugar"_ Hubo una época en que podíamos señalar un servidor con el dedo. Allí está la memoria, allí la CPU, esos son los discos y la red es ese desorden de cables detrás del rack. La diferencia con el software se resumía en una frase que muchos repetíamos con una sonrisa: "_El hardware se puede patear; el software, solo maldecir._ " ## La virtualización licuó el hardware**.** A fines de los noventa, la virtualización salió del mundo mainframe y llegó al escritorio, de pronto, el servidor dejó de ser un objeto físico para convertirse en una ilusión administrada por un hipervisor. La tarjeta de red es software, los discos, archivos y la memoria una asignación dinámica. El hardware seguía existiendo, pero desaparecio de nuestro campo visual. ## **Y la nube convirtío lo líquido en gaseoso.** La nube completó esa transformación. Ya no administramos servidores: declaramos estados. No configuramos redes: escribimos manifiestos. No instalamos infraestructura: la versionamos. La infraestructura dejó de ser un conjunto de dispositivos para convertirse en un conjunto de documentos. _Infrastructure as Code_ no convirtió el hardware en software; solo su administración. Y ese cambio impactó también en la ciberseguridad. ## **La complejidad no desaparece. Solo cambia de domicilio.** Durante decadas protegimos equipos, firewalls, routers y sistemas operativos. Incluso los ataques más sofisticados terminaban en un activo físico. Hoy una parte importante de una auditoría consiste en revisar un repositorio Git. Analizamos archivos YAML, módulos de Terraform, manifiestos de Kubernetes y pipelines CI/CD. La superficie de ataque migró hacia donde migró la infraestructura: al texto. Nuestro oficio cambió también, cada vez dedicamos menos tiempo a investigar fallas del hardware y más a comprender errores de diseño, decisiones arquitectónicas y configuraciones equivocadas. Primero vivía en los racks, después en el hipervisor y luego en los proveedores de nube. Hoy habita en repositorios Git, plantillas declarativas y cadenas de suministro de software. La inteligencia artificial parece ser el siguiente paso de ese mismo recorrido. Primero abstrajimos el hardware, luego la infraestructura. Ahora comenzamos a abstraer parte de la programación y, con ella, parte del razonamiento del ingeniero. (_Esa es una conversación que merece un artículo aparte_). Cada nueva capa de abstracción nos aleja un poco más, pero no elimina la complejidad. Solo la desplaza. Durante décadas nos preguntamos dónde estaba el servidor. Hoy la pregunta es: **¿quién está aplicando el criterio?**

Managing Kubernetes clusters entirely from the command line is a rite of passage. We have all typed `kubectl get pods -n kube-system` more times than we care to admit. But when you are troubleshooting a cascading failure across multiple namespaces at 3:00 AM, staring at raw JSON or squinting at nested YAML in a terminal window isn't just exhausting—it is a liability. Enter Freelens, a free, open-source, cross-platform desktop application designed to take the squinting out of Kubernetes administration. ## Why Freelens? The open-source alternative we actually need If Freelens looks familiar, that is because it is a direct fork of OpenLens, the open-source core that originally powered Mirantis's popular Lens Desktop. When the commercial version of Lens began locking features behind paywalls and subscription models, the community did what the community does best: they forked it. Freelens is built to preserve the dream of a powerful, unrestricted, and highly extensible Kubernetes IDE. It runs locally on your machine, respects your existing `kubeconfig` files, and does not require you to sign up for a cloud account just to view your local development clusters. * * * ## Installation guide Freelens is built using Electron, meaning it runs natively across macOS, Linux, and Windows. Below is the breakdown of how to get it running on your machine of choice. ### macOS Freelens requires macOS 12 (Monterey) or later. The project provides native binaries for both Apple Silicon (`arm64` for M1/M2/M3 chips) and Intel (`amd64`) architectures. #### The quick way (Homebrew) If you use Homebrew, you can install the cask with a single command: brew install --cask freelens #### Manual installation Alternatively, you can download the `.dmg` or `.pkg` installers directly from the Freelens Releases page. * * * ### Linux To run Freelens on Linux, your system must have GNU C Library (glibc) 2.34 or later. This is standard on modern distributions such as Debian 12, Fedora 35, Ubuntu 22.04, Arch Linux, and their derivatives. #### Flatpak (Recommended for sandboxed security) The Flatpak package is hosted on Flathub. It comes bundled with `kubectl` and `helm`, and automatically reads your local `~/.kube/config`. To install and run it: flatpak install flathub app.freelens.Freelens flatpak run app.freelens.Freelens _Note on Flatpak Sandboxing:_ Because Flatpak runs applications in an isolated environment, Freelens includes built-in wrappers to access host-installed CLI tools like `aws`, `doctl`, `gke-gcloud-auth-plugin`, and `kubelogin`. If you need to drop into a terminal within Freelens, it defaults to `/bin/sh` inside the sandbox, but you can configure it to use `/app/bin/host-spawn` to interact directly with your host system's shell. #### Snap Store For Ubuntu and other Snap-enabled distributions: sudo snap install freelens --classic #### APT repository (Debian/Ubuntu) If you prefer native package management via `apt`, you can add the official repository: # Add the repository signing key curl -L https://raw.githubusercontent.com/freelensapp/freelens/refs/heads/main/freelens/build/apt/freelens.asc | sudo tee /etc/apt/keyrings/freelens.asc # Add the source list curl -L https://raw.githubusercontent.com/freelensapp/freelens/refs/heads/main/freelens/build/apt/freelens.sources | sudo tee /etc/apt/sources.list.d/freelens.sources # Update and install sudo apt update sudo apt install freelens #### Arch User Repository (AUR) Arch users can find the precompiled binary package in the AUR under freelens-bin. #### AppImage If you prefer a portable executable, grab the `.AppImage` from the releases page. First, ensure you have the necessary fuse and compression libraries installed: sudo apt install libfuse2 zlib1g-dev Then, run the AppImage with the recommended flags to ensure smooth rendering under modern display servers (like Wayland) and to bypass sandbox-related GPU issues: ./Freelens*.AppImage --no-sandbox --ozone-platform-hint=auto --enable-features=WebRTCPipeWireCapturer --enable-features=WaylandWindowDecorations --disable-gpu-compositing * * * ### Windows Freelens supports Windows 10 or later, offering native builds for both `x64` and `arm64` architectures. #### WinGet (Windows Package Manager) You can install Freelens silently using Microsoft's native package manager: winget install Freelensapp.Freelens _Tip:_ Use the `--scope machine` flag if you want to install it globally to `C:\Program Files` instead of the local user directory. #### Scoop If you prefer the developer-focused Scoop installer: scoop bucket add extras scoop install freelens #### Portable and manual installers If you prefer a zero-installation footprint, download the **Portable EXE** from the releases page. Standard `.exe` (NSIS) and `.msi` installers are also available. * * * ## Extending Freelens One of the greatest strengths of the original OpenLens ecosystem was its extension API. Freelens maintains full compatibility with this ecosystem. Developers can easily port existing OpenLens extensions or write brand-new ones. * **Extensions Wiki:** Check out the Freelens Extensions Wiki to see a list of community-supported extensions. * **Get Involved:** If you have an extension you want to migrate or propose, join the discussion on GitHub Discussion #117. * **Documentation:** Read the Freelens Docs to learn how to build your own custom UI components and integrations. * * * ## Development and contribution Freelens is a community-driven project that welcomes contributors of all skill levels. Whether you want to fix a bug in the UI, optimize the build pipeline, or write documentation, your help is welcome. * **Building from source:** If you want to hack on the codebase, follow the step-by-step guide on the Development Wiki. * **Contributing guidelines:** Read the CONTRIBUTING.md file in the repository to understand the pull request process and coding standards. ### Earn money by contributing The Freelens project utilizes BountyHub, allowing community members to fund specific feature requests or bug fixes. Developers can claim these bounties by submitting successful pull requests that resolve the issues. To learn more about how to fund an issue or get paid for your code, check out the Fund an issue or earn money by developing wiki page. * * * ## Meet the team The rapid growth of Freelens is driven by a dedicated group of open-source maintainers: ### Core Team * Roberto Bandini (@robertobandini) – Founder: General management, community outreach, and product direction. * Piotr Roszatycki (@dex4er) – Maintainer: Architecture, release engineering, and extension development. * Mario Offertucci (@mariomamo) – Maintainer: UI/UX design, documentation, and AI integrations. * Leopoldo Capuano (@leo-capvano) – Maintainer: Generative AI solutions and smart extension development. ### Release Engineering Team * Piotr Roszatycki (@dex4er) – Release Engineering Lead * Omar Alani (@omarluq) – Release Engineering Member * Matías Roje (@MatiasRoje) – Release Engineering Member * * * ## Community and support Stay connected with the community, report bugs, or discuss new feature ideas through these channels: * **Chat & Discussion:** Join the Discord Server or participate in GitHub Discussions. * **Social Media:** Follow the project on Bluesky, X (formerly Twitter), and LinkedIn. * **Video Content:** Watch tutorials and updates on YouTube. * **Issues:** Spot a bug? Open an issue on the GitHub Issue Tracker. If your organization uses Freelens, consider adding your name to the official Adopters List to show your support for sustainable open-source software. * * * ## License Freelens is distributed under the permissive MIT License.

Imagina que los creadores de la "aplicación" más peligrosa del mundo, llamada "Pegasus", deciden empezar a vender el "antipegasus"? Bueno, el resultado es **Dream** , una startup israelí de _**ciberseguridad basada en AI** (uy, qué novedad...)_ quienes están "migrando" desde la **_"vigilancia ofensiva"_** hacia la **_"defensa soberana"... bueno, están con ganas de vendernos nuestro propio derecho soberano a la ciberseguridad en Latinoamérica._** La ironía es tan densa que podría ser la trama de una novela cyberpunk / techno-thriller: Shalev Hulio, cofundador de NSO Group y la mente maestra detrás del infame spyware Pegasus, ahora se quiere posicionar como el salvador de las infraestructuras nacionales. ## Del "Modo Dios" del spyware a la AI defensiva Para los que se perdieron el caos de los últimos años, Pegasus no era simplemente "spyware". Era una clase magistral de _zero-click exploits_ : la capacidad de comprometer un dispositivo sin que el usuario tuviera que hacer clic en un solo link ni siquiera contestar una llamada. Básicamente, convirtió los smartphones en micrófonos de vigilancia 24/7 para gobiernos de todo el mundo, apuntando frecuentemente a la gente "equivocada" (periodistas, activistas y algún que otro parlamentario). ### Avancemos hasta enero de 2023: Hulio deja NSO y lanza **Dream**. El discurso cambió. En lugar de crear herramientas para romper sistemas, Dream afirma construir plataformas impulsadas por AI que detectan amenazas y parchan vulnerabilidades antes de que puedan ser explotadas. Es el clásico pitch de ventas de _"yo sé cómo piensan los malos porque yo fui el arquitecto jefe de los malos"_. Desde un punto de vista técnico, es una transición lógica; la defensa más efectiva suele ser construida por alguien que entiende las primitivas ofensivas de la superficie de ataque, pero es el equivalente de ir a buscar a tu jefe de seguridad a una cárcel de alta seguridad. ## Por qué América Latina es el blanco perfecto Si estás vendiendo un "antídoto" carísimo, necesitas una región que sienta que el veneno ya está corriendo por las venas. América Latina calza perfecto por tres razones: ### 1. La brecha de vulnerabilidad Se reporta que los ciberataques en la región crecen un 25% anual. Según evaluaciones del Banco Mundial, la preparación en ciberseguridad de la región es mediocre, para decir lo menos (con un promedio de 10.2/20). Cuando tu defensa nacional es básicamente una estrategia de "cruzar los dedos y esperar que no pase nada", una startup de AI valuada en 3 billones de dólares parece un salvavidas. ### 2. El golpe de realidad de Costa Rica Los ataques de 2022 en Costa Rica son un caso de estudio sobre la fragilidad sistémica. Primero, el grupo de ransomware **Conti** dejó fuera de combate a 30 instituciones gubernamentales, forzando una emergencia nacional —la primera en el mundo causada por un ciberataque—. Poco después, el grupo **Hive** golpeó el sistema de salud, obligando a los hospitales a volver a la era del papel y el lápiz. Para los países vecinos, esto fue una demostración _cuática_ de que una nación mediana puede quedar paralizada por actores remotos si su perímetro es poroso y sus ciclos de parcheo son inexistentes. ### 3. Alineación política La ciberseguridad a nivel soberano no se trata solo de código; se trata de confianza (o de la ilusión de ella). Dream está apuntando a gobiernos alineados con Washington y Tel Aviv. * **Argentina:** Bajo Javier Milei, el país está girando hacia un hub centrado en AI y fortaleciendo lazos con Israel. * **Colombia:** La administración actual, con Abelardo De la Espriella, está restaurando vínculos diplomáticos con Israel. Vender una "plataforma de AI soberana" a una agencia de seguridad nacional requiere un nivel de cercanía política que un contrato estándar de SaaS no ofrece. La identidad israelí de Dream, que alguna vez fue una carga para NSO ante los grupos de derechos humanos, es ahora un activo estratégico en las capitales de derecha. ## La jugada técnica: AI Soberana y air-gapping Una de las mayores ventajas competitivas de Dream es su apuesta por los **centros de datos _"soberanos"_**. Construyeron una instalación cerca de Modiin, Israel, para entrenar Large Language Models (LLMs) propietarios sin depender de proveedores de nube pública como AWS, Azure o GCP. Para un gobierno, esto es un requisito crítico. Ninguna agencia de inteligencia quiere que sus datos sensibles de vulnerabilidades fluyan a través de un proveedor de nube basado en EE. UU. sujeto al CLOUD Act. Al ofrecer "AI soberana", Dream promete: * **Residencia de Datos:** Tus datos se quedan dentro de tus fronteras (o las de un "socio confiable"). * **Despliegue Air-gapped:** La capacidad de desplegar agentes de AI en entornos que no tienen conexión con la internet pública. * **LLMs personalizados:** Modelos entrenados específicamente con telemetría de ciberseguridad en lugar de prosa general de internet. ## La paradoja ética: ¿Podemos confiar en el antídoto? El caso de negocio está clarísimo: se reporta que las ventas han superado los 300 millones de dólares y la valoración se ha triplicado a 3 billones. Pero la pregunta ética sigue ahí: **¿Es este un giro genuino hacia la defensa, o es simplemente un modelo de negocio más sostenible para el mismo set de habilidades?** El lado "defensivo" de la ciberseguridad es, a menudo, el lado "ofensivo" con una licencia diferente. La misma AI que puede "detectar una vulnerabilidad para parcharla" también puede "detectar una vulnerabilidad para explotarla". Para los grupos de la sociedad civil en América Latina, la distinción es puramente académica. Ya sea que la herramienta se use para detener un ataque de ransomware o para monitorear a un disidente, el poder reside en quien tiene las llaves. En este caso, las llaves las tiene el hombre que construyó la herramienta de vigilancia más poderosa e ilegal de la historia reciente, respaldado por organismos de seguridad israelíes responsables de un genocidio que sigue en curso, lo cual supera cualquier argumento técnico para dar un rotundo rechazo a cualquier intento de apropiarse de los datos de empresas y personas en Latinoamér * * * ### Referencias y Recursos * **Artículo Original:** The man who built Pegasus now sells governments the antidote por Alina Maria Stan. * **Lecturas Adicionales:** * NSO Group and the Pegasus Project - Amnesty International. * Conti Ransomware Analysis - CISA (Buscar avisos de Conti/Hive). * Sovereign AI Concepts - Entendiendo el giro hacia la infraestructura de AI nacionalizada.

Is this a "Linux-ification" of Windows? Not quite. It's more of a pragmatic bridge. Coreutils for Windows won't make you forget you're on Windows, and it won't replace the need for a full WSL instance when you're doing heavy-duty Linux systems engineering. However, for the developer who just wants to `grep` a log file or `find` a config without fighting the shell, it is a massive quality-of-life improvement. For years, the relationship between Microsoft and the Linux ecosystem was one of mutual suspicion and occasional hostility. Fast forward to 2026, and the irony is palpable: Microsoft is now officially shipping Unix-style utilities to make Windows feel a little more like the environments developers actually live in. Announced at Microsoft Build 2026, **Coreutils for Windows** is a new, Microsoft-maintained suite of command-line tools designed to run natively on Windows. No WSL required, no heavy virtualization layers—just your familiar commands, running directly on the Windows kernel. ## The Rust-powered foundation Rather than attempting a messy port of aging GNU C code, Microsoft has gone the modern route. Coreutils for Windows is built upon uutils, a cross-platform, high-performance reimplementation of GNU Coreutils written in **Rust**. By leveraging Rust, Microsoft is tapping into the language's inherent memory safety and concurrency strengths, which is a smart move for system-level utilities. The package is distributed as a single, multi-call binary and includes Microsoft-maintained builds of: * `uutils/coreutils` * `uutils/findutils` * A specialized Microsoft fork of `uutils/grep` The goal is to reduce the "context-switching tax" paid by DevOps engineers and SREs who bounce between local Windows workstations, macOS laptops, and Linux-based cloud environments. ## Installation and setup Getting started is straightforward, assuming you aren't still clinging to the legacy CMD prompt. The package is distributed via **WinGet** , making it easy to integrate into automated setup scripts or developer onboarding workflows. # Install the coreutils package via WinGet winget install Microsoft.Coreutils _**Note:** To get the most out of this, you will need **PowerShell 7.4 or later**. If you are still running Windows PowerShell 5.1, you might want to upgrade before you start expecting modern behavior._ ## The "curated" experience: Limitations and conflicts Before you go rewriting all your `.bat` scripts, let's manage some expectations. This is not a complete, 1:1 replacement for a Linux distribution. It is a "Windows-focused subset." ### Command conflicts and aliases Because Windows has its own way of doing things, several common commands will collide with existing PowerShell or CMD built-ins and aliases. If you try to use `ls`, `cat`, `cp`, `mv`, `rm`, or `pwd`, you might find yourself in a tug-of-war between the native Windows behavior and the new Coreutils implementation. You'll need to be mindful of your environment's execution policy and alias precedence. ### What's missing? Microsoft has been quite selective about what they include. While the "essentials" are there, many power-user tools have been left on the cutting room floor. **Explicitly excluded utilities:** * `dd` (Because direct disk manipulation on Windows is a recipe for disaster) * `dircolors` * `shred` * `sync` * `uname` **Missing POSIX-specific tools:** If your workflow relies heavily on permission management or process inspection, you'll notice the absence of `chmod`, `chown`, `chroot`, `mkfifo`, `tty`, `users`, and `who`. Attempting to map POSIX permissions to the NTFS filesystem is a complex beast, and it seems Microsoft has decided to punt that particular headache for another day. ## The bigger picture: WSL containers The release of Coreutils for Windows isn't happening in a vacuum. Alongside this, Microsoft introduced **WSL containers**. While Coreutils aims to make the Windows CLI more familiar, WSL containers aim to make Linux containerization more native. Unlike the Coreutils package, WSL containers are currently in the works and are expected to enter public preview in the coming months. They promise a way to build and run Linux containers through a dedicated CLI and API, providing enterprises with policy-based control over image sources and host interaction—essentially bringing the "managed" feel of cloud-native environments to the local Windows desktop. Coreutils for Windows is available now via the Microsoft GitHub repository * * * **References & Credits:** * Original reporting by Bobby Borisov via Linuxiac * uutils/coreutils Project * Microsoft Build 2026 Announcements

¿Es esto una "Linux-ización" de Windows? No exactamente. Es más bien un puente pragmático. Coreutils for Windows no hará que olvides que estás en Windows, ni reemplazará la necesidad de una instancia completa de WSL cuando estés haciendo ingeniería de sistemas Linux pesada. Sin embargo, para el desarrollador que solo quiere hacer un `grep` a un archivo de log o un `find` a una config sin pelearse con la shell, es una mejora gigante en la calidad de vida. Durante años, la relación entre Microsoft y el ecosistema Linux fue de sospecha mutua y hostilidad ocasional. Damos un salto al 2026 y la ironía es evidente: Microsoft ahora está distribuyendo oficialmente utilidades estilo Unix para que Windows se sienta un poco más como los entornos donde los devs realmente se mueven. Anunciado en el Microsoft Build 2026, **Coreutils for Windows** es una nueva suite de herramientas de línea de comandos mantenida por Microsoft y diseñada para ejecutarse nativamente en Windows. Sin necesidad de WSL, sin capas pesadas de virtualización; solo tus comandos conocidos, corriendo directamente sobre el kernel de Windows. ## La base potenciada por Rust En lugar de intentar un porteo desordenado de código antiguo de GNU C, Microsoft tomó el camino moderno. Coreutils for Windows está construido sobre uutils, una reimplementación de GNU Coreutils de alto rendimiento y multiplataforma escrita en **Rust**. Al aprovechar Rust, Microsoft está sacando partido de la seguridad de memoria inherente al lenguaje y sus fortalezas en concurrencia, lo cual es una jugada inteligente para utilidades a nivel de sistema. El paquete se distribuye como un único binario multi-llamada e incluye builds mantenidas por Microsoft de: * `uutils/coreutils` * `uutils/findutils` * Un fork especializado de Microsoft de `uutils/grep` El objetivo es reducir el "impuesto del cambio de contexto" que pagan los ingenieros de DevOps y SREs que saltan entre estaciones de trabajo locales con Windows, laptops macOS y entornos de nube basados en Linux. ## Instalación y configuración Empezar es bastante simple, asumiendo que no sigas aferrado al viejo CMD. El paquete se distribuye vía **WinGet** , lo que facilita su integración en scripts de configuración automatizados o flujos de onboarding para desarrolladores. # Install the coreutils package via WinGet winget install Microsoft.Coreutils **Nota:** Para sacarle el máximo provecho a esto, necesitarás **PowerShell 7.4 o superior**. Si todavía estás usando Windows PowerShell 5.1, quizás quieras actualizar antes de esperar un comportamiento moderno. ## La experiencia "curada": Limitaciones y conflictos Antes de que te pongas a reescribir todos tus scripts `.bat`, bajemos un poco las expectativas. Esto no es un reemplazo completo 1:1 de una distribución de Linux. Es un "subconjunto enfocado en Windows". ### Conflictos de comandos y alias Como Windows tiene su propia forma de hacer las cosas, varios comandos comunes chocarán con los built-ins y alias existentes de PowerShell o CMD. Si intentas usar `ls`, `cat`, `cp`, `mv`, `rm` o `pwd`, podrías terminar en un tira y afloja entre el comportamiento nativo de Windows y la nueva implementación de Coreutils. Tendrás que tener ojo con la política de ejecución de tu entorno y la precedencia de los alias. ### ¿Qué falta? Microsoft ha sido bastante selectivo con lo que incluyó. Aunque los "esenciales" están ahí, muchas herramientas para power-users quedaron fuera del corte. **Utilidades explícitamente excluidas:** * `dd` (Porque la manipulación directa de discos en Windows es una receta para el desastre) * `dircolors` * `shred` * `sync` * `uname` **Herramientas específicas de POSIX faltantes:** Si tu flujo de trabajo depende mucho de la gestión de permisos o la inspección de procesos, notarás la ausencia de `chmod`, `chown`, `chroot`, `mkfifo`, `tty`, `users` y `who`. Intentar mapear permisos POSIX al sistema de archivos NTFS es un bicho complejo, y parece que Microsoft decidió patear ese dolor de cabeza para más adelante. ## El panorama general: WSL containers El lanzamiento de Coreutils for Windows no ocurre de forma aislada. Junto a esto, Microsoft introdujo los **WSL containers**. Mientras que Coreutils busca que la CLI de Windows sea más familiar, los WSL containers buscan que la contenerización de Linux sea más nativa. A diferencia del paquete de Coreutils, los WSL containers están actualmente en desarrollo y se espera que entren en preview pública en los próximos meses. Prometen una forma de construir y ejecutar contenedores de Linux a través de una CLI y API dedicada, brindando a las empresas un control basado en políticas sobre las fuentes de las imágenes y la interacción con el host; básicamente, trayendo esa sensación de entorno "managed" de la nube al escritorio local de Windows. Coreutils for Windows ya está disponible a través del repositorio de GitHub de Microsoft. * * * **Referencias y Créditos:** * Reporte original de Bobby Borisov vía Linuxiac * Proyecto uutils/coreutils * Anuncios de Microsoft Build 2026

Is this a "Linux-ification" of Windows? Not quite. It's more of a pragmatic bridge. Coreutils for Windows won't make you forget you're on Windows, and it won't replace the need for a full WSL instance when you're doing heavy-duty Linux systems engineering. However, for the developer who just wants to `grep` a log file or `find` a config without fighting the shell, it is a massive quality-of-life improvement. For years, the relationship between Microsoft and the Linux ecosystem was one of mutual suspicion and occasional hostility. Fast forward to 2026, and the irony is palpable: Microsoft is now officially shipping Unix-style utilities to make Windows feel a little more like the environments developers actually live in. Announced at Microsoft Build 2026, **Coreutils for Windows** is a new, Microsoft-maintained suite of command-line tools designed to run natively on Windows. No WSL required, no heavy virtualization layers—just your familiar commands, running directly on the Windows kernel. ## The Rust-powered foundation Rather than attempting a messy port of aging GNU C code, Microsoft has gone the modern route. Coreutils for Windows is built upon uutils, a cross-platform, high-performance reimplementation of GNU Coreutils written in **Rust**. By leveraging Rust, Microsoft is tapping into the language's inherent memory safety and concurrency strengths, which is a smart move for system-level utilities. The package is distributed as a single, multi-call binary and includes Microsoft-maintained builds of: * `uutils/coreutils` * `uutils/findutils` * A specialized Microsoft fork of `uutils/grep` The goal is to reduce the "context-switching tax" paid by DevOps engineers and SREs who bounce between local Windows workstations, macOS laptops, and Linux-based cloud environments. ## Installation and setup Getting started is straightforward, assuming you aren't still clinging to the legacy CMD prompt. The package is distributed via **WinGet** , making it easy to integrate into automated setup scripts or developer onboarding workflows. # Install the coreutils package via WinGet winget install Microsoft.Coreutils _**Note:** To get the most out of this, you will need **PowerShell 7.4 or later**. If you are still running Windows PowerShell 5.1, you might want to upgrade before you start expecting modern behavior._ ## The "curated" experience: Limitations and conflicts Before you go rewriting all your `.bat` scripts, let's manage some expectations. This is not a complete, 1:1 replacement for a Linux distribution. It is a "Windows-focused subset." ### Command conflicts and aliases Because Windows has its own way of doing things, several common commands will collide with existing PowerShell or CMD built-ins and aliases. If you try to use `ls`, `cat`, `cp`, `mv`, `rm`, or `pwd`, you might find yourself in a tug-of-war between the native Windows behavior and the new Coreutils implementation. You'll need to be mindful of your environment's execution policy and alias precedence. ### What's missing? Microsoft has been quite selective about what they include. While the "essentials" are there, many power-user tools have been left on the cutting room floor. **Explicitly excluded utilities:** * `dd` (Because direct disk manipulation on Windows is a recipe for disaster) * `dircolors` * `shred` * `sync` * `uname` **Missing POSIX-specific tools:** If your workflow relies heavily on permission management or process inspection, you'll notice the absence of `chmod`, `chown`, `chroot`, `mkfifo`, `tty`, `users`, and `who`. Attempting to map POSIX permissions to the NTFS filesystem is a complex beast, and it seems Microsoft has decided to punt that particular headache for another day. ## The bigger picture: WSL containers The release of Coreutils for Windows isn't happening in a vacuum. Alongside this, Microsoft introduced **WSL containers**. While Coreutils aims to make the Windows CLI more familiar, WSL containers aim to make Linux containerization more native. Unlike the Coreutils package, WSL containers are currently in the works and are expected to enter public preview in the coming months. They promise a way to build and run Linux containers through a dedicated CLI and API, providing enterprises with policy-based control over image sources and host interaction—essentially bringing the "managed" feel of cloud-native environments to the local Windows desktop. Coreutils for Windows is available now via the Microsoft GitHub repository * * * **References & Credits:** * Original reporting by Bobby Borisov via Linuxiac * uutils/coreutils Project * Microsoft Build 2026 Announcements

En la reciente **Google Cloud Next '26** , el mensaje fue clarito, fuerte y un poco intimidante: **Kubernetes ya no es solo un orquestador de contenedores; es el _"sistema operativo para la era de la IA"_.** Mientras algunos de nosotros todavía estamos tratando de solucionar un `ImagePullBackOff`, Google está preparando GKE para gestionar un millón de chips aceleradores y ejecutar código de _"agentes autónomos muy confiables" (léase OpenClaw)_ a gran escala. Los anuncios se centraron en dos pilares gigantes: * **GKE Agent Sandbox** para la ejecución segura de múltiples agentes * **GKE Hypercluster** para una infraestructura que ya roza lo absurdo. ## El auge de los poco confiables _"agentes autónomos"_ (léase OpenClaw) Ya pasamos la etapa de los chatbots. Los flujos de trabajo de IA multi-agente han subido más de un 300% últimamente y, como era de esperarse, darle a un LLM las llaves para ejecutar código es una pesadilla de seguridad cuyas consecuencias ya son visibles, evidenciado en la impresionante frecuencia y cantidad de CVEs, explloits, vulnerabilidades y leaks ocurridos en los últimos meses. La respuesta de Google es GKE Agent Sandbox. Esto no es solo un nombre de marketing, es una capa de aislamiento a nivel de kernel potenciada por gVisor, la misma tecnología de sandboxing que Google usa para evitar que Gemini se muerda la cola. ### Nuevos componentes de Kubernetes Google no solo está envolviendo contenedores; están introduciendo tres nuevos componentes de Kubernetes -lanzadas originalmente como un subproyecto de SIG Apps- para estandarizar cómo viven y respiran los agentes: * **Sandbox:** El recurso principal de la carga de trabajo (workload). * **SandboxTemplate:** El blueprint de seguridad (piénsalo como la configuración de "no dejes que el agente se escape"). * **SandboxClaim:** Un recurso transaccional para solicitar entornos de ejecución desde frameworks como LangChain o ADK, conceptualmente similar a un `persistentVolumeClaim` Para solucionar el problema del "cold start" que tanto nos pena en las ejecuciones tipo serverless, GKE ahora usa "_warm pools"_ de pods pre-provisionados, bajando la latencia a niveles de sub-segundos. Si estás corriendo sobre los procesadores Axion personalizados de Google, ellos aseguran una ventaja de precio-rendimiento del 30% frente a otros hyperscalers. ## Hypercluster: Un millón de chips, un solo control plane Si el Agent Sandbox se trata de lo "micro", GKE Hypercluster se trata de lo "macro". Actualmente en GA privada, Hypercluster permite que un solo control plane de GKE gestione hasta **un millón de chips aceleradores** a través de 256.000 nodos. Aunque la escala es _brígida (intimidante)_ , la preocupación por el _"blast radius"_ (radio de explosión) es real. Gestionar un millón de chips desde un solo punto de falla es una movida arriesgada, lo que probablemente explica por qué Google lo mantiene en GA privada por ahora. Para asegurar estas cargas de trabajo masivas, Google se apoya en el Titanium Intelligence Enclave. Esta arquitectura basada en hardware y "sin acceso de administrador" garantiza que ni siquiera los administradores de la plataforma —la gente a la que le pagan para que mantenga la cuestión andando— puedan ver los _weights_ de los modelos propietarios o los prompts. Todo se mantiene sellado criptográficamente. ## Solucionando el cuello de botella de la inferencia Escalar no sirve de nada si la latencia de inferencia hace que los usuarios sientan que volvieron al internet de los 90. Google introdujo dos funciones clave para que los tokens sigan fluyendo: ### 1. Predictive Latency Boost Basado en el proyecto llm-d (que ahora es un proyecto Sandbox de la CNCF), esta función usa ruteo basado en ML. En vez de depender de un round-robin "fome" o de un agendamiento heurístico, el GKE Inference Gateway predice qué nodo tendrá el menor time-to-first-token (TTFT) y rutea el tráfico según eso. Google dice que esto reduce la latencia hasta en un 70%. ### 2. Automatic KV Cache Tiering Las ventanas de contexto (context window) son devoradoras de memoria. GKE ahora soporta almacenamiento por niveles (tiering) automático de KV Cache entre RAM, SSD local y Google Cloud Storage (GCS). * **Offloading a RAM:** 50% de ganancia en throughput para 10K prompts. * **Offloading a SSD:** Casi un 70% de mejora en throughput para 50K prompts. ## Reinforcement Learning (RL) y autoscaling basado en _intención_ En cuanto a **Reinforcement Learning (RL)** , Google anunció **RL Scheduler** y **RL Sandbox**. Estas herramientas optimizan las cargas de trabajo de _evaluación de recompensas_ manteniendo el mismo aislamiento a nivel de kernel de Agent Sandbox. Finalmente, el **Horizontal Pod Autoscaler (HPA)** por fin va a andar más rápido. El **Intent-based autoscaling** reduce los tiempos de reacción de 25 segundos a apenas 5 segundos. Lo logra sacando las métricas directamente de los pods en vez de esperar a que el stack de monitoreo externo se dé cuenta de que tu cluster se está incendiando. La gran unificación de google cloud: opentelemetry se vuelve obligatorio (y ya era hora)Si pensabas que podrías seguir ignorando el avance de OpenTelemetry (OTel) mientras te escondías en tus scripts legacy, Google Cloud acaba de enviarte un recordatorio amistoso —o una amenaza elegante, según cómo lo mires—. La plataforma ha lanzado una nueva API de ingestión que soporta de forma nativa los protocolosSREDevOps.orgNicolás Georger ## Resumen: El diferenciador open-source Quizás lo más interesante de todo es el compromiso de Google con el camino del código abierto. Al convertir el Agent Sandbox en un proyecto de Kubernetes SIG, están apostando a que el mismo Kubernetes debería ser el runtime de los agentes. A diferencia de las soluciones propietarias, cualquier cluster de Kubernetes que cumpla con los estándares podría, en teoría, correr estas primitivas de agentes. Ya sea que necesites gestionar un millón de H100s o solo quieras asegurarte de que tu agente de IA no tire un `rm -rf /` en producción, las actualizaciones del Next '26 de GKE sugieren que el futuro de la IA es, inevitablemente, un archivo YAML. ### Referencias y lecturas adicionales * Official Google Cloud Blog: What’s new in GKE at Next '26 * gVisor Documentation * CNCF: Kubernetes as foundational infrastructure for AI * llm-d: Predicted latency-based scheduling * Original Article Source: InfoQ

## copy fail in kubernetes: when your pod escapes to the host with four bytes if you thought containers were a security boundary, cve-2026-31431 ("copy fail") has some unfortunate news for you. discovered by xint, this linux kernel vulnerability lets an unprivileged local user overwrite four controlled bytes in the page cache of _any readable file_ —and yes, that includes binaries inside your containers. worse: because the page cache is a host-wide resource, corruption in one container can silently propagate to another. the result? a fully unprivileged pod can achieve node-level code execution. this isn't a theoretical "what if." a public 732-byte python proof-of-concept demonstrates container escape on every major kubernetes distribution by exploiting shared image layers between an attacker-controlled pod and a privileged daemonset like `kube-proxy`. if your cluster runs linux kernels built between 2017 and april 2026, you should probably stop reading and start patching. ## the container escape primitive: shared page cache, shared fate the core vulnerability lives in the kernel's `algif_aead` subsystem, where improper handling of scatter-gather lists during in-place aead decryption allows a controlled 4-byte write into the page cache. the exploit chain is elegantly brutal: # simplified exploit flow (full PoC: https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC) import os, socket # 1. open AF_ALG socket to vulnerable crypto template s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET) s.bind(("aead", "authencesn(hmac(sha256),cbc(aes))")) # ... set key, accept request socket ... # 2. splice target file (e.g., /usr/sbin/ipset) into crypto operation os.splice(target_fd, pipe_wr, offset=chosen_offset) os.splice(pipe_rd, alg_fd, length=auth_tag_size) # 3. trigger decrypt → kernel writes 4 controlled bytes into page cache req_socket.recv(1) # hmac fails, but corruption persists the magic—and the danger—lies in how linux manages file i/o. when a container reads a file from a shared image layer, the kernel serves it from the _same physical page cache pages_ across all containers on that node. this is a performance optimization, not a bug. but when combined with copy fail, it becomes an escape hatch. ### why overlay filesystems make this worse container runtimes like `containerd` and `cri-o` use overlayfs to implement copy-on-write semantics. when multiple pods reference the same image layer: host page cache ├── lowerdir: /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/<layer>/usr/sbin/ipset ├── upperdir: (container-specific, empty for read-only files) └── merged view: served from shared page cache pages if an unprivileged pod corrupts `/usr/sbin/ipset` in the page cache, _every_ pod on that node that reads the same file from the same layer sees the corrupted in-memory version—without any cross-container communication, without touching disk, and without triggering traditional file integrity monitors. ## the kube-proxy attack vector: a privileged daemonset waiting to happen the public kubernetes poc targets `/usr/sbin/ipset`, a binary used by `kube-proxy` to manage iptables/ipset rules. here's why this is a perfect storm: characteristic | why it matters ---|--- `kube-proxy` runs as a privileged daemonset | executes with `hostnetwork: true`, full capabilities, and root uid `ipset` is invoked periodically | corrupted binary gets executed automatically, no user interaction needed image layer is shared across nodes | same base image (`registry.k8s.io/kube-proxy:v1.35.2`) means same page cache mapping binary is readable by unprivileged users | satisfies the "any readable file" prerequisite for copy fail the attack sequence: 1. attacker deploys an unprivileged pod with the poc script (no special capabilities required) 2. poc corrupts the page cache for `/usr/sbin/ipset` in the shared image layer 3. `kube-proxy` on the same node executes the corrupted binary during its next reconciliation loop 4. attacker-controlled shellcode runs with kube-proxy's privileges: root on the node, access to host namespaces, and full cluster control via the node's service account this isn't a "maybe." the poc has been tested and confirmed working on ubuntu, amazon linux, rhel, and suse kernels spanning versions 6.12 through 6.18. GitHub - Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoCContribute to Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC development by creating an account on GitHub.GitHubPercivalll ## kubernetes-specific mitigations: patch first, architect second ### immediate actions (today) **disable the vulnerable kernel module** (temporary) # node-level mitigation via DaemonSet apiVersion: apps/v1 kind: DaemonSet metadata: { name: disable-algif-aead } spec: template: spec: hostPID: true containers: - name: mitigator image: alpine:latest command: ["/bin/sh", "-c"] args: - | echo "install algif_aead /bin/false" > /host/etc/modprobe.d/disable-algif.conf chroot /host rmmod algif_aead 2>/dev/null || true volumeMounts: - name: host-root mountPath: /host volumes: - name: host-root hostPath: { path: /, type: Directory } **block`af_alg` at the runtime level** use seccomp profiles to prevent `af_alg` socket creation in untrusted pods: # pod securityContext with seccomp securityContext: seccompProfile: type: Localhost localhostProfile: profiles/block-af-alg.json // profiles/block-af-alg.json { "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [{ "names": ["socket"], "action": "SCMP_ACT_ERRNO", "args": [{"index": 0, "value": 38, "op": "SCMP_CMP_EQ"}] // AF_ALG = 38 }] } **patch your nodes** apply a kernel containing the upstream fix (commit a664bf3d603d). for managed kubernetes services: # EKS: trigger node group update aws eks update-nodegroup-config --cluster-name my-cluster --nodegroup-name my-ng \ --launch-template version=$NEW_VERSION # GKE: enable auto-upgrade or manually upgrade nodes gcloud container clusters upgrade my-cluster --node-pool default-pool \ --cluster-version=1.35.2-gke.100 ### architectural hardening (this quarter) * **isolate image layers for privileged workloads** use distinct base images for daemonsets like `kube-proxy` that aren't shared with user workloads. this breaks the page-cache propagation path. * **adopt pod security admission (psa) or gatekeeper policies** enforce that pods cannot request `hostpath` volumes, `privileged` mode, or `af_alg`-capable seccomp exemptions. **restrict pod placement with node affinity** prevent untrusted workloads from scheduling on nodes running privileged daemonsets with shared base images: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-role.kubernetes.io/control-plane operator: DoesNotExist - key: workload-trust-level operator: In values: ["untrusted"] **enforce read-only root filesystems** while copy fail bypasses on-disk checks, a read-only rootfs limits post-exploitation persistence options: securityContext: readOnlyRootFilesystem: true allowPrivilegeEscalation: false ## detection strategies for kubernetes environments copy fail is stealthy by design: the corrupted page is never marked dirty, so on-disk checksums remain valid. detection requires behavioral signals: 1. **monitor for anomalous`kube-proxy` behavior** corrupted `ipset` execution may cause: * unexpected iptables rule modifications * `kube-proxy` crash loops with unusual stack traces * auth.log entries with missing invoking usernames (see original advisory) 2. **watch for poc network artifacts** non-stealthy attackers may fetch exploit code from `https://copy.fail/exp`. alert on egress to this domain from cluster pods. **correlate pod scheduling with kernel version** flag any unprivileged pod scheduled on a node running an unpatched kernel: # quick cluster audit kubectl get nodes -o json | jq -r '.items[] | select(.status.nodeInfo.kernelVersion | test("6\\.(1[0-7]|[0-9])")) | .metadata.name' **audit`af_alg` socket creation** use auditd or ebpf-based tracing to alert on unexpected `socket(AF_ALG, ...)` calls from containerized processes: # ebpf trace example (bpftrace) tracepoint:syscalls:sys_enter_socket /args->family == 38/ { printf("AF_ALG socket from pid %d (%s)\n", pid, comm); } ## the uncomfortable truth about container "isolation" copy fail exposes a fundamental tension in container security: performance optimizations (shared page cache, overlayfs) directly conflict with isolation guarantees. the linux kernel was never designed with multi-tenant container workloads as a primary threat model—and it shows. this isn't a call to abandon containers. it's a reminder that "isolation" is a spectrum, not a binary. defense-in-depth means: * assuming local privesc vulnerabilities will exist * minimizing the blast radius when they do * treating kernel patch latency as a first-order risk metric because when four bytes can buy you the entire node, your pod security policy just became a suggestion. * * * ## references * wiz.io: copy fail vulnerability advisory * xint technical writeup: copy fail * kubernetes poc: cve-2026-31431 container escape * upstream kernel fix: commit a664bf3d603d * kubernetes pod security admission docs * seccomp profiles for kubernetes _source: adapted from wiz.io blog post by amitai cohen, merav bar, and shahar dorfman (may 1, 2026) and xint code research (april 29, 2026)_

Hey self-hosting folks, **REMINDER: I don’t work for Ghost. The content below is my own opinion, not that of the Ghost Foundation, blah blah blah. Might be wrong, and possibly worth only what you paid for it (nothing).** In case you’ve missed it, Ghost had a baaad security vulnerability back in February, disclosed here: SQL injection in Content API### Impact A SQL injection vulnerability existed in Ghost’s Content API that allowed unauthenticated attackers to read arbitrary data from the database. ### Vulnerable Versions This vulne…GitHubTryGhost That’s a bad one. Specifically, it allows an attacker to read your whole site, include admin api keys, and once they’ve got the admin api key, there’s a lot that can go wrong. 💡 If you are in managed hosting (at least Ghost Pro, Synaps, Magic Pages), you got patched as soon as 6.19.1 was released. You can probably give a sigh of relief and stop reading. This post is mostly for self-hosters who haven't upgraded, or who wanted a while before upgrading. So, if you’re self hosting, you should IMMEDIATELY upgrade. Do not pass go, do not collect $200, just upgrade. (The vulnerability is there all the way back to 3.x, so older sites are not safe.) If you updated right when 6.19.1 was released, it might be ok to assume that your site wasn’t compromised before you updated, since the vulnerability probably wasn’t widely known… maybe. If you’re still at < 6.19.1 NOW, you need to seriously consider the possibility that attackers might already have your admin api key, and that upgrading will remove the ability to get a key, but not fix any existing key leakage. My possibly over-cautious thought is that y _ou should probably roll all your keys, including staff tokens_. I’m not sure if this is overly alarmist, but better safe than sorry? My thinking here is that **NOTE: If you have services connected through these keys, you WILL break them by doing this. You’ll need to revisit each service and provide the newly regenerated key/token. Yes, that sounds like a pain.** Staff tokens can be regenerated from the individual staff profile (only for the logged in user). Scroll down and click ‘regenerate’. Suspend any admin or enhanced editor users you can’t get to regenerate their own tokens. (Editors with the enhanced editor role can read the members list.) Your Admin API keys in custom integrations can be regenerated from /ghost > settings > custom - click into each integration and regenerate. You also need to regenerate your Zapier token - in /ghost > settings > integrations, click ‘configure’ next to zapier and regenerate the token. I’ve seen two reports of sites being compromised via Zapier token, specifically. I’m not _sure_ it’s from this vulnerability instead of a Zapier vulnerability/leak, but I’m suspicious. * * * That’s all I know. Wanted to get it out there in case it helps someone. Even if key rolling sounds like too much to do today, please please please do yourself a favor and update to >= 6.19.1. (This is a crosspost with the Ghost forum: https://forum.ghost.org/t/if-you-are-on-ghost-6-19-1-you-really-need-to-update/62706 ) * * * Hey, before you go... If your finances allow you to keep this tea-drinking ghost and the freelancer behind her supplied with our hot beverage of choice, we'd both appreciate it! Buy me a tea ☕️

Si has pasado tiempo en el ecosistema _cloud-native_ , conoces esa sensación: has configurado meticulosamente tus `NetworkPolicies`, tu RBAC es lo suficientemente estricto como para hacer llorar de alegría a cualquier auditor de seguridad y todos tus pods están en un hermoso y saludable color verde. Te sientes seguro. Te sientes protegido. Entonces, despliegas un Modelo de Lenguaje Extenso (LLM) y te das cuenta de que, aunque tu infraestructura es una fortaleza, básicamente le has entregado las llaves del reino a un loro parlanchín que puede ser engañado para filtrar las credenciales de tu base de datos simplemente porque alguien le dijo que "ignore todas las instrucciones anteriores". La Cloud Native Computing Foundation (CNCF) lanzó recientemente una verdad lapidaria: Kubernetes es un orquestador increíble, pero es fundamentalmente ciego al caos semántico de la IA. Por eso, confiar únicamente en K8s para la seguridad de un LLM es el equivalente digital a instalar una cerradura biométrica de alta tecnología en una puerta de cartón. ## La ilusión del "pod en verde" Kubernetes es excelente en el "dónde" y el "cómo" del despliegue. Asegura que el pod de tu LLM tenga suficiente memoria de GPU, lo reinicia cuando falla y lo aísla de otras cargas de trabajo. Sin embargo, Kubernetes tiene cero visibilidad sobre el _contenido_ del tráfico que fluye hacia ese pod. Para Kubernetes, un _prompt_ que solicita el resumen de un PDF y un _prompt_ que le ordena al modelo "eliminar todos los buckets de S3 y enviar los logs a una IP aleatoria en Europa del Este" se ven exactamente igual: ambos son simplemente solicitudes HTTP. Esto crea una brecha peligrosa: **`salud operacional != seguridad`.** Tu clúster puede estar perfectamente saludable mientras tu IA desmantela activamente la privacidad de los datos de tu empresa desde adentro. ## Manejar el caos dentro del caos: el modelo de amenazas de LLM Las aplicaciones tradicionales son deterministas. Proporcionas la entrada A y el código ejecuta la ruta B. Los LLMs, sin embargo, son entidades de toma de decisiones programables. Cuando le das a un LLM acceso a herramientas internas, APIs o logs, no estás desplegando solo un servicio; estás desplegando un agente. Esto introduce riesgos que `kube-proxy` no puede resolver: * **Prompt Injection:** El arte de engañar a un LLM para que ignore sus _system prompts_ y realice acciones no autorizadas. * **Exposición no intencionada de datos:** El modelo "alucina" o filtra accidentalmente datos de entrenamiento sensibles o secretos del sistema en una respuesta. * **Uso indebido de herramientas:** Si tu LLM tiene un "plugin" para consultar tu base de datos, un usuario astuto podría engañarlo para que ejecute un comando `DROP TABLE` a través de un _prompt_ en lenguaje natural. ## Donde la seguridad tradicional se queda corta Seamos claros: sigues necesitando tu seguridad estándar de K8s. Si no estás usando Pod Security Admissions o Network Policies, tienes problemas más graves. Pero estas herramientas operan en las capas de red y de sistema operativo, mientras que las amenazas de los LLM operan en la **capa semántica**. Capa de Seguridad | Herramienta de Kubernetes | Vulnerabilidad de LLM | ¿Puede K8s detenerlo? ---|---|---|--- **Red** | NetworkPolicy | Prompt Injection | No **Identidad** | RBAC | Filtración de datos vía Chat | No **Cómputo** | Resource Quotas | Alucinaciones del modelo | No **Runtime** | Seccomp/AppArmor | Ejecución de herramientas maliciosas | Parcialmente Por ejemplo, una `NetworkPolicy` puede evitar que un pod se comunique con una IP externa, pero no puede evitar que un LLM le diga a un usuario: "Claro, aquí tienes la contraseña de administrador que encontré en las variables de entorno". ## Construyendo guardrails reales Para asegurar tus workloads LLM, debemos movernos hacia una **ingeniería de plataformas consciente de la IA (AI-aware platform engineering)**. Esto significa tratar al modelo como un usuario no confiable y envolverlo en una capa de gobernanza semántica. ### 1. Adopta OWASP Top 10 para LLMs OWASP Top 10 for LLM Applications es el estándar de oro para comprender estos riesgos. Cubre desde la Inyección de Prompts (LLM01) hasta la Divulgación de Información Sensible (LLM06). ### 2. Implementa guardrails semánticos En lugar de confiar en la infraestructura para bloquear el tráfico, implementa una capa intermedia (un "_guardrail_ ") que inspeccione tanto el _prompt_ de entrada como la respuesta de salida. ## Ejemplo conceptual de una Política de Guardrail ## (No es un CRD real de K8s, sino un flujo lógico) apiVersion: ai.security.io/v1 kind: LLMGuardrail metadata: name: pii-filter spec: inputValidation: - blockKeywords: ["ignore previous instructions", "system prompt"] - detectInjection: true outputValidation: - maskPII: true # Enmascarar emails, tarjetas de crédito, etc. - toxicityFilter: high ### 3. Usa el principio de menor privilegio Si tu LLM utiliza herramientas (_Function Calling_), no le otorgues privilegios de `cluster-admin` a la cuenta de servicio del LLM. Asígnale una identidad dedicada con los permisos mínimos absolutos requeridos para realizar su tarea específica. ## Reflexiones finales: confía, pero verifica (y luego verifica de nuevo) La industria está pasando de un modelo de seguridad "basado en el perímetro" a uno "basado en el comportamiento". En el mundo de la IA Generativa, el _prompt_ es el nuevo vector de ataque. Kubernetes sigue siendo la capa fundacional; es el terreno sobre el cual construimos. Pero si crees que un archivo `yaml` es suficiente para detener un ataque sofisticado de _prompt injection_ , no estás practicando la seguridad; estás practicando la esperanza. Y como cualquier SRE te dirá, la esperanza no es una estrategia de recuperación confiable. **Fuente:** Basado en análisis de la Cloud Native Computing Foundation (CNCF).

Si has pasado tiempo en el ecosistema _cloud-native_ , conoces esa sensación: has configurado meticulosamente tus `NetworkPolicies`, tu RBAC es lo suficientemente estricto como para hacer llorar de alegría a cualquier auditor de seguridad y todos tus pods están en un hermoso y saludable color verde. Te sientes seguro. Te sientes protegido. Entonces, despliegas un Modelo de Lenguaje Extenso (LLM) y te das cuenta de que, aunque tu infraestructura es una fortaleza, básicamente le has entregado las llaves del reino a un loro parlanchín que puede ser engañado para filtrar las credenciales de tu base de datos simplemente porque alguien le dijo que "ignore todas las instrucciones anteriores". La Cloud Native Computing Foundation (CNCF) lanzó recientemente una verdad lapidaria: Kubernetes es un orquestador increíble, pero es fundamentalmente ciego al caos semántico de la IA. Por eso, confiar únicamente en K8s para la seguridad de un LLM es el equivalente digital a instalar una cerradura biométrica de alta tecnología en una puerta de cartón. ## La ilusión del "pod en verde" Kubernetes es excelente en el "dónde" y el "cómo" del despliegue. Asegura que el pod de tu LLM tenga suficiente memoria de GPU, lo reinicia cuando falla y lo aísla de otras cargas de trabajo. Sin embargo, Kubernetes tiene cero visibilidad sobre el _contenido_ del tráfico que fluye hacia ese pod. Para Kubernetes, un _prompt_ que solicita el resumen de un PDF y un _prompt_ que le ordena al modelo "eliminar todos los buckets de S3 y enviar los logs a una IP aleatoria en Europa del Este" se ven exactamente igual: ambos son simplemente solicitudes HTTP. Esto crea una brecha peligrosa: **`salud operacional != seguridad`.** Tu clúster puede estar perfectamente saludable mientras tu IA desmantela activamente la privacidad de los datos de tu empresa desde adentro. ## Manejar el caos dentro del caos: el modelo de amenazas de LLM Las aplicaciones tradicionales son deterministas. Proporcionas la entrada A y el código ejecuta la ruta B. Los LLMs, sin embargo, son entidades de toma de decisiones programables. Cuando le das a un LLM acceso a herramientas internas, APIs o logs, no estás desplegando solo un servicio; estás desplegando un agente. Esto introduce riesgos que `kube-proxy` no puede resolver: * **Prompt Injection:** El arte de engañar a un LLM para que ignore sus _system prompts_ y realice acciones no autorizadas. * **Exposición no intencionada de datos:** El modelo "alucina" o filtra accidentalmente datos de entrenamiento sensibles o secretos del sistema en una respuesta. * **Uso indebido de herramientas:** Si tu LLM tiene un "plugin" para consultar tu base de datos, un usuario astuto podría engañarlo para que ejecute un comando `DROP TABLE` a través de un _prompt_ en lenguaje natural. ## Donde la seguridad tradicional se queda corta Seamos claros: sigues necesitando tu seguridad estándar de K8s. Si no estás usando Pod Security Admissions o Network Policies, tienes problemas más graves. Pero estas herramientas operan en las capas de red y de sistema operativo, mientras que las amenazas de los LLM operan en la **capa semántica**. Capa de Seguridad | Herramienta de Kubernetes | Vulnerabilidad de LLM | ¿Puede K8s detenerlo? ---|---|---|--- **Red** | NetworkPolicy | Prompt Injection | No **Identidad** | RBAC | Filtración de datos vía Chat | No **Cómputo** | Resource Quotas | Alucinaciones del modelo | No **Runtime** | Seccomp/AppArmor | Ejecución de herramientas maliciosas | Parcialmente Por ejemplo, una `NetworkPolicy` puede evitar que un pod se comunique con una IP externa, pero no puede evitar que un LLM le diga a un usuario: "Claro, aquí tienes la contraseña de administrador que encontré en las variables de entorno". ## Construyendo guardrails reales Para asegurar tus workloads LLM, debemos movernos hacia una **ingeniería de plataformas consciente de la IA (AI-aware platform engineering)**. Esto significa tratar al modelo como un usuario no confiable y envolverlo en una capa de gobernanza semántica. ### 1. Adopta OWASP Top 10 para LLMs OWASP Top 10 for LLM Applications es el estándar de oro para comprender estos riesgos. Cubre desde la Inyección de Prompts (LLM01) hasta la Divulgación de Información Sensible (LLM06). ### 2. Implementa guardrails semánticos En lugar de confiar en la infraestructura para bloquear el tráfico, implementa una capa intermedia (un "_guardrail_ ") que inspeccione tanto el _prompt_ de entrada como la respuesta de salida. ## Ejemplo conceptual de una Política de Guardrail ## (No es un CRD real de K8s, sino un flujo lógico) apiVersion: ai.security.io/v1 kind: LLMGuardrail metadata: name: pii-filter spec: inputValidation: - blockKeywords: ["ignore previous instructions", "system prompt"] - detectInjection: true outputValidation: - maskPII: true # Enmascarar emails, tarjetas de crédito, etc. - toxicityFilter: high ### 3. Usa el principio de menor privilegio Si tu LLM utiliza herramientas (_Function Calling_), no le otorgues privilegios de `cluster-admin` a la cuenta de servicio del LLM. Asígnale una identidad dedicada con los permisos mínimos absolutos requeridos para realizar su tarea específica. ## Reflexiones finales: confía, pero verifica (y luego verifica de nuevo) La industria está pasando de un modelo de seguridad "basado en el perímetro" a uno "basado en el comportamiento". En el mundo de la IA Generativa, el _prompt_ es el nuevo vector de ataque. Kubernetes sigue siendo la capa fundacional; es el terreno sobre el cual construimos. Pero si crees que un archivo `yaml` es suficiente para detener un ataque sofisticado de _prompt injection_ , no estás practicando la seguridad; estás practicando la esperanza. Y como cualquier SRE te dirá, la esperanza no es una estrategia de recuperación confiable. **Fuente:** Basado en análisis de la Cloud Native Computing Foundation (CNCF).

Editing a Ghost theme has always been more complicated than it should be. Even a small change meant going through the full cycle: download the theme, unzip it, edit files, zip it again, and upload it back. It works, but it breaks the flow. Starting today, this is no longer necessary. New "Edit in Browser" item in installed theme menu We’ve added a built-in Theme Editor to all Synaps Media publications, with no setup required. You can now edit your theme files directly from the Ghost Admin, instantly. By clicking "Edit in Browser" button in installed theme list on your Ghost Admin, you will see a file editor right inside your screen. Editing theme files in built-in code editor This is great for quickly editing translations, small updates on your templates, or adding a custom files to your theme like `robots.txt`. You can add/delete/rename files and folders. Edit language files or templates, within a full-featured code editor. No downloads. No uploads. No extra steps. If you’re working on customizing your theme, give it a try. This tool is an open-source project built and published by Synaps Media. If you are curious about the technical background of the project check the article from Murat Çorlu.

## la ironía de la seguridad: las github actions de trivy secuestradas (otra vez) En un giro del destino que haría que cualquier SRE se sirviera un trago fuerte, Trivy —el escáner de vulnerabilidades estándar de la industria mantenido por Aqua Security— ha sido comprometido por segunda vez en un mes. Parece que la herramienta diseñada para encontrar brechas en tu infraestructura era, en sí misma, una brecha bastante grande. Esto no es solo un pequeño error en un archivo README. Estamos hablando de un ataque a la cadena de suministro (_supply chain attack_) a gran escala, donde se secuestraron 75 etiquetas de versión (_tags_) para distribuir un _infostealer_ diseñado para succionar cada secreto en tu pipeline de CI/CD. ## el segundo acto de una tragedia en la cadena de suministro El la brecha afectó a dos GitHub Actions principales: `aquasecurity/trivy-action` y `aquasecurity/setup-trivy`. Estas son el pan de cada día en los pipelines de DevOps modernos, utilizadas para escanear imágenes de contenedores y configurar el entorno de Trivy. Según investigadores de Socket, un atacante logró realizar un _force-push_ en 75 de las 76 etiquetas de versión en el repositorio `trivy-action`. Al sobrescribir las etiquetas existentes (como `v0.1.0`, `v0.2.0`, etc.), el atacante se aseguró de que cualquiera que apuntara a estas versiones "estables" descargara automáticamente un _payload_ malicioso. Es un ataque clásico de "Tag Poisoning" (envenenamiento de etiquetas), demostrando una vez más que, en el mundo de Git, un _tag_ es tan permanente como una promesa de año nuevo. ## cómo ocurrió el atraco: tag poisoning 101 El atacante no necesitó explotar un _zero-day_ en Git. Simplemente utilizó credenciales válidas —probablemente un Personal Access Token (PAT) o un token de automatización— obtenidas de una brecha anterior. ### la mecánica del ataque 1. **Reutilización de credenciales:** Los atacantes aprovecharon secretos robados durante el incidente "hackerbot-claw" a finales de febrero de 2026. 2. **Force-Push de etiquetas:** En lugar de crear un nuevo _release_ sospechoso, el atacante reescribió la historia. Actualizaron las etiquetas existentes para que apuntaran a _commits_ maliciosos. 3. **Ejecución:** Cuando se ejecutaba un flujo de trabajo de GitHub Actions, este obtenía la etiqueta "envenenada", ejecutando un _infostealer_ basado en Python en el _runner_. # Lo que pensabas que estabas ejecutando: - name: Run Trivy vulnerability scanner uses: aquasecurity/[email protected] # Esta etiqueta fue secuestrada # Lo que realmente estaba pasando: # El runner descarga el commit malicioso asociado con v0.28.0 # y ejecuta el infostealer de Python embebido. ## el payload: una aspiradora digital de secretos El código malicioso no fue sutil. Una vez activo en un _runner_ de GitHub, realizaba un barrido sistemático del entorno para robar: * **Credenciales de nube:** Claves de AWS, Azure y GCP. * **Tokens de Kubernetes:** Porque, ¿por qué no apoderarse de todo el clúster? * **Claves SSH y configuraciones de Git:** Para movimiento lateral. * **Billeteras de criptomonedas:** Específicamente apuntando a pares de claves de validadores de Solana (un pequeño bono para los hackers). Si la exfiltración principal a `scan.aquasecurtiy[.]org` (noten la sutil falta de ortografía) fallaba, el script tenía un plan de respaldo: creaba un repositorio público llamado `tpcp-docs` bajo la propia cuenta de GitHub de la víctima y volcaba allí los datos robados. Eso es añadir sal a la herida. ## la causa raíz: una lección sobre "contención incompleta" Aqua Security admitió que esta segunda ola fue el resultado directo de una "contención incompleta" del primer incidente. Aunque rotaron los secretos, el proceso no fue "atómico". En el lapso entre la revocación y la rotación, los atacantes capturaron los nuevos tokens. Es un recordatorio aleccionador para los SRE: si no quemas la casa completa después de una brecha, las termitas simplemente se mudarán a la siguiente viga. ## atribución: conozcan a teampcp El _payload_ se autoidentificó como el "TeamPCP Cloud stealer". TeamPCP (también conocido como DeadCatx3 o ShellForce) es un grupo ya conocido en círculos de seguridad. Se especializan en vulnerar infraestructura para el robo de datos y extorsión. Aunque las "falsas banderas" siempre son una posibilidad en la atribución, las TTP (Tácticas, Técnicas y Procedimientos) coinciden estrechamente con el trabajo conocido del grupo. ## cómo detener la hemorragia Si estás usando Trivy en tus pipelines, detén lo que estés haciendo y verifica tus versiones. ### 1. Usa versiones seguras Asegúrate de estar utilizando los siguientes lanzamientos (o posteriores): * trivy 0.69.3 * trivy-action 0.35.0 * setup-trivy 0.2.6 ### 2. Fija por SHA, no por etiqueta Esta es la lección más importante. Las etiquetas son mutables; los hashes SHA-256 no lo son. Al fijar tus GitHub Actions a un hash de _commit_ específico, eliminas el riesgo de secuestro de etiquetas. # NO hagas esto: uses: aquasecurity/[email protected] # HAZ esto (hash de ejemplo): uses: aquasecurity/trivy-action@1234567890abcdef1234567890abcdef12345678 ### 3. Rótalo todo Si ejecutaste una versión comprometida (específicamente la `v0.69.4` del binario o las etiquetas de la _action_ secuestradas), asume que **todos** tus secretos están comprometidos. Rota tus claves de AWS, PATs de GitHub y tokens de Kubernetes de inmediato. ### 4. Filtrado de red Bloquea los siguientes indicadores de compromiso (IoCs) a nivel de firewall o proxy: * **Dominio:** `scan.aquasecurtiy[.]org` * **IP:** `45.148.10[.]212` Para más detalles técnicos, puedes seguir la discusión en curso en el GitHub oficial de Aqua Security. **Fuente:** The Hacker News **Referencia del autor:** Basado en reportes de The Hacker News e investigaciones de Socket, Wiz y StepSecurity.

Llevo más de una década haciendo turnos de guardia. Cuando los computadores que administro tienen un problema, le avisan a mi equipo 24/7 para que los ayude. Uso estos credos para que estar de turno sea lo más tranquilo posible. ### Descúbrelo antes que el cliente Ya sea que el cliente sea interno o externo, los monitores deben ajustarse para que el equipo de guardia pueda responder y reparar antes de que quienes dependen del servicio se den cuenta de que hay un problema. ### Cada alerta de alta prioridad debería ser accionable La fatiga de alertas es real. Claro, envía algunas alertas informativas pero no accionables a un canal de chat. Pero si el equipo de guardia se despierta e interrumpe cuando no hay trabajo real que hacer, eso es un problema. Reevalúa: * ¿Se puede ajustar el sistema o la alerta para que las alertas sean accionables? * ¿Necesitamos esta alarma en absoluto? * ¿Debería aumentarse temporalmente el umbral de la alerta? * ¿Podría deshabilitarse temporalmente la alerta, con un recordatorio establecido con una alerta configurada para cuando se espere que el problema esté completamente resuelto? ### Los sistemas críticos deberían ser redundantes Muchas emergencias de alta prioridad se pueden convertir en situaciones de baja prioridad si existe una política y práctica que establezca que todos los sistemas críticos son redundantes. Para servidores no críticos, usa una función como la que ofrece Amazon Web Services para detectar cuando el hardware subyacente falla. Luego, puede reaprovisionar automáticamente nuevo hardware y reiniciar el servidor. Eso es exactamente lo que haría un humano de guardia en esas situaciones, así que automatiza la solución. ### El primer responsable debería poder resolver la mayoría de los problemas. Para las alertas de una aplicación en particular, alguien familiarizado con la aplicación debería estar de turno para darle soporte. Los miembros nuevos del equipo de turno pueden acompañar a los miembros con más experiencia para adquirir conocimientos antes de tomar turnos solos. ### Debería haber un segundo de turno Si el principal no responde a tiempo, las alertas deberían pasar a otra persona. Hay que dejar bien clara la responsabilidad de cada rol. Se espera que el principal se encargue de las páginas o que haga arreglos con anticipación si hay un período en el que no pueda cubrir. Que dos personas estén de turno esperando que la otra tome una página no es una estrategia. ### Tener un runbook que documente las posibles alertas y las respuestas comunes a ellas Idealmente, para cada problema debería haber alguna forma de evitar que ocurra o automatizar una solución para los incidentes. Para el resto, algunos documentos y una lista de verificación son lo mejor. He usado un Google Doc organizado por servidor o servicio. Para cada uno, hay una breve sección de Contexto para recordar qué hace la cosa, una sección de Contacto para los expertos del servicio a quienes escalar. En algunos casos, las escaladas a estas personas se pueden automatizar con el servicio de paginación. Finalmente, si hay alguna nota especial sobre alertas y resoluciones comunes. Por ejemplo: _**Servidor del blog:** El alto uso de CPU en este servidor a menudo indica que WordPress está siendo atacado de nuevo. Considera bloquear las direcciones IP involucradas en el firewall._ Aún mejor: usa las herramientas en servicios como PagerDuty para incluir o enlazar la documentación que necesites para cada alerta directamente en la alerta misma. ## Los incidentes de producción deberían ser analizados Ah, no hay nada como el compañerismo que surge de vivir un "firefight" para volver a poner un servicio en línea juntos. Para minimizar las reuniones de tu brigada de bomberos, aprende de los errores cometidos y toma medidas proactivas para minimizar su recurrencia. Cuando haya una interrupción significativa, programa un informe post-incidente de producción dentro de una o dos semanas después del incidente. El enfoque es prospectivo para mejorar los sistemas. No es una sesión para buscar culpables. Usa una plantilla estándar y limita el tiempo de las reuniones para mantener las cosas en movimiento. Treinta minutos suelen ser suficientes. Aquí hay algunas preguntas que he usado antes en plantillas de informes post-incidente de producción que han resistido la prueba del tiempo: * Resumen y cronología del incidente * Acciones ya tomadas * ¿Qué salió bien? * ¿Cómo podemos prevenir incidentes similares en el futuro? * ¿Cómo podemos responder de manera más eficiente y efectiva? * ¿Qué acciones de seguimiento se deben tomar? Haz que una persona cercana al incidente redacte la cronología y dirija la reunión. Invita a todas las partes interesadas relevantes para el incidente. ## Todo lo demás también importa Detallar todo lo demás que podría mejorar la calidad de vida de los respondedores de guardia sería describir un departamento de TI completo y bien gestionado. Siempre habrá inconvenientes al estar de guardia. Con algunos principios sólidos y un compromiso con la mejora continua, hay esperanza de llegar al punto en que el número de alertas sea mínimo... y accionable.

## Resumen (Overview) Resulta que automatizar tus flujos de trabajo también hace que sea increíblemente fácil para los atacantes automatizar tu perdición. Una campaña de ataque autónoma, rastreada como **"hackerbot-claw"** , está acechando actualmente repositorios públicos. ¿Su misión? Encontrar workflows de GitHub Actions inseguros y convertirlos en puertas de enlace para la ejecución de código arbitrario y la exfiltración de credenciales. Esta campaña no es solo el proyecto de fin de semana de un _script-kiddie_ ; ha logrado comprometer con éxito varios proyectos de código abierto de alto perfil. Al abusar de configuraciones erróneas comunes, el bot efectivamente vuelve tu pipeline de CI/CD en tu contra. Si has estado tratando tus triggers de `pull_request_target` con la imprudencia de un desarrollador en su quinto café del día, es hora de prestar atención. La Linux Foundation y la OpenSSF están "triagiando" (triage) activamente las consecuencias, pero el bot trabaja más rápido que un comité. ## Anatomía del ataque El bot "hackerbot-claw" no está reinventando la rueda; simplemente está usando la rueda para pasarte por encima. Se dirige específicamente a workflows que: * Utilizan triggers privilegiados como `pull_request_target`. * Ejecutan código no confiable de _pull requests_ (PRs) forkeados sin aislamiento. * Incluyen scripts de shell _inline_ que confían ciegamente en inputs controlados por el usuario. * Carecen de cualquier forma de verificación de autorización antes de disparar _runners_ costosos (y peligrosos). ### Patrones de ataque observados 1. **Inyección directa de scripts:** Los atacantes modifican un script dentro de un PR. Si el workflow ejecuta ese script con privilegios del repositorio, el atacante efectivamente se adueña del _runner_. 2. **"Pwn request" (abuso de`pull_request_target`):** Este trigger es el "Modo Dios" de GitHub Actions. Cuando se usa para hacer _checkout_ y ejecutar código desde un _fork_ , otorga a ese código no confiable acceso a secretos y a un `GITHUB_TOKEN` con permisos de escritura. 3. **Inyección de contexto:** Los _payloads_ maliciosos se ocultan en nombres de ramas, títulos de PR o rutas de archivos. Si tu workflow hace algo como `echo "Checking out ${{ github.head_ref }}"`, podrías encontrarte ejecutando `echo "Checking out "; rm -rf / #`. ### Una víctima del mundo real: project-akri/akri En un caso documentado que involucró a `project-akri/akri`, un PR malicioso introdujo un _payload_ de inyección de shell en un script. Debido a que el workflow carecía de salvaguardas, ejecutó obedientemente los comandos del atacante, demostrando una vez más que las computadoras harán exactamente lo que les digas, incluso si es un suicidio profesional. ## Mitigaciones recomendadas Si no quieres que tu repositorio se convierta en un minero de criptomonedas para alguien más o en un punto de pivote para un ataque a la cadena de suministro, implementa estos controles de inmediato. ### 1. Refuerza (harden) tus workflows Deja de usar `pull_request_target` a menos que sea absolutamente necesario. Si debes usarlo, **nunca** hagas _checkout_ del código no confiable desde el _head_ del PR. # MAL: Esto le da al código del fork acceso a tus secretos on: pull_request_target jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} # PELIGRO ### 2. Aplica el principio de menor privilegio Limita los permisos del `GITHUB_TOKEN` en la parte superior de tu archivo de workflow. Si un _job_ solo necesita leer el código, indícalo explícitamente. permissions: contents: read pull-requests: read ### 3. Sanitiza los inputs como si tu vida dependiera de ello Nunca interpoles variables de contexto de GitHub directamente en scripts de shell. Usa variables de entorno en su lugar. # MAL: Vulnerable a inyección run: echo "Procesando rama: ${{ github.head_ref }}" # BIEN: Manejado como datos, no como código run: echo "Procesando rama: $BRANCH_NAME" env: BRANCH_NAME: ${{ github.head_ref }} ### 4. Pinnea tus actions No confíes en etiquetas (tags) como `@v1`. Los tags pueden ser movidos. Usa el SHA completo del commit para asegurar que el código que estás ejecutando es el código que revisaste. - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0 ## Alineación con el OpenSSF OSPS Baseline La campaña actual "hackerbot-claw" apunta exactamente a las brechas abordadas por el OpenSSF OSPS (Open Source Project Security) Baseline. Los proyectos que siguen estas pautas son significativamente más difíciles de comprometer. * **Menor Privilegio:** Restringir el `GITHUB_TOKEN` y usar OIDC para credenciales de nube de corta duración. * **CI/CD Protegido:** Requerir la aprobación de un mantenedor para todos los colaboradores primerizos antes de que se ejecuten los workflows. * **Revisión por Pares:** Usar `CODEOWNERS` para exigir que cualquier cambio en `.github/workflows/` sea revisado por un humano consciente de la seguridad, no solo por un mantenedor cansado. ## Lecturas adicionales y recursos * Guía oficial de GitHub sobre inyección de scripts * OpenSSF: Mitigando vectores de ataque en workflows de GitHub * Wiz.io: Guía de seguridad de GitHub Actions * Mejores prácticas de OpenSSF SCM * * * **Fuente:** Christopher "CRob" Robinson, Chief Technology Officer & Chief Security Architect en OpenSSF / The Linux Foundation. GitHub | LinkedIn

## overview It turns out that automating your workflows also makes it incredibly easy for attackers to automate your demise. An autonomous attack campaign, tracked as **"hackerbot-claw,"** is currently prowling public repositories. Its mission? Finding insecure GitHub Actions workflows and turning them into gateways for arbitrary code execution and credential exfiltration. The campaign isn't just a script-kiddie's weekend project; it has successfully compromised several high-profile open-source projects. By abusing common misconfigurations, the bot effectively turns your CI/CD pipeline against you. If you’ve been treating your `pull_request_target` triggers with the reckless abandon of a developer on their fifth espresso, it’s time to pay attention. The Linux Foundation and the OpenSSF are actively triaging the fallout, but the bot works faster than a committee. ## anatomy of the attack The "hackerbot-claw" bot isn't reinventing the wheel; it’s just using the wheel to run you over. It specifically targets workflows that: * Use privileged triggers like `pull_request_target`. * Execute untrusted code from forked pull requests without isolation. * Include inline shell scripts that blindly trust user-controlled inputs. * Lack any form of authorization check before firing off expensive (and dangerous) runners. ### observed attack patterns 1. **Direct script injection:** Attackers modify a script within a PR. If the workflow executes that script with repository privileges, the attacker effectively owns the runner. 2. **"Pwn request" (pull_request_target abuse):** This trigger is the "God Mode" of GitHub Actions. When used to check out and run code from a fork, it grants that untrusted code access to secrets and a `GITHUB_TOKEN` with write permissions. 3. **Context injection:** Malicious payloads are hidden in branch names, PR titles, or file paths. If your workflow does something like `echo "Checking out ${{ github.head_ref }}"`, you might find yourself executing `echo "Checking out "; rm -rf / #`. ### a real-world casualty: project-akri/akri In a documented case involving `project-akri/akri`, a malicious PR introduced a shell-injection payload into a script. Because the workflow lacked safeguards, it dutifully executed the attacker's commands, proving once again that computers will do exactly what you tell them to do, even if it's professional suicide. ## recommended mitigations If you don't want your repository to become a miner for someone else's cryptocurrency or a pivot point for a supply chain attack, implement these controls immediately. ### 1. harden your workflows Stop using `pull_request_target` unless you absolutely have to. If you must use it, **never** check out the untrusted code from the PR head. # BAD: This gives the fork's code access to your secrets on: pull_request_target jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} # DANGER ### 2. enforce least privilege Limit the `GITHUB_TOKEN` permissions at the top of your workflow file. If a job only needs to read the code, tell it so. permissions: contents: read pull-requests: read ### 3. sanitize inputs like your life depends on it Never interpolate GitHub context variables directly into shell scripts. Use environment variables instead. # BAD: Vulnerable to injection run: echo "Processing branch: ${{ github.head_ref }}" # GOOD: Handled as data, not code run: echo "Processing branch: $BRANCH_NAME" env: BRANCH_NAME: ${{ github.head_ref }} ### 4. pin your actions Don't trust tags like `@v1`. Tags can be moved. Use the full length commit SHA to ensure the code you're running is the code you reviewed. - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0 ## alignment with the openssf osps baseline The ongoing "hackerbot-claw" campaign targets the exact gaps addressed by the OpenSSF OSPS (Open Source Project Security) Baseline. Projects that follow these guidelines are significantly harder to compromise. * **Least Privilege:** Restrict `GITHUB_TOKEN` and use OIDC for short-lived cloud credentials. * **Protected CI/CD:** Require maintainer approval for all first-time contributors before workflows run. * **Peer Review:** Use `CODEOWNERS` to mandate that any change to `.github/workflows/` is reviewed by a security-conscious human, not just a tired maintainer. ## further reading & resources * GitHub's official guidance on script injection * OpenSSF: Mitigating attack vectors in GitHub workflows * Wiz.io: GitHub Actions security guide * OpenSSF SCM best practices * * * **Source:** Christopher "CRob" Robinson, Chief Technology Officer & Chief Security Architect at OpenSSF / The Linux Foundation. GitHub | LinkedIn

En una medida que evidencia la creciente tendencia autoritaria de gobiernos, la tensión entre la innovación tecnológica y los _"imperativos de seguridad nacional"_ ~~(ok...)~~ , el Departamento de Guerra de EE. UU. (DoW) ha designado oficialmente a Anthropic, empresa ya por todos conocida en inteligencia artificial (IA), como un "_riesgo en la cadena de suministro" (supply chain risk)_. Esta designación, impulsada por el secretario de Defensa de EE. UU., Pete Hegseth, surge tras un estancamiento en las negociaciones sobre el "despliegue ético" de Claude, el modelo de IA insignia de Anthropic, para aplicaciones y usos militares. ## La "postura desafiante" de Anthropic La designación de Anthropic como riesgo en la cadena de suministro se deriva de su negativa a permitir dos usos específicos de su tecnología: la vigilancia masiva doméstica de ciudadanos estadounidenses y el desarrollo de sistemas de armas autónomas. La compañía articuló su postura en un comunicado: _"Ninguna cantidad de intimidación o castigo del Departamento de Guerra cambiará nuestra posición sobre la vigilancia masiva doméstica o las armas totalmente autónomas"_. ## La hipocresía -si, también- de Anthropic Este desacuerdo fundamental sobre los límites éticos de la IA en la "defensa nacional" implica el apoyo de Anthropic al uso de su tecnología en otros países, pero rechaza su aplicación en EEUU por considerarla incompatible con valores democráticos y libertades fundamentales. Las contradicciones y el doble standard se revelan por sí mismos, no? ### No es conspiración ni ficción: documentos oficiales El Departamento de Guerra (antes llamado Departamento de Defensa), insiste en colaborar sólo con empresas que permitan _"cualquier uso lícito"_ de su tecnología, sin _"restricciones ideológicas"_. Un memorándum del Pentágono subraya esta postura: _"La Diversidad, Equidad e Inclusión no tienen cabida en el DoW. No emplearemos modelos de IA con 'ajustes' ideológicos que limiten respuestas objetivamente veraces"_. __Fuente:____https://media.defense.gov/2026/Jan/12/2003855671/-1/-1/0/ARTIFICIAL-INTELLIGENCE-STRATEGY-FOR-THE-DEPARTMENT-OF-WAR.PDF__ ## La rápida (y teatral) represalia del gobierno La designación fue parte de una respuesta coordinada. El presidente ordenó via 1 User Only"Social Network" eliminar gradualmente la tecnología de Anthropic en agencias federales dentro de seis meses. El secretario de guerra lo _retwitteó (?)_ en X, exigiendo a contratistas militares cesar toda relación con la empresa. El funcionario vinculó la medida a la orden presidencial, declarando: _"Designamos a Anthropic como Riesgo en la Cadena de Suministro para la Seguridad Nacional"_. El gobierno actuó con la agilidad de un _zero-day exploit_ , priorizando acción directa sobre formalidades. ### Detalles legales que no entendemos Anthropic calificó la designación de _"jurídicamente infundada"_ , argumentando que "10 USC 3252 solo aplica a contratos del DoW, no a otros clientes" ~~(La verdad es que no tengo idea de legislación en EEUU)~~. Este escenario sienta un precedente peligroso: "desacuerdos éticos" podrían convertirse en "riesgos de seguridad nacional" a gusto del gobierno o magnate de turno, pero sus consecuencias afectando al mundo entero. Por ejemplo, potencialmente un dron podría "decidir" atacarte ahora mismo sin orden humana. Si, a ti. ## 2 CEOs 1 Gov: el camino de OpenAI En contraste, el CEO de OpenAI, Sam Altman, anunció un acuerdo con el Departamento de Defensa para desplegar sus modelos en redes clasificadas. Ya sabemos el resto de la historia. ## Por qué debería importarme? La disputa trasciende países, política, o lo corporativo: define el futuro de la IA en "seguridad" y guerra. Cientos de empleados de Google y OpenAI exigen solidaridad con Anthropic, resaltando preocupaciones sectoriales. La designación envía un mensaje alarmante: la ética puede subordinarse a la "seguridad nacional". ¿Seguirán otras empresas el "ejemplo" de Anthropic o adaptarán sus principios a contratos gubernamentales? La respuesta define si la IA servirá a la humanidad o se convertirán en herramientas de guerra y vigilancia. Fuente: The Hacker News