Protege tu SBOM en Google Cloud

En los últimos años, la seguridad de la cadena de suministro de software ha sido una prioridad tanto para los gobiernos como para las empresas. Tras Log4Shell a finales de 2021, la Estrategia Nacional de Ciberseguridad de la administración Biden comenzó a enfocarse en la seguridad de la cadena de suministro de código abierto.

Hace poco, la Agencia de Seguridad Nacional (NSA) publicó nuevas pautas para proteger las cadenas de suministro de software de código abierto. Este nuevo documento ofrece recomendaciones para administrar el software de código abierto (OSS) y mantener una lista de materiales de software (SBOM).

La seguridad de la cadena de suministro de software recibe atención por una buena razón. La cantidad de paquetes de software afectados por ataques a la cadena de suministro pasó de unos 700 en 2019 a más de 185.000 en 2022.

Mientras los equipos de desarrollo consideran cómo responder a las nuevas pautas de la NSA, especialmente en entornos en la nube como Google Cloud, necesitan encontrar socios que puedan acompañarlos en el proceso y vincular estas prácticas recomendadas con un modelo iterativo de DevSecOps.

Desglose de las recomendaciones de la NSA

Este nuevo documento de recomendaciones, titulado Protección de la cadena de suministro de software: prácticas recomendadas para administrar el software de código abierto y la lista de materiales de software, se centra en cuatro temas principales de seguridad:

1. Administración del software de código abierto

2. Creación y mantenimiento de repositorios seguros de código abierto

3. Mantenimiento del código abierto y gestión de crisis

4. Creación y validación de SBOM

Veamos algunas de las recomendaciones para desarrolladores que se mencionan en este documento.

Administración del software de código abierto

Este documento asigna a los desarrolladores la mayor parte de la responsabilidad de administrar el software de código abierto. Deben elegir las mejores opciones de OSS, revisar posibles problemas de licencias y vulnerabilidades, incorporarlo a su ciclo de vida de desarrollo y crear una SBOM.

La NSA recomienda varias prácticas para usar software de código abierto en el proceso de desarrollo, entre ellas:

• Selección: evaluar correctamente el OSS para elegir las opciones más seguras

• Evaluación de riesgos: comprender plenamente los riesgos asociados con cada opción de OSS elegida

• Licencias: cumplir las obligaciones y restricciones establecidas por cada licencia

• Control de exportaciones: cumplir las regulaciones de exportación aplicables

• Mantenimiento: mantener un repositorio interno seguro

• Respuesta ante vulnerabilidades: establecer un proceso para detectar y corregir vulnerabilidades nuevas

• Entrega de software seguro: volver a verificar el contenido de la versión final mediante un análisis de composición binaria antes de distribuirla

Creación y mantenimiento de repositorios seguros de código abierto

La NSA dedica una sección de su publicación reciente a las recomendaciones para crear un repositorio interno seguro.

Sus dos recomendaciones para mantener este repositorio son:

• Establecer un proceso de adopción de OSS adecuado al tamaño de tu organización y a los recursos disponibles.

• Realizar evaluaciones de vulnerabilidades y riesgos antes y después de la adopción y usar los resultados para decidir qué componentes utilizar o cuáles revertir o actualizar a versiones más seguras.

Mantenimiento del código abierto y gestión de crisis

El software de código abierto que antes se consideraba seguro y estaba aprobado para un repositorio interno aún puede ser vulnerable a fallas de día cero. Las organizaciones también deben considerar cómo detectar y abordar estos nuevos riesgos en el OSS que elijan.

Las empresas pueden crear un plan de continuidad para detectar y corregir nuevas vulnerabilidades y amenazas de código abierto mediante estas prácticas recomendadas:

• Usar inteligencia confiable para detectar amenazas emergentes.

• Usar una SBOM para localizar componentes vulnerables en todas las bibliotecas.

• Seguir un proceso para corregir la vulnerabilidad, por ejemplo, actualizar a una versión con la corrección o volver a una versión no afectada.

• Establecer con anticipación un plan de gestión de crisis para responder a problemas importantes de software e informar oportunamente a las partes interesadas.

Creación y validación de SBOM

El documento también destaca la importancia de las SBOM: crearlas, actualizarlas y ponerlas a disposición de las personas y herramientas adecuadas.

La NSA destaca algunas características de una SBOM eficaz:

• Detalles sobre componentes, versiones, licencias y dependencias

• Integración en el pipeline con técnicas de seguridad como el análisis de composición de software (SCA)

• Herramientas de extracción automatizada para facilitar la detección y actualización de componentes en todo el ciclo de vida de desarrollo de software (SDLC)

• Control de calidad y validación para garantizar que los datos de la SBOM estén en el formato correcto y que los desarrolladores puedan integrarlos en herramientas y procesos automatizados

Cómo pueden los usuarios de Google Cloud seguir estas recomendaciones con Snyk

Estos procesos pueden parecer una carga adicional para tus equipos de desarrollo, pero no tienen por qué serlo. La administración de seguridad de código abierto de Snyk facilita la detección y corrección de vulnerabilidades en los componentes de código abierto que ya usas, el análisis de pull request para detectar componentes inseguros antes de combinarlos y la creación de SBOM enriquecidas. Gracias a Snyk Open Source, nuestra herramienta de SCA, el 99 % de los clientes de Snyk afectados por Log4J corrigieron la vulnerabilidad Log4Shell en tres días. Al aprovechar la plataforma de seguridad de Snyk, diseñada para desarrolladores, puedes cumplir más fácilmente las pautas federales de seguridad al:

• Detectar dependencias vulnerables mientras programas, directamente en tu IDE o CLI.

• Analizar tus proyectos directamente desde el repositorio antes de combinarlos y monitorearlos a diario para detectar nuevas vulnerabilidades.

• Agregar una prueba automatizada de Snyk a tu pipeline de CI/CD para evitar que nuevas vulnerabilidades pasen por el proceso de compilación.

• Analizar tu entorno de producción para verificar que no esté expuesto a vulnerabilidades existentes.

• Generar SBOM con información enriquecida de Snyk para cada paquete de código abierto, con detalles de licencias, enlaces externos, información de los responsables del mantenimiento y más.

Además, Snyk colabora con Google Cloud para proteger las cadenas de suministro de software y se integra con los servicios de Google que usas para crear y ejecutar tus aplicaciones, entre ellos:

• Google CloudBuild. Snyk analiza todos los paquetes de tus proyectos y ofrece recomendaciones automatizadas para corregirlos.

• Google Artifact Registry (GAR). Snyk analiza tus contenedores para detectar vulnerabilidades y prueba tus imágenes base.

• Google Kubernetes Engine (GKE). Snyk te permite importar y analizar cargas de trabajo en ejecución para identificar vulnerabilidades en imágenes y configuraciones.

Con estas integraciones, los equipos que desarrollan aplicaciones modernas en contenedores en Google Cloud pueden validar sus SBOM y proteger la cadena de suministro de software sin salir de sus entornos habituales.

Los clientes también pueden usar sus mecanismos de facturación actuales de Google para comprar el software de Snyk directamente en Google Cloud Marketplace.

Lee cómo Snyk ayudó al equipo de Kroger a proteger su cadena de suministro para obtener más información.