Cómo configurar la app de Strike para Jira
Last updated: October 30, 2026
La app de Strike para Jira convierte tus vulnerabilidades en issues de Jira de forma automática y los mantiene actualizados a medida que la vulnerabilidad cambia. Si lo habilitas, también funciona en el otro sentido: cuando tu equipo mueve un issue en el tablero, Strike reacciona.
Antes de empezar
Solo los usuarios con rol Owner en Strike pueden conectar la integración y cambiar su configuración. El resto de los roles la ve en modo lectura.
Necesitas permiso de administrador en tu sitio de Jira para instalar la app, y permiso de escritura en los proyectos donde quieras que Strike cree issues.
Conectar Strike con Jira
La conexión se hace con un código de un solo uso y te mueve entre tres lugares. Estos son los pasos en orden.
En Strike
Entra a Settings, luego a Integrations y abre Jira.
Haz clic en Connect Jira. Se abre el modal Strike for Jira.
Haz clic en Install the Strike app, dentro del primer paso del modal.
En Atlassian
En la página de la app, haz clic en Get app.
Elige el sitio de Jira donde quieres instalarla y haz clic en Install. La lista solo muestra los sitios donde eres administrador.
En tu sitio de Jira
Entra a Settings, luego a Marketplace Apps, y selecciona Strike en la columna de la izquierda.
Copia el código que aparece en Connect this Jira site with Strike. Sirve una sola vez y vence, así que si se te pasa el tiempo genera otro con Generate a new code.
De vuelta en Strike
Pega el código en Link code y haz clic en Continue. Antes de vincular, Strike te muestra la dirección del sitio de Jira: confirma que sea la correcta.
Al terminar, la integración pasa a Connected y muestra el nombre de tu sitio.
Crear un destino
Un destino le dice a Strike dos cosas: en qué proyecto de Jira crear los issues y qué vulnerabilidades mandar ahí.
En Jira project, elige el proyecto donde se van a crear los issues. La lista solo muestra los proyectos a los que tienes acceso.
En Source, elige de dónde vienen las vulnerabilidades que van a ese proyecto: Assets, Threat emulations, Projects o Entire organization.
Puedes crear varios destinos. Cuando una vulnerabilidad encaja en más de uno, gana el más específico, en este orden: Assets, Threat emulations, Projects y, por último, Entire organization.
Elegir el issue type
Strike crea siempre el mismo tipo de issue en ese proyecto, y tú eliges cuál. El workflow de ese issue type es el que define qué estados de Jira vas a poder usar en el paso siguiente, así que conviene elegirlo antes de pensar en el mapeo.
Asignar los estados de Strike a los de Jira
Cada estado de una vulnerabilidad en Strike mueve el issue al estado de Jira que elijas. Los estados a asignar son Pending Fix, In Progress, Fixed, Accepted Risk y Discarded.
Este paso es opcional. Si no eliges nada, Strike mueve el issue a cualquier estado de la categoría que corresponde, por ejemplo cualquier estado de la categoría Done para una vulnerabilidad Fixed. Elige un estado puntual solo cuando tu workflow tenga varios en la misma categoría y quieras uno en particular. Varios estados de Strike pueden apuntar al mismo estado de Jira.
Permitir que Jira actualice tus vulnerabilidades
Este paso es opcional y el permiso aplica a toda la organización. Con el switch apagado, nada de lo que pase en tu tablero modifica Strike.
Con el switch encendido, eliges qué significa cada estado de tu Jira cuando un issue entra en él:
Opción | Qué hace en Strike |
Nothing | Nada. Strike ignora ese estado. |
Work started | Pasa la vulnerabilidad a In Progress. |
Fix claimed · Strike retests | Strike retestea la vulnerabilidad antes de cerrarla. |
Mark as Accepted Risk | Cierra la vulnerabilidad como Accepted Risk. Desde Jira no viaja ninguna justificación. |
Mark as Fixed, no retest | Cierra la vulnerabilidad como Fixed sin retest. En los reportes figura como no verificada por Strike. |
Strike propone un valor por defecto para cada estado según su categoría en Jira (To Do, In Progress o Done). Cada fila te muestra además qué estado de Strike aterriza ahí, para que veas las dos direcciones antes de elegir.
Sacar un issue de un estado que declara un fix reabre la vulnerabilidad en Strike y cancela el retest si todavía no empezó.
Cuando el retest termina, Strike actualiza el issue: si confirma el fix, la vulnerabilidad queda cerrada; si la vulnerabilidad sigue ahí, Strike reabre el issue con un comentario que explica por qué.
Desconectar la integración
Puedes desconectar la integración desde la misma pantalla. Los issues que Strike ya creó quedan en tu Jira sin cambios. Strike deja de crear issues nuevos y de actualizar los existentes hasta que vuelvas a conectar.
Preguntas frecuentes
¿Qué vulnerabilidades llegan a Jira?
Solo las confirmadas. Las que todavía están pendientes de triage y las descartadas no generan ningún issue.
¿Strike puede pisar los cambios que hace mi equipo en un issue?
No. Strike solo escribe los campos que le pertenecen. Las etiquetas, el responsable, la fecha de entrega, los campos personalizados y los comentarios que agregue tu equipo se conservan en cada actualización.
¿Puedo mandar distintas vulnerabilidades a distintos proyectos de Jira?
Sí, creando un destino para cada uno. Si una vulnerabilidad encaja en más de un destino, gana el más específico.
¿Por qué una vulnerabilidad cerrada desde Jira figura como no verificada en los reportes?
Porque Strike no la retesteó. Es el mismo comportamiento que cuando cierras una vulnerabilidad como Fixed directamente en la plataforma sin pedir un retest. Si prefieres que quede verificada, usa la opción Fix claimed · Strike retests en lugar de Mark as Fixed, no retest.