Seguridad ofensiva
La seguridad no se pega al final del proyecto. Esta es la guía que compartimos en nuestro taller del OTD Challenge 2024: cómo integrar la seguridad en cada fase del desarrollo y llevarla al pipeline con DevSecOps.
El 18 de abril de 2024, por la tarde, impartimos en el Palacio de Congresos Baluarte de Pamplona un taller dentro del OTD Challenge, el evento de referencia de la transformación digital en Navarra organizado por la Fundación Industrial Navarra. El título era directo: "S-SDLC: cómo integrar la ciberseguridad en mi ciclo de vida de desarrollo". Esta guía recoge y ordena lo que contamos allí, para que sirva a cualquier equipo que construya software y quiera dejar de tratar la seguridad como un trámite de última hora.
Porque ese es el error de fondo que vemos una y otra vez: la seguridad se intenta "añadir al final", justo antes de salir a producción, cuando el diseño ya está cerrado y el código ya está escrito. En ese punto, cada fallo que aparece obliga a rehacer arquitectura, reabrir código y renegociar plazos. Corregir una vulnerabilidad en producción cuesta mucho más (en tiempo, en dinero y en riesgo) que haberla evitado en la fase de diseño. La alternativa tiene nombre y método: seguridad desde el diseño, integrada en cada etapa del ciclo de vida del desarrollo.
Un S-SDLC (Secure Software Development Life Cycle) es, sencillamente, el ciclo de vida de desarrollo de software de siempre, pero con prácticas de seguridad incorporadas en todas y cada una de sus fases. No es una etapa nueva que se añade al final ni un equipo aparte que revisa cuando el resto ha terminado. Es una manera de trabajar en la que la seguridad acompaña al producto desde que se recogen los primeros requisitos hasta que se retira.
La idea que resume todo esto es security by design: pensar en la seguridad cuando aún es barata cambiarla, es decir, cuando todavía estás decidiendo qué construir y cómo. Cuanto antes entra la seguridad en la conversación, menos cuesta y más eficaz resulta. Un S-SDLC no busca hacer el desarrollo más lento, sino evitar el frenazo caro del final: la vulnerabilidad crítica descubierta en el último pentesting, la que obliga a parar el despliegue.
Integrar la seguridad en el ciclo de vida significa saber qué prácticas tocan en cada etapa. Este es el mapa que usamos:
Dos de estas piezas son servicios que prestamos a diario: el análisis de código fuente cubre la fase de codificación con revisión estática y de dependencias, y el pentesting de aplicaciones ataca la fase de pruebas con la misma mentalidad ofensiva que aplicamos en el resto de nuestra seguridad ofensiva. Si quieres el panorama completo de esa disciplina, lo desarrollamos en nuestra guía de pentesting, análisis de vulnerabilidades y red team.
Tener buenas prácticas en cada fase es el qué. DevSecOps es el cómo hacerlas sostenibles: llevar esa seguridad al pipeline de integración y despliegue continuo (CI/CD) de forma automatizada, para que se ejecute sola en cada cambio de código en lugar de depender de que alguien se acuerde.
La diferencia de fondo es de responsabilidad. En el modelo antiguo, la seguridad era un silo al final del proceso: un equipo que revisaba cuando ya no había margen. En DevSecOps, la seguridad es responsabilidad de todo el equipo, integrada en el flujo de trabajo de desarrollo y operaciones. El análisis estático, el escaneo de dependencias y las pruebas de seguridad se enganchan al pipeline y devuelven el resultado en minutos, mientras el contexto del cambio sigue fresco. Es esa cultura y esa automatización lo que trabajamos en nuestro servicio de DevSecOps, y lo que enseñamos a los equipos de desarrollo en la formación en desarrollo seguro.
Ninguna herramienta funciona sin las personas que la usan. Por muy automatizado que esté el pipeline, quien escribe el código sigue decidiendo si valida una entrada o si guarda bien un secreto. Por eso la concienciación y la formación específica de los desarrolladores son parte del S-SDLC, no un extra.
Hay una razón de negocio y una razón normativa, y las dos empujan en la misma dirección. La de negocio ya la hemos visto: cada vez se desarrolla más software propio, más conectado y con más dependencias, y arreglar los fallos tarde es caro y arriesgado. Un S-SDLC reduce el número de vulnerabilidades que llegan a producción y el coste de las que aparecen.
La normativa refuerza el argumento. El CRA (Cyber Resilience Act), el reglamento europeo de ciberresiliencia para los productos con elementos digitales, empuja precisamente la "seguridad desde el diseño": obliga a los fabricantes a incorporar la seguridad a lo largo del ciclo de vida del producto, a gestionar sus vulnerabilidades y a mantenerlo con parches durante un periodo de soporte. Dicho de otro modo, el CRA convierte en obligación legal buena parte de lo que un S-SDLC ya hace por convicción. Si fabricas o vendes producto conectado en la UE, en nuestra consultoría de adecuación al CRA te ayudamos a encajar el desarrollo seguro dentro de lo que exige el reglamento.
La conclusión del taller fue la misma con la que lo cerramos aquí: la seguridad no se pega al final, se diseña desde el principio. Un S-SDLC no es un proyecto que se acaba, sino una forma de construir software que sale más rápido a producción porque no arrastra sorpresas de última hora. Y esa forma de trabajar se puede empezar hoy, con lo que ya tienes en marcha.
Te ayudamos a montar tu ciclo de vida de desarrollo seguro: revisión de código, pentesting de aplicaciones, seguridad en el pipeline y formación para tu equipo. Cuéntanos cómo desarrolláis y te decimos por dónde empezar.
Ver el servicio de DevSecOpsO escríbenos a [email protected].
