Equilibrio sorprendente: redefinición de la seguridad del software con 'Shift Left' y SDLC Guardrails

Todos los Artículos

TL; DR

En los últimos años, la industria tecnológica ha defendido fervientemente el concepto de “giro a la izquierda” en el desarrollo de software, abogando por una integración temprana de las prácticas de seguridad en el ciclo de vida del desarrollo. Este movimiento tiene como objetivo empoderar a los desarrolladores con la responsabilidad de garantizar la seguridad de su código desde el inicio del proyecto. Sin embargo, si bien las intenciones detrás de este enfoque son nobles, la realidad muestra un panorama más matizado, en el que la noción simplista de depender únicamente de los desarrolladores para defender seguridad de la cadena de suministro de software resulta inadecuado. En este artículo, presentaré un enfoque de equilibrio complementario: barreras de seguridad SDLC dirigidas por CISO: medidas de control automático que gobiernan o hacen cumplir la política de seguridad de SDLC.

¿Quién dejó mi queso?

El paradigma de cambio a la izquierda, en esencia, apunta a abordar las preocupaciones de seguridad en las etapas iniciales de desarrollo, esperando que los desarrolladores incorporen de manera proactiva medidas de seguridad dentro de su código. Es una ideología atractiva en la que los desarrolladores tienen la tarea de identificar vulnerabilidades e implementar controles de seguridad mientras escriben e implementan su código.

Sin embargo, este enfoque idealista encuentra importantes desafíos en la implementación práctica. Aunque dominan la codificación, es posible que los desarrolladores carezcan de una experiencia integral en técnicas y mejores prácticas de seguridad. Su enfoque principal gira en torno al cumplimiento de los requisitos funcionales, y esperar que posean una comprensión exhaustiva del panorama en constante evolución de la ciberseguridad no es realista.

Además, las limitaciones de tiempo y las presiones del proyecto a menudo resultan en compensaciones entre la seguridad y el cumplimiento de los plazos. En la prisa por ofrecer funciones rápidamente, los desarrolladores podrían pasar por alto sin darse cuenta posibles lagunas de seguridad o emplear prácticas de codificación menos seguras, dejando las vulnerabilidades sin abordar hasta etapas posteriores. Al fin y al cabo, sus KPI están orientados a la velocidad y la seguridad siempre estará en segundo lugar para la mayoría de ellos.

Ingrese a las barreras de seguridad de CI/CD

Aquí es donde se hace evidente la necesidad de implementar “barandillas” de seguridad en el proceso de integración/implementación continua (CI/CD). Las barreras de seguridad actúan como puntos de control automatizados integrados en el proceso de desarrollo, lo que garantiza que las medidas de seguridad no dependan únicamente de intervenciones manuales o de la experiencia o motivación de los desarrolladores individuales.

Los Guardrails sirven como guardianes proactivos, monitoreando y aplicando constantemente estándares, políticas y reglas de seguridad durante todo el ciclo de vida de desarrollo de software (SDLC). Estas comprobaciones automatizadas pueden abarcar varios aspectos de seguridad, incluidos, entre otros, incluir en listas de bloqueo paquetes defectuosos, detener código que contiene vulnerabilidades críticas, fallar pruebas de análisis de código estático o tiene dependencias problemáticas, y el cumplimiento de estándares de cumplimiento o políticas seguras de SDLC (por ejemplo, código revisión para cada confirmación).

Utilizando conceptos de política como código, uno puede crear casi cualquier regla que pueda imaginarse implementada como barrera de seguridad. A continuación se muestran algunos ejemplos de reglas de barandillas de acuerdo con NIST 800-204D:

Ejemplo de barandilla

Reglas ejemplares de barandillas:

  1. Estación de trabajo para desarrolladores
    • Verificar el conjunto de seguridad de endpoints de la estación de trabajo del desarrollador
  2. SMC
    • Verificar las reglas de protección de sucursales: aplicar revisiones múltiples\específicas
    • Verifique que los archivos CI sean modificados únicamente por el personal autorizado
    •  Verifique que el escaneo de secretos esté implementado y que no se detecten secretos.
  3. CI
    • Verifique que el escaneo de códigos esté en su lugar.
    • Verifique que los resultados del escaneo de código estén debajo de una barra predefinida
  4. Dependencias
    • Verifique la licencia de código abierto.
    • Verificar que las vulnerabilidades de código abierto cumplan con la política de la organización
  5. Los artefactos
    • Verifique que los artefactos de señales de identidad sean correctos.
    • Verificar las vulnerabilidades de los artefactos finales.

Barandillas, no pasamanos

Al integrar barreras de seguridad en el proceso de CI/CD, las organizaciones pueden aplicar sistemáticamente protocolos de seguridad y generar un producto seguro sin depender únicamente de los desarrolladores para garantizar medidas de seguridad integrales. Teniendo en cuenta que los desarrolladores pueden eludir las medidas de seguridad en aras del ritmo de desarrollo, el enfoque de barreras de seguridad hace que estas decisiones sean imposibles o al menos visibles, por lo que pueden tomarse en cuenta, tanto a nivel de compilación única (por ejemplo, decidir sobre la confiabilidad del artefacto) ) y a nivel organizacional (comprender lo que se puede y no se puede esperar de los desarrolladores de la organización). Las herramientas automatizadas pueden señalar o incluso bloquear posibles vulnerabilidades o problemas de incumplimiento antes de que la nueva versión se lance a producción o se entregue al cliente. Después de todo, abordar un problema de seguridad en la fase de desarrollo y no después de la entrega es mucho más fácil, rápido y económico.

Es imperativo reconocer que, si bien el desplazamiento hacia la izquierda fomenta la participación de los desarrolladores en las prácticas de seguridad, no debería eximir a otras partes interesadas (profesionales de seguridad, ingenieros de DevOps y equipos de control de calidad) de sus funciones. Si usted es un producto de seguridad, AppSec, DevSecOps o CISO, entonces ya sabe que "desplazar hacia la izquierda" la responsabilidad hacia los desarrolladores no le quita la responsabilidad de sus hombros. Dado que la mayoría de los CISO y sus equipos no provienen de I+D, los entornos de desarrollo de software históricamente estuvieron fuera de su vista. Tradicionalmente se centrarían en la seguridad operativa, la seguridad de la red y la conectividad entre organizaciones. El enfoque de barreras de seguridad es una forma de llevar “delicadamente” a los CISO al salvaje oeste de los entornos de desarrollo, recuperando el control sobre lo que se les contabiliza.. Por "delicadamente" me refiero a "colaborativamente". Dado que la seguridad del producto es un esfuerzo conjunto de los equipos de seguridad y desarrollo, la colaboración entre estas entidades es esencial para diseñar e implementar barreras de seguridad sólidas que fortalezcan el proceso de CI/CD contra posibles amenazas a la seguridad sin impedir la velocidad del desarrollo.

La integración de los principios cambiantes de la izquierda con el establecimiento de barreras de seguridad en el proceso de CI/CD es un buen equilibrio. Los desarrolladores siguen siendo responsables de escribir código seguro y comprender los principios básicos de seguridad, mientras que el equipo de seguridad decide los estándares que debe cumplir el producto para ser lanzado. Luego, las barreras de seguridad se automatizan en consecuencia en herramientas y procesos que actúan como red de seguridad, monitoreando y reforzando continuamente los estándares de seguridad y la política de SDLC. Las barandillas son un paso esencial hacia productos que sean seguros por diseño y por defecto.

Resumen

En conclusión, aunque bien intencionado, el concepto de desplazamiento hacia la izquierda no garantiza una seguridad integral del software únicamente mediante la participación de los desarrolladores. Para reforzar la integridad y confiabilidad del artefacto de software final, las organizaciones deben adoptar la implementación de barreras de seguridad dentro del proceso de CI/CD. Este enfoque combinado no solo eleva la postura de seguridad del software, sino que también fomenta un entorno colaborativo donde los desarrolladores, los profesionales de la seguridad y las herramientas de automatización trabajan sinérgicamente hacia el objetivo común de crear software seguro.

Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.