De Developer a Application Security: una transición pragmática

Por qué los developers son fuertes practicantes AppSec

El trabajo de application security exige dos cosas a la vez: pensar como atacante de aplicaciones web y razonar sobre diseño seguro y remediación a nivel de código. Los pentesters puros suelen tener la parte ofensiva pero les cuesta dar consejo de remediación accionable. Los developers invierten esa brecha. Cerrar la brecha ofensiva es más rápido que aprender a leer código de producción desde cero.

La transición no es dejar el desarrollo. Es superponer pensamiento de seguridad encima de habilidades de código que ya tienes y redirigir tu carrera alrededor de la combinación.

Qué se traslada

Tres hábitos de desarrollo trasladan directamente:

1. Velocidad lectora de código. El trabajo AppSec implica mucha revisión de código. Ya lees código más rápido que alguien formado desde cero.

2. Intuición de arquitectura. Saber cómo se construyen los sistemas hace más afilado el threat modelling. Ya sabes dónde están las costuras.

3. Lenguaje de remediación. Los AppSec engineers que pueden decir "arregla esto con consultas parametrizadas" en vez de "arregla la inyección SQL" son escuchados. Ya hablas ese idioma.

Qué tienes que construir

La brecha ofensiva y específica de seguridad:

• Ataques a aplicaciones web. OWASP Top 10 es el suelo, no el techo. Los practicantes reales saben SSRF, deserialización, race conditions, fallos de lógica de negocio. Construye familiaridad práctica, no solo conceptual.
• Patrones de diseño seguro. Threat modelling STRIDE, patrones secure-by-default, code smells relevantes para seguridad. El cambio de "funciona" a "cómo falla de forma segura".
• Seguridad de dependencias y supply chain. Herramientas SCA, disciplina de lockfile, conciencia de dependencias transitivas, artefactos firmados. AppSec moderno gasta tiempo real aquí.
• Integración de seguridad CI/CD. SAST, DAST, escaneo de secretos, escaneo IaC en el pipeline. Saber qué herramientas en qué etapa y cómo afinar falsos positivos."

Stack de certificaciones

Burp Suite Certified Practitioner es la credencial individual más directamente relevante porque enlaza con la herramienta estándar. OSCP añade amplitud ofensiva y credibilidad pero es más amplia que AppSec. OSWE (Offensive Security Web Expert) es la credencial de especialista web más rigurosa. Para AppSec engineering más que testing, CSSLP y certificaciones ISC2 señalan la orientación SDLC.

Dónde encaja el bootcamp

El Bootcamp de Ciberseguridad de Unihackers cubre fundamentos de ciberseguridad en los módulos m1 a m12, con el módulo m9 dedicado específicamente a web application security. Para developers que ya tienen fundamentos web, el bootcamp añade el contexto ofensivo y SOC que los AppSec engineers necesitan para comunicarse con equipos de seguridad. Lee el guía del programa para detalle por módulo, o si el bootcamp merece la pena si sopesas la inversión junto al autoestudio.

Frenos comunes

Tres patrones explican la mayoría de transiciones developer a AppSec estancadas:

1. Tratar AppSec solo como pentest más revisiones de código. AppSec es más amplio: threat modelling, diseño seguro, higiene de dependencias, integración CI/CD. Reducirlo a pentest subestima el rol.

2. Evitar el lado ofensivo. Algunos developers intentan entrar a AppSec haciendo desarrollo con sabor a seguridad. Raramente funciona porque los hiring managers quieren capacidad demostrada de encontrar y explotar, no solo defender.

3. Subestimar el lado blando. Los AppSec engineers gastan mucho tiempo convenciendo a developers de arreglar cosas. La parte de comunicación importa tanto como la técnica.

La transición es más corta que la mayoría de entradas a ciberseguridad porque la mitad de la base ya existe. Añade la capa ofensiva con intención y tendrás uno de los perfiles más fuertes del mercado de seguridad.

Por qué el developer es el perfil de mayor leverage en AppSec

Los equipos AppSec están perpetuamente en infraestructura porque el rol exige una combinación rara: profundidad de testing ofensivo web, intuición de diseño seguro y la credibilidad para influir en equipos de ingeniería. Los profesionales de seguridad puros suelen carecer de las dos últimas. Los developers puros suelen carecer de la primera. Un developer que aprende ofensiva representa la brecha más pequeña que cerrar.

Ese leverage se ve en la contratación. Las posiciones AppSec se redactan cada vez más como "engineer que sabe romper cosas" en lugar de "pentester que sabe leer código". Empresas como Stripe, GitLab, Datadog, Adyen, Klarna y la mayoría de scale-ups en fintech o developer tools estructuran sus programas de seguridad alrededor de AppSec engineers embebidos en equipos de producto. Quieren a alguien que pueda revisar un pull request, lanzar una sesión Burp contra staging, abrir un ticket de Jira con remediación concreta y no frenar la release.

La carrera también resiste la presión de automatización mejor que el trabajo de analista junior. El triage en un SOC está siendo comprimido por ML y servicios gestionados. El threat modeling, la revisión de diseño seguro y la remediación de raíz para lógica de aplicación nueva siguen siendo profundamente humanos en el horizonte previsible.

Los mapas OWASP que tienes que internalizar

OWASP publica los mapas que toda la industria AppSec usa para scoping, reporting y filtros de entrevista. Tienes que tener fluidez en cuatro:

• OWASP Top 10 (2021). Broken access control, fallos criptográficos, inyección, diseño inseguro, mala configuración de seguridad, componentes vulnerables y desactualizados, fallos de identificación y autenticación, fallos de integridad de software y datos, fallos de logging y monitorización, server-side request forgery. Memorízalos por categoría y por ejemplo.
• OWASP API Security Top 10. Las apps modernas son mayormente APIs. BOLA (broken object level authorization), broken authentication, BFLA (broken function level authorization), consumo no restringido de recursos y SSRF dominan los pagos reales en bug bounty.
• OWASP ASVS (Application Security Verification Standard). El checklist de verificación que los programas maduros usan para gatear releases. Los niveles 1, 2, 3 mapean a aplicaciones públicas, sensibles y de alta garantía. Leer ASVS una vez te da la forma de un modelo de madurez AppSec.
• OWASP WSTG (Web Security Testing Guide). La metodología práctica de testing. Úsala como tu walkthrough estructurado cuando evalúes cualquier aplicación de extremo a extremo.

Marca los cuatro. Vuelve a ellos en cada evaluación. Cuando un entrevistador senior pregunte "cómo enfocarías la revisión de una nueva API de pagos", la respuesta creíble nombra API Top 10 y ASVS L2 directamente.

La stack moderna de herramientas AppSec

Un AppSec engineer en activo toca cuatro categorías de herramientas cada semana:

• SAST (análisis estático). Semgrep es el default open-source para reglas custom rápidas. SonarQube cubre calidad de código más seguridad con amplia adopción enterprise. Checkmarx y Veracode dominan la procura de gran enterprise. Aprende Semgrep en profundidad porque escribir reglas custom separa a los usuarios de SAST de los dueños de SAST.
• DAST (análisis dinámico). Burp Suite Professional es el estándar de la industria para testing manual y semi-automatizado. OWASP ZAP es el equivalente open-source y es aceptable en muchos pipelines CI. Acunetix e Invicti cubren el escaneo automatizado a escala.
• SCA (software composition analysis). Snyk, GitHub Dependabot, OSV-Scanner y Trivy escanean dependencias y contenedores buscando CVEs conocidos. Aprende los internals de lockfile (package-lock.json, yarn.lock, Pipfile.lock, go.sum) y cómo se resuelven realmente las dependencias transitivas.
• IAST (análisis interactivo). Contrast Security y Datadog ASM instrumentan aplicaciones en ejecución. Menos común en stacks de carrera temprana pero cada vez más requerido en empresas con pipelines maduros.

No tienes que ser experto en las cuatro. Tienes que ser experto en una por categoría y saber lo suficiente de las demás para evaluarlas, integrarlas y afinarlas.

Threat modeling separa a mid de senior

El tooling encuentra patrones conocidos. El threat modeling encuentra los fallos de diseño que ningún scanner detectará. Es también el camino más rápido de AppSec engineer mid a senior o staff.

Tres frameworks cubren el campo:

• STRIDE. Spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. El framework de Microsoft. El punto de entrada más accesible. Combínalo con diagramas de flujo de datos y la pregunta "cuál es el objetivo del atacante en cada trust boundary".
• PASTA (Process for Attack Simulation and Threat Analysis). Centrado en riesgo, alineado con negocio. Usado en industrias reguladas y en empresas que necesitan defender el gasto de seguridad ante ejecutivos no técnicos.
• Attack trees. Útiles para razonamiento adversarial sobre flujos específicos de alto valor como autenticación, pago o acceso admin.

Practica sobre sistemas que ya conoces. Toma una feature que enviaste el trimestre pasado, dibuja el flujo de datos y pasea STRIDE por cada componente y trust boundary. Dos o tres repeticiones y empezarás a detectar fallos de diseño en tu propio trabajo pasado.

SDLC seguro y shift-left en la práctica

El AppSec moderno se mide por cuán pronto en el SDLC se encuentran y arreglan las vulnerabilidades. Shift-left es el modelo operativo. En la práctica se ve así:

• Requisitos y diseño. Threat models adjuntos a los design docs. Requisitos de seguridad derivados de ASVS. Privacy impact assessments donde sea relevante.
• Código. Secrets scanning pre-commit, hints SAST a nivel IDE, pull requests con branch protection y revisión de seguridad obligatoria para rutas de riesgo.
• Build. SCA en cada pull request, SAST en la rama main, artefactos firmados publicados en un registro controlado.
• Deploy. Escaneo IaC (Checkov, tfsec, KICS), escaneo de contenedores (Trivy, Grype), gates de policy-as-code (OPA, Kyverno).
• Operate. WAF y runtime protection, DAST en staging, bug bounty para producción, postmortems de incidentes que retroalimentan la fase de diseño.

El objetivo es empujar la detección antes y reducir la curva de coste por fix. Los AppSec engineers que demuestran impacto medible de shift-left son promovidos.

Supply chain: SLSA, Sigstore, SBOM

Desde SolarWinds y Log4Shell, la seguridad de supply chain ya no es opcional. Tres conceptos que internalizar:

• SLSA (Supply chain Levels for Software Artifacts). Los niveles 1 a 4 describen garantías progresivas sobre cómo se construyó un artefacto. Lee la spec en slsa.dev y conoce qué nivel cumple actualmente tu pipeline de build.
• Sigstore. Firma open-source para artefactos de software. Cosign para contenedores, gitsign para commits, Fulcio como autoridad certificadora. Combínalo con Rekor para logs de transparencia.
• In-toto y SBOM. In-toto atesta provenance de build. Los SBOMs (CycloneDX, SPDX) documentan qué hay realmente en tu software. Ambos son cada vez más requeridos por la procura enterprise y los contratos federales de EE.UU.

Un AppSec engineer junior que pueda levantar firma Cosign y generación SBOM en un pipeline CI es inmediatamente útil en empresas de cualquier tamaño.

Gestión de secretos y endurecimiento del pipeline CI/CD

Los secretos hardcodeados, los tokens filtrados y los runners CI con permisos excesivos causan más incidentes que cualquier vulnerabilidad web. Domina:

• Almacenamiento de secretos. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Conoce los patrones de acceso, modelos de rotación y logs de auditoría.
• Autenticación CI. GitHub OIDC y AWS IAM Roles for Service Accounts reemplazan credenciales estáticas de larga vida. La identidad federada es el default moderno.
• Aislamiento de pipeline. Self-hosted runners con instancias efímeras, branch protection, revisores requeridos, commits firmados y atestaciones de provenance.
• Detección. TruffleHog, Gitleaks, GitHub secret scanning. Pásalos sobre todo el historial git, no solo el commit actual.

Pregunta de entrevista típica: "encuentras una access key AWS de larga vida en un repo público, llévame por los próximos sesenta minutos". Si respondes con confianza, ya estás por delante de la mayoría de candidatos.

Plan realista de transición de 9 meses

• Meses 1 a 2. PortSwigger Web Security Academy. Todos los labs apprentice y practitioner. Lee OWASP Top 10 y API Top 10 al completo.
• Meses 3 a 4. Burp Suite Certified Practitioner. Práctica de threat modeling sobre tres de tus proyectos pasados. Lee el ASVS de extremo a extremo una vez.
• Meses 5 a 6. Construye un pipeline AppSec en homelab: GitHub Actions corriendo Semgrep, Trivy, Gitleaks, OWASP ZAP. Documenta públicamente. Empieza a contribuir reglas Semgrep.
• Meses 7 a 8. Security+ como baseline HR-friendly si aún no la tienes. Empieza prep de OSWE o de OSCP según quieras label de especialista o generalista.
• Mes 9. Aplica. Primero rol de security champion interno si tu empleador actual tiene programa. Luego roles externos de AppSec engineer. Lidera con portfolio, no con certificaciones.

Combina esto con el Bootcamp Unihackers de Ciberseguridad si quieres contexto ofensivo y SOC estructurado, o auto-dirígete si ya tienes la disciplina. La página de carrera de security engineer cubre roles adyacentes con los que acabarás compitiendo.

Realidad salarial: dev mid a AppSec junior a AppSec senior en EU

Un developer mid en Europa Occidental gana aproximadamente EUR 50.000 a 70.000 en 2026 según ciudad y stack. Los AppSec engineers junior en los mismos mercados aterrizan alrededor de EUR 65.000 a 80.000 con uno o dos años de experiencia enfocada en seguridad y una certificación relevante. Los AppSec engineers senior alcanzan EUR 90.000 a 130.000, con roles staff y principal AppSec en scale-ups y grandes fintechs pagando significativamente por encima.

La prima sobre desarrollo es real pero no infinita. AppSec paga más porque la oferta está restringida y el impacto está concentrado. La prima es mayor para engineers que pueden enviar código seguro, ejecutar una evaluación ofensiva creíble e influir en el diseño al mismo tiempo. Ese es el perfil hacia el que construye este pathway.