Informe PulseMeter: Cadenas de suministro de software

Los recuerdos no tan lejanos de incidentes de seguridad como Log4Shell y el ataque a SolarWinds mantienen los ataques a la cadena de suministro de software en la mente de los desarrolladores.

Las organizaciones pueden tomar medidas para detectar y disuadir los ataques maliciosos a la cadena de suministro, incluido el inventario de materiales de software (SBOM), que recientemente exigió el gobierno federal de EE. UU. Los SBOM enumeran los componentes integrados en el código para que los usuarios de estas aplicaciones y paquetes de software puedan rastrear posibles exposiciones a vulnerabilidades existentes que aún no se han descubierto.

Hacia fines de 2022, Techstrong Research consultó a nuestra comunidad de lectores de DevOps, cloud native, ciberseguridad y transformación digital para conocer su opinión sobre los SBOM. Estos fueron sus hallazgos:

• Los ataques a la cadena de suministro de software preocupan a todos.

• Muchas organizaciones ya usan SBOM.

• Los SBOM por sí solos no son suficientes.

Los ataques a la cadena de suministro de software preocupan a todos

La investigación reveló que más del 78 % de las personas consultadas están algo preocupadas por los ataques a la cadena de suministro de software, y el 40 % de quienes respondieron están muy preocupados. Esto tiene mucho sentido, porque estos actos maliciosos suelen tener gran repercusión y pueden causar daños enormes. Sin embargo, el 25 % de las personas consultadas mantiene una actitud pasiva frente a las vulnerabilidades de la cadena de suministro y no analiza exhaustivamente el código ni las bibliotecas de código abierto de terceros que utiliza.

Al preguntarles sobre los SBOM en general, más del 55 % de quienes respondieron indicó que ya los genera, y entre el 70 y el 90 % de ese grupo también los publica.

Muchas organizaciones ya usan SBOM

Desde diciembre de 2022, una orden ejecutiva exige contar con SBOM para todo el software que compra el gobierno de EE. UU. Si bien los SBOM no pueden ni resolverán directamente los ataques al software, la información que proporcionan es útil para identificar software vulnerable y mitigar posibles vectores de ataque.

Un inventario de materiales de software proporciona información detallada sobre el software y las bibliotecas que componen las aplicaciones, y presenta datos fundamentales sobre lo que podría estar oculto en el código para evaluarlo más adelante. Esto mejora la respuesta ante vulnerabilidades, ya que permite a los desarrolladores identificar versiones vulnerables de los componentes y, junto con las herramientas de seguridad adecuadas, mitigar rápidamente las funciones en riesgo.

Estos son los beneficios de usar una lista de materiales de software:

• Mejora la respuesta ante vulnerabilidades y la seguridad. Con un SBOM, puedes verificar los componentes y sus versiones en bases de datos de vulnerabilidades y asegurarte de que no haya vulnerabilidades potenciales.

• Mejora el cumplimiento. Con los SBOM, puedes identificar fácilmente los componentes que no están permitidos en un marco de cumplimiento específico.

• Mejora los informes. Con los SBOM, puedes comprender los factores históricos que impulsan las soluciones de seguridad.

Los SBOM por sí solos no son suficientes

La investigación muestra que, tras años de trabajo en silos, los equipos de seguridad de aplicaciones y desarrollo pronto tendrán que unir fuerzas y colaborar para entregar código seguro y cumplir con los requisitos de la organización.

Como el 78 % de las personas que participaron en nuestra investigación siente algo de temor ante los ataques a la cadena de suministro de software, el momento de actuar es ahora. Debemos enseñar principios de seguridad a los desarrolladores para que puedan elegir paquetes menos riesgosos mientras programan y crear procesos continuos que rastreen y corrijan las nuevas vulnerabilidades a medida que surjan.

Además, la investigación muestra que publicar un SBOM es necesario, pero no suficiente por sí solo para ayudar a las organizaciones a proteger su código.

Piensa en un SBOM como una lista de ingredientes. Se genera la lista y, aunque al principio todo parece saludable, pronto descubres que hay un ingrediente perjudicial para ti, o que un lote fue alterado.

El descubrimiento conduce a la mitigación, pero descubrir el problema no basta para mitigarlo.

El código abierto necesita seguridad y automatización

De las personas encuestadas, el 25 % respondió que depende del código abierto por su funcionalidad.

La seguridad del código abierto sigue siendo, en gran medida, un proceso manual. Por eso, un excelente primer paso para reforzar la seguridad de la cadena de suministro de código abierto es obtener tecnología automatizada para generar SBOM. Automatizar tus SBOM te permitirá identificar rápidamente problemas de seguridad y cumplimiento. También mejorará el seguimiento de vulnerabilidades en tus bibliotecas de código abierto.

Para proteger la cadena de suministro de software se necesita un enfoque dinámico, un esfuerzo conjunto entre los equipos de seguridad y desarrollo, y hacerlo en todas las etapas.

Tanto si los componentes integrados en tu código representan una parte grande o pequeña del software que implementas, como si se importan al código como una dependencia de terceros o desde un contenedor base, la seguridad es fundamental.

Descubre más sobre los hallazgos del informe Techstrong PulseMeter.