Verificar a un investigador de bug bounty es un dial, no un interruptor. Ajustas cuánto compruebas sobre un investigador a la sensibilidad de aquello que puede tocar, con cuatro niveles: **admisión solo con registro** (cualquiera puede informar, sin identidad obligatoria), **pagos con identidad verificada** (informes con seudónimo, pero identidad más comprobaciones fiscales y de sanciones antes de mover dinero), **acceso privado por confianza** (invitaciones ganadas por reputación más verificación de identidad obligatoria) y **con verificación de antecedentes o por contrato** (cribado penal y evaluadores nombrados y contratados para el alcance más crítico). El error que cometen los fundadores es aceptar el valor por defecto de un marketplace en lugar de elegir la muesca que su modelo de amenazas realmente necesita. Estás a punto de invitar a desconocidos a hurgar en producción. La pregunta que subyace a todo programa de divulgación de vulnerabilidades (VDP) es simple e incómoda: ¿a quién exactamente estoy dejando entrar y cuánto necesito saber sobre esa persona antes? Esta es la respuesta, nivel a nivel. ## Qué significa realmente «verificar a un investigador» Verificar no es una sola cosa. Son tres controles distintos y apilables que los fundadores confunden constantemente, y las grandes plataformas activan cada uno por separado. - **Verificación de identidad (IDV / KYC).** Confirmar que detrás del alias hay una persona real y verificable por las autoridades, normalmente un documento de identidad con foto más un selfie de prueba de vida. - **KYC de pago e impuestos.** El formulario fiscal, el método de pago y el cribado de sanciones que necesitas legalmente antes de poder enviarle dinero a alguien. - **Verificación de antecedentes penales.** Un cribado formal de registros, normalmente con un histórico de varios años. La mayoría de los programas públicos usan solo el control intermedio. Puedes dejar que alguien informe de un fallo con seudónimo y exigir la documentación de identidad y fiscal solo cuando toca pagar. Esa separación, la participación por un lado y el dinero por otro, es el eje sobre el que gira todo el modelo de confianza. Una vez que ves la verificación como tres diales en lugar de un interruptor, la clasificación por niveles sale de forma natural. ## ¿Con qué ligereza verifican de verdad HackerOne y Bugcrowd? Los marketplaces principales verifican de forma deliberadamente ligera por defecto, porque toda su propuesta es la escala. La comunidad registrada de HackerOne supera con creces el millón de cuentas, en su mayoría seudónimas, y el argumento económico del bug bounty abierto es tener muchos ojos con poca fricción. En HackerOne, los investigadores pueden participar **con seudónimo**. Solo hace falta una identidad legal para cobrar: la verificación de identidad se hace a través de Veriff, tiene una validez de 12 meses y solo queda disponible después de que un investigador envíe al menos un informe válido. Para recibir una recompensa de verdad, un investigador también necesita un formulario fiscal aprobado y un método de pago. Las verificaciones de antecedentes penales son **opcionales** y solo condicionan el nivel mejorado **HackerOne Clear**, gestionado por Checkr con un histórico de 7 años, repetido cada dos años y reservado para investigadores que superan umbrales de conducta y reputación (incluidos 15 000 USD en recompensas acumuladas). Alrededor de 20 países prohíben la comprobación por completo. Bugcrowd ha subido una muesca de rigor. Ahora **exige** verificación de identidad, un selfie en vivo más un documento oficial, antes de que un investigador pueda enviar informes a un programa Managed Bug Bounty, sea público o privado. Las verificaciones de antecedentes, sin embargo, siguen siendo un complemento solo por invitación para un grupo pequeño y de máxima confianza. Así que los dos marketplaces no son idénticos: HackerOne prioriza el seudónimo con KYC condicionado al pago, mientras que Bugcrowd condiciona la propia participación a la IDV. Ambos superponen luego un **recorrido de confianza**. Los investigadores de Bugcrowd desbloquean compromisos públicos, después privados y después restringidos a medida que crece su reputación. HackerOne construye hacia la misma idea a través de su programa Pentester, donde los evaluadores deben estar verificados por Clear, contar con más de 3 años de experiencia y las mejores certificaciones, superar un cribado penal y cumplir un periodo de prueba en sus tres primeros pentests. Incluso las plataformas «ligeras» construyen una escalera hacia el trabajo de alta garantía. ## El extremo pesado: el red team cerrado y contratado de Synack Synack se sitúa en el polo opuesto y verifica a fondo, por adelantado, antes de que nadie toque a un cliente. Opera su propio **Synack Red Team (SRT)** de **más de 1 500** investigadores, y cada miembro supera un **proceso de verificación de cinco pasos** diseñado para evaluar tanto la habilidad como la fiabilidad. Históricamente, se acepta a **menos del 10 %** de los solicitantes, y según se informa la incorporación es un proceso que dura meses. La diferencia decisiva no es la tasa de aceptación. Es que los miembros del SRT son **talento contratado, no seudónimos al azar**. Los miembros estadounidenses cobran como **contratistas independientes 1099** (los no estadounidenses vía un W-8BEN), y ganan por misiones, informes válidos, verificación de parches y mentoría. Synack monitoriza de forma continua el comportamiento en línea de sus miembros y los expulsa cuando procede. Esta es la multitud cerrada y verificada que compran los gobiernos y las empresas fuertemente reguladas, y es cara precisamente porque verificar con ese rigor estrecha el embudo. Ese intercambio es la clave de todo. La verificación pesada es un impuesto sobre tu grupo, tu velocidad y tu presupuesto. Verificar en exceso un sitio de marketing público es tanto un desajuste como verificar de menos un núcleo de pagos. Por eso la respuesta nunca es «verificar al máximo», sino «verificar según el alcance». ## La escalera de verificación de cuatro niveles, y cómo elegir el tuyo **¿Cuánto deberías verificar a los investigadores de bug bounty?** Ajusta el rigor de la verificación a la sensibilidad de lo que está dentro del alcance, con cuatro niveles: (1) **admisión solo con registro**, donde cualquiera puede informar y no se exige identidad, para activos públicos y de baja sensibilidad; (2) **pagos con identidad verificada**, donde el informe es con seudónimo pero se exige KYC de identidad, impuestos y sanciones antes de pagar, el valor por defecto habitual; (3) **acceso privado por confianza**, donde la reputación gana una invitación y la verificación de identidad es obligatoria; y (4) **con verificación de antecedentes o por contrato**, con cribado penal y evaluadores nombrados y contratados para el alcance más crítico, regulado o clasificado. Aquí tienes la escalera como una tabla operativa de decisión. | Nivel | Quién puede informar | Verificación antes del acceso | Verificación antes del pago | Mejor encaje | |---|---|---|---|---| | **0: Admisión solo con registro (VDP)** | Cualquiera | Ninguna | Ninguna o solo KYC de pago | Activos públicos de baja sensibilidad; sitios de marketing; «si ves algo, di algo» | | **1: Pagos con identidad verificada** | Cualquiera (con seudónimo) | Ninguna | KYC de identidad + impuestos + sanciones | El valor por defecto habitual para un SaaS con datos reales pero no de máxima criticidad | | **2: Acceso privado por confianza** | Invitados, por reputación | Verificación de identidad obligatoria | KYC de pago completo | Datos sensibles; quieres un grupo curado y de identidad conocida | | **3: Con antecedentes / por contrato** | Evaluadores cribados y contratados | Verificación de antecedentes penales o contrato 1099 | Contractual | Alcance más crítico, regulado (fintech/salud) o clasificado | Lee la tabla por radio de impacto, no por prestigio. Hazte una sola pregunta por activo: si un actor malicioso operara dentro de este alcance, ¿cómo de grave sería el peor día verosímil? Un informante con seudónimo hurgando en tu sitio público de documentación es un problema de nivel 0. Un desconocido con una vía hacia tu núcleo de pagos en producción no lo es, y ningún pago de recompensa vale saltarse la identidad ahí. Dos apuntes prácticos. Primero, la mayoría de las startups operan **más de un nivel a la vez**: un programa público amplio de nivel 1 para el perímetro y una invitación de nivel 2 o 3 para cualquier cosa cercana a datos sensibles. Segundo, los niveles son una progresión, no una cadena perpetua. Un investigador que informa bien en el nivel 1 es exactamente a quien promocionas a tu grupo privado de nivel 2. La reputación es la forma en que los desconocidos de buena fe se ganan el camino hacia la confianza. ## Qué tiene que ver la verificación con mantenerse dentro de la ley: la lección Sullivan Aquí está la parte que a los fundadores se les escapa. La verificación no es solo un control de seguridad; es la manera de demostrar, a posteriori, que un actor dado operaba dentro de un alcance autorizado. Y en 2026 esa prueba tiene un peso legal real. En *Estados Unidos contra Sullivan*, el Noveno Circuito (sentencia emitida el **13 de marzo de 2025**) confirmó la condena del ex director de seguridad de Uber y sostuvo que, bajo la Computer Fraud and Abuse Act (CFAA), el «sin autorización» se juzga **en el momento del acceso**. El papeleo posterior, en aquel caso un acuerdo de confidencialidad disfrazado de bug bounty, **no puede limpiar de forma retroactiva** un acceso que no estaba autorizado cuando ocurrió. Los hechos de fondo son ya de por sí una advertencia: una brecha de 2016 expuso datos de 57 millones de usuarios y 600 000 números de permiso de conducir, con un pago de 100 000 USD canalizado a través del programa de bug bounty, y Sullivan acabó siendo condenado por obstrucción y encubrimiento de un delito grave. La lección para el responsable de un programa es precisa. La autorización tiene que establecerse **por adelantado, por escrito y ligada a una parte conocida**. La verificación ligera no crea responsabilidad bajo la CFAA por sí sola, pero dificulta demostrar más tarde que un actor concreto estaba dentro de un alcance autorizado y de buena fe. El lenguaje de puerto seguro (Safe Harbor) más saber *quién* es tu investigador son las dos mitades de la misma respuesta a «¿fue legítimo este acceso?». Por eso tu documento de alcance, tus términos de puerto seguro y tu nivel de verificación son una sola decisión, no tres. (Para la parte de redacción, consulta nuestra guía sobre [puerto seguro y amenazas legales a los investigadores de seguridad](/blog/safe-harbor-legal-threats-security-researchers-vdp), y el más amplio [mandato de divulgación de la Ley de Ciberresiliencia de la UE](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure) si vendes en Europa.) Nada de esto es asesoramiento legal. Kit te da el lugar donde poner el lenguaje de autorización y alcance; que un abogado revise el texto final de la política. ## Verificar investigadores es verificar contratistas con otro nombre El modelo mental más claro que un fundador ya tiene es el del contratista. Un investigador externo con una vía hacia el acceso a producción es el equivalente en seguridad de un contratista al que dejas entrar en tus sistemas. Y casi con seguridad ya escalas el escrutinio de contratistas según la sensibilidad del rol: un diseñador que toca un archivo de Figma pasa una comprobación más ligera que un ingeniero con credenciales de producción. Aplica la misma lógica gradual. Identidad, reputación o referencias, y verificaciones de antecedentes ajustadas a lo que la persona puede alcanzar: eso se traslada casi uno a uno desde tu política de contratación a los niveles de investigadores. Tratar «quién puede tocar producción» como una decisión de política deliberada, y no como una ocurrencia tardía, es toda la disciplina. También es la razón por la que el fraude de identidad en la cadena de suministro de talento, como la oleada de [fraude de contratación de trabajadores de TI norcoreanos](/blog/north-korean-it-worker-hiring-fraud), pertenece a la misma conversación: un contratista falso y un «investigador» seudónimo sancionado son el mismo fallo de KYC con distinto disfraz. ## Donde los programas cripto dejan obvia la palanca del dinero Los programas Web3 sacan a relucir el dial del KYC de pago con más nitidez, porque los pagos son lo bastante grandes como para que la cuestión del dinero domine. Immunefi no exige KYC por defecto; cada proyecto fija su propia política. Cuando se exige KYC, se recoge a través de Onfido **solo una vez que un informe de fallo se confirma como válido**, justo antes de un pago que puede alcanzar seis o siete cifras. Ese es todo el principio en una frase: **el KYC condiciona el dinero, no la participación.** Puedes mantener la admisión totalmente abierta y aun así negarte a mover un solo dólar hasta saber exactamente quién lo recibe y que legalmente puedes pagarle. Separar «puede informar» de «puede cobrar» es el patrón de diseño, tanto si tus recompensas son de 500 USD como de 5 millones. ## Poner en marcha el nivel que elijas sin la sobrecarga de una empresa grande Cada actor establecido tiene un incentivo para empujarte hacia *su* muesca. Los marketplaces venden ligero y a escala; Synack vende pesado y cerrado. Nadie neutral publica un marco de «cuánta verificación necesita realmente *tu* programa» guiado por el alcance, y luego te entrega las herramientas para operar el nivel que elijas. En ese hueco se sitúa la vertical CSIRT de Kit. Kit es infraestructura autoalojada, no una multitud gestionada. No suministra investigadores verificados como hace Synack. Lo que te da son los controles para operar cualquier nivel y para codificar tú mismo las decisiones de confianza: - **Configura el programa con alcance y puerto seguro por adelantado**, para que la «buena fe» quede definida *antes* del acceso, la lección Sullivan hecha operativa. La validación de alcance mantiene los informes dentro del límite que publicaste. - **Separa «puede informar» de «puede cobrar».** Los perfiles de investigador y un flujo de pago registrado en libro mayor te permiten mantener la admisión abierta (nivel 0/1) mientras condicionas el dinero a la identidad y la aprobación. - **Opera un recorrido de confianza que se gana con el trabajo.** El karma del investigador y las señales de reputación te permiten promocionar a informantes fuertes del nivel 1 a un alcance privado y curado de nivel 2. - **Restringe un grupo de mayor garantía.** Los controles de acceso a nivel de programa enrutan el alcance sensible y más crítico a un grupo privado y cribado (nivel 3). - **Haz triaje de forma coherente sin importar quién informó.** La evaluación estandarizada, las sugerencias de severidad y las comprobaciones de duplicados hacen que un seudónimo y un contratista nombrado reciban el mismo trato riguroso. Como Kit también posee una vertical de contratación (Hiring), está en una posición única para tratar la verificación de investigadores como la hermana externa (del hacker) de la política de verificación de antecedentes de contratistas: una sola disciplina de identidad para todos los que pueden tocar tus sistemas.

Decide tu nivel de verificación esta misma tarde y luego pon en marcha el programa que lo haga cumplir. El módulo CSIRT de Kit te deja configurar alcance, puerto seguro, perfiles de investigador y un flujo de pago registrado en libro mayor para que la identidad y la autorización queden codificadas desde el primer día, no añadidas a posteriori tras un incidente.

Empieza tu prueba gratuita

## Checklist de verificación para el primer día de un fundador Copia esto, ajústalo a tu alcance y tendrás una posición de partida defendible. 1. **Inventaría el alcance por radio de impacto.** Lista cada activo de tu programa y marca el peor día verosímil si un actor malicioso operara dentro de él. Esa marca es tu nivel. 2. **Pon el perímetro por defecto en nivel 1.** Los activos públicos y no críticos reciben informes con seudónimo con KYC de identidad, impuestos y sanciones antes de cualquier pago. 3. **Acota los activos más críticos en nivel 2 o 3.** Todo lo cercano a pagos, PII, PHI o claves de infraestructura va a un grupo solo por invitación, con identidad verificada o con antecedentes comprobados. 4. **Escribe la autorización por adelantado.** Publica el lenguaje de alcance y puerto seguro antes de invitar a nadie, y liga la autorización a una parte conocida. Que un abogado lo revise. 5. **Condiciona el dinero, no la admisión.** Nunca envíes un pago hasta que se completen la identidad, el formulario fiscal y el cribado de sanciones. Registra cada aprobación, reducción y rechazo en un libro mayor. 6. **Construye una vía de promoción.** Deja que los informantes fuertes del nivel 1 se ganen la entrada a tu grupo privado por reputación, para que tu grupo de confianza crezca a partir de comportamientos demostrados. Verificar es un dial. Ajústalo a la sensibilidad de lo que está dentro del alcance, codifica la identidad y la autorización con la firmeza suficiente para sobrevivir a una pregunta de «¿fue legítimo este acceso?», y obtienes a los informantes de buena fe sin la exposición legal. Elige tu muesca, publica tus términos y opera el programa que haga cumplir ambos. Para la mecánica de la puesta en marcha, empieza con [cómo montar un programa de divulgación de vulnerabilidades](/blog/how-to-set-up-vulnerability-disclosure-program) y nuestra visión sobre [los niveles de recompensa del bug bounty y la confianza en los investigadores](/blog/bug-bounty-reward-tiers-researchers-trust-hackerone-cuts).