Cómo contratar un Security Engineer (AppSec / Application Security)

Una fintech de 70 personas con un equipo de ingeniería de doce desarrolladores cerró un contrato grande con un cliente enterprise que exigía certificación SOC 2 en seis meses. Nadie en el equipo se dedicaba a seguridad de forma exclusiva. En lugar de contratar un ingeniero de seguridad, la dirección trajo a un consultor de gobierno con perfil de CISO, convencida de que necesitaba a alguien senior que "se hiciera cargo de la seguridad". Cuatro meses después tenían un montón de políticas escritas y ningún control técnico implementado: el código seguía sin escaneo automático, la nube tenía permisos demasiado amplios y los hallazgos del pentest anual seguían abiertos. La empresa no contrató mal a una persona: contrató mal al perfil. Necesitaba alguien que construyera controles en el código y en la infraestructura, y trajo a alguien que redacta estrategia. El riesgo real seguía intacto mientras el reloj del contrato corría.

Contratar un Security Engineer es difícil precisamente porque el rubro de la seguridad está lleno de títulos que suenan parecido y significan cosas muy distintas. El mismo mercado usa "seguridad" para nombrar a quien gobierna el riesgo a nivel de directorio, a quien ataca sistemas para encontrar fallas y a quien construye los controles que evitan esas fallas. Esta guía de IT Workers desarma esa ambigüedad para un decisor no técnico: qué hace realmente un Security Engineer de Application Security, en qué se diferencia de un CISO y de un pentester, cuándo aparece la necesidad del primer ingeniero de seguridad, cómo evaluar threat modeling, SAST, DAST, cloud security e IAM sin ser técnico, qué estructura de entrevista filtra de verdad, qué rangos de mercado considerar y qué errores evitar. El objetivo es que el lector tome una decisión informada sobre el perfil correcto, no que llene una vacante rápido.

El público objetivo es CTO, VP Engineering, Head of Security, Founder y Gerente de RRHH. Sin jerga innecesaria, sin alarmismo. Las recomendaciones aplican el mismo criterio que un buen Security Engineer aplica a su trabajo: priorizar por riesgo real y no por miedo, y construir controles en vez de acumular reportes. Los rangos numéricos que aparecen son referenciales de mercado 2026; el disclaimer correspondiente está al inicio del bloque que los usa.

1. Qué hace realmente un Security Engineer de Application Security

Un Security Engineer de Application Security es dueño de que el producto sea seguro por diseño, no de escribir políticas ni de romper sistemas una vez al año. Su trabajo central es embeber la seguridad dentro del ciclo de desarrollo de software, de modo que las vulnerabilidades se prevengan antes de llegar a producción y, cuando aparezcan, se detecten y remedien de forma sistemática. Esto se descompone en varias actividades. Primero, hace threat modeling de nuevas funcionalidades: razona cómo un adversario intentaría abusar de una feature antes de que se escriba el código. Segundo, integra herramientas de análisis en el pipeline de CI/CD: SAST para analizar el código estático, DAST para probar la aplicación en ejecución y SCA para vigilar las dependencias de terceros. Tercero, revisa código con foco en las vulnerabilidades del OWASP Top 10. Cuarto, endurece la configuración de la nube y la gestión de identidades. Y quinto, define estándares de secure coding y apoya la respuesta a incidentes cuando algo ocurre.

Lo que distingue a un Security Engineer senior de uno junior no es cuántas herramientas conoce, sino su criterio de riesgo y su capacidad de habilitar al equipo de desarrollo. El senior prioriza: sabe que no todas las vulnerabilidades importan igual y ordena el trabajo por impacto real de negocio y probabilidad de explotación, no por la severidad teórica que arroja un scanner. El junior, en cambio, abre mil tickets con la misma urgencia y ahoga al equipo en ruido. El senior, además, construye controles automáticos que reducen el trabajo manual, escribe guías que los desarrolladores pueden seguir sin fricción, y entiende que su rol es hacer más segura la ingeniería sin convertirse en un cuello de botella que frena cada release. Por eso evaluarlo bien exige mirar cómo razona el riesgo y cómo colabora, no su lista de siglas.

Seguridad no es un checklist al final

Una confusión frecuente en empresas que recién montan su capacidad de seguridad es tratarla como una auditoría que se pasa al final, justo antes de un release o de una certificación. El escaneo y la revisión son parte del oficio, pero no son el oficio. Un buen Security Engineer trabaja aguas arriba: participa en el diseño de una funcionalidad, cuestiona los supuestos de confianza, define cómo se autentican y autorizan las acciones, y deja controles que corren solos en cada commit. La seguridad embebida en el proceso, el llamado secure SDLC, es mucho más barata que perseguir vulnerabilidades después: una falla detectada en diseño cuesta una fracción de lo que cuesta arreglarla en producción tras un incidente. Contratar un ingeniero de seguridad con mentalidad de auditor final produce fricción constante con desarrollo y una seguridad de fachada, que es exactamente lo que la mayoría de las empresas quiere evitar al invertir en el área.

2. Security Engineer vs CISO vs Pentester: no son el mismo rol

La pregunta sobre la diferencia entre security engineer vs ciso, y entre security engineer vs pentester, es la que más confusión genera al abrir un proceso. Los tres títulos viven en el mundo de la seguridad, a veces se usan como si fueran intercambiables, y describen roles muy distintos con perfiles muy distintos. La regla mental es simple: el CISO gobierna la estrategia y el riesgo a nivel ejecutivo, el pentester ataca de forma ofensiva y puntual para encontrar fallas, y el Security Engineer construye y opera de forma continua los controles defensivos embebidos en el desarrollo. El CISO decide qué riesgo se acepta; el pentester muestra dónde está el problema; el Security Engineer hace que el problema no ocurra. La tabla siguiente compara las tres figuras en las dimensiones que importan al decidir a quién contratar.

En empresas pequeñas, una sola persona puede cubrir parte de varios de estos frentes, y eso está bien mientras el volumen y la madurez lo permitan. El problema aparece cuando una empresa abre un proceso buscando ingeniería de seguridad y describe la vacante con tareas de gobierno, o al revés. El error de matching más común y más caro es contratar un CISO cuando lo que realmente falta es un Security Engineer que arregle vulnerabilidades: el gobierno sin capacidad de ejecución técnica produce documentos, no seguridad. El segundo error más común es confundir un pentester con un Security Engineer: un perfil ofensivo brillante en romper sistemas no necesariamente sabe construir los controles continuos que evitan que esas fallas vuelvan. Antes de abrir el proceso conviene definir el riesgo dominante en una frase y revisar la diferencia operativa con el resto del área en la guía general sobre contratar perfiles de ciberseguridad.

Cuatro sabores de ingeniería de seguridad

Dentro del paraguas "Security Engineer" conviven especializaciones que rara vez cubre una sola persona en una empresa grande. Conocerlas ayuda a redactar la vacante correcta y a no pedir un unicornio que domine todo por igual.

La mayoría de las pymes tech y scale-ups regionales necesitan primero un Application Security Engineer con base sólida de cloud security, capaz de cubrir el producto y una parte de la infraestructura. Al crecer, conviene separar: alguien dueño de la seguridad del código y alguien dueño de la seguridad de la plataforma. Definir cuál de los cuatro sabores ataca el riesgo dominante de hoy evita contratar un perfil que no toca el problema principal.

3. Señales de que necesitas un Security Engineer

La señal más clara de que una empresa necesita su primer Security Engineer es que la seguridad ya no cabe como tarea part-time de un desarrollador senior que la atiende entre features. Hay señales operativas concretas que conviene revisar antes de abrir el cargo.

• El producto maneja datos sensibles (financieros, de salud, personales) y crece el volumen de usuarios sin nadie dedicado a protegerlos.
• Un cliente enterprise exige una certificación como SOC 2 o ISO 27001 como condición para cerrar el contrato.
• Aparecen hallazgos repetidos en cada pentest anual y nadie los remedia de forma estructural: se parchan y vuelven.
• El equipo de desarrollo creció y ya no hay quien revise la seguridad del código antes de que llegue a producción.
• La seguridad se trata de forma reactiva, apagando incendios tras cada incidente, en vez de estar embebida en el proceso.

La advertencia clave es no confundir la urgencia con el perfil. Una presión de compliance por un contrato grande puede empujar a contratar apresuradamente un consultor de gobierno cuando lo que falta es capacidad técnica de ingeniería que implemente los controles que la certificación exige. Ese desperdicio silencioso de traer el perfil equivocado bajo presión es lo que IT Workers documenta en el análisis del costo oculto de un puesto tech vacante: el problema no es solo la vacante abierta, sino la mala asignación de un perfil caro a un trabajo que no le corresponde, mientras el riesgo real sigue intacto.

El salto a Head of Security

Pasar de Security Engineer a Head of Security no es un ascenso automático ni una cuestión de antigüedad: es una decisión de estructura. Conviene contratar un Head of Security cuando se dan tres condiciones simultáneas: hay un equipo de seguridad de varias personas que necesita dirección y criterio común; la estrategia de riesgo deja de caber en la cabeza del CTO; y la seguridad requiere una voz a nivel ejecutivo que negocie de igual a igual con producto, ingeniería, legal y finanzas, y que responda ante el directorio y ante auditores. Saltar a Head of Security con un solo ingeniero de seguridad, o sin controles técnicos base implementados, agrega una capa de gestión que la empresa todavía no necesita y encarece la estructura sin retorno claro. La lógica de cómo se estructuran los equipos técnicos a medida que la empresa madura se desarrolla en la guía general de contratar ciberseguridad.

4. Perfil y stack: qué domina un buen Security Engineer

El stack de un Security Engineer de Application Security es amplio, y ninguna persona domina todo por igual. Lo importante para un decisor no técnico no es memorizar cada sigla, sino entender qué familia de capacidades cubre cada área y cuáles importan más según el riesgo dominante de la empresa. A grandes rasgos, el perfil se apoya en seis bloques.

• Análisis de seguridad del código (SAST, DAST, SCA): SAST analiza el código estático en busca de patrones vulnerables, DAST prueba la aplicación en ejecución simulando ataques, y SCA vigila las dependencias de terceros y sus vulnerabilidades conocidas. Un buen ingeniero integra estas herramientas en el pipeline y, sobre todo, sabe filtrar el ruido para que el equipo atienda lo que importa.
• Threat modeling y OWASP: la capacidad de razonar cómo un adversario atacaría una funcionalidad antes de construirla, y el dominio de las vulnerabilidades más frecuentes catalogadas por OWASP, como inyección, control de acceso roto o exposición de datos sensibles.
• Cloud security (AWS, Azure, GCP): configuración segura de la nube, principio de menor privilegio, segmentación de red, cifrado y gestión de secretos. Gran parte del riesgo moderno vive en configuraciones de nube mal hechas, no en el código.
• IAM y gestión de identidades: diseño de quién puede hacer qué sobre qué recurso, autenticación, autorización y gobierno de accesos. Una identidad mal gobernada es una de las puertas de entrada más comunes en incidentes reales.
• Seguridad de infraestructura como código (IaC): revisar y endurecer las definiciones de infraestructura antes de desplegarlas, de modo que la nube nazca segura y no se corrija después a mano.
• Respuesta a incidentes y cumplimiento: saber cómo detectar, contener y aprender de un incidente, y manejar los marcos de cumplimiento relevantes como ISO 27001 y SOC 2, que traducen la seguridad a requisitos que un auditor verifica.

5. Seniority y bandas de renta de un Security Engineer

El sueldo de un Security Engineer varía fuerte según industria, etapa de la compañía, frente de especialización y nivel real de responsabilidad, por lo que cualquier número es un orden de magnitud y no una oferta. Aun así, conocer los rangos de mercado evita dos errores frecuentes: ofrecer por debajo y no atraer talento senior en un rubro con escasez estructural de perfiles, u ofrecer por encima sin necesidad. La tabla siguiente entrega rangos referenciales brutos mensuales del mercado tech regional 2026.

Los rangos que siguen son estimaciones referenciales de mercado 2026 elaboradas en base a procesos gestionados por IT Workers y no constituyen una oferta ni una garantía de compensación para ningún rol o empresa específica. Varían por industria, etapa de la compañía y alcance real del cargo.

Banca, fintech y empresas con obligaciones regulatorias de compliance tienden a pagar en el extremo superior de cada rango, porque la competencia por ingenieros de seguridad con experiencia en esos dominios es intensa y la oferta de talento es escasa. El desglose por rol específico, con percentiles y diferencias por industria, está en la guía detallada del sueldo de un Security Engineer 2026, en el sueldo de un Application Security Engineer, en el sueldo de un Cloud Security Engineer, en el sueldo de un pentester o ethical hacker y en el sueldo de un CISO, útiles para calibrar la banda antes de hacer una oferta.

6. Cómo evaluar a un Security Engineer sin ser técnico

La buena noticia para un decisor no técnico es que las competencias que definen a un gran Security Engineer se evalúan sin programar ni dominar la jerga de seguridad. Lo que se evalúa es cómo razona el riesgo y cómo colabora, no su stack de herramientas. Cinco competencias permiten distinguir a un ingeniero de seguridad senior de uno mediocre, y todas se pueden juzgar pidiendo un caso concreto del pasado en vez de opiniones generales.

• Mentalidad de riesgo: cómo prioriza las vulnerabilidades. Un buen perfil ordena por impacto real de negocio y probabilidad de explotación; uno débil trata todo con la misma urgencia o se guía solo por la severidad teórica del scanner.
• Secure SDLC: dónde ubica la seguridad en el proceso. Un buen ingeniero la embebe en el diseño y en el pipeline; uno débil la trata como una auditoría de último minuto antes del release.
• Threat modeling: cómo piensa como atacante. Un buen perfil razona cómo abusaría de una feature antes de construirla; uno débil espera a que el scanner le diga qué está mal.
• Colaboración con desarrollo: si habilita o bloquea. Un buen ingeniero da al equipo herramientas y guías para avanzar seguro; uno débil se convierte en una compuerta que frena cada entrega.
• Comunicación del riesgo: si traduce a negocio. Un buen perfil explica el impacto de una vulnerabilidad a un gerente sin jerga; uno débil se esconde en tecnicismos que nadie entiende ni puede priorizar.

Green flags y red flags

Las green flags más fiables: el candidato cuenta un caso concreto con una vulnerabilidad que encontró, cómo la priorizó según impacto, cómo la remedió y qué control automático puso para que no volviera; pregunta por el contexto de negocio y por los datos sensibles antes de proponer controles; y habla de habilitar al equipo de desarrollo, no de bloquearlo. Las red flags: trata la seguridad como un checklist de herramientas sin razonar el riesgo; quiere frenar cada release; prioriza por severidad del scanner en vez de impacto real; solo habla de certificaciones y compliance sin poder contar una remediación concreta; y describe seguridad únicamente como auditoría al final del ciclo. Una guía general aplicable a cualquier perfil tech está en cómo evaluar candidatos tech siendo no técnico.

La decisión entre una prueba tipo caso en vivo y un ejercicio para llevar a casa depende del nivel del cargo y del tiempo disponible; el análisis de qué formato conviene según el perfil está en la guía sobre prueba técnica tech: take-home, live coding y system design, aplicable también a un caso de threat modeling.

7. Proceso de contratación paso a paso

Una entrevista de Security Engineer improvisada decide por impresión, y la impresión premia al candidato que suena más alarmante o que recita más siglas, no al que mejor razona el riesgo. Un proceso estructurado con etapas claras y un scorecard común reduce el sesgo y hace comparables a los candidatos. La estructura siguiente cubre las cinco competencias y reparte la evaluación entre varios evaluadores con foco distinto.

El caso de threat modeling es la etapa más reveladora. En lugar de una batería de definiciones, conviene plantear una funcionalidad real y abierta: cómo aseguraría un nuevo flujo de pagos, o cómo protegería un endpoint que expone datos de clientes. Lo que se observa no es la respuesta correcta (no hay una), sino el proceso: si el candidato pregunta por el contexto de negocio y los datos sensibles antes de saltar a controles, si distingue lo crítico de lo cosmético, si propone mitigaciones proporcionales al riesgo y si plantea controles que el equipo de desarrollo puede adoptar sin frenarse. La etapa técnica de AppSec y cloud baja eso a la práctica evaluando el dominio real de las herramientas y de la nube, y la conversación con desarrollo valida si sabe habilitar en vez de bloquear y explicar el riesgo sin jerga.

El scorecard común

Cada etapa debe terminar con una evaluación escrita sobre criterios definidos de antemano, no con un comentario verbal del tipo "se ve sólido en seguridad". Un scorecard común permite que cinco evaluadores juzguen al mismo candidato con la misma vara y que la decisión final se tome sobre evidencia comparable. La metodología completa de evaluación estructurada está en la guía de scorecard de contratación tech, base para definir las competencias de ingeniería de seguridad que cada evaluador va a puntuar.

8. Errores comunes y cuándo conviene un headhunter especializado

Después de gestionar búsquedas de perfiles de seguridad en compañías tech regionales, los errores que arruinan una contratación de Security Engineer se repiten con claridad. Casi todos son evitables con un proceso ordenado y una definición honesta del riesgo dominante.

Headhunter especializado vs LinkedIn por tu cuenta

Buscar un Security Engineer por tu cuenta en LinkedIn funciona cuando tienes tiempo, criterio técnico para filtrar y una marca empleadora que atrae a un rubro con escasez estructural de talento. En la práctica, la mayoría de las empresas no técnicas enfrenta tres problemas: no distingue en el CV a un ingeniero de seguridad real de un perfil que solo colecciona certificaciones, los mejores candidatos son pasivos y no responden a avisos, y el proceso de evaluar seguridad sin ser experto es lento y propenso a error. Un headhunter especializado aporta exactamente donde el proceso propio falla: define el riesgo dominante, accede a candidatos pasivos y traduce la seguridad a criterios de decisión. Cuándo conviene delegar y cuándo no se analiza en el marco de contratar ciberseguridad con un headhunter especializado.

IT Workers ejecuta búsquedas dirigidas de Security Engineers, Application Security Engineers, Cloud Security Engineers, Staff y Heads of Security con un proceso que ataca estos errores de raíz. Parte de un brief preciso que define qué frente de seguridad duele más (código, nube o compliance) e identifica si lo que se necesita es ingeniería de seguridad, gobierno o pentesting puntual; identifica candidatos pasivos que no aplican a avisos; los evalúa con un scorecard de competencias de ingeniería de seguridad; y presenta una shortlist en pocos días. Cada colocación incluye garantía de 90 días. Para empresas no técnicas, además, traduce el lenguaje de seguridad a criterios de decisión claros para el directorio.

9. FAQ: 12 preguntas que recibimos al contratar ingenieros de seguridad