Disputas por el pago de recompensas: SLA y equidad en tu VDP

Las disputas por el pago de recompensas (bug bounty) surgen cuando un programa niega, reduce o retrasa una recompensa sin anclar la decisión a una regla que el investigador pudiera leer de antemano. Los detonantes más habituales son una corrección lenta sin reloj de resolución, una declaración de “fuera de alcance” emitida después de publicar el parche, un pago por debajo de la matriz anunciada y cambios retroactivos en los términos del programa. La solución no es pagar más. Es publicar el reloj y la matriz desde el principio, medir el tiempo de corrección contra ellos y registrar cada decisión de aprobar, reducir o rechazar en un libro mayor auditable.

En junio de 2026, AMD convirtió a un investigador colaborador en un crítico público al equivocarse en los cuatro frentes a la vez. Esta es la guía para no repetirlo.

124 días y luego “fuera de alcance”: la pelea por la recompensa de AMD

En febrero de 2026, el investigador Paul LaRosa (alias “MrBruh”) reportó un fallo crítico en las herramientas de actualización automática de AMD. El actualizador descargaba su lista de actualizaciones por HTTPS, pero obtenía los ejecutables reales por HTTP plano y sin una verificación de firma de verdad. Un atacante en la misma red podía ejecutar un ataque de tipo man-in-the-middle y enviar código malicioso a la máquina de la víctima.

AMD tardó 124 días en publicar la corrección. Después negó la recompensa de 10.000 dólares, alegando que los ataques man-in-the-middle contra “herramientas opcionales” quedaban fuera de alcance. Y eso a pesar de que AMD asignó un CVE (CVE-2026-40677, CVSS 4.0 con puntuación base 7,7, ALTA) y reconoció públicamente a LaRosa en su propio boletín de seguridad. El parche final solo añadió una verificación CRC32, que es una suma de comprobación de integridad, no una firma criptográfica. Varios medios también informaron de que AMD modificó los términos de su programa para exigir consentimiento por escrito antes de la divulgación, y luego aplicó ese cambio al caso de LaRosa a posteriori.

El fallo no era la historia. La historia es que un reloj lento, sumado a una decisión de pago opaca y tomada después de los hechos, transformó a un investigador que reportó discretamente un fallo real en alguien con un altavoz y una queja. Cada parte de ese desenlace fue una decisión de proceso, y cada parte se podía evitar.

Una aclaración sobre lo que este artículo no afirma: AMD no estaba legalmente obligada a pagar, y nadie puede forzar la inclusión de un informe en el alcance. La afirmación honesta y más acotada es que falló el proceso. Un reloj silencioso, una decisión de alcance sin documentar y una decisión sin registrar son lo que convirtió una recompensa negada en un incidente de reputación.

Por qué se producen las disputas por el pago de recompensas

Las disputas por el pago de recompensas rara vez giran solo en torno a la cifra. Nacen de la brecha entre lo que un programa anunció y lo que de verdad hizo. Los investigadores toleran un techo bajo; lo que no toleran es que muevan la portería. Cinco enemigos de la confianza causan la mayoría de las disputas:

• Sin reloj de resolución. La corrección se alarga durante meses porque nada cuenta hacia atrás. El investigador queda en silencio y asume mala fe.
• “Fuera de alcance”, decidido tras publicar la corrección. La elegibilidad se dictamina de forma retroactiva, una vez que la empresa ya tiene el parche en la mano.
• Pagar por debajo de la matriz anunciada. Un programa que promete “más de 1.000 dólares por nivel Medio” paga 200 sin explicación, así que la injusticia que se siente es la brecha, no la cifra.
• Cambios de reglas retroactivos. Los términos cambian a mitad del informe y los nuevos términos se aplican hacia atrás a un informe presentado bajo los antiguos.
• Decisiones opacas y sin registrar. Nadie puede reconstruir quién decidió qué, cuándo ni contra qué regla.

Los veteranos de la seguridad llevan años advirtiéndolo. Como han sostenido voces críticas como Katie Moussouris, Jonathan Leitschuh, Robert Graham y Tavis Ormandy en la cobertura sobre la industria del bug bounty, los acuerdos de confidencialidad (NDA) y la compra del silencio erosionan el modelo de divulgación; la transparencia es lo que hace eficaz a un programa. El patrón en todas las disputas es el mismo: la decisión no estaba anclada a nada que el investigador hubiera podido leer de antemano.

Sin reloj de resolución, la corrección simplemente se va a la deriva

Una vulnerabilidad sin fecha límite de remediación es una vulnerabilidad que nadie asume como propia. La mayoría de las organizaciones tardan entre 60 y 150 días en parchear vulnerabilidades críticas, según la investigación sobre SLA de remediación de Secure.com. Mientras tanto, los atacantes explotan fallos críticos en apenas 5 días tras la divulgación pública, y alrededor del 60 % de las brechas de 2024 estaban ligadas a una vulnerabilidad conocida y sin parchear. Los 124 días de AMD caían de lleno en la zona de peligro y, como no se había publicado ningún reloj, nadie respondía por ello.

“Fuera de alcance”, decidido tras publicar la corrección

El alcance es una promesa que haces antes de que llegue el informe, no un veredicto al que llegas cuando ya tienes el parche. Cuando un programa acepta un informe, asigna un CVE, reconoce al investigador y luego declara ese mismo problema fuera de alcance, la decisión de alcance se lee como una maniobra para evitar el pago, porque funcionalmente eso es lo que es. Decide la elegibilidad contra un documento de alcance publicado de antemano, o no invoques el alcance en absoluto.

Pagar por debajo de la matriz anunciada

Otra disputa distinta y muy comentada involucró a un investigador al que se le ofrecieron 50.000 dólares por un fallo crítico, frente al máximo declarado de 500.000 dólares del programa, sin una explicación detallada de la reducción y con un largo retraso en el pago. Puede que la cifra fuera defendible. El silencio no lo era. Una reducción sin un motivo documentado frente a una matriz pública siempre parece un menosprecio, aunque no lo sea.

Cambios de reglas retroactivos

Cambiar los términos de tu programa está bien. Aplicar los nuevos términos a informes presentados bajo los antiguos no lo está. Una vez que aceptas un envío, las reglas vigentes en el momento del envío son las que lo rigen. Todo lo demás es un señuelo y la comunidad de investigadores lo trata como tal.

¿Qué tan rápido es “suficientemente rápido”? SLA de resolución por severidad

Un SLA de resolución es un plazo publicado, por nivel de severidad, para entregar una corrección, medido desde el momento en que confirmas el informe. Es lo que hace que “124 días” sea objetivamente indefendible, en lugar de una cuestión de opinión. Los objetivos del sector más citados son ajustados:

Fuentes: guía de SLA de remediación de Secure.com; manual de gestión de vulnerabilidades de GitLab.

Frente a cualquiera de estos puntos de referencia, una corrección de 124 días para un problema crítico de clase RCE multiplica el objetivo varias veces. Los límites exactos de cada nivel los defines tú. Lo que importa es que los definas, los publiques de peor a menos grave en tu página de política y pongas un reloj en cada informe confirmado, para que “vencido” sea un estado que el sistema muestra, no una queja que el investigador tiene que presentar.

Cuánto debería pagar realmente una recompensa

Una matriz de recompensas es una tabla publicada con los rangos de recompensa por nivel de severidad, anclada a datos reales de mercado para que los pagos se calculen, no se negocien a la baja. Los puntos de referencia públicos te dan los anclajes:

Fuentes: bug-bounties.as93.net (medianas de HackerOne); guía de pagos de Bugcrowd.

Son rangos, no dogma. El Vulnerability Reward Program de Google paga mucho más, con hallazgos críticos que se sitúan entre 10.000 y 31.337 dólares, y, a nivel de toda la plataforma, HackerOne pagó a los investigadores alrededor de 81 millones de dólares en un período reciente de 12 meses. Presenta tu matriz como rangos, atribuye la plataforma que usaste como referencia y resiste la tentación de citar una única “recompensa media” canónica. El objetivo de la matriz no es ser generoso. Es que un investigador pueda estimar su recompensa antes de pulsar enviar, y que tu pago final caiga dentro de una banda que ya había visto.

Cómo rechazar un informe sin perder al investigador

Vas a rechazar informes. Fuera de alcance, duplicado, informativo, riesgo aceptado: todos son legítimos. Un rechazo solo se convierte en disputa cuando es una sorpresa. Cuatro prácticas evitan que un “no” se convierta en una pelea pública:

1. Decide contra una regla publicada de antemano. Señala por su nombre el documento de alcance o el nivel de la matriz en el que se apoya la decisión. Si la regla no existía cuando se presentó el informe, no puedes usarla.
2. Muestra los datos. Cuando reduzcas un pago, muestra la banda de referencia de la que salió la cifra. Un motivo documentado vale más que una cifra generosa pagada en silencio.
3. Mantén intacto el reconocimiento. Un pago rechazado no tiene por qué significar crédito borrado. Un lugar en el salón de la fama y los puntos de reputación no cuestan nada y preservan la buena voluntad incluso cuando el dinero está en disputa.
4. Ofrece una apelación. Un “no” unidireccional se lee como un dictamen inapelable. Una decisión revisable se lee como justa, aunque la respuesta no cambie.

Si todavía no has montado la parte de recepción de todo esto, empieza por nuestra guía sobre cómo configurar un programa de divulgación de vulnerabilidades. Y si lo que te preocupa es la relación más que el dinero, el artículo complementario sobre cuándo los investigadores se hacen públicos tras una divulgación mal gestionada aborda en profundidad la mecánica de la confianza. Este artículo es la secuela del día 2: cómo no perder a un investigador cuando el dinero y un plazo están ambos en juego. (Para el problema del volumen creciente, consulta la basura generada por IA que inunda el triaje de bug bounty.)

Cómo Kit pone en práctica los SLA de resolución y la equidad en los pagos

El vertical CSIRT de Kit se construyó casi como una respuesta punto por punto al fracaso de AMD: publica el reloj y la matriz, mide el tiempo de corrección contra ellos y registra cada decisión de pago para que sea defendible en lugar de negable. Así es como cada paso en falso de AMD se corresponde con una función integrada.

La tesis es acotada y se sostiene: AMD no perdió al investigador porque el fallo fuera difícil. Lo perdió porque no había ningún reloj corriendo y la decisión de pago se tomó a oscuras, a posteriori, contra una regla que no existía cuando él reportó. Un SLA de resolución que publicas y mides, sumado a una matriz de recompensas anclada a tus propios datos de pago y registrada en un libro mayor, convierten un “fuera de alcance, sin pago” de una traición en una decisión predecible y defendible. Que pagues o no un informe concreto sigue siendo tu decisión. Kit hace que esa decisión sea rápida, anclada a datos y auditable.

La conclusión: publica el reloj y la matriz antes de decir que no

Toda disputa por el pago de una recompensa se remonta a la misma causa raíz: una decisión tomada contra una regla que el investigador nunca llegó a ver. Publica tus SLA de resolución por nivel de severidad. Ancla tu matriz de recompensas a datos de referencia reales y publícala también. Pon un reloj en cada informe confirmado para que “vencido” sea un estado del sistema, no una queja del investigador. Registra cada aprobación, reducción y rechazo en un libro mayor que puedas auditar. Hazlo, y un rechazo se convierte en algo que el investigador esperaba, puede verificar y por lo que seguirá reportando, en lugar de aquello que te lleva a la portada de Tom’s Hardware.

Si gestionas un VDP o un programa de recompensas pagadas y la parte del dinero y el reloj todavía vive en hojas de cálculo y buena voluntad, esa es exactamente la brecha que cierra el módulo CSIRT de Kit. Empieza una prueba gratuita y define tus SLA y tu matriz de recompensas antes de que llegue el próximo informe crítico.