Como configurar o app da Strike para Jira

Last updated: October 30, 2026

O app da Strike para Jira transforma suas vulnerabilidades em issues do Jira de forma automática e as mantém atualizadas conforme a vulnerabilidade muda. Se você habilitar essa opção, ele também funciona no sentido contrário: quando sua equipe move um issue no quadro, a Strike reage.

Antes de começar

  • Somente usuários com o papel Owner na Strike podem conectar a integração e alterar suas configurações. Os demais papéis a veem em modo somente leitura.

  • Você precisa de permissão de administrador no seu site do Jira para instalar o app e de permissão de escrita nos projetos em que quer que a Strike crie issues.

Conectar a Strike ao Jira

A conexão é feita com um código de uso único e leva você por três lugares. Estes são os passos, em ordem.

Na Strike

  1. Acesse Settings, depois Integrations e abra Jira.

  2. Clique em Connect Jira. O modal Strike for Jira será aberto.

  3. Clique em Install the Strike app, dentro do primeiro passo do modal.

Na Atlassian

  1. Na página do app, clique em Get app.

  2. Escolha o site do Jira em que você quer instalá-lo e clique em Install. A lista mostra apenas os sites em que você é administrador.

No seu site do Jira

  1. Acesse Settings, depois Marketplace Apps, e selecione Strike na coluna da esquerda.

  2. Copie o código que aparece em Connect this Jira site with Strike. Ele só pode ser usado uma vez e expira, então, se o tempo acabar, gere outro com Generate a new code.

De volta à Strike

  1. Cole o código em Link code e clique em Continue. Antes de vincular, a Strike mostra o endereço do site do Jira: confirme se é o correto.

  2. Ao terminar, a integração passa para Connected e mostra o nome do seu site.

Criar um destino

Um destino diz à Strike duas coisas: em qual projeto do Jira criar os issues e quais vulnerabilidades enviar para lá.

  1. Em Jira project, escolha o projeto em que os issues serão criados. A lista mostra apenas os projetos aos quais você tem acesso.

  2. Em Source, escolha de onde vêm as vulnerabilidades que vão para esse projeto: Assets, Threat emulations, Projects ou Entire organization.

Você pode criar vários destinos. Quando uma vulnerabilidade se encaixa em mais de um, vence o mais específico, nesta ordem: Assets, Threat emulations, Projects e, por último, Entire organization.

Escolher o issue type

A Strike sempre cria o mesmo tipo de issue nesse projeto, e você escolhe qual. O workflow desse issue type define quais status do Jira você poderá usar no passo seguinte, então vale a pena escolhê-lo antes de pensar no mapeamento.

Associar os status da Strike aos do Jira

Cada status de uma vulnerabilidade na Strike move o issue para o status do Jira que você escolher. Os status a associar são Pending Fix, In Progress, Fixed, Accepted Risk e Discarded.

Este passo é opcional. Se você não escolher nada, a Strike move o issue para qualquer status da categoria correspondente, por exemplo qualquer status da categoria Done para uma vulnerabilidade Fixed. Escolha um status específico apenas quando o seu workflow tiver vários na mesma categoria e você quiser um em particular. Vários status da Strike podem apontar para o mesmo status do Jira.

Permitir que o Jira atualize suas vulnerabilidades

Este passo é opcional e a permissão vale para toda a organização. Com o switch desligado, nada do que acontecer no seu quadro modifica a Strike.

Com o switch ligado, você escolhe o que cada status do seu Jira significa quando um issue entra nele:

Opção

O que faz na Strike

Nothing

Nada. A Strike ignora esse status.

Work started

Passa a vulnerabilidade para In Progress.

Fix claimed · Strike retests

A Strike faz o reteste da vulnerabilidade antes de fechá-la.

Mark as Accepted Risk

Fecha a vulnerabilidade como Accepted Risk. Nenhuma justificativa é enviada a partir do Jira.

Mark as Fixed, no retest

Fecha a vulnerabilidade como Fixed sem reteste. Nos relatórios, aparece como não verificada pela Strike.

A Strike sugere um valor padrão para cada status de acordo com a categoria dele no Jira (To Do, In Progress ou Done). Cada linha também mostra qual status da Strike chega ali, para que você veja os dois sentidos antes de escolher.

Tirar um issue de um status que declara um fix reabre a vulnerabilidade na Strike e cancela o reteste, se ele ainda não tiver começado.

Quando o reteste termina, a Strike atualiza o issue: se o fix for confirmado, a vulnerabilidade é fechada; se a vulnerabilidade ainda estiver lá, a Strike reabre o issue com um comentário que explica o motivo.

Desconectar a integração

Você pode desconectar a integração pela mesma tela. Os issues que a Strike já criou permanecem no seu Jira sem alterações. A Strike deixa de criar novos issues e de atualizar os existentes até que você conecte novamente.

Perguntas frequentes

Quais vulnerabilidades chegam ao Jira?

Apenas as confirmadas. As que ainda estão pendentes de triagem e as descartadas não geram nenhum issue.

A Strike pode sobrescrever as alterações que minha equipe faz em um issue?

Não. A Strike escreve apenas os campos que pertencem a ela. As etiquetas, o responsável, a data de entrega, os campos personalizados e os comentários adicionados pela sua equipe são preservados a cada atualização.

Posso enviar vulnerabilidades diferentes para projetos diferentes do Jira?

Sim, criando um destino para cada um. Se uma vulnerabilidade se encaixar em mais de um destino, vence o mais específico.

Por que uma vulnerabilidade fechada pelo Jira aparece como não verificada nos relatórios?

Porque a Strike não fez o reteste dela. É o mesmo comportamento de quando você fecha uma vulnerabilidade como Fixed diretamente na plataforma, sem pedir um reteste. Se você prefere que ela fique verificada, use a opção Fix claimed · Strike retests em vez de Mark as Fixed, no retest.