Los Stars de GitHub Están Trayendo Bots de IA. 5 Cosas Que Hacer Antes de Que Lleguen

11 min read

Hay una notificación de GitHub que vas a odiar.

Un nuevo issue, bien redactado. Cita números de línea precisos en tu código, describe una vulnerabilidad de seguridad con vocabulario técnico convincente, estructura el argumento en 3 puntos claros. El tipo de reporte que parece serio a primera vista.

Generado completamente por un LLM. Enviado por alguien cazando un bug bounty o algunos PRs en su perfil de GitHub antes de la próxima entrevista de trabajo.

Daniel Stenberg ha mantenido curl desde 1998. Instalado en miles de millones de dispositivos, incluido el tuyo. En enero de 2026, cerró su bug bounty de HackerOne después de recibir 7 reportes falsos de seguridad en 16 horas. 20 envíos en 21 días, ninguno identificando una vulnerabilidad real. Estima que cada reporte le cuesta $150 en tiempo de voluntarios para hacer triage. Lo llamó "terror reporting" y mató el programa.

La asimetría en el núcleo de esto: enviar cuesta unos centavos en tokens de AI. Hacer triage cuesta $150 en tiempo humano. Esa asimetría no le importa el tamaño de tu proyecto. Le importa 1 cosa: si tus issues están abiertos.

Ilustración de portada – Escena de oficina dividida mostrando dos desarrolladores en escritorios adyacentes lidiando con notificaciones de issues de GitHub
Ilustración de portada – Escena de oficina dividida mostrando dos desarrolladores en escritorios adyacentes lidiando con notificaciones de issues de GitHub

El Issue Que Parecía Real

Vale la pena describir cómo se ven estos reportes en la práctica, porque el primer que recibas probablemente te engañe durante unos 30 segundos. Esos 30 segundos son toda la mecánica.

El patrón es consistente en los hilos de maintainers de los últimos meses. El issue llega con estructura limpia: nombra una versión específica de tu librería, referencia rutas de archivos que existen en tu repo, y describe un vector de ataque usando el vocabulario correcto. Algo como "validación de entrada inadecuada en el handler podría permitir a un atacante eludir..." seguido de 3 pasos que suenan plausibles. A veces un snippet de proof-of-concept. Gramática perfecta, tono profesional.

Luego vas a ver el código.

La vulnerabilidad no existe. Los números de línea no mapean a nada relevante. El vector de ataque solo funciona si tu librería hace algo que no hace. Todo es una alucinación con el formato de un reporte de seguridad legítimo, enviado por alguien que apuntó un scanner a tu repo, gastó unos centavos de tokens de API, y esperó 3 minutos.

No puedes saltarte estos de forma segura. Cada reporte de seguridad ignorado que resulta ser real es un desastre. Así que haces triage de todos. Es básicamente una alerta DEFCON 1 en tu servidor de Minecraft: el riesgo es cero, pero la respuesta sigue siendo obligatoria. (Lo sé. Profundamente injusto.)

Stenberg describió la experiencia como "terror reporting". La palabra es exacta. No porque los reportes sean peligrosos. Porque cada uno demanda atención inmediata que resulta ser completamente desperdiciada.

1 Maintainer. 18 Meses. $150 por Reporte.

TITLE "The curl Bug Bounty Collapse" + subtitle "18 months from signal to noise". Metaphor: engineer blueprint timeline left to right with annotated inflection points at key dates. Style: technical blueprint on dark navy background, white annotation lines, measurement brackets, hand-drawn grid, technical marker feel. Palette: navy #0A1628, cyan #00D4FF, white #FFFFFF, amber #FFB347, charcoal #2A3548. Content: Left zone (2024) "1 report/week, 1 in 6 real". Center zone (Late 2025) "1 in 30 real, volume x5". Right zone (Jan 2026) "7 in 16 hours, 20 in 21 days, 0 real". Far right (Jun 2026) "1 every 18h, duplicates". Each zone annotated "$150 triage cost per report". Highlight: Jan 2026 zone stamped diagonal "PROGRAM CLOSED" in amber with border. Footer: copyright rentierdigital.xyz. NOT flat corporate vector, NOT minimalist tech startup aesthetic, NOT stock infographic.
Timeline del declive del programa de bug bounty de curl

Antes de 2025, Stenberg recibía aproximadamente 1 reporte de seguridad por semana. Cerca de 1 de cada 6 era real. Tenía un proceso de triage documentado, un equipo de 7 voluntarios, y el tipo de reputación que atraía investigadores serios.

Luego las proporciones cambiaron.

Finales de 2025: 1 de cada 20 a 30 reportes era real. El volumen se había multiplicado por 5. Enero de 2026: 7 envíos en 16 horas. 20 en 21 días, ninguno identificando una vulnerabilidad real. Stenberg cerró el programa de HackerOne y actualizó el security.txt de curl para hacer las consecuencias de envíos de mala fe explícitas y públicas.

Estimó el costo: $150 por reporte en tiempo de triage de voluntarios. En 20 reportes en 21 días, eso son $3,000 en horas de voluntarios con 0 valor de seguridad devuelto.

He estado siguiendo las charlas de Stenberg en FOSDEM durante algunos años. curl siempre se leyó como el ideal platónico de sostenibilidad de código abierto: un solo maintainer, décadas de compromiso, un proyecto corriendo en miles de millones de dispositivos. El capítulo de slopageddon se siente como un plot twist especialmente cruel para alguien que construyó la plomería de internet a mano.

1 salvedad que vale la pena mantener, porque Stenberg la mantiene: alguna investigación asistida por AI es legítima. Joshua Rogers encontró alrededor de 50 vulnerabilidades reales en curl usando ZeroPath, combinando la herramienta con su propia experiencia para filtrar señal del ruido. Stenberg lo describió como "una persona inteligente usando una herramienta poderosa". En 6 años de rastrear envíos de seguridad generados por AI, 0 vulnerabilidades fueron encontradas por AI solo, sin un humano en el loop.

Stenberg reabrió el bounty en marzo de 2026. No porque la inundación se detuviera, sino porque la calidad había mejorado lo suficiente como para que algunos reportes fueran ahora técnicamente coherentes, solo masivamente duplicados. Múltiples investigadores independientemente apuntaron el mismo scanner al mismo repo, obtuvieron el mismo output, y enviaron el mismo no-hallazgo. "Era literalmente como 2 personas encontrando agujas en el mismo pajar", dijo. "Y eso nunca había pasado." A junio de 2026: 1 reporte cada 18 horas.

Lo Que Le Pasó a curl Está Pasando en Todas Partes

2 poblaciones distintas están generando este ruido, y tienen incentivos diferentes. Entender la diferencia importa porque la solución para una no aborda la otra.

Los cazadores de bounty son la multitud de scanners automatizados. Apuntan a proyectos con recompensas monetarias activas. curl era un objetivo principal específicamente por el bounty de HackerOne. Remueve el incentivo financiero y en gran medida desapareces de su cola. Jazzband, un colectivo de Python, se cerró completamente después de ser abrumado por este grupo. El builder solitario sin un bounty monetario tiene 1 ventaja estructural: los cazadores de bounty en su mayoría se van.

Los que rellenan currículum no les importa el bounty. Un perfil de GitHub mostrando 50 contribuciones, PRs enviados e issues abiertos, incluso todos rechazados, se lee mejor para un reclutador que un perfil en blanco. AI bajó el costo de generar un PR que se ve plausible a aproximadamente 0. Así que esta población apunta a cualquier proyecto con issues abiertos y visibilidad indexable. 200 estrellas o 2 millones, la diferencia en atractivo es menor de lo que la mayoría de builders asume.

Escribí sobre el costo de volverse closed-source en 2026 cuando Cal.com tomó esa decisión. Este artículo es el otro lado: mantenerse abierto no es mantenerse pasivo.

Remi Verschelde, que mantiene Godot, describió el trabajo de triage como "agotador y desmoralizante". Mitchell Hashimoto, que construyó Vagrant y Terraform y ahora mantiene Ghostty, escribió en enero: "Es una puta zona de guerra aquí, hombre. La moral de los maintainers en su punto más bajo". Prohibió las contribuciones de AI no atribuidas directamente. tldraw auto-cierra todos los PRs externos. GitHub está construyendo activamente controles de moderación de emergencia para pull requests. Cuando una plataforma envía controles de emergencia, es una señal, no una queja de nicho.

1 de cada 10 PRs generados por AI cumple el estándar de calidad requerido para abrirlo, según una discusión de la comunidad de GitHub de junio de 2026. Los otros 9 aterrizan en la cola de triage de alguien.

Kate Holterhoff lo nombró "AI Slopageddon" a principios de 2025. El portmanteau se extendió inmediatamente. Cuando una etiqueta se adopta tan rápido, la experiencia subyacente ya era generalizada y solo necesitaba un nombre.

Enviaste un Side Project. Te Acabas de Convertir en Maintainer

Aquí está la parte que no viene con ninguna documentación.

Cuando pusheaste tu proyecto, activaste issues (la configuración por defecto, la mayoría de gente la deja así), y empezaste a acumular estrellas, también acordaste algo sin doc de onboarding: maintainership. Con eso viene una responsabilidad que nadie asigna formalmente, una que aún consume tu tiempo real: hacer triage de lo que sea que aterrice en la pestaña de issues.

Stenberg tuvo 6 años para construir su infraestructura de moderación. Tenía 7 triagers voluntarios, una política de triage documentada con consecuencias declaradas para envíos de mala fe, una reputación pública que funciona como disuasivo, y un archivo security.txt que explícitamente advierte a los malos actores sobre lo que les pasa. Construyó todo esto deliberadamente, durante años, en respuesta a un volumen pre-AI de ruido que ya era significativo y creciente. Y esto es para curl, un proyecto corriendo en miles de millones de dispositivos mundialmente. La escala del objetivo, el tamaño de la infraestructura, y los años de construcción deliberada son proporcionales entre sí de una manera que no se transfiere a un side project pusheado un jueves por la tarde.

Tienes un README.

La brecha entre esas 2 situaciones vale la pena nombrarla sin catastrofizar. Enviar rápido con AI hace que una demo funcione, un prototipo trabaje, algo que gane estrellas de GitHub. Ese es el primer loop que Vibe Coding, For Real cubre para builders que han golpeado la pared demo-a-producción. Pero enviar rápido no envía la capa de moderación. La capa de moderación es el DLC que no vino incluido, y se vuelve obligatorio una vez que el proyecto es visible.

Creo que el umbral de visibilidad importa más que el conteo de estrellas, en realidad. Un proyecto con 150 estrellas e issues abiertos es indexable por los mismos scanners automatizados que uno con 15,000. Tal vez estoy equivocado, pero la implicación práctica parece la misma de cualquier manera: una vez que eres encontrable, eres un objetivo potencial.

La superficie de ataque de supply chain y la superficie de ataque de AI slop comparten la misma lógica: ambas son pasivas, ambas crecen con visibilidad, y el costo aterriza completamente en ti. Me topé con la primera directamente y la documenté en mi análisis de supply chain de LiteLLM. Ambos ataques no necesitan una vulnerabilidad en tu código. Necesitan que no tengas una política.

El costo de contribución acaba de llegar a cero. El costo de moderación no.

5 Cosas Que Hacer Antes de Que los Bots Te Encuentren

Ninguna de estas es complicada. Todas son más fáciles de configurar antes de que empiece el ruido que después.

1. No ejecutes un bug bounty monetario a menos que puedas realmente defenderlo

Un bounty monetario es la señal de targeting primaria para la población de cazadores de bounty. HackerOne, Bugcrowd, cualquier programa de recompensa estructurado: tener uno es aproximadamente equivalente a postear "se acepta pago por reporte" en el directorio de código abierto. Sin uno, los scanners automatizados en su mayoría priorizan otros objetivos. Esto no es un argumento contra los bug bounties como concepto. Es un argumento contra agregar uno como checkbox de "se ve serio" sin la infraestructura de triage para soportarlo. Stenberg tuvo 6 años de infraestructura antes de que llegara la inundación. Ejecutar un bounty sin esa infraestructura es pagar para ser objetivo.

2. Escribe un CONTRIBUTING.md con una regla explícita de AI y consecuencias declaradas

La regla necesita decir qué pasa, no solo qué se espera. Algo como: "Issues o PRs generados por AI enviados sin pasos de reproducción verificados serán cerrados inmediatamente. Violaciones repetidas resultarán en un bloqueo." Las consecuencias necesitan estar ahí porque la regla existe no para persuadir, existe para hacer los cierres públicamente defendibles. Cuando cierras un envío y alguien empuja de vuelta, apuntas a la regla. Sin ella, cada cierre se convierte en una decisión de juicio que tienes que relitigar desde cero.

3. Agrega un template de issue con un campo obligatorio de verificación humana

Esta es la capa técnica para lo que el CONTRIBUTING.md cubre en política. Un campo requerido que dice "Pasos que personalmente reprodujiste en tu máquina, en secuencia:" crea fricción que los envíos automatizados generalmente no pueden llenar coherentemente. El template crea un rastro de papel que hace los envíos de mala fe más fáciles de identificar y cerrar limpiamente.

4. Despliega un stale bot a 14 días

Cualquier issue sin actividad por 14 días se auto-cierra con un mensaje estándar. Piénsalo como el git gc del manejo de issues: corre silenciosamente y reclama espacio que no te diste cuenta que habías asignado. El backlog pasivo que se acumula incluso con triage activo desaparece sin intervención manual. Sin un stale bot, la pestaña de issues se llena con reportes no resueltos que crean overhead cognitivo cada vez que miras el repo.

5. Deshabilita issues completamente si no estás en modo de mantenimiento activo

Esta opción se salta porque los issues abiertos se sienten como una señal de madurez. Pero un proyecto donde los issues han estado abiertos y sin triage por 6 meses envía una peor señal que un proyecto actualmente en pausa. Y desde un punto de vista de targeting, issues deshabilitados significa no indexable por los scanners automatizados buscando objetivos de contribución. Si estás entre ciclos de features, si enviaste algo y seguiste adelante, apagar la pestaña de issues es una elección válida. El repo se mantiene público, forkeable, útil. Solo se queda silencioso.

La Misma Herramienta. 2 Direcciones

La misma herramienta de AI genera los reportes de seguridad para cazadores de bounty y los PRs para los que rellenan currículum. Misma capacidad subyacente, incentivo diferente, defensa diferente.

Los cazadores de bounty en su mayoría se auto-seleccionan cuando no hay recompensa financiera. El builder solitario sin un bounty monetario es, estructuralmente, un objetivo menos atractivo para esa población. Esa es aproximadamente la única noticia estructuralmente buena aquí.

Los que rellenan currículum no responden a la ausencia de un bounty. El costo de esfuerzo es 0. El beneficio a su perfil es real. El costo aterriza completamente en el maintainer. Los PRs generados por AI para rellenar currículum "se ven bien. Los tests pasan. El código podría incluso funcionar", como lo puso Continue Blog en enero de 2026. "El problema es que no hay nadie en casa." Esa es la población que las medidas de arriba están diseñadas para filtrar, porque no hay incentivo estructural que los detenga de la manera que remover un bounty detiene a los cazadores.

AI comprimió el tiempo de build. No comprimió el tiempo de mantenimiento. La fricción que filtraba malas contribuciones, el esfuerzo de entender una codebase, reproducir un bug, escribir algo coherente, desapareció del lado del envío. No del lado del triage. Stenberg gastó 6 años construyendo su defensa con 7 triagers voluntarios.

Aún recibe 1 reporte cada 18 horas. C'est la vie 🤷‍♂️

Fuentes

Este post puede contener enlaces de afiliados. Si los clickeas, podría ganar una pequeña comisión (no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura.)