Security by design: dejar de parchear agujeros que tú mismo creaste

Publicado el 29 de mayo de 2026  •  12 minutos  • 2441 palabras

La mayoría de los “problemas de seguridad” que acabas parcheando a las 3 de la mañana no son accidentes.

Son decisiones tomadas meses antes con prisas, una taza de café y la firme convicción de que “esto ya lo arreglaremos luego”.

Security by design va exactamente de eso: meter la seguridad en el ciclo de desarrollo desde el principio, en lugar de confiar en el sagrado combo de escáner + pentest + fe ciega.

Bajemos esto a tierra: threat modeling, principios básicos, errores que llevamos repitiendo desde 2010 y cómo dejar de dispararte en el pie con tu propio código.

Seguridad by design != echarle un ojo al final

El ciclo vital del desarrollador promedio frente a la seguridad es tan predecible como un reloj suizo roto.

Primero diseñas la aplicación pensando en funcionalidades, magnífico.

Luego la desarrollas pensando en plazos, porque la jefatura de proyecto ha convertido “estimaciones, nos os preocupéis, que son solo orientativas” en “roadmap grabado en piedra, porque tú te has comprometido”.

Y justo cuando el sufrimiento parece haber finalizado y todo está a punto de salir a producción, alguien pregunta con voz tímida: “oye, ¿le hemos pasado algún escáner de seguridad?”.

Silencio incómodo. Alguien mira al techo. Alguien abre una nueva pestaña.

El enfoque security by design propone algo revolucionario: hacer las cosas en orden.

Metes requisitos de seguridad desde el inicio en el SDLC (Secure Development Lifecycle) , haces threat modeling cuando defines la arquitectura, no seis meses después con la app en producción y el CEO mirándote fijamente.

También integras análisis estático, revisiones de código y tests de seguridad en el pipeline, en lugar de rezar una vez al año durante el pentest anual.

OWASP tiene incluso un Secure by Design Framework completo dedicado a esto: seguridad embebida en arquitectura, diseño, código y operaciones, en vez de ir pegando emplastos sobre una construcción que nunca fue diseñada para aguantar nada.

Threat modeling: pensar como atacante antes de que lo haga un atacante real

Threat modeling suena muy académico, como algo que se hace en traje con pizarra blanca y rotulador azul que siempre se queda sin tinta en el momento menos oportuno.

La realidad es más sencilla: consiste en sentarte a responder cuatro preguntas directas:

¿Qué estamos construyendo (diagramas, flujos de datos, componentes)? ¿Qué puede salir mal? ¿Qué estamos haciendo al respecto? ¿Y lo estamos haciendo bien o nos estamos mintiendo a nosotros mismos?

Microsoft, OWASP y prácticamente cualquier guía moderna coinciden: hay que hacer threat modeling en las fases tempranas del SDLC, en requisitos y diseño, y revisarlo cada vez que la arquitectura cambie de forma significativa.

Disclaimer: ya sé que poner a Microsoft como ejemplo de seguridad es como poner a un político como ejemplo de honradez, pero, a ver, puede que ninguno de los dos practiquen nada de lo que hablan, pero hablan de ello bastante y bien, que era lo que yo pretendía mencionar.

En fin, el beneficio concreto es que detectas fallos de diseño (falta de separación de responsabilidades, flujos inseguros, datos sensibles almacenados en texto plano porque total, ¿quién va a entrar?) antes de haber escrito una sola línea de código. Y eso significa que puedes priorizar medidas de seguridad según riesgo real, no según lo que ha salido esta semana en Hacker News.

Lo que evita, entre otras cosas, es esa conversación en la que con la app ya en producción alguien descubre que todo el modelo de datos está mal planteado para cumplir con GDPR.

O que el esquema de permisos asume que los usuarios son todos buenas personas con buenas intenciones.

Errores básicos que seguimos repitiendo en 2026

OWASP lleva años publicando su Top 10 de vulnerabilidades y lo fascinante (o lo devastador, según cómo lo mires) es que los mismos fallos aparecen edición tras edición, con la puntualidad de ese primo que viene a la cena familiar y siempre dice exactamente lo mismo.

La mala configuración de seguridad es la campeona histórica: usuarios y contraseñas por defecto sin cambiar, puertos y servicios innecesarios expuestos, paneles de administración o endpoints de debug disponibles en producción porque nadie se acordó de quitarlos antes de salir a comer.

Justo al lado está la gestión catastrófica de credenciales: API keys y contraseñas codificadas en duro en el código, ficheros de configuración con secretos en texto plano subidos alegremente a repositorios públicos. Hay startups enteras que han descubierto de esta manera que sus claves de AWS llevaban meses indexadas en Google.

Luego está el control de acceso, digno de una puerta giratoria: rutas de admin accesibles para cualquiera que conozca la URL, APIs que confían ciegamente en lo que envía el cliente, incluyendo un campo isAdmin: true que no es broma, existe, ha pasado, y probablemente esté pasando ahora mismo en algún lugar del mundo.

Y finalmente, el clásico imperecedero de no actualizar dependencias con CVEs reportadas desde hace meses o años porque “ahora no toca” y luego siempre toca de la peor manera posible.

La propia OWASP lo resume con la paciencia infinita de quien lleva muchos años repitiendo lo mismo: la mayor parte del riesgo viene de errores sistemáticos de diseño y configuración, no de ataques ultracomplejos dignos de película de espías con gadgets y música de fondo.

12-Factor Apps, configuración y secretos: no seas tu peor enemigo

El manifiesto de las 12-Factor Apps se hizo famoso principalmente por temas de despliegue y escalabilidad, pero si lo lees con atención tiene dos factores que son directamente de seguridad, y que mucha gente ignora porque están enterrados entre los de “logs” y “procesos” y resultan menos atractivos.

El primero es el de configuración: guarda la configuración en el entorno, no en el código.

Las credenciales, los endpoints, las claves de terceros… todo eso debe vivir en variables de entorno o en un almacén de secretos dedicado, no incrustado en el repositorio como si fuera un comentario de bienvenida.

Guardar usuarios y contraseñas en el código fuente es la violación más obvia de este principio y, a la vez, la receta más eficiente para aparecer en un informe de incidentes con tu nombre bien visible en la primera página.

El segundo es el de los backing services: tratar bases de datos, colas, cachés y otros servicios externos como recursos adjuntos, con credenciales y permisos adecuados para cada entorno.

Combinar esta filosofía con buenas prácticas de IAM y protección de datos (secret stores, cifrado en tránsito y en reposo) es prácticamente el ABC de cualquier aplicación moderna que aspire a no salir en las noticias por los motivos equivocados.

CVE: el inventario público de meteduras de pata y cómo usarlo bien

El sistema CVE (Common Vulnerabilities and Exposures) es la base de datos estándar para identificar y catalogar vulnerabilidades conocidas en software y hardware. En términos prácticos: cada CVE es un identificador (CVE-2025-XXXX) que describe una vulnerabilidad concreta, sea un buffer overflow, una inyección SQL o un fallo de autenticación que no debería existir pero existe, con nombre, apellidos y número de expediente.

MITRE y una red de CNAs se encargan de mantener y asignar esos IDs, con la paciencia de quien cataloga los errores ajenos como vocación.

El error más habitual con los CVEs no es ignorarlos por completo, eso sería demasiado obvio como mala práctica, sino descartarlos con un “no es explotable en nuestro caso” sin ningún análisis real detrás, o sencillamente no tener ningún proceso que los revise de forma periódica.

Lo segundo es casi más peligroso, porque al menos lo primero implica que alguien ha leído la descripción.

Lo sensato es integrar escáneres de dependencias y contenedores en el pipeline (SCA, container scanning) y mantener un proceso de vulnerability management: priorizar CVEs según criticidad y exposición real, parchear, documentar.

No es nada espectacular, pero es lo que separa a los equipos que se enteran de un problema antes de que lo haga un atacante de los que lo descubren leyendo un tweet.

Pentesting, revisiones y la seguridad como hábito

El pentesting no es el final boss, ni el sello de calidad que convierte una aplicación insegura en segura por arte de magia. Es una capa más dentro de un programa de seguridad by design, y tratarla como el único mecanismo de validación es exactamente como hacerse una analítica de sangre una vez cada cinco años y considerarse en plena forma.

Un pentest bien hecho sirve para identificar vulnerabilidades que se te han escapado ( bugs, configuraciones inseguras, vectores de ataque reales que no habías considerado), validar que tus controles funcionan como crees que funcionan, y cumplir los requisitos de normativas como PCI-DSS, HIPAA o GDPR.

La clave está en hacerlo con regularidad (no solo tras un incidente que ya ha ocurrido), definir bien el alcance, y asegurarse de que los hallazgos entran en el backlog y se cierran, en lugar de quedarse en un PDF bonito que nadie vuelve a abrir hasta el siguiente pentest.

Todo esto se complementa con análisis estático y dinámico integrados en CI/CD y revisiones de código con foco en patrones de seguridad.

Y con logging y monitorización que detecten comportamientos anómalos antes de que se conviertan en incidentes, no solo que registren las caídas cuando ya es demasiado tarde para evitarlas.

Security by design en la práctica: qué deberías estar haciendo ya

Si quieres dejar de parchear tus propios agujeros, el mínimo decente tiene cuatro momentos y ninguno de ellos es opcional.

En requisitos y diseño: incluir requisitos de seguridad explícitos desde el principio (cifrado, auditoría, permisos, cumplimiento normativo) y hacer threat modeling en funcionalidades y sistemas críticos antes de que nadie haya escrito una sola línea de código.

En implementación: seguir guías de secure coding , gestionar bien configuración y secretos , y tratar la seguridad como un criterio de aceptación, no como una nota al margen que se revisará “cuando haya tiempo”.

En verificación: SAST, DAST, escáner de dependencias y contenedores en CI/CD, revisiones de código con lista de comprobación de seguridad, y pentests periódicos bien integrados en el ciclo de mejora, no como evento traumático anual.

En operación: monitorizar eventos de seguridad y actividad anómala, mantener procesos de gestión de CVEs y parches, y hacer análisis post-incidente con acciones correctivas reales, no con solemnes promesas de que “esto no volverá a pasar”.

Epílogo: el coste ya lo estás pagando

Si todo esto te suena a mucho trabajo, es porque lo es.

Integrar seguridad en el ciclo de desarrollo requiere disciplina, herramientas y la disposición a tener conversaciones incómodas sobre riesgo cuando todo el mundo preferiría hablar de features.

No es “chulo”". No sale en el roadmap. No genera demos espectaculares para enseñar a jefes y clientes.

Pero aquí está la trampa: el coste no desaparece si decides no pagarlo ahora sino que se acumula.

Cada decisión tomada con prisas, cada secreto hardcodeado “de forma temporal”, cada proceso de vulnerability management que se pospone porque ahora hay cosas más urgentes … todo eso es una factura diferida que alguien va a tener que pagar.

A veces eres tú, a las 3 de la mañana. A veces es un cliente cuyos datos acaban en un foro en el que preferiría no ser mencionado.

La pregunta real no es si es caro hacer security by design, es cuánto llevas gastando ya en apagar fuegos que tú mismo encendiste, y si ese dinero habría bastado para no encenderlos.

Glosario rápido (para que nadie se pierda en las siglas)

Porque “ya sé lo que es” a veces significa cosas distintas para personas distintas, y en seguridad eso tiene consecuencias.

• Security by design : enfoque en el que la seguridad se integra desde el inicio del diseño y desarrollo, en lugar de añadirse cuando ya es demasiado tarde para cambiar algo sin llorar.
• SDLC (Secure Development Lifecycle) : ciclo de vida de desarrollo con actividades de seguridad en cada fase – requisitos, diseño, implementación, pruebas, despliegue – . Convierte la seguridad en parte del proceso en lugar de un apéndice incómodo que nadie quiere gestionar.
• Threat modeling : proceso de identificar activos, amenazas, vulnerabilidades y mitigaciones antes – y durante – el desarrollo. Idealmente antes de que alguien externo lo haga por ti y te lo cuente en un informe con muchos rojos.
• OWASP : proyecto abierto que publica guías y estándares de seguridad para aplicaciones web, conocido sobre todo por el Top 10 que lleva décadas avergonzándonos colectivamente con los mismos errores.
• 12-Factor Apps : conjunto de principios para aplicaciones modernas que, entre otras cosas, insisten en separar la configuración del código y tratar los servicios externos como recursos adjuntos.
• CVE (Common Vulnerabilities and Exposures) : estándar de identificación de vulnerabilidades conocidas. El archivo histórico de todo lo que ha salido mal y ya tiene número de referencia oficial.
• Pentesting : pruebas de intrusión controladas realizadas por profesionales para evaluar la seguridad de sistemas y aplicaciones. Funcionan muy bien siempre que no sean el único mecanismo de seguridad que tienes.

Fuentes y referencias

Porque “me lo dijo un compañero en el standup” no es una referencia académica válida, aunque a veces lo parezca.

• Threat Modeling and Secure by Design Applications – ISACA - ISACA. Artículo sobre cómo integrar threat modeling en el ciclo de desarrollo seguro.
• OWASP Secure by Design Framework - OWASP. Marco de referencia para embeber seguridad en arquitectura, diseño, código y operaciones.
• Understanding the Secure Development Lifecycle (SDLC) for App Security - PointGuard AI. Guía práctica sobre el SDLC y sus fases de seguridad.
• Secure by Design: The Complete Guide - Check Point. Visión completa del enfoque security by design aplicado al desarrollo moderno.
• Practice Security by Design – Salesforce Trailhead - Salesforce. Módulo práctico sobre seguridad integrada en el SDLC.
• Software Development Lifecycle Threat Modeling - Versprite. Cómo aplicar threat modeling en cada fase del SDLC.
• Threat Modeling – Microsoft Security Engineering - Microsoft. Guía oficial de Microsoft para modelado de amenazas en el SDL.
• OWASP Top 10: Security Misconfiguration Explained - Security Journey. Explicación detallada de la categoría de misconfiguration del OWASP Top 10.
• The In-Depth Guide to OWASP’s Top 10 Vulnerabilities - Jit.io. Análisis exhaustivo de las 10 vulnerabilidades más críticas según OWASP.
• Secure 12-Factor Apps - Think DevOps. Cómo aplicar los principios 12-Factor con foco en seguridad.
• The Twelve-Factor App: Config - 12factor.net. Factor III del manifiesto: separar configuración del código.
• Common Vulnerabilities and Exposures (CVE) - Rapid7. Explicación del sistema CVE y cómo usarlo en vulnerability management.
• CVE – Fortinet Cybersecurity Glossary - Fortinet. Definición y contexto del sistema CVE en la industria.
• Best Practices for Penetration Testing - Cobalt. Buenas prácticas para planificar y ejecutar pentests de forma efectiva.
• Pentest Best Practice Checklists - Shubham Sharma (LinkedIn). Checklist práctico de buenas prácticas para pentesting.