Certificación ISTQB Security Test Engineer (CT-STE): guía completa

La seguridad dejó de ser un tema exclusivo del equipo de ciberseguridad. Hoy cualquier equipo que libera software necesita a alguien que sepa probar autenticación, permisos, cifrado, dependencias de código abierto y configuraciones expuestas. Para ese perfil, ISTQB creó la Certified Tester Security Test Engineer (CT-STE). En esta guía te explico qué cubre, cómo es el examen y por dónde empezar si quieres certificarte.

Qué es la CT-STE y dónde está en el portafolio ISTQB

La CT-STE es una certificación del flujo Specialist de ISTQB, el grupo de certificaciones que profundiza en un tipo de prueba o en una industria concreta. Su syllabus oficial es la versión 1.0.1: la versión 1.0 se publicó el 18 de octubre de 2024 y la 1.0.1, con la revisión técnica final, el 31 de enero de 2025. ISTQB anunció su lanzamiento oficial en febrero de 2025.

Su enfoque es práctico. El propio syllabus aclara que existe un perfil complementario, el Security Test Analyst, que diseña las pruebas de seguridad que luego ejecuta el Security Test Engineer. Dicho de otra forma: el analista decide qué riesgos atacar y con qué estrategia; el ingeniero lo lleva a la práctica, con herramientas, entornos, evidencias y reportes.

Si vienes de la certificación anterior, la ISTQB Security Tester (CT-SEC) de 2016, te conviene leer la sección de relación entre ambas más abajo: ISTQB confirmó que no hay grandfathering (equivalencia automática) para quienes ya tienen la CT-SEC.

Si todavía estás ubicando el mapa completo de certificaciones, revisa nuestra guía de la certificación ISTQB, donde verás el portafolio, los costos en tu moneda y cómo funciona el examen.

Para quién es y requisitos previos

La CT-STE está pensada para personas que ya trabajan en pruebas o desarrollo y quieren especializarse en seguridad:

• QA testers y analistas de pruebas que ya hacen pruebas funcionales y quieren sumar pruebas de seguridad a su trabajo diario.
• Ingenieros de automatización que quieren integrar escáneres SAST, DAST o de composición de software (SCA) en sus pipelines.
• Desarrolladores que necesitan entender cómo se prueba la seguridad de lo que construyen.
• Personas de DevOps o infraestructura que validan hardening, firewalls y configuraciones.
• Líderes de QA que necesitan hablar el mismo idioma que el área de seguridad de la información.

Requisitos oficiales

• Obligatorio: tener la certificación ISTQB Foundation Level (CTFL) antes de presentar el examen.
• Recomendado: experiencia mínima en desarrollo, pruebas o pruebas de seguridad. ISTQB aclara que el conocimiento técnico o de programación no es obligatorio para el examen, aunque sí te facilita entender los ejemplos.
• No obligatorio: tomar un curso acreditado. Puedes prepararte por tu cuenta.

El syllabus no está limitado a una industria específica: aplica igual a banca, comercio electrónico, salud, gobierno o software empresarial.

Qué serás capaz de hacer: objetivos de negocio del syllabus

ISTQB define nueve business outcomes (resultados de negocio) para quien obtiene la CT-STE. En palabras simples, un Security Test Engineer certificado puede:

Contenido del syllabus CT-STE capítulo por capítulo

El syllabus tiene nueve capítulos examinables. Los tiempos son los mínimos que ISTQB exige a un curso acreditado; te sirven también para estimar cuánto estudiar cada tema.

Capítulo 1. Paradigmas de seguridad

Antes de probar, hay que saber qué proteger y cuánto. El capítulo arranca con los niveles de seguridad de los activos: no es lo mismo una página informativa que la base de datos de clientes o las llaves de cifrado. La sensibilidad de la información define la profundidad de las pruebas, sobre la tríada confidencialidad, integridad y disponibilidad.

Después explica el papel de las pruebas dentro de una auditoría de seguridad: la auditoría revisa que los controles existan y se cumplan; las pruebas aportan la evidencia técnica de que funcionan. También introduce Zero Trust (no confiar por defecto en nada, ni siquiera dentro de la red) y cómo aplicarlo al probar: por ejemplo, verificar que un microservicio interno rechace una llamada sin token válido aunque venga de otro servicio de la misma red.

Cierra con el software de código abierto: hoy la mayor parte de una aplicación son dependencias de terceros, y cada una puede traer vulnerabilidades conocidas. Ejemplo práctico: una librería de registro con una vulnerabilidad pública obliga a identificar qué sistemas la usan y a probar el parche.

Capítulo 2. Técnicas de pruebas de seguridad

Es el capítulo más técnico. Primero clasifica las pruebas según la información disponible: caja negra (atacas como un externo, sin conocer el código), caja blanca (con acceso al código y a la arquitectura) y caja gris (conocimiento parcial, por ejemplo con credenciales de un usuario normal). Luego distingue las pruebas estáticas (revisión de código, análisis estático, revisión de configuraciones) de las dinámicas (ejecutar el sistema y atacarlo).

La segunda parte baja a controles concretos:

• Gestión de identidades y accesos (IAM): pruebas de reconciliación (que las cuentas y permisos reales coincidan con los autorizados) y de recertificación (que los permisos se revisen periódicamente). Ejemplo: detectar que una persona que dejó la empresa hace tres meses sigue con acceso activo.
• Identificación, autenticación y autorización: probar contraseñas débiles, bloqueo de cuenta, MFA, y que un usuario no pueda ver datos de otro cambiando un ID en la URL.
• Cifrado: verificar que los datos viajen con TLS configurado correctamente y que la información sensible en reposo esté cifrada.
• Tecnologías de protección: hardening de sistemas, firewalls, detección de intrusos, escaneo de malware y ofuscación de datos (por ejemplo, que los ambientes de prueba no usen datos reales sin enmascarar).

Capítulo 3. El proceso de pruebas de seguridad

Aquí el syllabus toma el proceso de pruebas que ya conoces del Foundation Level (planeación, análisis, diseño, implementación, ejecución, monitoreo y control, cierre) y lo adapta a seguridad, indicando qué tareas corresponden a cada rol. Por ejemplo, en la ejecución el ingeniero corre pruebas funcionales de seguridad y pruebas de penetración; en el cierre se archivan resultados y datos sensibles en ubicaciones seguras.

También describe las características de un buen entorno de pruebas de seguridad: aislado de producción, representativo y autorizado. Después explica cómo diseñar pruebas por nivel: en componentes (por ejemplo, validar que una función sanitice entradas contra inyección SQL), en integración (que los servicios se autentiquen entre sí) y en sistema y aceptación, donde el objetivo K3 es implementar una prueba de extremo a extremo que valide requisitos de seguridad dentro de un proceso de negocio, como un flujo completo de recuperación de contraseña.

Capítulo 4. Estándares y buenas prácticas

Un Security Test Engineer no inventa la rueda: se apoya en catálogos reconocidos. El capítulo diferencia estándares (ISO, NIST) de buenas prácticas y profundiza en los recursos de facto del sector:

• OWASP: comunidad con guías y listas de riesgos para aplicaciones web y APIs.
• CAPEC: catálogo de patrones de ataque.
• CWE: catálogo de tipos de debilidades de software (por ejemplo, validación de entrada incorrecta).
• CVE: identificadores de vulnerabilidades públicas concretas.
• CVSS y CWSS: sistemas para calificar la severidad de vulnerabilidades y debilidades.

El objetivo K3 es aplicar estos recursos al probar. Ejemplo: tomas un hallazgo de tu escáner, lo relacionas con su CWE, revisas si existe un CVE asociado a la versión del componente y usas CVSS para priorizarlo. También verás cómo usar los estándares como oráculo de prueba y sus ventajas y desventajas, y la diferencia entre aplicarlos por obligación (regulación, contrato) o de forma voluntaria.

Capítulo 5. Ajustar las pruebas al contexto organizacional

Es uno de los dos capítulos con nivel K4 (analizar). Primero estudia cómo la estructura de la organización (tamaño, sector, proveedores, nube) cambia lo que hay que probar. Después aborda las regulaciones y su impacto en las políticas de seguridad, y cómo probar que esas políticas realmente se cumplen.

La parte más interesante es el análisis de escenarios de ataque: tipos de atacantes y sus motivaciones, y las fases típicas de un ataque (recolección de información, explotación y obtención de acceso, persistencia y borrado de huellas). Cierra con la respuesta a incidentes: preparación, detección y análisis, contención, erradicación y recuperación, y actividades posteriores. En el examen puedes encontrar un escenario y tener que identificar el origen y la motivación probables del ataque.

Capítulo 6. Ajustar las pruebas al ciclo de vida

La seguridad debe probarse durante todo el ciclo de vida, no solo al final. El capítulo compara cómo cambian las actividades en modelos secuenciales, en ágil (con principios como "desarrolladores y testers por encima de especialistas aislados" o "asegurar mientras trabajas, no al terminar") y en DevOps, donde las pruebas de seguridad se automatizan dentro del pipeline.

En operación y mantenimiento, el objetivo K3 es definir y ejecutar pruebas de regresión y de confirmación de seguridad después de un cambio. Ejemplo: tras actualizar el framework de autenticación, vuelves a correr las pruebas de sesión, expiración de tokens y control de acceso, además de confirmar que la vulnerabilidad corregida ya no se puede explotar.

Capítulo 7. Pruebas de seguridad como parte de un ISMS

Un ISMS (sistema de gestión de seguridad de la información, como el que describe ISO/IEC 27001) necesita datos para gestionar riesgos. Este capítulo explica cómo los criterios de aceptación de seguridad influyen en las técnicas que eliges, cómo los resultados de tus pruebas se convierten en insumo del ISMS y cómo puedes ayudar a madurarlo: sumando nuevos objetos de prueba, nuevos enfoques o mejor cobertura, y haciendo la seguridad más medible.

Capítulo 8. Reporte de resultados de pruebas de seguridad

Un hallazgo de seguridad es información sensible: si el reporte se filtra, se convierte en un manual para atacar. Por eso el capítulo empieza por la criticidad de los resultados y cómo manejarlos y comunicarlos. Luego enseña a evaluar resultados para identificar vulnerabilidades reales (descartando falsos positivos y ajustando el impacto al contexto) y a evaluar técnicas para cerrarlas: ocultar la vulnerabilidad (mitigación temporal, por ejemplo con una regla de firewall de aplicaciones) o evitarla (corregir la causa en el código o en la configuración).

Capítulo 9. Herramientas de pruebas de seguridad

El último capítulo clasifica las herramientas: de caja blanca, negra y gris; estáticas como SAST (análisis del código fuente) y SCA (análisis de componentes de terceros), y dinámicas como DAST (atacan la aplicación en ejecución) e IAST (instrumentan la aplicación mientras se prueba). También explica criterios para seleccionarlas, incluida la comparación entre herramientas de código abierto y comerciales. El syllabus no recomienda marcas: te enseña a elegir según tu necesidad.

Si ya automatizas pruebas, este capítulo conecta directo con lo que haces en el día a día. Puedes reforzar esa parte con nuestra guía de automatización de pruebas desde cero.

Descarga el syllabus oficial

Descarga el syllabus para estudiar con la fuente original. Al momento de escribir, ISTQB lo publica en inglés.

El examen CT-STE

Esta es la estructura oficial según las tablas de estructura de exámenes de ISTQB:

Fíjate en la distribución: más de un tercio de las preguntas son de aplicación o análisis. No basta con memorizar definiciones; vas a resolver escenarios.

Modalidades

• En línea con supervisión remota (iSQI FLEX): desde tu casa, 24/7. Necesitas cámara, micrófono, una segunda cámara (puede ser tu celular) e identificación oficial. Reserva con anticipación: iSQI pide al menos 2 horas para exámenes Foundation y 48 horas para los avanzados; confirma el plazo de este examen al reservar.
• Pearson VUE: en un centro de examen o en línea con OnVUE, según disponibilidad para este examen.
• En tu empresa: si son 6 personas o más, Cool Testers lleva un aplicador para presentar el examen presencial.

Ya no existe el examen en papel. Al momento de escribir, iSQI ofrece el examen CT-STE en inglés; por eso aplica el tiempo extra de 25 % si el inglés no es tu lengua materna. La certificación vale exactamente lo mismo en cualquier idioma.

Dónde comprarlo

• Directo en iSQI, nuestro partner y proveedor oficial de exámenes. Conviene si tú pagas.
• Con Cool Testers, con 1 o 2 oportunidades y 1 año para presentarlo. Conviene si lo paga tu empresa, te lo reembolsan o necesitas factura: compra o cotiza tu examen de certificación.

¿Dudas sobre qué opción te conviene? Escríbenos por WhatsApp.

Cómo prepararte para la CT-STE

Cool Testers no tiene por ahora un curso específico de CT-STE, así que te comparto la ruta que recomendamos:

1. Asegura tu base con Foundation Level. Es requisito y, además, el syllabus de seguridad reutiliza el proceso de pruebas, los niveles de prueba y las técnicas de CTFL. Si aún no la tienes, empieza por nuestro curso ISTQB Fundamentos (CTFL 4.0): 40 horas en vivo, curso pregrabado, Curso Express de repaso y 4 exámenes de práctica. Y revisa la guía de la certificación ISTQB para planear tu ruta.
2. Lee el syllabus completo una vez, sin tomar notas, para tener el mapa general.
3. Estudia por capítulo con el tiempo como guía. Los capítulos 4 y 5 son los más largos (195 minutos cada uno) y el 5 y el 6 tienen objetivos K4: dales más tiempo.
4. Practica con casos reales. Toma una aplicación de práctica intencionalmente vulnerable, revisa la lista OWASP Top 10, corre un escáner DAST en un entorno autorizado y clasifica los hallazgos con CWE y CVSS.
5. Haz el examen de muestra oficial que publica ISTQB y analiza por qué cada respuesta incorrecta es incorrecta.
6. Repasa el glosario: todas las palabras clave y términos de seguridad son examinables a nivel K1.

Si nunca has presentado un examen ISTQB, nuestra guía cómo aprobar el examen ISTQB Foundation te sirve para entender el estilo de las preguntas, y el simulador gratuito del examen Foundation te ayuda a medir tu nivel antes de dar el salto.

¿Necesitas preparar a un equipo de tu empresa en pruebas de seguridad? Solicita una propuesta de capacitación para empresas.

Beneficios y salidas profesionales

• Diferenciación clara: hay muchos QA funcionales y pocos que dominan pruebas de seguridad con un marco reconocido.
• Lenguaje común con seguridad de la información: CWE, CVSS, ISMS y respuesta a incidentes dejan de ser siglas ajenas.
• Encaja con DevSecOps: integrar SAST, SCA y DAST al pipeline es una necesidad creciente en equipos que liberan seguido.
• Reconocimiento internacional: ISTQB es el esquema de certificación en pruebas de software más extendido del mundo, útil si trabajas o quieres trabajar en proyectos para EE. UU. o Europa.

Roles donde aporta: QA con enfoque en seguridad, Security Test Engineer, ingeniero de automatización con responsabilidades de DevSecOps, analista de vulnerabilidades junior, o consultor de calidad en sectores regulados como banca y salud. Si estás buscando empleo, revisa nuestra guía de vacantes de QA tester remoto.

Relación con otras certificaciones y siguiente paso

CT-STE y CT-SEC

La Security Tester (CT-SEC) de 2016 combinaba varios roles y actividades en una sola certificación. Según ISTQB, la dividió en dos para distinguir mejor las responsabilidades: la CT-STE, centrada en la ejecución práctica de las pruebas de seguridad, y la CT-STA (Security Test Analyst), centrada en analizar riesgos de seguridad del negocio y definir estrategias de pruebas. ISTQB anunció la CT-STA para 2026; consulta istqb.org para conocer su estado. Quien ya tiene la CT-SEC no recibe la CT-STE automáticamente: debe presentar el examen.

Otras certificaciones que se complementan

• Technical Test Analyst (CTAL-TTA): profundiza en características técnicas de calidad, incluida la seguridad, y en técnicas de caja blanca.
• Quality in DevOps (CT-QDO): ideal si tus pruebas de seguridad viven en un pipeline de integración y entrega continuas.
• Test Automation Engineering (CTAL-TAE): para diseñar arquitecturas de automatización donde integrar herramientas de seguridad.
• Performance Testing (CT-PT): la disponibilidad también es seguridad; las pruebas de carga ayudan a entender la resistencia a ataques de denegación de servicio.

Preguntas frecuentes

¿Qué significa CT-STE?

Certified Tester Security Test Engineer. Es la certificación de ISTQB para profesionales que ejecutan pruebas de seguridad: aplican técnicas, montan entornos, usan herramientas, analizan vulnerabilidades y reportan resultados.

¿Necesito la certificación Foundation Level para presentar la CT-STE?

Sí. ISTQB exige tener la certificación Foundation Level (CTFL) antes de presentar el examen CT-STE. No es obligatorio tomar un curso acreditado.

¿Cuántas preguntas tiene el examen CT-STE y cuánto dura?

Tiene 40 preguntas con un total de 43 puntos; apruebas con 28 puntos (65 %). Dura 75 minutos, o 94 minutos si lo presentas en un idioma que no es tu lengua materna.

¿Necesito saber programar?

No es obligatorio. ISTQB indica que el conocimiento técnico no es requisito del examen, aunque una base en desarrollo o pruebas te ayuda a entender los ejemplos de código y herramientas.

¿La CT-STE reemplaza a la CT-SEC?

ISTQB dividió la CT-SEC de 2016 en dos certificaciones: Security Test Engineer (ejecución) y Security Test Analyst (estrategia y riesgo). No hay equivalencia automática: si tienes la CT-SEC y quieres la CT-STE, debes presentar el examen.

¿Puedo presentar el examen CT-STE en español?

Al momento de escribir, iSQI lo ofrece en inglés, con 25 % de tiempo extra si no es tu lengua materna. La certificación tiene el mismo valor sin importar el idioma del examen.

¿Cool Testers tiene curso de CT-STE?

Por ahora no tenemos un curso específico de CT-STE. Te recomendamos empezar por el curso ISTQB Fundamentos (CTFL 4.0), que es requisito, y prepararte con el syllabus oficial y el examen de muestra.