Créditos: qué son y cómo se consumen
Last updated: October 14, 2026
Tu plan de Strike se mide en créditos. Cada ejecución consume créditos de tu plan. Cuántos consume depende del tipo de testing que configuraste.
Tipos de testing y cómo consume cada uno
Al configurar una Threat Emulation eliges entre tres tipos de testing. Todos consumen créditos del mismo plan:
Tipo de testing | Qué hace | Cómo consume créditos |
|---|---|---|
Full Security | Testea toda la superficie incluida en el scope, con la recurrencia que configuraste | Según los paths en scope, la profundidad y la cantidad de ejecuciones por año |
Focused Test | Ejecuta un test puntual sobre un objetivo específico | Cada ejecución consume créditos |
Change-Based Testing | Se ejecuta automáticamente cuando hay cambios en tu repositorio | Un valor fijo por cada ejecución que dispara un PR o un release |
Full Security
El consumo se calcula con tres variables:
Paths en scope × profundidad × ejecuciones por año
Paths en scope: la cantidad de paths incluidos en la Threat Emulation. Si excluyes paths, el consumo baja.
Profundidad: Medium multiplica por 1 y Deep multiplica por 2.
Ejecuciones por año: dependen de la recurrencia. Mensual equivale a 12 ejecuciones por año, trimestral a 4 y semestral a 2.
Ejemplo: una Threat Emulation con 40 paths en scope, profundidad Deep y recurrencia trimestral consume 40 × 2 = 80 créditos por ejecución, es decir 320 créditos por año.
Human Hacking. Si activas el switch Human Hacking, cada ejecución suma una revisión humana (human review), que tiene un valor fijo en créditos. Ese valor se multiplica por la cantidad de ejecuciones por año. Por ejemplo, con recurrencia mensual, en How it is calculated verás × 12 human reviews.
Focused Test
Un Focused Test es una ejecución puntual, no recurrente. Consume créditos cada vez que lo ejecutas, del mismo plan que el resto de tus Threat Emulations.
Change-Based Testing
Con Change-Based Testing, cada cambio en tu repositorio dispara una ejecución según el trigger que configuraste: por cada PR o por cada release.
Cada ejecución consume un valor fijo de créditos, que es el mismo para PR y para release. No depende del tamaño del cambio: un PR chico y uno grande consumen lo mismo. Al configurarlo, la plataforma te muestra ese valor por ejecución.
Por eso, el consumo total en un período depende de cuántos PR o releases se generen en tu repositorio. Los créditos salen del mismo plan que el resto de tus Threat Emulations, no de una bolsa aparte.
Otros módulos y servicios
Además de las Threat Emulations, estos módulos y servicios también consumen créditos de tu plan:
Strike Cloud: al activar el módulo se descuenta una cantidad de créditos una vez por año.
Projects: consumen créditos según la cantidad de horas de pentesting manual que se acuerden para cada proyecto.
Dónde ver tus créditos
Al configurar una Threat Emulation. Mientras defines el scope, el tipo de testing, la profundidad y la recurrencia, la plataforma muestra una estimación de consumo que se recalcula con cada cambio. En How it is calculated puedes ver el detalle del cálculo.
En la sección de tu plan, en Settings. Ahí ves:
El total de créditos de tu plan y las fechas de vigencia.
Los créditos disponibles, los proyectados (lo que ya está programado) y los consumidos.
El consumo desglosado por tipo de test o por Threat Emulation.
Cuándo se consumen
En las Threat Emulations, los créditos se consumen cuando el agente de IA de Strike empieza la ejecución. Crear o configurar una Threat Emulation no consume créditos.
Acción | ¿Consume créditos? |
|---|---|
Ejecución programada de Full Security | Sí |
Human Hacking activado | Sí, una human review por ejecución |
Ejecución adicional fuera de la recurrencia | Sí |
Focused Test | Sí |
Ejecución de Change-Based Testing | Sí |
Ejecución cancelada | Sí |
Activación de Strike Cloud | Sí, una vez por año |
Projects | Sí, según las horas acordadas |
Pre-flight Check | No |
Retest automático | No |
Qué pasa si te quedas sin créditos
Si tu plan se queda sin créditos, las Threat Emulations se pausan automáticamente y la plataforma muestra un mensaje. Para retomar el testing, contacta a tu CSM para sumar créditos a tu plan.
Preguntas frecuentes
¿Por qué una Threat Emulation consume más créditos que otra?
Depende del tipo de testing. En Full Security, el consumo depende de la cantidad de paths en scope, la profundidad, la recurrencia y si tiene Human Hacking activado. En Change-Based Testing, depende de cuántos PR o releases disparan ejecuciones.
¿Cómo puedo reducir el consumo?
En Full Security puedes excluir paths del scope, elegir profundidad Medium o usar una recurrencia menos frecuente. Los cambios aplican desde la próxima ejecución.
¿Change-Based Testing tiene créditos propios?
No. Consume del mismo plan que el resto de tus Threat Emulations.
¿El Pre-flight Check consume créditos?
No. Los créditos se consumen recién cuando empieza la ejecución.
Si cancelo una ejecución, ¿recupero los créditos?
No. Los créditos de una ejecución cancelada se consumen igual. Para más detalle, consulta Cómo pausar una Threat Emulation o cancelar una ejecución.