En el artículo anterior expusimos la necesidad de proteger el software que tú, tu equipo o tu empresa construís y desplegáis en vuestra infraestructura. Hoy vamos a describir cómo diseñarlo a alto nivel.

El compromiso

Ya sea porque un análisis detectó carencias de seguridad en tu software o porque alguna normativa te obliga a mejorarla, lo cierto es que hay que comunicar a los equipos y a las partes interesadas que habrá trabajo nuevo (y adicional) para adoptar un proceso distinto.
Sé amable, apoya a los equipos y consigue los acuerdos necesarios para implantar el ciclo con éxito.

El proceso

Lo primero es lo primero: es imprescindible definir un proceso transversal, con fases claramente definidas, para cada pieza de código que se cree.
En el nuevo ciclo no se admite una falsa sensación de avance, así que en cuanto un pipeline falle... ¡detenlo!
No se avanza hasta que desarrolladores, equipos y organizaciones adopten la nueva forma de hacer las cosas. Y este es el punto donde quienes patrocinan y apoyan el SSDLC deben mantenerse firmes y no aceptar ni un solo intento de negociación para volver al estado anterior.

Fases

Suponiendo que tienes un pipeline automatizado con cualquier herramienta del mercado (GitLab, GitHub, etc.), puedes seguir estas etapas:

Pipeline con cuatro etapas: build, lint-security, test y deploy

Olvida el lenguaje de programación y la herramienta de pipeline, y centrémonos en las etapas.

1. Build

La más simple: compilar el código.

2. Lint-Security

Aquí está la clave. Por supuesto, podrías diluir la seguridad dentro de la fase de compilación, pero definirla como una fase distinta subraya su importancia.
Aquí combinas tus puertas de calidad (linting) y aplicas tus herramientas de análisis estático (SAST) y de análisis de composición de software (SCA). Fíjate en el plural: no confíes en una sola herramienta, usa más de una si puedes.

3. Test

Ejecuta las pruebas necesarias para validar el cambio, pero ahora sabiendo que el código compila y es seguro.

4. Deploy

Despliega el código en tu gestor de repositorios de software, y aquí es donde hay que cerrar la puerta al software inseguro. Haz que tu herramienta de pipeline sea la única capaz de desplegar en el repositorio, o habrás abierto la mayor puerta trasera del proceso.

Conclusión

Llevar a organizaciones y equipos a un proceso completamente nuevo no será rápido ni fácil. Necesitas mano izquierda y diseñar una hoja de ruta realista de dónde estás y dónde quieres estar. Lo cierto es que merecerá la pena, para ti, para tus compañeros de seguridad y, sin duda, para tu organización. En el próximo artículo intentaremos mostrar un ejemplo real de cómo implementarlo.