## Por qué es importante

Quien aplica el triaje a un informe de vulnerabilidad casi nunca es quien lo corrige. El triaje ocurre en Kit; la corrección, en un tablero de ingeniería. Sin un vínculo entre ambos, alguien copia y pega el informe en Jira a mano — y desde ese momento los dos sistemas se separan. La incidencia dice «In Review» mientras el informe dice «Validado», nadie sabe responder a «¿esto está corregido de verdad?» y el investigador espera.

Conectar Jira cierra ese círculo. Un clic en un informe crea la incidencia de ingeniería, y el vínculo entre ambos es un registro real que Kit mantiene, no una URL que alguien pegó en un comentario.

También resuelve el problema menos llamativo: copiar a mano acaba pegándolo **todo** —incluidos los pasos de reproducción y el correo del investigador— en un proyecto cuya audiencia real nadie ha auditado. La integración de Kit envía en su lugar un resumen mínimo y deliberado.

## Lo que necesitas

- Una cuenta de Kit con el **complemento VDP** habilitado
- Un sitio de Jira Cloud (no son compatibles Jira Data Center ni Jira Server)
- Una cuenta de Atlassian con acceso al proyecto de destino
- Permisos de administrador del módulo en Kit: conectar un gestor de incidencias es una decisión de toda la organización

> [!NOTE]
> Kit usa **OAuth 2.0 (3LO)**. No hay ningún campo para un token de API, y no es un descuido: los requisitos de seguridad de Atlassian prohíben que las aplicaciones recojan los tokens de API de los usuarios. Iniciarás sesión en Atlassian y concederás el acceso.

## Configuración

### 1. Conecta tu cuenta de Atlassian

1. Ve a [**VDP > Ajustes > Gestor de incidencias**](/csirt/settings/tracker_connection)
2. Haz clic en **Conectar Jira**
3. Inicia sesión en Atlassian y aprueba el acceso solicitado
4. Elige el sitio de Jira que quieres usar, si tu cuenta de Atlassian tiene más de uno

La autorización pertenece a la persona que la concedió. Kit deja constancia de quién fue, porque cuando esa persona deja la organización la conexión deja de funcionar y necesitas saber el acceso de quién hay que renovar.

> [!WARNING]
> Algunas organizaciones de Atlassian exigen que un administrador apruebe las aplicaciones de terceros. Si hace falta esa aprobación, el paso de conexión falla con un mensaje de Atlassian y no con un error de Kit: traslada la solicitud a quien administre tu organización de Atlassian.

### 2. Elige un proyecto y un tipo de incidencia

1. En la página de ajustes, haz clic en **Elegir proyecto**
2. Elige el proyecto que debe recibir el trabajo sobre vulnerabilidades
3. Elige el tipo de incidencia con el que se crean las nuevas (normalmente Bug o Task)

Mientras tanto, Kit lee el tipo de proyecto. Si es un proyecto de **Jira Service Management**, los comentarios de hito —la opción **Comentar los cambios de estado**— se desactivan por defecto: JSM obliga a que los comentarios creados a través de la API de la plataforma sean públicos, lo que los dejaría a la vista de los clientes externos de tu service desk.

Kit lee también los nombres de prioridad que admiten el proyecto y el tipo de incidencia que has elegido, y hace corresponder con ellos los niveles de severidad de los informes (Crítico → Highest, Alto → High, y así sucesivamente). Hay dos casos que conviene conocer, y la página de ajustes te avisa cuando se da cualquiera de ellos:

- **Tu proyecto usa sus propios nombres de prioridad**, o funciona en un idioma distinto del inglés. Kit no se inventa una prioridad que no puede emparejar, así que esos informes se crean con la prioridad predeterminada que aplique el proyecto. En cualquier caso, la severidad siempre se escribe en la descripción de la incidencia.
- **Tu proyecto no tiene campo de prioridad** en su pantalla de creación, algo habitual en los proyectos gestionados por el equipo. Entonces Kit no envía ninguna prioridad.

Para controlar tú mismo esa correspondencia, define una anulación `priority_map` en la conexión: todavía no hay ninguna pantalla para hacerlo.

### 3. Confirma que funciona

Haz clic en **Probar conexión**. Kit hace una petición autenticada a tu sitio y te muestra el resultado.

## Enviar un informe

Abre cualquier informe. En la columna derecha encontrarás una tarjeta **Gestor de incidencias**.

1. Haz clic en **Crear incidencia**
2. Lee el panel que muestra qué se envía y qué se queda en Kit
3. Haz clic en **Crear incidencia**

La tarjeta muestra un indicador de carga mientras se crea la incidencia y, después, la clave de la incidencia, su estado y un enlace que abre Jira en una pestaña nueva.

Puede hacerlo cualquier miembro del equipo que pueda ver el informe: es triaje rutinario, el mismo nivel de permiso que adjuntar un enlace. Lo que queda reservado a los administradores es configurar la conexión.

## Qué sale de Kit

Esta es la parte que conviene leer con calma. Por defecto, la incidencia que se envía es un **resumen mínimo**: lo justo para que un ingeniero pueda planificar el trabajo, y nada más.

| Se envía a Jira | Se queda en Kit |
|---|---|
| Título del informe y su referencia de Kit | La descripción de la vulnerabilidad |
| Severidad y puntuación CVSS | Los pasos de reproducción |
| Tipo de vulnerabilidad | El endpoint afectado |
| Área afectada | Los archivos de prueba de concepto y las capturas de pantalla |
| Fecha límite de corrección | El nombre, el correo y los datos de pago del investigador |
| Un enlace de vuelta al informe en Kit | Las notas internas y el hilo de conversación |

No es prudencia por prudencia. Desde Kit no hay forma de saber quién ve realmente lo que hay en Jira: permisos de proyecto abiertos a toda la organización, aplicaciones del marketplace con permiso de lectura de incidencias, exportaciones a CSV y copias de seguridad que sobreviven a la propia incidencia. Los campos que Kit retiene son los mismos que cifra en reposo, así que enviarlos trasladaría tus datos más protegidos a tu sistema menos controlado.

**La identidad del investigador y los importes de las recompensas no tienen ninguna opción que los active.** La ausencia de esa opción es la garantía.

### Compartir los detalles completos aun así

Hay equipos que sí quieren la descripción dentro de la incidencia. Para eso hacen falta **dos** condiciones independientes:

1. Un administrador activa **Permitir los detalles completos de la vulnerabilidad** en *VDP > Ajustes > Gestor de incidencias*
2. Quien envía el informe marca la casilla para esa incidencia en concreto

Ambas están desactivadas por defecto. Con el ajuste del programa desactivado, las casillas ni siquiera se muestran; y una petición fabricada a mano tampoco sirve para saltárselas, porque Kit vuelve a comprobar el ajuste del programa al construir el contenido que envía.

Cuando se incluye el texto del informe, se coloca en un bloque de código, de modo que Jira lo muestra tal cual lo escribió el investigador en lugar de interpretarlo como marcado.

> [!TIP]
> Déjalo desactivado. La incidencia enlaza de vuelta a Kit, y el ingeniero que necesite los pasos de reproducción puede abrir el informe: bajo tus controles de acceso y dejando registro de la consulta.

## Estado de la corrección

La tarjeta muestra la etiqueta de estado de la propia incidencia tal como la nombra tu tablero («In Review», «Ready for QA»), porque es lo que ve el ingeniero. Kit la traduce internamente a uno de cinco estados —Sin empezar, En curso, Corregido, No se corregirá y Desconocido— a partir de las *categorías* de estado fijas de Jira y no de los nombres de estado, así que no hace falta configurar ninguna correspondencia de flujo de trabajo por proyecto.

**Kit nunca resuelve un informe porque Jira diga Done.** En un tablero de ingeniería, «Done» suele significar «fusionado, no desplegado», y resolver un informe tiene consecuencias que no se le pueden presuponer a quien arrastra una tarjeta: se avisa al investigador, se abre el flujo de la recompensa y se mueven los plazos de divulgación. Kit muestra que la incidencia está terminada y deja la decisión en manos de una persona.

## Desvincular y reintentar

- **Desvincular** elimina el vínculo solo en Kit. La incidencia sigue en Jira, donde puede que ya tenga comentarios de un ingeniero y una rama con la corrección: allí Kit no es el sistema de referencia.
- **Reintentar** repite un envío que falló. Puedes pulsarlo dos veces sin riesgo: Kit etiqueta cada incidencia con una clave única y busca esa etiqueta antes de crear nada, así que una petición que agotó el tiempo de espera después de que Jira ya hubiera creado la incidencia adopta la existente en lugar de crear una segunda.
- **Desconectar** la integración elimina la copia que Kit guarda de la autorización y sus registros de seguimiento. Todas las incidencias que ya hayas creado siguen en Jira.

## Solución de problemas

| Síntoma | Causa | Solución |
|---|---|---|
| «Se ha revocado el acceso a Jira» | Se revocó la autorización en Atlassian, o se desactivó al usuario que la concedió | Vuelve a conectar desde la página de ajustes; puede volver a autorizar otro administrador |
| «Ese proyecto no tiene ningún tipo de incidencia utilizable» | El proyecto solo expone tipos de subtarea | Elige otro proyecto, o añade un tipo de incidencia estándar en Jira |
| La incidencia se rechazó por un campo | Un campo personalizado obligatorio que el resumen mínimo no rellena | Revisa el error que muestra la tarjeta y ajusta la configuración de campos del proyecto para que ese campo sea opcional al crear la incidencia |
| No aparece el botón **Crear incidencia** | No hay ningún gestor de incidencias conectado, o el complemento VDP no está activo | Conecta uno en *VDP > Ajustes > Gestor de incidencias* |

## Checklist rápido

- [ ] Complemento VDP activo en la cuenta
- [ ] Cuenta de Atlassian conectada, y sabes quién la autorizó
- [ ] Proyecto y tipo de incidencia elegidos
- [ ] La prueba de conexión se supera
- [ ] Has revisado en la página de ajustes si hay un aviso sobre la correspondencia de prioridades en el proyecto que has elegido
- [ ] Has decidido, de forma deliberada, si se pueden compartir los detalles completos de la vulnerabilidad
- [ ] Si es un proyecto de Jira Service Management, has confirmado que **Comentar los cambios de estado** está desactivado