Solo con fines educativos; no constituye asesoramiento legal, fiscal ni de seguridad. La publicación de un programa, una cláusula de salvaguarda, una calificación de gravedad o una recompensa estimada no garantiza autorización, inmunidad, pago ni seguridad del protocolo.
Respuesta directa
Un bug bounty de cripto es un proceso versionado mediante el cual un proyecto invita a comunicar en privado determinadas vulnerabilidades y puede recompensar los informes que cumplen sus reglas vigentes. No equivale a una política de divulgación de vulnerabilidades: esta puede ofrecer un canal de comunicación y condiciones de autorización sin prometer pago. Ninguno de los dos certifica la seguridad, proporciona un seguro ni crea una relación laboral.
El objeto vinculante es una copia fechada del programa, no el nombre del proyecto ni la página web actual. Registre la URL, revisión y hora; las redes, contratos, implementaciones de proxy, repositorios, commits y versiones exactas; los impactos elegibles; los sistemas y métodos excluidos; la tabla y el límite de recompensas; las reglas de envío y divulgación; la cláusula de salvaguarda; y las condiciones de identidad, sanciones, fiscalidad y pago. El alcance es la intersección entre activo, versión, red, impacto y método de prueba permitido.
Una cláusula de salvaguarda expresa cómo pretende actuar una organización ante una investigación de buena fe que respete sus reglas. No amplía el alcance, no vincula a terceros ni a las autoridades, no anula otras jurisdicciones ni excusa invasiones de privacidad, interrupciones, extorsión o movimientos no autorizados de fondos. Si la autorización no está clara, consulte por el canal oficial antes de probar.
Mantenga cuatro registros separados: autorización y pruebas; explotabilidad técnica e impacto económico; mitigación, remediación y divulgación; y recompensa, cumplimiento y pago. Una etiqueta critical no determina por sí sola la recompensa, una decisión de concesión no es un recibo de pago y que un parche supere una prueba unitaria no demuestra que el despliegue afectado sea seguro.
Cómo funciona
Las pruebas deben respetar las reglas congeladas. Una prueba de concepto mínima suele avanzar desde análisis estático y pruebas unitarias o de propiedades hasta un fork local u otro entorno expresamente autorizado. Pueden estar prohibidas las pruebas en mainnet o testnet pública, de denegación de servicio, ingeniería social, terceros o datos personales. No transfiera ni retenga activos reales de usuarios para demostrar el impacto ni suponga que un rescate durante un ataque activo queda autorizado por un bug bounty ordinario.
Un informe útil fija la red, dirección, implementación, commit, bloque de estado y copia del programa afectados. Expone prerrequisitos, pasos exactos de reproducción, comportamiento esperado y real, secuencia de transacciones o calldata, hashes de artefactos, recorrido técnico, límite realista de impacto, capital y privilegios del atacante, supuestos y un contacto seguro. Cifre el material utilizable como arma y los datos sensibles, minimice su recopilación, registre el acceso y conserve una cronología.
El triaje debe separar alcance, estado de duplicado o problema conocido, explotabilidad técnica, impacto económico, gravedad y elegibilidad de la recompensa. Una clase técnica no determina una pérdida ejecutable. Capital, permisos, competencia, liquidez, ventanas de oráculo, límites de tasa, pausas, riesgo de reorganización, repetibilidad e interacción del usuario pueden cambiar el resultado. El primer mensaje no es necesariamente el primer informe completo elegible; mandan la regla de duplicados archivada y la prueba de conocimiento previo.
Acuse de recibo, reproducción, decisión de gravedad, mitigación de emergencia, remediación final, divulgación, aprobación de recompensa y pago son estados y relojes diferentes. Objetivos como 24 hours o 72 hours solo tienen sentido si el programa o plan de incidentes los define. El silencio perjudica la operación, pero las palabras bug bounty no implican ningún plazo universal.
Una medida de emergencia puede pausar una función, reducir un límite, retirar una ruta del frontend o cambiar la supervisión, pero no es la solución definitiva. Una actualización debe verificar autorización, timelock o poderes de emergencia, implementación e inicializador, distribución del almacenamiento, migración y reversión. Convierta la prueba original en una prueba de regresión, examine rutas e invariantes adyacentes, simule el estado desplegado, verifique recibos de ejecución y supervise las versiones reales en cada red afectada.
La divulgación requiere canal privado, inicio del embargo, cadencia de actualizaciones, reglas de prórroga y publicación de emergencia, reconocimiento o anonimato del investigador y condiciones de conservación o eliminación de pruebas. El pago exige su propia conciliación: recompensa nominal, fórmula o discreción, moneda y referencia de cambio, controles KYC o de sanciones, formularios fiscales o retención, red y dirección de destino, comisiones, estado de aprobación, identificador de transacción e importe recibido.
Siga este proceso:
- Archive el programa: URL, revisión y hora, activos, redes, direcciones, implementaciones, commits, impactos elegibles, exclusiones, condiciones de recompensa, salvaguarda y política de divulgación.
- Obtenga autorización escrita para actor, sistema, entorno, método, tasa, tratamiento de datos y límite con terceros; deténgase y pregunte ante cualquier duda.
- Construya la prueba no dañina más pequeña en el entorno expresamente permitido; fije código y estado, cuantifique prerrequisitos e impacto y deténgase cuando haya pruebas suficientes.
- Envíe por el canal seguro autorizado el ID, horas, artefactos cifrados, hashes, pasos de reproducción, registro de impacto, supuestos e historial de contactos.
- Determine alcance y estado de duplicado o conocido; después evalúe por separado explotabilidad, impacto económico, gravedad y elegibilidad según las reglas archivadas.
- Registre como estados distintos mitigación, parche o migración, revisión de actualización y almacenamiento, pruebas de regresión e invariantes, recibos de despliegue, supervisión y divulgación coordinada.
- Concilie recompensa aprobada, moneda y tipo de cambio, KYC, sanciones, impuestos, red, dirección, comisiones y recibo; conserve un registro auditable sin datos sensibles innecesarios.
Ejemplos
- El alcance es más estrecho que la coincidencia de nombres. Un programa archivado enumera
12 assets. Un informe menciona9; solo7coinciden con la red y versión desplegada, mientras que uno es un oráculo tercero y otro un commit no publicado. La coincidencia nominal es9 / 12 = 75%, pero la cobertura autorizada es7 / 12 = 58.33333333%. La copia del programa, no el porcentaje, decide la elegibilidad. - Impacto, gravedad y recompensa candidata son distintos. El valor directo reproducible en riesgo es
$8,000,000. Una regla hipotética archivada paga10%, con un mínimo de$50,000y un máximo de$500,000. El cálculo bruto es$8,000,000 * 0.10 = $800,000; tras el límite, la candidata es$500,000. Exigir un firmante privilegiado podría cambiar el nivel; el cálculo no constituye derecho ni fórmula universal. - Cada reloj de respuesta mide un estado diferente. Envío
2026-08-13 09:00; acuse a las11:30, tras2.5 hours; triaje a2026-08-14 16:00, tras31 hours; límite temporal a21:00, tras36 hours; parche a2026-08-16 21:00, tras84 hours; divulgación a2026-08-23 09:00, tras240 hours, o10 days. Un acuse rápido no implica remediación ni pago rápidos. - La recompensa nominal y la liquidación son distintas. Una recompensa aprobada de
$500,000se paga en USDC a un cambio fijo de$1.002 per USDC; corresponden$500,000 / $1.002 = 499,001.996008 USDC. Si el proyecto paga aparte una comisión de red de$18, el investigador recibe499,001.996008 USDC; si la descuenta, el valor recibido es$499,982al cambio fijado. Impuestos y retenciones son registros separados.
Riesgos
- La página cambia y no existe copia fechada.
- El activo, versión, red, dirección o implementación probados quedan fuera del alcance.
- Una actualización del proxy cambia el código durante la investigación o remediación.
- La cláusula de salvaguarda se confunde con inmunidad legal universal.
- La prueba alcanza a un proveedor, oráculo, cuenta de usuario u otro tercero excluido.
- La actividad en mainnet o testnet pública incumple las reglas del entorno.
- La prueba mueve fondos reales, interrumpe el servicio o accede a datos personales.
- La automatización supera límites de carga o se convierte en denegación de servicio.
- Ingeniería social, phishing, coacción o extorsión exceden la autorización.
- La prueba recopila o revela más material utilizable como arma del necesario.
- Un canal inseguro filtra secretos, datos de usuarios o detalles del exploit.
- Hashes, horas, versiones de código o estado de red no pueden reproducirse.
- Faltan pruebas de duplicado, conocimiento previo o primer informante elegible.
- El nombre de la vulnerabilidad sesga la gravedad sin probar requisitos y alcance.
- El valor teórico en riesgo se confunde con pérdida realizable o beneficio del atacante.
- Se interpretan mal mínimo, máximo, discreción, moneda o elegibilidad de la recompensa.
- KYC, sanciones, impuestos, factura o red de pago retrasan o impiden la liquidación.
- Silencio, relojes ambiguos o divulgación prematura elevan el riesgo de explotación.
- Pausa, límite, actualización, cambio de almacenamiento o migración causan nuevo daño.
- Un bounty, auditoría, prueba formal o sistema de supervisión se trata como garantía.
Errores comunes
- «Un programa público autoriza probar cualquier activo y método relacionados». La autorización está limitada por activo, versión, impacto, entorno y conducta archivados.
- «La salvaguarda garantiza inmunidad en toda jurisdicción». Es una política condicional y no vincula a todos los terceros ni autoridades.
- «Una etiqueta crítica o porcentaje de impacto fija automáticamente el pago». Gravedad, elegibilidad, reglas, límites, discreción y liquidación son distintos.
- «El primer mensaje siempre gana un duplicado y mover fondos demuestra el impacto». Puede exigirse el primer informe completo elegible; causar daño no autorizado puede descalificarlo y generar responsabilidad.
- «Un bounty y una auditoría prueban que no quedan errores cuando el parche supera las pruebas». Auditorías, métodos formales, pruebas, bounties, supervisión y respuesta cubren versiones, supuestos y fallos diferentes.
Temas relacionados
Fuentes
- Immunefi Rules - Immunefi (consultado: 2026-08-13)
- Immunefi Vulnerability Severity Classification System v2.3 - Immunefi (consultado: 2026-08-13)
- Binding Operational Directive 20-01 - Cybersecurity and Infrastructure Security Agency (consultado: 2026-08-13)
- Department of Justice Announces New Policy for Charging Cases under the Computer Fraud and Abuse Act - U.S. Department of Justice (consultado: 2026-08-13)
- Safe Harbor Overview & FAQ - HackerOne (consultado: 2026-08-13)
- Bug Bounty Program - ethereum.org (consultado: 2026-08-13)
- Writing Upgradeable Contracts - OpenZeppelin Docs (consultado: 2026-08-13)
- Secure Software Development Framework (SSDF) Version 1.1 - National Institute of Standards and Technology (consultado: 2026-08-13)