Créditos: o que são e como são consumidos
Last updated: October 14, 2026
O seu plano da Strike é medido em créditos. Cada execução consome créditos do seu plano. Quantos créditos ela consome depende do tipo de testing que você configurou.
Tipos de testing e como cada um consome
Ao configurar uma Threat Emulation, você escolhe entre três tipos de testing. Todos consomem créditos do mesmo plano:
Tipo de testing | O que faz | Como consome créditos |
|---|---|---|
Full Security | Testa toda a superfície incluída no scope, com a recorrência que você configurou | De acordo com os paths no scope, a profundidade e a quantidade de execuções por ano |
Focused Test | Executa um teste pontual em um alvo específico | Cada execução consome créditos |
Change-Based Testing | É executado automaticamente quando há mudanças no seu repositório | Um valor fixo por cada execução disparada por um PR ou um release |
Full Security
O consumo é calculado com três variáveis:
Paths no scope × profundidade × execuções por ano
Paths no scope: a quantidade de paths incluídos na Threat Emulation. Se você excluir paths, o consumo diminui.
Profundidade: Medium multiplica por 1 e Deep multiplica por 2.
Execuções por ano: dependem da recorrência. Mensal equivale a 12 execuções por ano, trimestral a 4 e semestral a 2.
Exemplo: uma Threat Emulation com 40 paths no scope, profundidade Deep e recorrência trimestral consome 40 × 2 = 80 créditos por execução, ou seja, 320 créditos por ano.
Human Hacking. Se você ativar o switch Human Hacking, cada execução soma uma revisão humana (human review), que tem um valor fixo em créditos. Esse valor é multiplicado pela quantidade de execuções por ano. Por exemplo, com recorrência mensal, em How it is calculated você verá × 12 human reviews.
Focused Test
Um Focused Test é uma execução pontual, não recorrente. Ele consome créditos cada vez que você o executa, do mesmo plano que o restante das suas Threat Emulations.
Change-Based Testing
Com o Change-Based Testing, cada mudança no seu repositório dispara uma execução de acordo com o trigger que você configurou: por cada PR ou por cada release.
Cada execução consome um valor fixo de créditos, que é o mesmo para PR e para release. Ele não depende do tamanho da mudança: um PR pequeno e um grande consomem a mesma quantidade. Ao configurar, a plataforma mostra esse valor por execução.
Por isso, o consumo total em um período depende de quantos PRs ou releases são gerados no seu repositório. Os créditos saem do mesmo plano que o restante das suas Threat Emulations, não de uma bolsa separada.
Outros módulos e serviços
Além das Threat Emulations, estes módulos e serviços também consomem créditos do seu plano:
Strike Cloud: ao ativar o módulo, uma quantidade de créditos é descontada uma vez por ano.
Projects: consomem créditos de acordo com a quantidade de horas de pentesting manual acordadas para cada projeto.
Onde ver seus créditos
Ao configurar uma Threat Emulation. Enquanto você define o scope, o tipo de testing, a profundidade e a recorrência, a plataforma mostra uma estimativa de consumo que é recalculada a cada mudança. Em How it is calculated você pode ver o detalhe do cálculo.
Na seção do seu plano, em Settings. Ali você vê:
O total de créditos do seu plano e as datas de vigência.
Os créditos disponíveis, os projetados (o que já está programado) e os consumidos.
O consumo detalhado por tipo de teste ou por Threat Emulation.
Quando os créditos são consumidos
Nas Threat Emulations, os créditos são consumidos quando o agente de IA da Strike inicia a execução. Criar ou configurar uma Threat Emulation não consome créditos.
Ação | Consome créditos? |
|---|---|
Execução programada de Full Security | Sim |
Human Hacking ativado | Sim, uma human review por execução |
Execução adicional fora da recorrência | Sim |
Focused Test | Sim |
Execução de Change-Based Testing | Sim |
Execução cancelada | Sim |
Ativação do Strike Cloud | Sim, uma vez por ano |
Projects | Sim, de acordo com as horas acordadas |
Pre-flight Check | Não |
Retest automático | Não |
O que acontece se os créditos acabarem
Se o seu plano ficar sem créditos, as Threat Emulations são pausadas automaticamente e a plataforma mostra uma mensagem. Para retomar o testing, entre em contato com o seu CSM para adicionar créditos ao seu plano.
Perguntas frequentes
Por que uma Threat Emulation consome mais créditos que outra?
Depende do tipo de testing. No Full Security, o consumo depende da quantidade de paths no scope, da profundidade, da recorrência e de o Human Hacking estar ativado ou não. No Change-Based Testing, depende de quantos PRs ou releases disparam execuções.
Como posso reduzir o consumo?
No Full Security, você pode excluir paths do scope, escolher a profundidade Medium ou usar uma recorrência menos frequente. As mudanças se aplicam a partir da próxima execução.
O Change-Based Testing tem créditos próprios?
Não. Ele consome do mesmo plano que o restante das suas Threat Emulations.
O Pre-flight Check consome créditos?
Não. Os créditos só são consumidos quando a execução começa.
Se eu cancelar uma execução, recupero os créditos?
Não. Os créditos de uma execução cancelada são consumidos da mesma forma. Para mais detalhes, consulte Como pausar uma Threat Emulation ou cancelar uma execução.