¿Quién arregla los proyectos que no mantiene nadie?

Obras

De vez en cuando nos encontramos con ese meme donde aparece toda la infraestructura de internet apoyada en una pequeña columna: un simple desarrollador, mal financiado y no siempre con la motivación suficiente para seguir manteniendo su proyecto.

En Maintainers of last resort, Filippo Valsorda nos habla de Geomys, una organización de desarrolladores de software libre que se ocupa de algunos proyectos (fundamentalmente desarrollados en Go) y a la que se puede contratar para tener acceso a su conocimiento y experiencia en ellos.

Our retainer clients engage us both to get access to our expertise, and so that the critical dependencies they rely on are professionally maintained.

Además, en algunas ocasiones también ejercen de «batallón de choque» cuando se produce algún incidente en otro proyecto que carece de mantenimiento.

Beyond our portfolio, we sometimes act as maintainers of last resort when critical, security-relevant Go projects go unmaintained.

Interesante.

Una IA para generar un secuestro de información completo

Robot guitarrista

Hasta ahora hemos oído hablar de cómo se usa la IA para mejorar las oportunidades de los ataques tipo phishing con mejores traducciones, mensajes más convincentes y todo eso. En Experimental PromptLock ransomware uses AI to encrypt, steal data nos contaban un caso que va un poco más allá, porque PromptLock sería una demostración de la posibilidad de usar una IA para generar los programas de ataque:

The malware uses OpenAI’s gpt-oss:20b model through the Ollama API to dynamically generate the malicious Lua scripts from hard-coded prompts.

Por lo que nos dicen se trata simplemente de una ‘demo’ o una prueba de concepto.

The cybersecurity company believes that PromptLock is a proof-of-concept or work in progress, and not an active ransomware in the wild.

El proyecto parece tener varios ‘padres’.

After ESET published details about PromptLock, a security researcher claimed that that the malware was their project and somehow it got leaked.

Y también, uno académico, sobre el que se puede leer en Large language models can execute complete ransomware attacks autonomously, NYU Tandon research shows.

Researchers from the NYU Tandon School of Engineering have reached out to point out that PromptLock seems to have been directly derived from their project, called “Ransomware 3.0.” They also published a blog post explaining the connection here.

¿Cuánto tiempo tu dominio será tuyo?

Jarras

Muchas veces se habla de que corremos mucho riesgo al confiar nuestra presencia digital (y más, la comunicación digital, dirección de correo…) aservicios externos (gratuitos o no). La solución que suele proponerse es que vale la pena que contratemos nuestro propio dominio, ya que siempre podremos hacer que apunte a nuestro proveedor de cada momento. El problema del que no se habla tanto es lo que puede suceder si perdemos ese dominio por cualquier motivo (dejamos de pagar, cambiamos a otro, …).

En Preventing Domain Resurrection Attacks hablaban justamente de eso relacionado con el proyecto PyPI, que es un repositorio de proyectos escritos en Python y en el que muchos programadores confían.

El problema tiene que ver con el registro en el sitio, que va ligado a una dirección de correo.

PyPI user accounts are linked to email addresses. Email addresses are tied to domain names; domain names can expire if unpaid, and someone else can purchase them.

Y el problema puede aparecer si el dominio de una de estas direcciones cambia de manos, el nuevo propietario podrá usar las cuentas que considere oportuno, entre ellas alguna de las que existía anteriormente, asociada a algún proyecto.

For older accounts prior to the 2FA requirement date, having an email address domain expire could lead to account takeover, which is what we’re attempting to prevent, as well as minimize potential exposure if an email domain does expire and change hands, regardless of whether the account has 2FA enabled.

Para remediarlo, en PyPI hacen verificaciones sobre el estado de registro del dominio (dicho de forma muy simplificada) y cuando se produzca la caducidad considerarán las direcciones de correo asociadas como no verificadas.

After an initial bulk check period that took place in April 2025, PyPI will check daily for any domains in use for status changes, and update its internal database with the most recent status.

El problema es que sólo agentes muy preocupados (y suficientemente grandes) pueden invertir recursos en este tipo de soluciones, así que veremos de vez en cuando cómo puede afectar esto en distintas situaciones.

¿Cómo validar a los proveedores de productos de seguridad que incluyen IA?

Tienda navideña

Ya había productos de ciberseguridad que decían utilizar la IA para protegernos antes de la explosión de la IA generativa: algunos CISOs apoyaban estas aproximaciones y otros las miraban con escepticismo. Sin embargo, ahora ya parece fuera de toda duda que la IA debe incluirse en el arsenal defensivo de cualquier empresa. En A CISO’s Guide to Vetting AI Security Vendors dan algunas recomendaciones sobre la elección de proveedores, basándose en tres pilares.

  • ¿Resuelven algún problema importante?

Pillar 1: The Problem — Are You Solving Anything That Matters?

Se basa en un par de preguntas interesantes: ¿qué problema está resolviendo esta IA?

“What specific pain is your AI solving?”

Y la respuesta debería ser concreta, fácil de entender…

A vendor who can give you a concrete, understandable example of their product’s value actually understands the problem.

¿Realmente es necesaria la IA para eso?

“Why is AI necessary here? How is it superior to simpler methods?”

Esta es una pregunta que deberíamos estar haciéndonos en todos los ámbitos, claro: leí en algún sitio (y trato de seguirlo) que no deberíamos utilizar IA si lo podemos resolver con un programa ‘normal’. O, como dice en el texto, a veces un centenar de expresiones regulares puede producir mejores resultados que un modelo malo al que llaman IA.

Many times, a hundred regular expressions can produce better results than a poorly implemented model, but the vendor just calls it “AI.”

  • ¿Realmente funciona?

Pillar 2: The Proof — Does It Actually Work?

En este caso, la primera pregunta sería ¿Cuáles son los datos de entrada de tu modelo? ¿Qué algoritmo utilizas?

“What are the inputs to your model? What algorithms are you using?”

Se trata de conocer cómo funciona el producto.

También sobre la calidad, ¿qué tasas de falsos positivos y falsos negativos tiene el modelo?

“What are your model’s false positive and false negative rates?”

Se trata de hablar de precisión y sensibilidad (recall): si no pueden darnos esa información es porque probablemente no la conocen, no les interesa, o no es muy buena.

Any serious AI vendor tracks precision and recall. If they can’t give you hard numbers, that’s a red flag. Ask for them in the context of a real customer deployment, not a lab test.

¿Cómo maneja el modelo las amenazas que nunca antes se han visto?

“How does your system handle a threat it has never seen before?”

No debemos olvidar que algunas IAs (LLMs, en particular) proporcionarán respuestas aleatorias en esos casos.

If you pass an LLM a complex attack with multiple TTPs it hasn’t seen before, it might have low confidence and just spit out random MITRE ATT&CK categories.

  • ¿Cómo impactará esto en mi equipo?

Pillar 3: The Practicality — How Will This Impact My Team?

La primera pregunta sería ¿cuál es el verdadero coste de tener esta solución?

“What is the true cost of ownership?”

No se trata de hablar solo del coste de la licencia sino de otros aspectos (el propio funcionamiento, ¿va incluido en la suscripción o aparecerá en mi factura de operaciones en la nube?

This isn’t just the license fee. If the product is feeding massive amounts of data into an LLM, who pays the inference cost? Is it included in your subscription, or is that going to show up on my cloud bill?

Pero también el coste para las personas: ¿cuánto tiempo necesitarán para validar las alertas y resultados que ofrezca la herramienta?

Even more importantly, what is the cost of my team’s time? If my analysts have to spend their days validating the AI’s output, I haven’t saved them work; I’ve just shifted it.

Otra pregunta interesante estaría relacionada con la corrección de errores: ¿si encontramos fallos podemos hacer que la IA aprenda para que no los vuelva a cometer?

“Can my analysts correct the AI’s mistakes, and does it learn from them?”

La última pregunta tendría que ver con la explicabilidad y el cumplimiento: ¿cómo proporciona el sistema la información para los auditores?

“How does your system provide ‘explainability’ for auditors or the board? I need to see detailed decision logs, confidence scores, and visualization tools.”

Complementa el escrito con las señales de alarma (red flags) que incluyen las típicas que hemos visto en otros contextos:

  • Nuestro producto es propietario y no podemos darte detalles.

“Our AI is proprietary and we can’t share details.” Transparency is non-negotiable.

  • No hacemos seguimiento de la tasa de falsos positivos.

“We don’t track false positive rates.” If they don’t measure accuracy, they can’t improve.

  • Funciona sin tener que tocar nada.

“It works out of the box with no tuning.” Real-world environments always require configuration.

Buena lista de recomendaciones.

CSRF y go

Espada del Califa Umar

Igual A Modern Approach to Preventing CSRF in Go es excesivamente técnico y sobre algo muy concreto, pero quería dejarlo guardado porque nunca se sabe qué se puede necesitar en algún momento futuro.

Have we finally reached the point where CSRF attacks can be prevented without relying on a token-based check (like double-submit cookies)? Can we build secure web applications without bringing in third-party packages like justinas/nosurf or gorilla/csrf?

And I think the answer now may be a cautious “yes” — so long as a few important conditions are met.