¿Qué es DevSecOps?

DevSecOps integra las prácticas de seguridad en cada fase del desarrollo, garantizando que las vulnerabilidades se aborden en una fase temprana sin ralentizar su proceso de CI/CD.

DevSecOps destaca la importancia de incorporar pruebas y prácticas de seguridad en el proceso de desarrollo de software. La incorporación temprana de la seguridad al proceso de desarrollo (desplazamiento a la izquierda) ayuda a garantizar que la entrega rápida no se efectúe a expensas de las vulnerabilidades de seguridad.

¿Por qué utilizar un servidor de CI?

DevSecOps es un enfoque del desarrollo de software basado en la metodología DevOps. Al igual que «DevOps» fusiona «desarrollo» y «operaciones», el término «DevSecOps» combina «desarrollo», «seguridad» y «operaciones». La incorporación de «seguridad» subraya la importancia de integrar las consideraciones de seguridad en cada etapa del ciclo de vida de desarrollo del software.

La tríada de DevSecOps

El objetivo de DevSecOps es permitir a los equipos entregar software de forma más rápida y eficaz, manteniendo al mismo tiempo la base de código libre de vulnerabilidades de seguridad. Esta estrategia protege tanto a su organización como a sus usuarios de los ciberataques.

DevSecOps vs. DevOps

La metodología DevOps está diseñada para acelerar la entrega de software al tiempo que se mejora la calidad y se reducen los errores. Con raíces en el movimiento Agile, DevOps se desarrolló para abordar las incidencias con el enfoque tradicional de cascada para el desarrollo y la entrega de software.

En lugar de un proceso lineal de diseño, desarrollo, integración, pruebas y lanzamiento que puede durar varios años, DevOps anima a los equipos a hacer avanzar su trabajo a través de esos ciclos con rapidez y frecuencia. Para lograrlo, DevOps aboga por procesos de CI/CD robustos y automatizados que abrevien los plazos de entrega y proporcionen una retroalimentación rápida, creando un círculo virtuoso de mejora continua.

¿En qué se diferencia DevSecOps de DevOps? En realidad, nunca se pretendió que DevOps excluyera la seguridad. Sin embargo, mientras que el movimiento DevOps ayudó a derribar las fronteras entre los equipos de desarrollo y operaciones, los equipos de seguridad de la información habitualmente permanecían aislados. El término «DevSecOps» —junto con otras versiones, como «SecDevOps», «DevOpsSec» y «Rugged DevOps»— se acuñó con el fin de abordar esta cuestión.

El uso del término «DevSecOps» recuerda a los equipos que deben tener en cuenta la seguridad en el proceso de desarrollo e implementación del software. Esto incluye:

  • Ampliar la cultura del entendimiento y la responsabilidad compartidos a las cuestiones de seguridad.
  • Incorporar comprobaciones de seguridad al régimen de pruebas automatizadas de un proceso de CI/CD.
  • Asegurar la cadena de suministro de software, incluidas todas las dependencias y el propio proceso de CI/CD.
Prácticas DevSecOps

Del mismo modo que las pruebas de «desplazamiento a la izquierda» facilitan y agilizan la búsqueda y corrección de errores, las prácticas de seguridad son más fáciles de incorporar y más eficaces cuando se abordan en una fase más temprana del proceso de desarrollo.

¿Por qué es importante DevSecOps?

Nunca debe subestimarse el impacto potencial de las vulnerabilidades de seguridad en su software.

Además de los daños financieros y de reputación, las brechas de seguridad del software han provocado la filtración de grandes cantidades de datos sensibles, incluidos documentos internos e información personal de los clientes. Dependiendo de la jurisdicción aplicable, la filtración de datos de los usuarios puede acarrear graves sanciones económicas, así como responsabilidades legales.

A pesar de todo esto, el enfoque tradicional de la seguridad del software puede hacer que parezca más un estorbo que un activo. Las auditorías y los informes de seguridad ralentizan el progreso y le impiden poner sus últimas funcionalidades en manos de los usuarios. Sin embargo, si se opta por ignorar la importancia de la seguridad en el ciclo de vida del desarrollo de software (SDLC), se corre el riesgo de que el próximo ciberataque se convierta en noticia.

Aunque estos se convirtieron en escándalos que llenaron titulares, su origen fue mucho más mundano. Las vulnerabilidades existen porque los humanos escribimos código y los humanos cometemos errores. Otras veces, esos errores ya los han cometido otros antes y son más fáciles de reconocer (si sabe dónde buscar). A veces, sin embargo, son novedosos, quizá resultantes de una combinación de factores que no se habían dado antes de esa manera.

Para complicar aún más las cosas, casi todo el software incorpora dependencias —ya sea de código abierto o propietario— y no hay garantía de que el código de terceros no contenga vulnerabilidades. Por ello, asegurar su cadena de suministro de software es tan importante como evaluar la seguridad de su propio código fuente.

Así que, ¿cómo podemos garantizar la seguridad en el SDLC? El enfoque DevSecOps aplica los mismos principios que han permitido lanzamientos más rápidos y estables: desplazar la seguridad a la izquierda para que se aborde pronto y con frecuencia.

Pruebas de desplazamiento a la izquierda

A primera vista, podría parecer que para desplazar la seguridad a la izquierda solo se necesita añadir una etapa a su proceso de CI/CD para que su software esté disponible para ser probado y revisado por el equipo de seguridad.

Aunque hay lugar para las pruebas de seguridad manuales (como veremos), limitar su participación en los requisitos de seguridad a un paso al final del proceso de CI/CD significa que se pierde los beneficios de una retroalimentación rápida y regular por varias razones:

  • Realizar pruebas manuales lleva mucho tiempo, lo que significa que tiene que ralentizar las implementaciones o limitar las pruebas de seguridad a un subconjunto de versiones.
  • Para cuando se identifique cualquier problema de seguridad, la persona que escribió el código pertinente habrá pasado a otra cosa, lo que dificultará la aplicación de la corrección o recomendación.
  • Por último, limitar las pruebas de seguridad a un único paso del proceso da lugar a una mentalidad de «nosotros y ellos» entre la seguridad y el resto de la organización. Esto no ayuda a ninguna de las partes a conseguir lo que quieren: la publicación de un software que sea útil y seguro.
¿Cómo deben integrarse las pruebas de seguridad en el proceso de CI/CD?

Cómo incorporar las pruebas de seguridad anticipadas al proceso de desarrollo

Entonces, ¿qué significa en la práctica un enfoque en el que se incorporan las pruebas de seguridad de forma anticipada? Aunque no existe una solución universal, las siguientes herramientas y técnicas pueden ayudarle a integrar la seguridad en el SDLC.

Nombre embajadores de la seguridad

Aunque es importante una cultura de responsabilidad compartida, no basta con decirles a sus equipos de desarrollo que son responsables de la seguridad del software. Mantenerse al día de los últimos vectores de ataque y desarrollos de malware es un trabajo a tiempo completo, así que no puede esperar que todos tengan el mismo nivel de conocimientos.

Incorporar a un embajador de la seguridad en un equipo multidisciplinar para que enseñe a los demás y comparta con ellos buenas prácticas les ayudará a comprender y a promover la cultura de la colaboración con los profesionales de la seguridad.

Considere la seguridad como restricción de diseño

Lo ideal es tener en cuenta la seguridad antes de escribir nada de código. Debería incluirse entre los argumentos de los usuarios, comentarse en las reuniones de revisión de trabajo pendiente, y debatirse al planificar cada sprint. Al reflexionar acerca de cómo abordar una nueva funcionalidad, tómese su tiempo para hablar de los riesgos que puede entrañar y cómo mitigarlos.

Adoptar una estrategia de modelado de amenazas, como STRIDE, o utilizar una herramienta como OWASP, puede ayudarle a mantenerse al día mientras aprende al respecto. Aunque tener en cuenta la seguridad durante la fase de diseño no lo solucionará todo, es un buen comienzo, y le ayudará a promover la cultura DevSecOps.

Modelización de amenazas STRIDE

Incluir la seguridad en las pruebas automatizadas

La automatización es un principio básico de DevOps. Agiliza las tareas y garantiza que se realicen de forma coherente, y libera a las personas para que haga un trabajo más creativo. Si desea entregar software a los usuarios con regularidad y con frecuencia, es esencial añadir pruebas de seguridad automatizadas a su proceso.

Al escribir pruebas de unidades, de integración y de extremo a extremo, las características de seguridad deberían considerarse tan importantes como cualquier otra funcionalidad. Si su equipo ha estado incorporando requisitos de seguridad en los argumentos de los usuarios y debatiendo sobre modelos de amenazas durante el proceso de diseño, añadir pruebas que cubran las funciones de seguridad es una extensión natural de ese trabajo.

Añada herramientas de pruebas de seguridad a su proceso de CI/CD

Además de las pruebas que escribe usted mismo, existen varias herramientas de pruebas de seguridad que pueden ayudarle a generar confianza en la calidad de su código. Mientras que las herramientas tradicionales de análisis de seguridad no se adaptaban bien a un proceso de CI/CD automatizado, ahora existen herramientas de pruebas de seguridad de CI/CD diseñadas para la automatización. Estas se integran en su proceso de CI/CD y pueden informar de los resultados a través del panel de control o introducirlos directamente en las herramientas de seguimiento de errores. Como sucede con las pruebas automatizadas, vale la pena estructurar sus pruebas de modo que obtenga feedback lo más rápido posible.

Las herramientas de pruebas de seguridad para aplicaciones estáticas (SAST, del inglés Static application security testing), realizan análisis de código estático para comprobar si su código fuente presenta defectos de seguridad, como sobrecargas del búfer y oportunidades de inyección SQL. Dado que el análisis estático se ejecuta en el código fuente, puede ejecutarse en una fase temprana del proceso de CI/CD tan pronto como se hayan confirmado los cambios.

Las herramientas de SAST son específicas de cada lenguaje, y algunas se integran con el IDE para ofrecer feedback continuo a medida que escribe, o la opción de ejecutar pruebas bajo solicitud. Al orientar a los desarrolladores hacia la línea de código específica que contiene la vulnerabilidad, las herramientas de SAST ofrecen datos objetivos que permiten solucionar las incidencias más rápidamente. No obstante, los falsos positivos pueden suponer un problema, así que ser capaz de silenciar o desechar ciertas alertas es esencial si desea evitar el riesgo de que todos los resultados de SAST se conviertan en distracciones.

Uso de herramientas SAST en CI/CD

Las pruebas de seguridad para aplicaciones dinámicas (DAST, del inglés Dynamic application security testing) son el complemento ideal de SAST. Se basa en un enfoque de pruebas tipo caja negra para la aplicación que se está ejecutando, donde se comprueban vulnerabilidades conocidas como scripts intersitios, inyección SQL y de comandos, y configuración de servidor no segura. Como las herramientas de DAST requieren que la aplicación se compile e implemente en un entorno de pruebas, suelen utilizarse en una fase más avanzada del proceso de CI/CD.

Asegure su cadena de suministro de software

El potencial de los ciberataques es enorme. Los delincuentes pueden encontrar a menudo un fallo de seguridad en una pieza de software muy utilizada. Estos ataques y otros similares son un recordatorio esencial de la importancia de asegurar su cadena de suministro de software.

¿Qué entendemos por «cadena de suministro de software»? En pocas palabras, es todo lo que interviene en el desarrollo y la entrega de su software. Todo desarrollo de software requiere otro software, desde componentes reutilizables y bibliotecas hasta IDE, marcos de trabajo y herramientas de compilación. La seguridad de la cadena de suministro de software implica evaluar la seguridad del resto del software del que depende y asegurar sus procesos de desarrollo.

Puede evaluar la primera utilizando herramientas de composición de software o de análisis de componentes (SCA). Las herramientas de SCA deberían explorar no solo has dependencias que ha añadido, sino también las dependencias de éstas a lo largo de toda la cadena de suministro: un perfecto ejemplo de una tarea que es mejor encomendar a los ordenadores, especialmente si pensamos en con qué frecuencia se añaden dependencias nuevas a un proyecto.

Cadena de suministro de software

Además de ejecutarse automáticamente como parte del proceso de CI/CD, algunas herramientas de SCA están disponibles como complementos del IDE para ofrecer feedback instantáneo. Como sucede con las pruebas de seguridad estáticas y dinámicas, las pruebas de SCA se limitan a las vulnerabilidades que las herramientas conocen, así que asegúrese de que las herramientas que escoja se actualicen con regularidad con nuevas vulnerabilidades y cubran las áreas relevantes para su producto y organización.

Incorpore al equipo rojo

El concepto del equipo rojo nace en los videojuegos de guerra, donde se pide a miembros de su propio equipo que desempeñen el papel de enemigo en un ataque simulado para identificar las debilidades en sus propias defensas y estrategias. Este mismo enfoque se ha utilizado con grandes resultados en el desarrollo de software, en ocasiones en forma de pruebas de penetración o pirateo ético, para encontrar nuevas e inesperadas vulnerabilidades.

Para que un equipo rojo funcione con eficacia, este no puede haber participado en el desarrollo del sistema que se va a probar. Al igual que con las pruebas exploratorias, el trabajo con un equipo rojo requiere que los testers piensen de forma diferente y utilicen el software de un modo distinto al previsto.

Un equipo rojo puede trabajar tanto un entorno representado (idealmente lo más similar posible al de producción) o en un sistema de producción en vivo. Si elige esta última opción, tendrá que tener confianza en los modos de fallo de su software o contar con usuarios muy tolerantes (y ejecutivos de nivel C).

Trate todas las vulnerabilidades como errores

Un enfoque DevSecOps implica que todo el mundo asuma la responsabilidad de la seguridad de su software. Por ello, ya es hora de dejar de pensar en las incidencias de seguridad como si no tuviesen nada que ver con los errores "normales". Todos los fallos o vulnerabilidades que descubra en su sistema corresponden al mismo backlog que todas las demás incidencias, y deberían priorizarse junto con ellas.

Todo el equipo, no solo el embajador de seguridad, debe ser responsable de solucionar las vulnerabilidades. Esto ayudará a todos a aumentar sus conocimientos y experiencia en materia de seguridad para que puedan utilizarlos en la base de código actual y en futuros proyectos.

Monitorice la producción

A pesar de todos sus esfuerzos de las etapas anteriores del SDLC, todavía existe el riesgo de que un hacker encuentre alguna debilidad en su sistema en ejecución. Vale la pena invertir en firewalls y en herramientas de monitorización para proteger tanto a su organización como a sus usuarios. Las herramientas de autoprotección de aplicaciones de tiempo de ejecución (RASP, del inglés Runtime application self protection) son la última incorporación a estas defensas, y su función es detectar y bloquear el comportamiento sospechoso.

Conclusión

  • El enfoque DevOps implica bucles de retroalimentación regulares diseñados para ayudarle a mejorar lo que está creando y lanzar los cambios más rápidamente.
  • Desplazar la seguridad hacia la izquierda significa considerar la seguridad para todo el equipo en cada etapa del SDLC.
  • Integrar la seguridad en su proceso de CI/CD significa que obtendrá con regularidad feedback sobre la seguridad de su aplicación, y podrá mejorarla del mismo modo que el resto de sus funcionalidades.
  • Asegurar su cadena de suministro de software es tan importante como asegurar el código de su aplicación. Comprobar si existen vulnerabilidades conocidas y protegerse frente a ellas le asegurará, al menos, que su software está a la altura de los atacantes, y que no le deja indefenso ante vulnerabilidades conocidas.
  • Tratar cualquier nueva vulnerabilidad como un error más por clasificar, reparar y testear en el futuro irá fortaleciendo su software con el tiempo.
  • DevOps y DevSecOps tienen que ver tanto con la cultura como con las herramientas y los procesos. Integrar la seguridad en el proceso de desarrollo de software requiere una cultura de responsabilidad compartida.