Cómo configurar Change-Based Testing en un asset
Last updated: May 13, 2026
Change-Based Testing detecta automáticamente los cambios de código en los repositorios vinculados a un asset y dispara una ejecución focalizada en esos cambios. Te ayuda a cerrar la brecha que se abre entre cómo evoluciona tu asset y cuándo se valida, incluyendo casos como acortar el tiempo entre un deploy y su testing, o asegurar que ningún cambio relevante quede sin revisar hasta el próximo ciclo recurrente.
⚠ Disponibilidad: Change-Based Testing es un add-on del producto. Para tenerlo disponible es necesario contratar una bolsa de testing units (también llamadas ejecuciones puntuales), que es la misma que se utiliza para los Focused Tests. Si no tienes el add-on contratado, no vas a ver el flujo de integración en el asset configuration. Para activarlo, contacta a tu Customer Success Manager.
Qué es Change-Based Testing
Hasta ahora, la validación de seguridad sobre un asset en Strike funcionaba a través de las threat emulations: ejecuciones continuas, automáticas y recurrentes que se nutren del asset context.
El asset context es la base sobre la que se ejecuta toda la validación. Pero el asset evoluciona constantemente: cada deploy, cada PR, cada release introduce cambios que pueden quedar sin validar hasta el próximo ciclo recurrente. Esa brecha entre cómo cambia tu asset y cuándo se testea puede traducirse en nuevas vulnerabilidades o en áreas nuevas que pasan semanas sin revisión.
Para cerrar esa brecha creamos los Change-Based Tests: ejecuciones automáticas que se disparan cuando hay cambios en los repositorios vinculados al asset, focalizadas en esos cambios. Strike detecta lo que cambió y valida ese delta sin que tengas que intervenir, complementando el ciclo recurrente con validaciones puntuales en el momento exacto en que aparecen los cambios.
Automático: se dispara solo, no tienes que pedirlo cada vez.
Change-scoped: la prueba se enfoca en los PRs o releases que generaron el evento.
Configurable: tú decides cuándo se dispara, por PR, por release o agrupando una vez por semana.
Independiente: no afecta ni pausa el ciclo de threat emulations recurrentes.
Cómo funciona
Cuando configuras Change-Based Testing en un asset, Strike instala una GitHub App que escucha eventos en los repositorios vinculados. Cada vez que se dispara el trigger que elegiste, Strike ejecuta una threat emulation focalizada en los cambios incluidos.
El resultado es una ejecución enfocada en el scope acotado de lo que cambió. Las vulnerabilidades quedan vinculadas a los PRs que las introdujeron, así sabes exactamente qué cambio las generó y puedes cerrar la brecha entre el deploy y su validación.
ℹ Strike no accede al contenido de tu código. La GitHub App tiene permisos de solo lectura sobre metadatos: título del PR, autor, fecha, archivos modificados. No puede leer, modificar ni descargar el código de tus repositorios.
Opciones de trigger
Tienes tres formas de configurar cuándo se dispara la ejecución, según el flujo de tu equipo:
Opción | Cuándo se dispara | Consumo |
|---|---|---|
Per pull request | Cada vez que un PR se mergea a la rama principal. | 1 ejecución por PR mergeado. |
Per release | Cada vez que se publica un release nuevo. | 1 ejecución por release publicado. |
Weekly batch | Una vez por semana, agrupando todos los PRs mergeados durante la ventana. | 1 ejecución por semana, solo si hubo PRs. |
Change-Based Tests vs. threat emulations
Ambos tipos de ejecución usan el mismo AI Pentester engine y la misma configuración del asset, pero tienen ciclos de vida y propósitos distintos. Las threat emulations ejecutan validación continua según un calendario fijo, mientras que Change-Based Testing reacciona a eventos del código para acortar la ventana entre deploy y validación.
Atributo | Threat emulations | Change-Based Tests |
|---|---|---|
Trigger | Automático (calendario) | Automático (eventos de GitHub) |
Frecuencia | Recurrente, continuo | Una ejecución por evento (o por batch semanal) |
Scope | Driven by asset context | Focalizado en cambios de código |
Profundidad | Análisis completo y profundo | Validación enfocada y optimizada |
Propósito | Validación continua | Cerrar la ventana entre deploy y testing |
Engine | AI Pentester | AI Pentester |
Configuración del asset | Misma | Misma |
Bolsa de consumo | Plan base de recurrencia | Bolsa de testing units (compartida con Focused Tests) |
Cuándo usar cada una
Threat emulations son tu capa continua de validación: déjalas activas para mantener visibilidad permanente sobre el riesgo del asset.
Change-Based Testing es tu herramienta para acortar la ventana de exposición: úsalo cuando tienes deploys frecuentes y quieres que cada cambio relevante se valide cerca del momento en que se introduce.
No es uno u otro. Los Change-Based Tests complementan a las threat emulations recurrentes, no las reemplazan. Lo ideal es tener ambos activos: la cobertura periódica completa, más una validación rápida en cada cambio.
Cómo configurar Change-Based Testing
Antes de empezar
Tener el add-on contratado y testing units disponibles en tu cuenta.
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.
Paso 1: Ir a la configuración del asset
Desde el listado de assets, selecciona el asset sobre el que quieres activar la feature. Dentro del asset, en la tab Configuration, busca la sección Change-based testing. Si todavía no lo activaste en ningún otro asset, vas a ver el botón Connect GitHub.
Paso 2: Conectar GitHub
Haz clic en Connect GitHub. Se abre una pestaña nueva de GitHub donde tienes que:
Seleccionar la organización donde se va a instalar la GitHub App de Strike.
Seleccionar los repositorios a los que Strike va a tener acceso (puede ser todos o un subset específico para un asset).
Confirmar la instalación. GitHub te redirige automáticamente de nuevo al asset en Strike.
ℹ Una sola vez por organización. La instalación de la GitHub App se hace una vez por organización de GitHub. Si después quieres activar Change-Based Testing en otros assets que apuntan a la misma organización, el Paso 2 ya va a estar marcado como ✓ Connected y vas a saltar directo al Paso 3.
Paso 3: Vincular repositorios y elegir trigger
Una vez conectada la GitHub App, se habilita debajo el botón Set Up. Aquí vas a definir:
Repositorios: selecciona los repositorios que corresponden a este asset. Puedes vincular más de uno si tu asset depende de múltiples repos.
Test trigger: elige entre Per pull request, Per release o Weekly batch (configurando día, hora y timezone para este último).
Haz clic en Confirm and Enable y listo: el asset queda escuchando los cambios.
Paso 4: Verificar que está funcionando
Cuando el asset queda en estado Enabled, vas a ver:
En la lista de assets: un ícono verde 🔄 que indica Listening for changes in repositories.
En el overview del asset: una sección que te muestra la información de la funcionalidad activa (ejecuciones disponibles, contador de PRs en batch, repositorios vinculados, etc.).
Al hacer clic en la sección, el detalle de cada PR pendiente: título, autor, fecha, líneas cambiadas y próxima ejecución estimada.
Paso 5: Revisar los resultados
Las ejecuciones change-based aparecen en la tabla de threat emulations identificadas con un tag de Change-Based. Haz clic en una ejecución para ver el detalle:
Resumen de la ejecución (duración, scope, repos vinculados).
Tab PRs tested con la lista completa de los PRs incluidos, cada uno con título, autor, líneas cambiadas y link directo a GitHub.
Hallazgos (vulnerabilidades, evidencias y severidad), vinculados al contexto de los cambios concretos que las introdujeron.
ℹ Las ejecuciones change-based pasan por triage del equipo de Strike, igual que cualquier otra threat emulation. Los hallazgos que ves ya están validados.
Estados de la feature por asset
Estado | Indicador | Qué significa |
|---|---|---|
Disabled | Sin ícono / Gris | La feature no está configurada en este asset. |
Enabled | Verde + Enabled | Activo, escuchando cambios en los repos vinculados. |
Paused | Rojo + Paused | Sin testing units disponibles. Los cambios se detectan pero no se disparan tests. |
Plan y consumo
Change-Based Testing es un add-on que se contrata sobre el plan base. Tres conceptos para entender cómo se factura:
Add-on: se vende como un complemento separado de la recurrencia base de tu asset. Tu testing recurrente sigue funcionando como siempre; esta feature suma cobertura, no la reemplaza.
Activación por asset: cada asset puede tener la feature activa o no. La integración con GitHub se hace una sola vez a nivel organización; en cada asset solo vinculas los repos que correspondan.
Bolsa compartida: cada ejecución consume 1 testing unit de la bolsa de ejecuciones puntuales. Esa bolsa se comparte con Focused Tests, así que el consumo se descuenta del mismo pool.
Puedes ver el saldo disponible de tu bolsa desde la página Plan & Usage de tu organización. Para sumar más ejecuciones o ajustar tu plan, contacta a tu Customer Success Manager.
Preguntas frecuentes
¿Necesito involucrar al equipo de desarrollo para configurar esto?
No necesariamente. Si tienes acceso de admin a la organización de GitHub, puedes completar todo el setup tú mismo. Tarda menos de 10 minutos.
¿Strike puede ver o modificar mi código?
No. La GitHub App tiene permisos de solo lectura sobre metadatos de PRs (título, autor, fecha, archivos modificados). No accede al contenido del código ni se mete en tu pipeline de CI/CD.
¿Puedo vincular varios repositorios a un mismo asset?
Sí. Un asset puede tener múltiples repos vinculados; los PRs de todos ellos se monitorean y se incluyen en los batches.
¿Un repositorio puede estar vinculado a varios assets?
Sí. Si un repo afecta múltiples assets, vincúlalo a cada uno. Un PR en ese repo dispara tests en todos los assets vinculados.
¿Cómo sé qué PR introdujo una vulnerabilidad?
En el detalle de la threat emulation, la tab PRs tested muestra todos los PRs incluidos. Las vulnerabilidades quedan en el contexto de esos cambios específicos.
¿Las vulnerabilidades de change-based pasan por triage del equipo de Strike?
Sí. Igual que cualquier otra threat emulation, el equipo de Strike revisa y valida los hallazgos antes de mostrarlos como confirmados.
¿Cómo se consumen las ejecuciones de Change-Based Testing?
Cada ejecución consume 1 testing unit de la bolsa de ejecuciones puntuales asociada a tu cuenta. Esta bolsa es compartida con Focused Tests, por lo que el consumo se descuenta del mismo pool. Puedes ver el saldo disponible desde la página Plan & Usage de tu organización.
¿Qué pasa si coincide una ejecución scheduled y una change-based el mismo día?
Ambas se ejecutan en paralelo. La recurrente consume del plan base de recurrencia; la change-based consume de la bolsa de testing units. No hay deduplicación automática: son dos tests con propósitos distintos.
¿Qué pasa si desvinculo un repositorio?
El repo deja de ser monitoreado y los PRs pendientes de ese repo se eliminan del batch. El historial de ejecuciones anteriores se mantiene visible y los hallazgos asociados siguen disponibles en el asset.
¿Qué pasa si se desinstala la GitHub App desde GitHub?
Todos los assets que dependían de esa organización pierden la conexión y pasan a estado Disabled. Para reactivar la feature hay que volver a instalar la app y reconfigurar el vínculo de repos.
¿Qué pasa si se me agota la bolsa de testing units?
La feature pasa al estado Paused. Los PRs se siguen detectando y acumulando, pero los tests no se disparan hasta renovar o ampliar la bolsa. Las threat emulations recurrentes no se ven afectadas; siguen ejecutándose con el plan base. Cuando se suman nuevas units, la feature se reactiva automáticamente. Para sumar más ejecuciones, contacta a tu Customer Success Manager.
¿Solo se integra con GitHub? ¿Hay soporte para GitLab, Jenkins u otros?
Por ahora la integración disponible es con GitHub. Estamos sumando soporte para otras plataformas (GitLab, Jenkins, etc.) de forma incremental, según las necesidades de los clientes. Si usas otra herramienta y te interesa esta feature, contacta a tu Customer Success Manager para que sumemos tu caso a la priorización.