Configura tu programa
Configura las once áreas de ajustes del VDP, como el alcance, el enrutamiento, los objetivos de respuesta, los pagos, la recepción y el correo del programa.
Por qué es importante
Una buena configuración es la diferencia entre un VDP creíble y una política vaga que los investigadores ignoran. La claridad del alcance protege a tu equipo de ingeniería de informes irrelevantes, los objetivos de SLA mantienen honestos tus tiempos de respuesta, y una matriz de recompensas bien definida fija las expectativas de los investigadores antes de que envíen un informe.
Kit ofrece valores predeterminados para muchos ajustes, pero debes revisar el alcance, los datos de contacto, las responsabilidades y la política pública antes de activar el programa.
Activar VDP
Ve a VDP para activar tu programa. El pipeline completo está incluido en todas las suscripciones activas de Kit.
Una vez creado tu programa, ve a VDP > Program Settings para configurarlo. Tu programa comienza en estado Draft: no aceptará informes hasta que cambies el estado a Active.
Pestaña General
La pestaña General controla la identidad de tu programa y la política de divulgación.
| Campo | Descripción |
|---|---|
| Program Name | Se muestra en tu página de política de divulgación y en el portal del investigador |
| Status | Draft, Active o Paused: cámbialo a Active cuando la configuración esté completa |
| Disclosure Policy | Campo de texto enriquecido predefinido con lenguaje de puerto seguro (Safe Harbor). Admite formato, enlaces y listas. |
| Prohibited Actions | Acciones que los investigadores no deben realizar (por ejemplo, ingeniería social, ataques físicos, denegación de servicio) |
Mantén tu programa en Draft mientras configuras las pestañas restantes. Cambia a Active solo cuando estés listo para aceptar envíos.
Pestaña Scope
El alcance define lo que los investigadores deben y no deben probar. Un alcance vago genera informes vagos: sé específico.
| Campo | Descripción |
|---|---|
| In-Scope Targets | Hosts, URLs o rangos de IP que los investigadores deben probar (uno por línea). Ejemplo: app.yourcompany.com, api.yourcompany.com
|
| Out-of-Scope Categories | Exclusiones de categorías estilo OWASP (por ejemplo, “Denial of Service”, “Physical Attacks”) |
| Excluded Vulnerability Types | Clases de vulnerabilidades específicas que no aceptarás (por ejemplo, “Self-XSS”, “Missing rate limiting on non-critical endpoints”) |
Si dejas vacíos los objetivos en alcance, todos los objetivos quedan implícitamente en alcance. Esto rara vez es lo que quieres. Como mínimo, lista los dominios principales de tu aplicación.
Kit usa la configuración de alcance para validar los informes entrantes automáticamente. Los informes dirigidos a tipos de vulnerabilidades excluidos o a categorías fuera de alcance se marcan antes de que lleguen a tu tablero de triaje.
Pestaña Bounty Matrix
Suscripción de Kit: esta pestaña requiere una suscripción activa de Kit. Las recompensas siguen siendo opcionales.
La matriz de recompensas define los rangos de pago para cada nivel de severidad. Los montos se muestran en tu página de política de divulgación para que los investigadores sepan qué esperar.
| Severidad | Mín. predeterminado | Máx. predeterminado |
|---|---|---|
| Súper crítico | $5,000 | $10,000 |
| Crítico | $1,500 | $5,000 |
| Alto | $500 | $1,500 |
| Medio | $150 | $500 |
| Bajo | $50 | $150 |
| Informativo | $0 | $0 |
Ajusta estos rangos según tu presupuesto y tu tolerancia al riesgo. Cuando se registra una evaluación CVSS en un informe, Kit sugiere automáticamente un monto de recompensa dentro del rango del nivel correspondiente.
Visibilidad de los votos de recompensa
Debajo de la matriz, la misma pestaña incluye el ajuste de visibilidad de los votos. Controla si el recuento de una propuesta de recompensa (el marcador en curso, quién votó en qué sentido y los importes alternativos) puede leerse antes de que un compañero haya emitido su propio voto.
| Qué ven los compañeros antes de votar | |
|---|---|
| A ciegas (predeterminado) | El importe, quién lo propuso y por qué, más cuántas respuestas están selladas y cuántas personas siguen pendientes. Ni posturas, ni nombres, ni importes alternativos. |
| En directo | Todo, desde el primer voto. |
A ciegas es el modo predeterminado porque la primera cifra en pantalla condiciona a las que vienen después. Elige en directo solo si quieres que el equipo vea las posturas de los demás mientras se forman. Cualquiera de los dos ajustes se guarda con el resto de la pestaña y sobrevive a las ediciones posteriores de los niveles; también puedes cambiarlo pidiéndole a tu asistente de IA conectado que reconfigure el programa (consulta Integración con IA).
Pestaña SLAs
Los SLAs definen los compromisos de tiempo de respuesta de tu equipo. El reloj del SLA arranca con el envío del informe. Tu dashboard muestra el estado de cada informe como en plazo, en riesgo o incumplido.
El SLA de acuse de recibo se aplica de forma uniforme a todas las severidades: es el tiempo máximo desde el envío hasta la primera respuesta. Valor predeterminado: 72 horas.
Los objetivos de resolución varían según la severidad:
| Severidad | Objetivo de resolución predeterminado |
|---|---|
| Súper crítico | 24 horas |
| Crítico | 72 horas (3 días) |
| Alto | 168 horas (1 semana) |
| Medio | 336 horas (2 semanas) |
| Bajo | 720 horas (30 días) |
| Informativo | 720 horas (30 días) |
Modifica cualquiera de estos valores según la capacidad de tu equipo. Los SLAs agresivos quedan bien sobre el papel, pero pierden credibilidad si los incumples a menudo. Fija objetivos que de verdad puedas cumplir y ve ajustándolos con el tiempo.
Los indicadores de SLA aparecen en cada tarjeta de informe en el tablero de triaje:
- On Track (verde): queda más del 25 % de la ventana del SLA
- At Risk (amarillo): queda el 25 % o menos de la ventana del SLA (ha transcurrido el 75 % o más)
- Breached (rojo): el plazo del SLA ha vencido
Alertas de incumplimiento
Un informe que incumple su SLA de acuse de recibo avisa al equipo por tres vías a la vez: una respuesta en el hilo de Slack del informe, un DM o un correo a quien esté de guardia y un incidente de PagerDuty si lo tienes conectado. Un incumplimiento que nadie puede resolver es noticia la primera vez y ruido la quinta, así que dos campos al final de esta pestaña limitan cada cuánto vuelve esa alerta.
| Campo | Predeterminado | Rango | Descripción |
|---|---|---|---|
| Repeats after a breach | 3 | 0–20 | Cuántas veces se vuelve a avisar de un informe incumplido después de la primera alerta. Ponlo a 0 para avisar una sola vez y no repetir nunca. |
| Time between breach alerts | 6 horas | 6–720 | Cuánto espera Kit antes de volver a avisar de un informe que sigue sin acuse de recibo. |
La primera alerta siempre se envía: lo único que se limita son las repeticiones. La última alerta del cupo lo dice en Slack, con el sufijo last reminder — no further alerts for this report, para que el silencio posterior se lea como un cupo agotado y no como una integración rota.
Aplazar un informe también silencia las repeticiones, pero nunca la primera alerta: ese aviso es justo la noticia a la que respondía el aplazamiento.
El contador se reinicia cuando un informe sale del pipeline abierto (Submitted, Triaged, Needs Clarification, Validated, In Progress), así que un informe que se reabre más tarde arranca con un cupo nuevo. Pasar un informe de un estado abierto a otro no lo reinicia.
Note
El mínimo de 6 horas del intervalo es deliberado. Cada señal que avisa sobre un informe consume un mismo cupo de alertas compartido entre señales, y ese cupo se tragaría cualquier repetición pedida antes de ese plazo: un intervalo más corto nunca llegaría a dispararse.
Aviso de cola
Cuando las revisiones se retrasan, díselo a los investigadores en lugar de dejar que lo adivinen. La sección Aviso de cola está en VDP > Portal de seguridad, no en la configuración del programa.
| Campo | Descripción |
|---|---|
| Activar ahora / Desactivar | Activa o desactiva el aviso. La línea de al lado indica si los investigadores lo ven ahora. |
| Mensaje | Texto sin formato, hasta 1000 caracteres. Déjalo en blanco para usar el mensaje predeterminado de Kit, que cada investigador lee en su idioma. Tu propio texto se muestra tal cual. |
| Tiempo de respuesta estimado | Opcional, por ejemplo «2–3 semanas». Aparece debajo del mensaje; déjalo en blanco para omitirlo. |
| Avisar también a los investigadores cuyo informe supere tu plazo de acuse de recibo | Correo automático opcional, descrito más abajo. |
Mientras el aviso está activo, los investigadores lo ven en el formulario de envío, la página del justificante, el correo de acuse de recibo y cada informe abierto del portal del investigador. Una vista previa bajo los campos muestra exactamente lo que van a leer.
Con el envío automático activado, Kit manda el aviso una sola vez, por correo y en el hilo del informe, cuando un informe supera tu SLA de acuse de recibo sin que nadie de tu equipo lo haya tocado: ni triado, ni evaluado, ni respondido. Asignarlo, aunque sea de forma automática, no cuenta como respuesta. Solo cuentan los informes recibidos después de activar el envío automático, así que activarlo no escribe a todo tu atraso. El historial del informe registra cada aviso enviado.
Desactiva el aviso cuando te hayas puesto al día. Con él se detiene también el envío automático.
Peticiones de novedades de los investigadores
Un investigador que no ha tenido noticias puede pedirlas desde la página del informe en el portal del investigador con Pedir novedades, y añadir una nota opcional que solo ve tu equipo de seguridad.
- El botón se desbloquea cuando el informe supera tu SLA de acuse de recibo sin respuesta, o tras 14 días sin actividad de tu equipo visible para el investigador.
- Se puede pedir una vez cada 7 días por informe, y solo mientras el informe siga abierto.
- Cada petición avisa a los administradores de seguridad del programa y aparece en el hilo de Slack del informe. El informe muestra el aviso Pendiente de respuesta hasta que alguien responde al investigador, cambia el estado, asigna el informe o registra una nueva evaluación.
- Cada petición dispara además el evento de webhook
csirt.report.escalation_requestedsi estás suscrito. La nota del investigador nunca se incluye.
Pestaña Triage
La configuración de triaje controla cómo se enrutan y procesan los informes entrantes.
| Campo | Predeterminado | Descripción |
|---|---|---|
| Default Assignee | Ninguno | Miembro del equipo que recibe los nuevos informes automáticamente. Asígnalo a tu contacto principal de seguridad. |
| Escalation Severities | Critical, Super Critical | Niveles de severidad que disparan una alerta de escalamiento por email y Slack |
| Deduplication | Activado | Marca informes potencialmente duplicados antes de que lleguen a tu tablero |
| Require Retest | Desactivado | Exige la verificación del investigador de que la corrección funciona antes de resolver |
| Max Appeals | 3 | Número máximo de apelaciones que un investigador puede presentar sobre un informe desestimado |
La configuración de la rotación de guardia (modo, horario, miembros y asignación automática) tiene su propia página. Consulta Rotación de guardia para más detalles.
Si no estableces un responsable predeterminado, los nuevos informes aparecen sin asignar en el tablero de triaje. Tu equipo aún puede tomarlos manualmente, pero la asignación garantiza que nada se quede en el tintero.
Un escalamiento publica una línea en el hilo de Slack del informe y, una vez que el informe se valida, avisa a quien esté de guardia por DM de Slack o por correo. Configura la integración de Slack en Account Settings > Integrations.
Pestaña Components
Suscripción de Kit: los componentes están incluidos y son opcionales. Los informes también funcionan sin enrutamiento por componentes.
Los componentes etiquetan los informes por área de producto y permiten que Kit sugiera un área para que el equipo de triaje la confirme. Cuando se confirma un componente, Kit asigna su responsable predeterminado si está configurado y el informe sigue sin asignar. Después de validar el informe, Kit avisa al canal de Slack del componente si se ha configurado uno. Crea componentes solo cuando exista un límite de responsabilidad real; un catálogo decorativo añade otro campo sin mejorar el enrutamiento.
Consulta Enrutar informes a los equipos para conocer las reglas de coincidencia, la confirmación, la asignación predeterminada y el enrutamiento a Slack.
Pestaña Payouts
Suscripción de Kit: esta pestaña requiere una suscripción activa de Kit.
La pestaña Payouts configura cómo se gestionan los desembolsos de recompensas.
| Campo | Predeterminado | Descripción |
|---|---|---|
| Supported Payment Methods | PayPal | Selecciona los métodos que admites: Transferencia bancaria, PayPal y Cheque |
| Require Tax Documents | Sí | Los investigadores deben subir un W-9 (EE. UU.) o W-8BEN (internacional) antes de recibir el pago |
| Require Agreement | Sí | Los investigadores deben aceptar tu acuerdo de divulgación antes del pago |
| Minimum Payout | $50 | Los investigadores por debajo de este umbral se agrupan hasta que las ganancias acumuladas alcanzan el mínimo |
| Currency | USD | Moneda para todos los montos de recompensa y pagos |
| Finance Email | En blanco | La bandeja que programa los pagos. Si se configura, iniciar un pago le envía una solicitud de pago con un enlace seguro donde finanzas confirma el pago, o notifica que falló, sin necesidad de una cuenta de Kit. Déjalo en blanco para registrar los pagos tú mismo. Consulta Confirmación del equipo de finanzas |
Los requisitos de documentación fiscal existen por tu cumplimiento legal. Desactivar este ajuste significa que los investigadores pueden recibir pagos sin aportar documentación fiscal: consúltalo con tu equipo de finanzas antes de desactivarlo.
Pestaña Spam
Los ajustes de spam protegen el programa de avalanchas de envíos e informes masivos de baja calidad. Miden una ráfaga (informes recibidos con poca separación), no todo el historial del investigador con tu programa.
| Campo | Predeterminado | Descripción |
|---|---|---|
| Max Reports per Window | 5 | Número de informes que una dirección de correo o IP puede enviar dentro de una ventana antes de quedar bloqueada |
| Window Duration | 5 minutos | Ventana medida desde el informe que la abrió. El primer informe que llegue después de cerrarse abre otra y reinicia el contador |
| Block Duration | 1 hora | Duración de un bloqueo automático. Los bloqueos aplicados manualmente desde la pantalla Spam Records siempre duran una semana |
Los valores predeterminados son conservadores. Si se bloquea a investigadores legítimos, aumenta Max Reports per Window o acorta la Window para que sus informes caigan en ventanas distintas. Si recibes muchos mensajes basura, reduce el umbral y amplía Block Duration.
Quien queda bloqueado ve un aviso inespecífico a propósito. Kit no indica a un posible atacante qué filtro lo ha detenido. Los bloqueos se levantan solos cuando vence Block Duration, y el contador se reinicia con el siguiente informe después de terminar su ventana de recuento. También puedes consultar y levantar cualquier bloqueo desde VDP > Spam Records.
Consulta Límites de envíos y bloqueos por spam para conocer todo el recorrido: cada control que supera un envío, cómo leer un registro de spam y qué decir a un investigador rechazado.
Pestaña Takedown
La pestaña Takedown controla si el programa también acepta avisos de abusos de terceros y de suplantación de marca. Configúrala solo si tu equipo es responsable de responder a esos casos. Un aviso de retirada tiene su propia recepción, pruebas, estado e historial de auditoría; no es un informe de vulnerabilidades con otra etiqueta.
Consulta Avisos de retirada antes de habilitar esta vía de recepción.
Pestaña security.txt
Esta pestaña configura los campos usados para generar tu archivo /.well-known/security.txt según la RFC 9116. Kit sirve este archivo automáticamente cuando tu programa está activo.
| Campo | Predeterminado | Descripción |
|---|---|---|
| Contact Email | Ninguno (requerido) | La dirección de email que los investigadores usan para notificar vulnerabilidades. Se publica en el campo Contact:. |
| Expiration | 365 días | Días desde la generación hasta que el security.txt expira. La RFC 9116 exige un campo Expires:. |
| Policy URL | Autogenerado | URL de tu página de política de divulgación. Por defecto apunta a tu política alojada en Kit. |
| Acknowledgments URL | Ninguno | URL de tu página del salón de la fama (Hall of Fame), si está habilitada |
| Hiring URL | Ninguno | Enlace a las ofertas de empleo de tu equipo de seguridad |
| Encryption URL | Ninguno | URL de tu clave pública PGP para comunicación cifrada |
Debes establecer un email de contacto antes de que se sirva tu security.txt. Para todos los detalles sobre configuración, formato y verificación de security.txt, consulta Configuración de security.txt.
Pestaña Email
La pestaña Email aprovisiona un gestor security@ en una integración de correo entrante que esté lista. Kit prefiere Startupkit Email cuando ambos proveedores están preparados; en caso contrario, usa una integración existente y lista de Cloudflare Email Routing. El aprovisionamiento registra el gestor en Kit, pero no configura el dominio. El correo que coincida se enruta cuando están operativos el buzón de captura de Startupkit Email o el worker activo de Cloudflare.
Un buzón respaldado por Cloudflare recibe correo, pero los mensajes para investigadores siguen enviándose desde la dirección de la plataforma de Kit. Para enviar desde la dirección del programa necesitas Startupkit Email con la función de envío como remitente activa.
Eliminar la identidad detiene el correo nuevo enviado a esa dirección; antes, confirma cómo contactarán los investigadores con el equipo. La marca de la cuenta sigue controlando el logotipo y los colores del correo para investigadores. Consulta Comunicación con investigadores para conocer el comportamiento de los mensajes.
Checklist
- Define el nombre del programa y personaliza el texto de la política de divulgación
- Define los objetivos en alcance y las categorías fuera de alcance
- Configura la matriz de recompensas o indica que el programa no ofrece recompensas
- Fija los objetivos de SLA por nivel de severidad
- Decide el cupo de repeticiones de las alertas de incumplimiento: cuántas veces vuelve a avisarte un informe incumplido y con cuánta separación
- Decide si usarás el aviso de cola, y su envío automático, cuando las revisiones se retrasen
- Asigna un responsable de triaje predeterminado
- Crea rutas de componentes solo cuando estén claras las responsabilidades
- Configura los métodos de pago y los requisitos fiscales
- Revisa los umbrales de spam
- Decide si el programa acepta avisos de retirada
- Establece el email de contacto para security.txt
- Aprovisiona y prueba la identidad de correo del programa
- Configura la integración de Slack para las alertas de escalamiento
- Cambia el estado a Active cuando esté todo listo
Siguientes pasos
- Configuración de security.txt: guía detallada del cumplimiento y la verificación de la RFC 9116
- Triaje de informes: cómo usar el tablero Kanban, evaluar la severidad y resolver informes
- Límites de envíos y bloqueos por spam: todos los motivos por los que se puede rechazar un envío y cómo liberar a quien haya quedado bloqueado por error
- Enrutar informes a los equipos: etiquetas de componentes, asignación predeterminada y enrutamiento a Slack
- Avisos de retirada: el flujo independiente para avisos de abuso