Cómo configurar una Change-based Threat Emulation
Last updated: October 16, 2026
Una Change-based Threat Emulation es una Threat Emulation de tipo Change-based: se ejecuta automáticamente cuando hay cambios en los repositorios que elijas. Te ayuda a acortar el tiempo entre un deploy y su validación, para que ningún cambio relevante quede sin revisar hasta la próxima ejecución recurrente.
Cómo funciona
Cuando configuras una Change-based Threat Emulation, Strike escucha los eventos de los repositorios que seleccionaste. Cada vez que se cumple el trigger que elegiste, se genera una ejecución: el agente de IA de Strike testea los assets de la Threat Emulation, enfocado en los cambios incluidos.
Automática: se ejecuta sola, no tienes que lanzarla cada vez.
Enfocada en los cambios: cada ejecución se centra en el pull request o release que la disparó.
Configurable: eliges si se ejecuta por cada pull request o por cada release.
Los repositorios definen qué cambios disparan una ejecución, pero no modifican el scope de la Threat Emulation: la ejecución se hace sobre los assets que incluiste en el paso de Scoping.
Strike no accede al contenido de tu código. La integración con GitHub tiene permisos de solo lectura sobre los metadatos de los repositorios y los pull requests, y recibe los eventos por webhooks. No puede modificar tus repositorios.
Opciones de trigger
Opción | Cuándo se ejecuta |
|---|---|
Per pull request | Cada vez que se hace merge de un pull request a la rama principal. |
Per release | Cada vez que se publica un release nuevo. |
Antes de empezar
Tener rol de Owner u Operator en la organización de Strike.
Tener acceso de admin a la organización de GitHub donde está tu código, si todavía no conectaste GitHub en Strike.
Cómo configurarla
Crea una Threat Emulation y define su scope. Para más detalle, consulta Cómo crear una Threat Emulation.
En el paso Test configuration, elige Change-based.
Si GitHub todavía no está conectado, haz clic en Connect GitHub y luego en Continue with GitHub. En GitHub, da acceso a todos los repositorios que Strike pueda necesitar. La conexión se hace una sola vez a nivel organización.
Selecciona los repositorios que quieres monitorear.
En Test trigger, elige Per pull request o Per release.
Opcional: completa Additional information con detalles importantes sobre tu scope.
Haz clic en Confirm & enable.
Desde ese momento, la Threat Emulation queda escuchando los cambios en los repositorios seleccionados.
Créditos
Cada ejecución Change-based consume un valor fijo de créditos, que es el mismo para pull requests y releases. No depende del tamaño del cambio. Al configurarla, la plataforma te muestra ese valor por ejecución.
El consumo total depende de cuántos pull requests o releases se generen en tus repositorios. Los créditos salen del mismo plan que el resto de tus Threat Emulations.
Si tu plan se queda sin créditos, las ejecuciones se pausan hasta que sumes créditos. Para sumar créditos, contacta a tu Customer Success Manager.
Para más detalle, consulta Créditos: qué son y cómo se consumen.
Preguntas frecuentes
¿Necesito involucrar al equipo de desarrollo para configurarla?
No necesariamente. Si tienes acceso de admin a la organización de GitHub, puedes completar todo el setup tú mismo.
¿Strike puede ver o modificar mi código?
No. La integración tiene permisos de solo lectura sobre metadatos de repositorios y pull requests. No accede al contenido del código ni puede modificarlo.
¿Tengo que conectar GitHub cada vez que creo una Threat Emulation?
No. La conexión se hace una sola vez a nivel organización. En cada Threat Emulation solo eliges qué repositorios monitorear.
¿Puedo monitorear varios repositorios en una misma Threat Emulation?
Sí. Puedes seleccionar todos los repositorios que correspondan.
¿Un pull request grande consume más créditos que uno chico?
No. Cada ejecución consume el mismo valor fijo, sin importar el tamaño del cambio.
¿Puedo elegir la profundidad o definir restricciones?
No. En una Change-based Threat Emulation solo eliges los repositorios, el trigger y, si quieres, información adicional.
¿Solo se integra con GitHub?
Por ahora sí. Si usas otra herramienta, como GitLab o Jenkins, contacta a tu Customer Success Manager para que sumemos tu caso a la priorización.