DevSecOps: 7 factores clave para implementar la seguridad en DevOps

DevSecOps, también conocida como SecDevOps, es una filosofía de desarrollo de software que promueve la adopción de la seguridad en todo el ciclo de vida del desarrollo de software (SDLC). DevSecOps va más allá de ser una herramienta o una práctica en concreto; favoreciendo la automatización de la seguridad, la comunicación y la escalabilidad.

DevSecOps nace como evolución de la metodología DevOps. Su principal motivación es automatizar la seguridad para responder a la aceleración en los ciclos de lanzamiento de software promovida por la adopción de DevOps. DevSecOps no solo añade elementos de seguridad a ciclos DevOps, sino que aplicada correctamente, hace de la seguridad una parte integral dentro de todo el proceso, desde el inicio hasta el final. Como consecuencia, el equipo de seguridad se compromete mucho más con el resto de equipos que intervienen en el SDLC, incluyendo Desarrollo y Operaciones. Esto elimina fricción, ya que la tensión natural que existe entre velocidad y seguridad se comparte por todos los equipos.

A pesar de, o tal vez debido, a su gran adopción, la metodología DevSecOps recibe críticas a su falta de concreción o guías específicas. En este post, queremos ofrecer siete consejos directamente aplicables que resuelven los problemas más habituales que observamos en los equipos que adoptan DevSecOps.   

1. Utilizar herramientas IAST para evitar falsos positivos y la puesta a punto de los SAST

Las herramientas Application Security Testing (AST), tipo SAST y DAST permiten a los desarrolladores encontrar vulnerabilidades, sin que sean expertos en seguridad. El problema es que, debido a enfoques anticuados y poco sofisticados, estas herramientas no ofrecen un nivel de precisión ideal. Para evitar esta falta de precisión, recomendamos la utilización de una herramienta de detección más precisa como es un IAST (Interactive Application Security Testing). Las herramientas IAST no requieren de una “puesta a punto” o revisiones manuales ya que no generan falsos positivos.

2. Integrar fallos de seguridad en las herramientas de colaboración para mejorar la coordinación

Integra el sistema de seguimiento de errores (“bug tracker”) que tu equipo esté utilizando, por ejemplo Jira, con las herramientas de seguridad para que los desarrolladores puedan visualizar los errores de seguridad como tareas habituales. El objetivo detrás de esta recomendación es que los desarrolladores no se alejen del entorno que utilizan habitualmente.

3. Definir métricas y umbrales para asegurar la calidad si la cadencia de despliegues acelera

De la misma forma que los errores de compilación paralizan el despliegue, los errores de seguridad también deberían hacerlo. Conocidos como “controles de seguridad” estos checkpoints aseguran que el código que llegue al CI/CD respete los estándares de seguridad. Crea checkpoints automáticos de seguridad para cumplir los objetivos de calidad, y paraliza el build si el número de vulnerabilidades sobrepasa un límite.

4. Automatizar la protección de errores de diseño para reducir la verificación manual (pentesting)

Para mitigar el cuello de botella que supone verificar manualmente estos errores, recomendamos automatizar la validación utilizando soluciones y arquitecturas que sean seguras desde el inicio. Los equipos de pentesters son más productivos cuando tienen una imagen clara de las zonas donde atacar.

5. Adoptar reporting continuo para ganar visibilidad sobre el histórico de la seguridad

El reporting continuo implica la generación de informes y métricas de seguridad que rastreen la evolución, el número y la severidad de las vulnerabilidades de cada lanzamiento. El objetivo es mitigar la falta de visibilidad sobre el histórico de la seguridad a medida que se van publicando nuevas versiones del software. Es recomendable utilizar herramientas como Jenkins Reports o Web Reports y mejorar los informes incluyendo la evolución de los fallos de seguridad.

6. Integrar la seguridad en las aplicaciones para mejorar el soporte a cloud

Adoptar “seguridad como código”, frente a enfoques dependientes de hardware o de entorno de red, significa que las aplicaciones se mantienen seguras allá donde vayan, sin necesidad de cambios de configuración para adaptarse a un nuevo despliegue o a una nueva versión de la aplicación.  

7. Asegurar la escalabilidad lineal y costes asequibles

Asegúrate de que la infraestructura de seguridad de tu aplicación no es un cuello de botella en lo que a rendimiento se refiere. Busca soluciones de seguridad que puedan escalar de forma constante y lineal en el tiempo.

Las siete recomendaciones que hemos expuesto en este artículo tienen como principal objetivo fortalecer a los desarrolladores para que puedan crear código de forma segura gracias a la automatización de la seguridad. Hdiv Security fue creada por y para desarrolladores desde sus inicios. Las claves descritas en este artículo, e incluso nuestro ADN como empresa, han perseguido siempre la filosofía DevSecOps incluso antes de que el término existiese. Para cualquier consulta relacionada con la automatización de la seguridad en aplicaciones, no dudes en contactar con nosotros.