I would like to view this page in
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.
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.
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.
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:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
He aquí algunos pasos adicionales que puede dar para reforzar la seguridad de sus procesos de compilación.
La orquestación de lanzamientos es la capacidad de coordinar las tareas automatizadas realizadas por varios sistemas para entregar las actualizaciones de software a los usuarios.
La funcionalidad Pre-tested Commit de TeamCity le permite verificar remotamente sus cambios ANTES de confirmarlos en el VCS.