Valsorda: los reportes de vulnerabilidades dejaron de ser especiales

⏱️ Lectura: 11 min

Durante años, la regla no escrita del open source fue clara: podés ignorar casi cualquier issue o pull request, pero un reporte de seguridad es sagrado. Filippo Valsorda, ex líder del equipo de seguridad del lenguaje Go, acaba de poner esa regla en duda.

📑 En este artículo

1. TL;DR
2. Qué pasó
3. Contexto e historia
4. Datos y cifras
5. Impacto y análisis
6. Qué sigue: análisis de seguridad en el CI
7. Preguntas frecuentes
   1. ¿Valsorda dice que hay que ignorar los reportes de seguridad?
   2. ¿Por qué los LLM cambian la ecuación?
   3. ¿Significa que la divulgación coordinada ya no sirve?
   4. ¿Qué debería hacer hoy un mantenedor de open source?
   5. ¿Esto aplica a proyectos pequeños de LATAM?
   6. ¿Los modelos reemplazan a los investigadores de seguridad?
8. Referencias

En un texto publicado el 23 de junio de 2026, sostiene que los reportes de vulnerabilidades ya no son especiales. El motivo: los modelos de lenguaje volvieron abundante lo que antes era escaso, y el verdadero trabajo se movió del hallazgo al triaje.

TL;DR

• Filippo Valsorda, ex líder del equipo de seguridad de Go, publicó el 23 de junio de 2026 que los reportes de vulnerabilidades ya no son especiales.
• El argumento clásico: los investigadores ofrecían insight escaso y confidencialidad a cambio de respuesta rápida y atribución.
• En 2026 esas premisas se rompen: los LLM hallan bugs tan bien como casi cualquier investigador y los puede correr cualquiera.
• El cuello de botella ya no es encontrar problemas potenciales, sino determinar cuáles son reales: el triaje.
• La confidencialidad y los embargos pierden peso porque el atacante también puede preguntarle a su propio LLM.
• La nueva prioridad del mantenedor: triaje, remediación rápida, prevención y análisis con LLM dentro del CI.
• Para LATAM y el open source de la región, implica automatizar el análisis de seguridad en vez de depender del reporte externo.

Qué pasó

Valsorda no es un opinador cualquiera. Lideró el equipo de seguridad de Go en Google y hoy mantiene piezas críticas del lenguaje a través de Geomys, una organización de mantenedores profesionales de Go financiada por empresas como Datadog, Tailscale, Teleport, Sentry y Ava Labs. Cuando alguien con ese recorrido dice que un dogma de la industria caducó, vale la pena leerlo con atención.

Su punto de partida es una idea sana para cualquier mantenedor: cada issue, PR o comentario es un regalo, no una obligación. Podés aceptarlo, ignorarlo o usarlo a medias. Durante años, Valsorda le decía a la gente nueva del equipo que había una única excepción: los reportes de vulnerabilidades. Esos sí eran especiales, porque el investigador te estaba haciendo un favor al reportar en privado en lugar de hacer divulgación total.

El intercambio era explícito. El mantenedor ofrecía dos cosas: responsividad (acusar recibo rápido, investigar, mantener al reportante al tanto) y atribución (acreditar el descubrimiento). A cambio recibía dos cosas valiosas: el insight de haber encontrado la falla, y la confidencialidad necesaria para publicar el parche antes de que el atacante publicara el exploit.

La tesis de 2026 es que ninguna de esas premisas sigue en pie. Los LLM, dice, son tan buenos como casi cualquier investigador de seguridad, y cualquiera los puede correr: el mantenedor, el investigador externo y el atacante por igual.

Contexto e historia

Para entender por qué esto es polémico hay que recordar de dónde viene la idea de la divulgación coordinada. En otra época, reportar una vulnerabilidad era literalmente peligroso: a investigadores bien intencionados se los recibía con amenazas legales o directamente con denuncias penales.

Hizo falta el movimiento de full disclosure (divulgación total) para que la industria internalizara lo contraproducente de esa actitud. Parte del trato de la divulgación coordinada —que Valsorda prefiere llamar así y no “responsable”, por la carga moral del término— fue una promesa implícita: no perseguir a quien reporta. Ese miedo, afortunadamente, hoy es casi irrelevante en el open source: ningún investigador teme una demanda por reportar, y ningún proyecto debería siquiera insinuarla.

Sobre esa historia se construyó la idea de que el reportante presta un servicio. Y el corolario era duro pero justo: ignorar un reporte de seguridad comunicaba que no te importaba la seguridad de tus usuarios, y era —con razón— motivo de vergüenza. Esa lógica funcionó mientras el insight fue escaso. El cambio de 2026 es que dejó de serlo.

💭 Clave: El reportante nunca fue lo especial. Lo especial era el insight escaso y la confidencialidad. Cuando esos dos recursos se vuelven abundantes, la deuda de responsividad y atribución pierde su fundamento.

Datos y cifras

El argumento es cualitativo, pero se apoya en una observación medible sobre la economía del trabajo de seguridad. Tradicionalmente el embudo tenía un único cuello de botella escaso: encontrar el problema. Conseguir una persona capaz de hallar un bug explotable en una librería de criptografía era caro y raro.

Hoy ese paso se abarató casi a cero. Un LLM genera decenas de hallazgos candidatos en minutos. El cuello de botella se desplazó por completo hacia el otro extremo del embudo: el triaje, es decir, decidir cuáles de esos candidatos son reales y cuáles son ruido plausible pero falso.

Y acá está el detalle incómodo: salvo que ya exista una relación de confianza, un investigador externo no puede aportar gran cosa a ese triaje. Revisar la salida cruda de un LLM ajeno o revisar tu propia bandeja security@ tiene aproximadamente la misma relación señal/ruido. El reporte externo, que antes traía señal pura, ahora puede traer el mismo ruido que vos ya podrías generar solo.

flowchart LR
  A["Investigador o LLM"] --> B["Muchos hallazgos candidatos"]
  B --> C["Triaje: cual es real?"]
  C -->|"Real"| D["Remediacion rapida"]
  C -->|"Ruido"| E["Descartar"]
  D --> F["Prevencion en CI"]

La confidencialidad sufre el mismo destino. Los embargos y la coordinación importaban porque el atacante necesitaba leer la divulgación para aprender de la falla. Pero si el atacante puede correr su propio LLM sobre el mismo código, no necesita tu post: probablemente ya tiene el mismo embudo y el mismo cuello de botella de triaje que vos. El secreto deja de comprar la ventaja temporal que justificaba todo el ritual.

Impacto y análisis

Si la premisa es correcta, la consecuencia para los mantenedores —y muy especialmente para el open source de LATAM, donde los equipos suelen ser de una o dos personas sin presupuesto— es un cambio de rol. El trabajo deja de ser esperar y atender reportes y pasa a ser triaje, remediación rápida y, como siempre, prevención.

Esto tiene un lado liberador. Muchos mantenedores arrastraban una culpa difusa por no responder con la rapidez “debida” a cada correo de security@. Si el reporte externo ya no es un favor escaso sino una más de las miles de salidas posibles de un modelo, la presión moral asimétrica se diluye. El mantenedor recupera el derecho a tratar esos mensajes como lo que son hoy: insumos a triar, no obligaciones a honrar.

El lado complicado aparece en los bordes. Valsorda menciona un caso espinoso: ¿qué hacés si quien reporta una vulnerabilidad real también está violando el código de conducta del proyecto? ¿La ignorás? ¿La arreglás en silencio sin dar crédito? No hay forma limpia de cuadrar ese círculo; queda en un juicio caso por caso según la gravedad de la conducta y los recursos del equipo.

⚠️ Ojo: “Los LLM ya triajan solos” es la lectura fácil y equivocada. El modelo genera candidatos; la decisión de qué es real sigue necesitando criterio humano y contexto del proyecto. Lo que se abarató es el hallazgo, no el juicio.

Qué sigue: análisis de seguridad en el CI

La conclusión práctica de Valsorda es directa: deberíamos descubrir cómo correr análisis con LLM dentro del CI. La idea es invertir el flujo. En lugar de esperar a que un tercero te avise, vos mismo corrés el análisis automatizado en cada pull request, junto a los linters y los tests.

En el ecosistema Go esto no parte de cero. Herramientas como govulncheck ya escanean dependencias contra una base de vulnerabilidades conocidas. El paso nuevo es sumar análisis generativo que busque patrones sospechosos en el código propio, no solo CVE ya catalogados. Veamos una integración mínima con GitHub Actions que combina ambos enfoques:

name: security-scan
on: [pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.24'
      # Escaneo de CVE conocidos en dependencias
      - name: govulncheck
        run: |
          go install golang.org/x/vuln/cmd/govulncheck@latest
          govulncheck ./...
      # Analisis generativo del diff sobre patrones sospechosos
      - name: llm-review
        run: ./scripts/security-llm.sh "$(git diff origin/main...HEAD)"

El script security-llm.sh envía el diff a un modelo con un prompt acotado (“buscá manejo inseguro de entrada, comparaciones de tiempo no constante, rutas de path traversal”) y falla el build si la confianza supera un umbral. La clave es que esto se ejecuta antes de que cualquier atacante o reportante mire el código, y de forma reproducible.

Si querés instalar una CLI de LLM para experimentar localmente con este flujo, acá van los comandos para los tres sistemas más comunes en la región:

# Windows (PowerShell, con winget)
winget install Anthropic.ClaudeCode

# macOS (Homebrew)
brew install claude-code

# Linux (script oficial)
curl -fsSL https://claude.ai/install.sh | sh

El punto de fondo no es la herramienta específica, sino el cambio de mentalidad: la seguridad deja de ser un evento reactivo disparado por un correo y se vuelve una etapa más del pipeline, tan rutinaria como compilar. Para equipos pequeños de LATAM, automatizar este análisis puede ser la diferencia entre depender de la buena voluntad de un extraño y tener un piso de protección que corre solo en cada commit.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Valsorda dice que hay que ignorar los reportes de seguridad?

No exactamente. Dice que dejaron de ser una categoría sagrada con obligaciones asimétricas. Hay que triarlos como cualquier insumo, sin la culpa de “deberles” respuesta inmediata y atribución por defecto.

¿Por qué los LLM cambian la ecuación?

Porque vuelven abundante el hallazgo de fallas, que antes era escaso. Si cualquiera puede generar candidatos a vulnerabilidad, el reporte externo deja de aportar un recurso único y el valor se concentra en el triaje.

¿Significa que la divulgación coordinada ya no sirve?

Pierde parte de su sentido. El embargo protegía una ventaja temporal frente al atacante; si el atacante tiene el mismo análisis automatizado, esa ventaja se reduce. La coordinación sigue siendo útil entre partes con relación de confianza.

¿Qué debería hacer hoy un mantenedor de open source?

Priorizar triaje, remediación rápida y prevención. En concreto: automatizar análisis de seguridad en el CI, mantener dependencias escaneadas y tratar la bandeja security@ como una fuente más, no como una deuda moral.

¿Esto aplica a proyectos pequeños de LATAM?

Aplica especialmente. Los equipos chicos no pueden sostener una operación de respuesta a reportes 24/7, pero sí pueden poner un análisis automatizado en cada pull request a costo casi nulo, ganando un piso de seguridad reproducible.

¿Los modelos reemplazan a los investigadores de seguridad?

No al juicio. Generan candidatos, pero decidir qué es real, explotable y prioritario sigue requiriendo criterio humano y contexto del proyecto. Lo que se democratizó es el hallazgo, no la evaluación.

Referencias

• words.filippo.io — “Vulnerability Reports Are Not Special Anymore”, artículo original de Filippo Valsorda (23/06/2026).
• go.dev/security/policy — Política de divulgación de vulnerabilidades del proyecto Go.
• go.dev/blog/govulncheck — Anuncio de govulncheck, herramienta para detectar vulnerabilidades conocidas en proyectos Go.
• Wikipedia — Divulgación coordinada de vulnerabilidades: definición e historia.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.