La modernización de las operaciones aumentará la necesidad de seguridad en la cadena de suministro de software.
No es de sorprender que hoy en día los aspectos de seguridad de la cadena de suministro de software se vean amenazados. Primero, log4j apareció en las noticias y puso a todos a trabajar para mitigar la vulnerabilidad muy generalizada y problemática en la cadena de suministro de software.
Más recientemente, Spring4Shell apareció en nuestro radar: otra vulnerabilidad introducida por el marco que causa caos para las empresas que necesitan abordar la amenaza.
Por lo tanto, fue un placer ver que GitHub introdujera una nueva funcionalidad orientada a la seguridad de la cadena de suministro de software. Fue especialmente agradable después de haber digerido el último informe de Sonatype sobre el estado de la cadena de suministro de software , en el que proporcionaron estadísticas que deberían asustar a cualquier tecnólogo preocupado por la seguridad, sin importar su función. De interés:
- Actualmente hay 37 millones de versiones de componentes OSS disponibles
- El 29% de los proyectos populares contienen al menos una vulnerabilidad de seguridad conocida
- Aumento interanual del 650% en ciberataques dirigidos a proveedores de código abierto
Estos hallazgos son particularmente preocupantes porque el informe determinó que “la aplicação moderna promedio contiene 128 dependencias de código abierto ”.
Ahora, ya sabes que no soy fanático de hacer matemáticas, pero hagamos algunas.
En la Estrategia sobre el Estado de las Aplicação de 2022 encontramos varias estadísticas que vale la pena destacar:
- Las aplicações modernas (nativas de contenedores y móviles) comprenden un promedio del 33 % de la cartera de aplicaciones empresariales
- Las empresas de todas las industrias mantienen una cartera de aplicaciones promedio de alrededor de 200 aplicações.
Entonces, el 33% de 200 significa que la empresa típica tiene un promedio de 66 aplicações modernas en su cartera. Si tomamos el promedio de dependencias de código abierto de Sonatype, esto significa que una empresa promedio podría tener que asumir la carga de proteger 8448 dependencias de código abierto diferentes. Ahora bien, es casi seguro que hay superposición entre aplicações. Las aplicaciones nativas de contenedores casi siempre comparten el mismo entorno de orquestación de contenedores (Kubernetes es el rey de los COE en este momento) y, por lo tanto, la carga es en realidad menor en términos de dependencias específicas, pero no en el sentido de que cada una de esas instancias deba actualizarse en caso de una vulnerabilidad.
Sin hacer más cálculos, simplemente convengamos en que asegurar la cadena de suministro de software hoy en día es una tarea importante dado el tamaño de las carteras de aplicaciones y la inclusión de dependencias de código abierto.
La nueva funcionalidad de GitHub ayuda a solucionar este problema al "encontrar y bloquear vulnerabilidades que actualmente solo se muestran en la diferencia enriquecida de una solicitud de extracción". En otras palabras, se integra en el flujo de trabajo de CI/CD y escanea, en tiempo real, en busca de vulnerabilidades conocidas.
Fresco. Ésta no es una capacidad inusual. DevSecOps ha impulsado este tipo de movimiento de seguridad de “desplazamiento a la izquierda” durante años. La mayoría de los pipelines de CI/CD, independientemente de sus herramientas, son capaces de realizar análisis de seguridad en el código. Sin embargo, no todos integran la capacidad de escanear en busca de vulnerabilidades conocidas que pueden estar profundamente ocultas en dependencias o ser el resultado de un error lógico que no es tan fácil de detectar.
Ahora bien, por supuesto que debes incluir tanta seguridad como sea posible en el flujo de trabajo de CI/CD para eliminar vulnerabilidades y errores que te puedan perjudicar más adelante. Pero no es ese el motivo por el que hicimos este ejercicio.
SRE, software y seguridad de la cadena de suministro
La razón por la que señalo el problema con la cadena de suministro de software existente es que solo empeorará a medida que las organizaciones modernicen sus operaciones con enfoques de SRE. Esto se debe a que, en esencia, las prácticas de SRE dependen de la automatización que, como seguramente ya sabe, depende de software y scripts, muchos de los cuales son (espere) de código abierto.
De hecho, no debería sorprendernos saber que muchas de esas herramientas de código abierto utilizadas por DevOps serán utilizadas por SRE. Si desea simplificar los roles y las relaciones, los SRE son DevOps para producción. Mientras que los profesionales de DevOps generalmente se centran en el proceso de creación y lanzamiento de software, los SRE se centran en el proceso de operaciones de software. Esto significa no solo las aplicaciones, sino también los servicios de seguridad y entrega de aplicaciones, así como las plataformas y entornos (como el núcleo, la nube y el borde). El alcance del personal de SRE abarca la pila de TI, lo que hace que su tarea sea significativamente más difícil cuando se trata de proteger la cadena de suministro de software.
Basta decir que la seguridad de la cadena de suministro de software debería ser una preocupación para todas las organizaciones porque afecta todo el ciclo de vida de las aplicaciones: desde el desarrollo hasta la compilación, el lanzamiento, la implementación y la operación.
Y debería ser una preocupación para las organizaciones que esperan sobrevivir a su viaje de transformación digital . Se avecina un cambio significativo en las empresas de todo el mundo y que afecta al corazón mismo de la organización: la arquitectura empresarial.
La mayoría de las arquitecturas empresariales se establecieron hace décadas, basándose en marcos desarrollados bajo la premisa de que los recursos eran fijos e inflexibles y que el centro de datos era el foco del universo empresarial.
Nada de eso es cierto hoy en día, y aunque lo fuera, el negocio también ha cambiado. Ese negocio es ahora cada vez más digital, y un negocio digital con procesos basados en datos no puede representarse adecuadamente con una arquitectura diseñada para representar un negocio físico con procesos impulsados por humanos. Es necesario modernizar la arquitectura empresarial y, al hacerlo, incorporar nuevos dominios, como el de las operaciones de SRE.
Y lo son. Nuestra investigación de este año encontró que el 37% de las organizaciones ya han adoptado operaciones de SRE para modernizar aplicaciones y operaciones, y otro 40% planea hacerlo en los próximos 12 meses. Eso significa herramientas y scripts, software y datos, y todo un conjunto de tecnologías que respaldarán este nuevo rol dentro de la organización.
Y con el software, los scripts y las pilas vienen las cadenas de suministro y la seguridad. Y lo único que hemos aprendido de DevOps y que no se puede ignorar a medida que se modernizan las operaciones es que las prácticas de SRE generarán gran parte de la misma deuda técnica y desafíos de seguridad.
La buena noticia es que, a diferencia de DevOps y los procesos de compilación, las operaciones de SRE serán una nueva práctica para las organizaciones. Y establecer nuevas prácticas significa establecer nuevas formas de operar, incluida la incorporación de la seguridad desde el principio.