Como configurar Change-Based Testing em um asset

O Change-Based Testing detecta automaticamente as mudanças de código nos repositórios vinculados a um asset e dispara uma execução focada nessas mudanças. Ele ajuda a fechar a brecha que se abre entre a evolução do seu asset e o momento em que ele é validado, incluindo casos como reduzir o tempo entre um deploy e o teste correspondente, ou garantir que nenhuma mudança relevante fique sem revisão até o próximo ciclo recorrente.

⚠ Disponibilidade: Change-Based Testing é um add-on do produto. Para tê-lo disponível, é necessário contratar um pacote de testing units (também chamadas de execuções pontuais), que é o mesmo utilizado pelos Focused Tests. Se você não tiver o add-on contratado, o fluxo de integração não vai aparecer no asset configuration. Para ativá-lo, entre em contato com o seu Customer Success Manager.

O que é Change-Based Testing

Até agora, a validação de segurança sobre um asset na Strike funcionava por meio das threat emulations: execuções contínuas, automáticas e recorrentes que se baseiam no asset context.

O asset context é a base sobre a qual toda a validação é executada. Mas o asset evolui constantemente: cada deploy, cada PR, cada release introduz mudanças que podem ficar sem validar até o próximo ciclo recorrente. Essa brecha entre a forma como o seu asset muda e o momento em que é testado pode se traduzir em novas vulnerabilidades ou em novas áreas que ficam semanas sem revisão.

Para fechar essa brecha, criamos os Change-Based Tests: execuções automáticas que são disparadas quando há mudanças nos repositórios vinculados ao asset, focadas nessas mudanças. A Strike detecta o que mudou e valida esse delta sem que você precise intervir, complementando o ciclo recorrente com validações pontuais no momento exato em que as mudanças aparecem.

• Automático: é disparado sozinho, você não precisa pedir toda vez.

• Change-scoped: o teste foca nos PRs ou releases que geraram o evento.

• Configurável: você decide quando é disparado, por PR, por release ou agrupando uma vez por semana.

• Independente: não afeta nem pausa o ciclo das threat emulations recorrentes.

Como funciona

Quando você configura Change-Based Testing em um asset, a Strike instala um GitHub App que escuta eventos nos repositórios vinculados. Cada vez que o trigger que você escolheu é acionado, a Strike executa uma threat emulation focada nas mudanças incluídas.

O resultado é uma execução focada no scope restrito do que mudou. As vulnerabilidades ficam vinculadas aos PRs que as introduziram, então você sabe exatamente qual mudança as gerou e pode fechar a brecha entre o deploy e a validação.

ℹ A Strike não acessa o conteúdo do seu código. O GitHub App tem permissões de somente leitura sobre os metadados: título do PR, autor, data, arquivos modificados. Ele não pode ler, modificar nem baixar o código dos seus repositórios.

Opções de trigger

Você tem três formas de configurar quando a execução é disparada, conforme o fluxo da sua equipe:

Change-Based Tests vs. threat emulations

Os dois tipos de execução usam o mesmo AI Pentester engine e a mesma configuração do asset, mas têm ciclos de vida e propósitos diferentes. As threat emulations executam validação contínua segundo um calendário fixo, enquanto o Change-Based Testing reage a eventos do código para reduzir a janela entre deploy e validação.

Quando usar cada um

• Threat emulations são a sua camada contínua de validação: deixe-as ativas para manter visibilidade permanente sobre o risco do asset.

• Change-Based Testing é a sua ferramenta para reduzir a janela de exposição: use-o quando você tem deploys frequentes e quer que cada mudança relevante seja validada perto do momento em que é introduzida.

• Não é um ou outro. Os Change-Based Tests complementam as threat emulations recorrentes, não as substituem. O ideal é manter os dois ativos: a cobertura periódica completa, mais uma validação rápida em cada mudança.

Como configurar Change-Based Testing

Antes de começar

• Ter o add-on contratado e testing units disponíveis na sua conta.

• Ter role de Owner ou Operator na organização da Strike.

• Ter acesso de admin à organização do GitHub onde está o seu código.

Passo 1: Acessar a configuração do asset

A partir da lista de assets, selecione o asset no qual você quer ativar a feature. Dentro do asset, na tab Configuration, encontre a seção Change-based testing. Se você ainda não ativou em nenhum outro asset, vai ver o botão Connect GitHub.

Passo 2: Conectar o GitHub

Clique em Connect GitHub. Abre uma nova aba do GitHub onde você precisa:

• Selecionar a organização onde o GitHub App da Strike será instalado.

• Selecionar os repositórios aos quais a Strike terá acesso (pode ser todos ou um subset específico para um asset).

• Confirmar a instalação. O GitHub te redireciona automaticamente de volta ao asset na Strike.

ℹ Uma única vez por organização. A instalação do GitHub App é feita uma vez por organização do GitHub. Se depois você quiser ativar Change-Based Testing em outros assets que apontam para a mesma organização, o Passo 2 já vai estar marcado como ✓ Connected e você vai pular direto para o Passo 3.

Passo 3: Vincular repositórios e escolher o trigger

Uma vez conectado o GitHub App, o botão Set Up é habilitado abaixo. Aqui você vai definir:

• Repositórios: selecione os repositórios que correspondem a este asset. Você pode vincular mais de um se o seu asset depende de múltiplos repos.

• Test trigger: escolha entre Per pull request ou Per release.

Clique em Confirm and Enable e pronto: o asset fica escutando as mudanças.

Passo 4: Verificar que está funcionando

Quando o asset entra no estado Enabled, você verá:

• Na lista de assets: um ícone verde 🔄 indicando Listening for changes in repositories.

• No overview do asset: uma seção mostrando as informações da funcionalidade ativa (execuções disponíveis, contador de PRs no batch, repositórios vinculados, etc.).

• Ao clicar na seção, o detalhe de cada PR pendente: título, autor, data, linhas alteradas e próxima execução estimada.

Passo 5: Revisar os resultados

As execuções change-based aparecem na tabela de threat emulations identificadas com uma tag de Change-Based. Clique em uma execução para ver o detalhe:

• Resumo da execução (duração, scope, repos vinculados).

• Tab PRs tested com a lista completa dos PRs incluídos, cada um com título, autor, linhas alteradas e link direto para o GitHub.

• Findings (vulnerabilidades, evidências e severidade), vinculados ao contexto das mudanças concretas que as introduziram.

ℹ As execuções change-based passam por triage do time da Strike, igual a qualquer outra threat emulation. Os findings que você vê já estão validados.

Estados da feature por asset

Plano e consumo

Change-Based Testing é um add-on contratado sobre o plano base. Três conceitos para entender como é faturado:

• Add-on: vendido como um complemento separado da recorrência base do seu asset. O seu testing recorrente continua funcionando como sempre; esta feature soma cobertura, não a substitui.

• Ativação por asset: cada asset pode ter a feature ativa ou não. A integração com o GitHub é feita uma única vez no nível da organização; em cada asset você apenas vincula os repos correspondentes.

• Pacote compartilhado: cada execução consome 1 testing unit do pacote de execuções pontuais. Esse pacote é compartilhado com Focused Tests, então o consumo é descontado do mesmo pool.

Você pode ver o saldo disponível do seu pacote na página Plan & Usage da sua organização. Para adicionar mais execuções ou ajustar o seu plano, entre em contato com o seu Customer Success Manager.

Perguntas frequentes

Preciso envolver o time de desenvolvimento para configurar isso?

Não necessariamente. Se você tem acesso de admin à organização do GitHub, pode completar todo o setup sozinho. Leva menos de 10 minutos.

A Strike pode ver ou modificar o meu código?

Não. O GitHub App tem permissões de somente leitura sobre metadados de PRs (título, autor, data, arquivos modificados). Ele não acessa o conteúdo do código nem interfere no seu pipeline de CI/CD.

Posso vincular vários repositórios a um mesmo asset?

Sim. Um asset pode ter múltiplos repos vinculados; os PRs de todos eles são monitorados e incluídos nos batches.

Um repositório pode estar vinculado a vários assets?

Sim. Se um repo afeta múltiplos assets, vincule-o a cada um. Um PR nesse repo dispara testes em todos os assets vinculados.

Como sei qual PR introduziu uma vulnerabilidade?

No detalhe da threat emulation, a tab PRs tested mostra todos os PRs incluídos. As vulnerabilidades ficam no contexto dessas mudanças específicas.

As vulnerabilidades de change-based passam por triage do time da Strike?

Sim. Igual a qualquer outra threat emulation, o time da Strike revisa e valida os findings antes de exibi-los como confirmados.

Como são consumidas as execuções de Change-Based Testing?

Cada execução consome 1 testing unit do pacote de execuções pontuais associado à sua conta. Esse pacote é compartilhado com Focused Tests, então o consumo é descontado do mesmo pool. Você pode ver o saldo disponível na página Plan & Usage da sua organização.

O que acontece se coincidirem uma execução scheduled e uma change-based no mesmo dia?

As duas são executadas em paralelo. A recorrente consome do plano base de recorrência; a change-based consome do pacote de testing units. Não há deduplicação automática: são dois testes com propósitos diferentes.

O que acontece se eu desvincular um repositório?

O repo deixa de ser monitorado e os PRs pendentes desse repo são removidos do batch. O histórico de execuções anteriores permanece visível e os findings associados continuam disponíveis no asset.

O que acontece se o GitHub App for desinstalado a partir do GitHub?

Todos os assets que dependiam dessa organização perdem a conexão e passam para o estado Disabled. Para reativar a feature, é preciso reinstalar o app e reconfigurar o vínculo dos repos.

O que acontece se acabarem as testing units?

A feature passa para o estado Paused. Os PRs continuam sendo detectados e acumulados, mas os testes não são disparados até renovar ou ampliar o pacote. As threat emulations recorrentes não são afetadas; continuam rodando com o plano base. Quando novas units são adicionadas, a feature é reativada automaticamente. Para adicionar mais execuções, entre em contato com o seu Customer Success Manager.

Só integra com o GitHub? Há suporte para GitLab, Jenkins ou outros?

Por enquanto, a integração disponível é com o GitHub. Estamos adicionando suporte para outras plataformas (GitLab, Jenkins, etc.) de forma incremental, conforme as necessidades dos clientes. Se você usa outra ferramenta e tem interesse nesta feature, entre em contato com o seu Customer Success Manager para que possamos adicionar o seu caso à priorização.