Seguridad en el desarrollo de sistemas
La seguridad en el desarrollo consiste en integrar controles y buenas prácticas de seguridad a lo largo de todo el ciclo de vida del software (SDLC), y no como una capa que se añade al final. Este enfoque se conoce como Secure SDLC o seguridad por diseño (Security by Design): la seguridad se considera un requisito desde el análisis, se plasma en el diseño (modelado de amenazas), se aplica en la codificación (codificación segura), se comprueba en la fase de pruebas (SAST/DAST) y se mantiene en la explotación (gestión de vulnerabilidades y parcheo). El principio rector es que corregir un defecto de seguridad es más barato cuanto antes se detecta.
Principios de diseño seguro
Las normalizadoras (OWASP, NIST) coinciden en un conjunto de principios que deben guiar el diseño y la codificación:
-
Mínimo privilegio (Least Privilege): cada usuario, proceso o componente dispone solo de los permisos estrictamente necesarios para su función, reduciendo el impacto de una brecha.
-
Defensa en profundidad (Defense in Depth): se disponen múltiples capas de control, de modo que si una falla, otras siguen protegiendo la información (diseñar como si el cortafuegos ya estuviera comprometido).
-
Denegación por defecto (Deny by Default / Secure by Default): salvo los recursos públicos, todo acceso se deniega si no se concede explícitamente; el sistema arranca en un estado seguro.
-
Fallo seguro (Fail Securely): ante un error, el sistema no debe quedar en un estado que exponga datos ni conceda accesos indebidos.
-
Validación en servidor: los controles de acceso y la validación de entradas solo son fiables en código de servidor de confianza, nunca delegados al cliente, que el atacante puede manipular.
-
Superficie de ataque mínima y separación de privilegios.
OWASP Top 10 (2021)
El OWASP Top 10 es el documento de referencia sobre los riesgos de seguridad más críticos en aplicaciones web. En su versión 2021 las categorías, por orden, son:
| Código | Categoría |
|---|---|
| A01 | Pérdida de control de acceso (Broken Access Control) |
| A02 | Fallos criptográficos (Cryptographic Failures) |
| A03 | Inyección (Injection, incluye SQLi y XSS) |
| A04 | Diseño inseguro (Insecure Design) |
| A05 | Configuración de seguridad defectuosa (Security Misconfiguration) |
| A06 | Componentes vulnerables y obsoletos |
| A07 | Fallos de identificación y autenticación |
| A08 | Fallos de integridad de software y datos |
| A09 | Fallos de registro y monitorización de seguridad |
| A10 | Falsificación de peticiones del lado del servidor (SSRF) |
A01 – Broken Access Control ascendió al primer puesto en 2021 (era el quinto en 2017): es la categoría con más incidencias. Incluye la elusión de comprobaciones modificando la URL o el estado interno, las referencias directas inseguras a objetos (IDOR), la falta de control en métodos POST/PUT/DELETE de una API y la manipulación de metadatos como tokens JWT o cookies. Su mitigación exige aplicar el control en servidor, denegar por defecto y reutilizar un único mecanismo de control de acceso. La categoría A04 – Diseño inseguro fue de nueva creación en 2021 y refuerza precisamente la idea de seguridad por diseño y el modelado de amenazas.
Codificación segura frente a las amenazas típicas
La fase de codificación debe neutralizar los defectos recogidos en enumeraciones como CWE:
-
Inyección (A03): usar consultas parametrizadas / prepared statements frente a SQL Injection; escapar y codificar la salida frente a XSS; validar todas las entradas con listas de permitidos (allowlist).
-
Criptografía (A02): cifrar los datos sensibles en tránsito (TLS) y en reposo, con algoritmos vigentes y sin claves ni secretos incrustados en el código.
-
Autenticación (A07): gestión robusta de contraseñas, protección frente a fuerza bruta y sesiones seguras.
-
Componentes (A06): mantener actualizadas las dependencias de terceros (análisis de composición de software, SCA).
Verificación: pruebas de seguridad
El SDLC seguro incorpora herramientas y actividades de verificación:
-
SAST (Static Application Security Testing): análisis estático del código fuente sin ejecutarlo, para detectar patrones vulnerables.
-
DAST (Dynamic Application Security Testing): análisis dinámico de la aplicación en ejecución, incluido el fuzz testing.
-
Revisiones de código (manuales y automatizadas) y pentesting.
-
Integración de estas comprobaciones en la cadena DevSecOps / CI-CD.
Marcos y normas de referencia
-
NIST SP 800-218 – SSDF (Secure Software Development Framework), versión 1.1: organiza las prácticas en cuatro grupos: PO Prepare the Organization (preparar la organización: roles, formación, SDLC documentado), PS Protect the Software (proteger la integridad del código y los artefactos, firma de código), PW Produce Well-Secured Software (producir software bien asegurado: codificación segura, revisiones, análisis estático y dinámico) y RV Respond to Vulnerabilities (responder a las vulnerabilidades detectadas tras la entrega).
-
ISO/IEC 27034: seguridad de las aplicaciones a lo largo de su ciclo de vida.
-
ISO/IEC 27001 / 27002: controles de seguridad de la información, con dominios aplicables al desarrollo (adquisición, desarrollo y mantenimiento de sistemas).
-
Esquema Nacional de Seguridad (ENS), RD 311/2022: en España exige aplicar seguridad en el ciclo de vida de los sistemas del sector público, incluyendo el desarrollo y la gestión de cambios.
-
Métrica v3 contempla actividades de interfaz de seguridad en el desarrollo de sistemas de información.
Relación con la confidencialidad y disponibilidad en el puesto de usuario
Un desarrollo seguro contribuye directamente a las dimensiones clásicas de la seguridad —confidencialidad, integridad y disponibilidad— también en el puesto de usuario final: validar entradas y controlar accesos protege la confidencialidad de los datos; el registro y la monitorización (A09) permiten detectar incidentes; y una gestión adecuada de errores y de componentes evita caídas que comprometan la disponibilidad. La seguridad no termina con la entrega del software: la gestión continua de vulnerabilidades (parches, avisos, respuesta ante incidentes) es parte inseparable del desarrollo seguro.
Fuentes
-
OWASP Top 10:2021 — https://owasp.org/Top10/2021/
-
OWASP Top 10:2021 A01 Broken Access Control — https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
-
OWASP Developer Guide, Principles of security — https://devguide.owasp.org/en/02-foundations/03-security-principles/
-
OWASP Secure Product Design Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html
-
NIST SP 800-218, Secure Software Development Framework (SSDF) v1.1 — https://csrc.nist.gov/pubs/sp/800/218/final
-
BOE, Real Decreto 311/2022 (Esquema Nacional de Seguridad) — https://www.boe.es/eli/es/rd/2022/05/03/311