Distribuir software de forma segura

La velocidad y el tiempo de lanzamiento son las principales prioridades de las empresas de todo el mundo que desarrollan software y aplicaciones para satisfacer las necesidades de sus clientes. Estos imperativos estratégicos han sido el motor de un enorme crecimiento de contenedores como plataforma de elección. Durante el último año, muchas de esas empresas han empezado a sacar partido a las ventajas de los contenedores, entre las que se incluyen un tiempo de lanzamiento más reducido, una mayor disponibilidad, una seguridad mejorada, una mayor escalabilidad y una reducción de costes. Muchas de estas empresas también han comenzado a pensar en una estrategia sin servidor.

Aunque las soluciones de software han reducido el tiempo necesario para lanzar una función nueva o incluso un producto nuevo, muchas de las prácticas de seguridad disponibles no pueden adaptarse al aumento de la velocidad, lo que lleva a uno de estos tres problemas:

1. Los desarrolladores ralentizan los procesos, por lo que se producen retrasos
2. Los equipos de seguridad y operaciones ponen en riesgo a la empresa ante amenazas
3. Los equipos de desarrollo trabajan en torno a los procesos de seguridad para cumplir las fechas límite, por lo que son vulnerables

En los últimos años, se han producido infracciones de seguridad clasificadas como ataques a la "cadena de suministro de software".

Log4Shell era una vulnerabilidad peligrosa del software Apache Log4j identificada en diciembre del 2021. Marcada con la puntuación máxima de CVSS de 10, esta vulnerabilidad ha sido especialmente devastadora debido a la popularidad de Log4j, un framework de registro basado en Java. Dos factores fueron los que contribuyeron a la gravedad: en primer lugar, era muy fácil explotar y permitir la ejecución completa del código remoto; y, en segundo lugar, solía estar en muchas capas del árbol de dependencias y, por tanto, era fácil no detectarla.

Solarwinds, una empresa de software de gestión informática, sufrió ataques de agentes estado-nación que introdujeron código malicioso en compilaciones oficiales de software libre que usaba la empresa. Esta actualización maliciosa se insertó para 18.000 clientes, incluidos los departamentos del Tesoro y Comercio de Estados Unidos.

Kaseya, otra empresa de software de gestión informática, sufrió un ataque que la puso en riesgo mediante una vulnerabilidad de día cero que comprometió el servidor Kaseya VSA y envió una secuencia de comandos maliciosa para distribuir ransomware que encriptaba todos los archivos de los sistemas afectados.

La necesidad urgente de responder a estos y otros incidentes similares llevaron a la Casa Blanca a publicar una orden ejecutiva en mayo del 2021, en la que se exigía a las empresas que trabajan con el Gobierno federal mantener determinados estándares de seguridad del software.

En muchos sentidos, el término "cadena de suministro de software" es muy adecuado: los procesos para crear una cadena de suministro de software son muy similares a los que se usan para fabricar un coche.

El fabricante de un coche compra piezas de fábrica, fabrica sus propios componentes y los combina mediante un proceso muy automatizado. Los fabricantes se encargan de proteger sus operaciones y se aseguran de que todos los componentes de terceros procedan de orígenes de confianza. Los componentes propios se prueban exhaustivamente para verificar que no tengan problemas de seguridad. Por último, el montaje se lleva a cabo mediante un proceso fiable que genera coches acabados.

La cadena de suministro de software es similar en muchos aspectos. Los fabricantes de software obtienen componentes de terceros, a menudo de código abierto, que llevan a cabo funciones específicas y desarrollan su propio software, que es su propiedad intelectual principal. A continuación, el código se ejecuta mediante un proceso de compilación que combina estos componentes en artefactos desplegables, que se despliegan en producción.

Un solo enlace no seguro es suficiente para provocar una brecha de seguridad en la cadena de suministro de software.

Al igual que ocurre con los ataques importantes del año pasado, cada uno de los pasos del proceso puede dar lugar a una vulnerabilidad que un atacante puede explotar.

Por ejemplo, el paquete medio de npm tiene 12 dependencias directas y unas 300 dependencias indirectas. Además, sabemos que casi el 40 % de todos los paquetes de npm publicados dependen de código con vulnerabilidades conocidas.

En realidad, las vulnerabilidades no tienen por qué hacer que el código no sea seguro (por ejemplo, la vulnerabilidad podría pertenecer a una biblioteca que nunca se usa). No obstante, se deben seguir comprobando.

La escala de este problema es monumental. Si una sola de estas vulnerabilidades no tuviera parches, podría suponer una oportunidad para que algunos agentes perniciosos accedieran a tu cadena de suministro de software.

En Google, llevamos décadas desarrollando aplicaciones a escala mundial. Con el tiempo, hemos abierto muchos de nuestros proyectos internos para ayudar a aumentar la velocidad de desarrollo. Al mismo tiempo, hemos desarrollado verios procesos internos para proteger la experiencia de software

Estas son algunas de las iniciativas que estamos desarrollando para que las cadenas de suministro de software sean más sólidas en todas partes.

• Aumento de la inversión: en agosto del 2020 anunciamos que íbamos a invertir 10.000 millones de dólares en los próximos cinco años para reforzar la ciberseguridad, lo que incluye desplegar programas de confianza cero, proteger la cadena de suministro de software y mejorar la seguridad de software libre.
• Niveles de la cadena de suministro para artefactos de software (SLSA): SLSA es un framework de extremo a extremo para la integridad de la cadena de suministro. Es el equivalente de código abierto de muchos de los procesos que hemos implementado internamente en Google. SLSA proporciona pruebas comprobables de lo que se ha creado y de cómo se ha hecho.
• DevOps Research and Assessment (DORA): nuestro equipo de DORA llevó a cabo un programa de investigación de siete años que puso de manifiesto una serie de funciones técnicas, culturales, de procesos y de medidas para mejorar el envío de software y el rendimiento de las empresas.
• Foundation de seguridad de código abierto: cofundamos Open Source Security Foundation en el 2019, un foro multisector sobre la seguridad de la cadena de suministro.
• Allstar: Allstar es una aplicación de GitHub instalada en empresas o repositorios para implementar y aplicar políticas de seguridad. Como consecuencia, se aplican prácticas recomendadas de seguridad en los proyectos de GitHub de forma continua.
• Cuadros de resultados de código abierto: las tarjetas de resultados usan métricas de evaluación, como una política de seguridad bien definida, un proceso de revisión de código y una cobertura de pruebas continua con herramientas de fuzzing y análisis de código estático para proporcionar una puntuación de riesgo a proyectos de software libre.

Creemos que son dos cosas necesarias para superar el problema de la seguridad en la cadena de suministro de software:

1. Estándares y frameworks del sector.
2. Los servicios gestionados que implementan estos estándares mediante el principio de mínimos accesos se conocen como arquitectura de confianza cero. Una arquitectura de confianza cero es aquella en la que ninguna persona, dispositivo ni red disfruta de la confianza inherente, sino que debe obtenerse toda la confianza que permite el acceso a la información.

A continuación, veremos uno por uno:

Actualmente, los SLSA son un conjunto de directrices de seguridad que se pueden adoptar de forma incremental y que están consensuadas por el sector. En su forma final, los SLSA difieren de una lista de prácticas recomendadas en cuanto a su aplicabilidad, ya que admitirán la creación automática de metadatos auditables que se podrán introducir en los motores de políticas para otorgar la certificación SLSA a un paquete o una plataforma de compilación específicos.

Los SLSA están diseñados para ser incrementales, prácticos y ofrecer ventajas de seguridad en cada paso. Una vez que un artefacto cumple los requisitos de un nivel superior, los consumidores pueden confiar en que no se ha manipulado y, si es seguro, que se puede rastrear hasta su origen, algo que suele ser difícil, o imposible.

SLSA consta de cuatro niveles: SLSA 4 representa el estado final ideal. Los niveles inferiores representan hitos incrementales con sus correspondientes garantías de integridad incrementales. A continuación, se indican los requisitos que deben cumplirse para conseguir estos objetivos.

SLSA 1 requiere que el proceso de compilación esté completamente guionizado o automatizado, y que genere procedencia. La procedencia son los metadatos sobre cómo se ha creado un artefacto, incluidos el proceso de compilación, el origen de nivel superior y las dependencias. Esta información permite que los consumidores de software tomen decisiones de seguridad basadas en riesgos. Aunque la procedencia de las normas de SLSA 1 no ofrece protección frente a la manipulación, ofrece un nivel básico de identificación de los orígenes del código y puede ayudar a gestionar vulnerabilidades.

SLSA 2 requiere el control de versiones y un servicio de compilación alojado que genera procedencias autenticadas. De este modo, los consumidores pueden confiar más en el origen del software. A este nivel, la procedencia impide la manipulación si el servicio de compilación es de confianza. SLSA 2 también ofrece una ruta de actualización sencilla a SLSA 3.

Además, SLSA 3 exige que las plataformas de origen y compilación cumplan unos estándares concretos para garantizar la fiabilidad del origen y la integridad de la procedencia, respectivamente. SLSA 3 ofrece protección mucho más segura contra manipulaciones que los niveles anteriores, ya que previene amenazas específicas, como la contaminación por compilación cruzada.

Actualmente, el nivel SLSA 4 es el más alto, ya que requiere que dos personas revisen todos los cambios y un proceso de compilación hermético y reproducible. La revisión de dos personas es una práctica recomendada del sector para detectar errores y disuadir a los usuarios de comportamientos inadecuados. Las compilaciones de Hermetic garantizan que la lista de dependencias de procedencia sea completa. Las compilaciones reproducibles, aunque no estrictamente necesarias, ofrecen muchas ventajas de fiabilidad y auditoría. En general, SLSA 4 ofrece al consumidor una alta certeza de que el software no se ha manipulado. Puedes consultar más detalles de estos niveles propuestos en el repositorio de GitHub, incluidos los requisitos de origen y compilación o procedencia correspondientes. 

La cadena de suministro de software se puede dividir en cinco fases distintas: código, compilación, paquete, despliegue y ejecución. Trataremos cada una de estas fases en relación con nuestra estrategia de seguridad.

En Google Cloud ofrecemos herramientas totalmente gestionadas (desde el código y la compilación hasta el despliegue y la ejecución) con los estándares y las prácticas recomendadas mencionados anteriormente que se implementan de forma predeterminada.

Asegurar la cadena de suministro de software requiere determinar, verificar y mantener una cadena de confianza que determine el código y garantice que lo que ejecutas en producción es lo que quieres. Para ello, llevamos a cabo estas atestaciones, que se generan y comprueban durante todo el desarrollo de software y el proceso de despliegue, lo que permite ofrecer un nivel de seguridad ambiental mediante revisiones de código, procedencia del código verificado y medidas de cumplimiento de políticas. Juntos, estos procesos nos ayudan a minimizar los riesgos de la cadena de suministro de software y, a la vez, a mejorar la productividad de los desarrolladores.

Su base incluye servicios de infraestructura segura, como gestión de identidades y accesos, y registros de auditoría. A continuación, protegemos tu cadena de suministro de software con una forma de definir, comprobar e implementar atestaciones a lo largo de todo el ciclo de vida del software.

Veamos con más detalle cómo puedes conseguir seguridad ambiental en tu proceso de desarrollo mediante políticas y procedencias de Google Cloud.

La seguridad de tu cadena de suministro de software empieza cuando los desarrolladores comienzan a diseñar tu aplicación y a escribir el código. Eso incluye el software propio y los componentes de código abierto, cada uno de los cuales presenta sus propios retos.

Software libre y dependencias de código abierto

El software libre permite que los desarrolladores creen cosas más rápido para que las empresas puedan ser más ágiles y productivas. Sin embargo, el software libre no es perfecto, ni mucho menos y, aunque nuestro sector depende de él, a menudo tenemos muy poca información sobre sus dependencias y los distintos niveles de riesgo que conlleva. Para la mayoría de las empresas, el riesgo se debe principalmente a vulnerabilidades o licencias.

La base de tu "cadena de confianza" es el software libre, los paquetes, las imágenes base y otros artefactos que necesitas.

Por ejemplo, piensa que tu empresa está creando el software "a". En este diagrama se muestra la cadena de confianza; es decir, el número de dependencias implícitas de tu proyecto. En el diagrama, las letras que van de la "b" a la "h" son dependencias directas, y de la "i" a la "m" son dependencias indirectas.

Ahora, ten en cuenta que hay una vulnerabilidad en el árbol de dependencias más profundo. El problema puede aparecer rápidamente en muchos componentes. Además, las dependencias cambian con bastante frecuencia: en un día medio, 40.000 paquetes de npm experimentan un cambio en sus dependencias.

Open Source Insights es una herramienta desarrollada por Google Cloud que proporciona un gráfico transitorio de dependencias para que puedas ver tus dependencias y las dependencias de estas, a lo largo de todo el árbol de dependencias. Open Source Insights se actualiza continuamente con avisos de seguridad, información sobre licencias y otros datos de seguridad en varios idiomas en un mismo lugar. Cuando se utiliza junto con Open Source Scorecards, que ofrecen una puntuación de riesgo para los proyectos de software libre, esta herramienta ayuda a los desarrolladores a tomar mejores decisiones en los millones de paquetes de código abierto disponibles.

Para abordar esta preocupación, es fundamental centrarse en las dependencias como código. Como estas dependencias se acercan al final de la cadena de suministro, es más difícil inspeccionarlas. Para proteger tus dependencias, te recomendamos que empieces por el suministro:

• Usa herramientas como Open Source Insights y los gráficos de resultados de software libre para comprender mejor tus dependencias.
• Escanea y verifica todo el código, los paquetes y las imágenes de base mediante un proceso automatizado que sea una parte clave de tu flujo de trabajo.
• Controla cómo acceden las personas a estas dependencias. Es fundamental controlar detenidamente los repositorios de código propio y de código abierto, con restricciones de revisión de código exhaustiva y requisitos de auditoría.

Veremos con más detalle los procesos de compilación y despliegue, pero también es importante verificar la procedencia de la compilación, usar un entorno de desarrollo seguro y garantizar que las imágenes estén firmadas y se validen posteriormente en el momento del despliegue.

Los desarrolladores también pueden usar varias prácticas de programación segura:

• Automatizar prueba
• Usa lenguajes de software seguros para la memoria
• Revisiones del código de orden
• Asegura la autenticidad de las confirmaciones
• Identificar el código malicioso antes
• Evita exponerte a información sensible
• Requerir almacenamiento de registros y resultados de compilación
• Gestión de licencias

El siguiente paso para proteger tu cadena de suministro de software es establecer un entorno de desarrollo seguro a escala. En esencia, el proceso de compilación consiste en importar el código fuente en uno de los muchos posibles lenguajes de un repositorio y ejecutar compilaciones para cumplir las especificaciones incluidas en los archivos de configuración.

Los proveedores de servicios en la nube, como Google, te permiten acceder a un entorno de desarrollo gestionado y actualizado donde puedes crear imágenes a cualquier escala.

A lo largo del proceso de compilación, hay varios aspectos que debes tener en cuenta:

• ¿Tus secretos están protegidos durante el proceso de compilación y tras este?
• ¿Quién tiene acceso a tus entornos de compilación?
• ¿Qué ocurre con los vectores de ataque o los riesgos de filtración externa relativamente nuevos?

Para desarrollar un entorno de desarrollo seguro, debes empezar por los secretos. Son esenciales y relativamente fáciles de proteger. En primer lugar, asegúrate de que tus secretos nunca sean texto sin formato y de que, en la medida de lo posible, no formen parte de tu compilación. En lugar de eso, debes asegurarte de que estén cifrados y de que tus compilaciones se hayan parametrizado para hacer referencia a secretos externos que puedan usarse según sea necesario. Esto también simplifica la rotación periódica de los secretos y minimiza el impacto de las fugas.

El siguiente paso es configurar los permisos de la compilación. El proceso de compilación implica diferentes cuentas de usuario y de servicio. Por ejemplo, puede que algunos usuarios tengan que gestionar secretos, que otros tengan que añadir o modificar pasos para gestionar el proceso de compilación y que otros necesiten ver los registros.

Para ello, es importante seguir estas prácticas recomendadas:

• Lo más importante es el principio de mínimos accesos. Implementa permisos detallados para conceder a los usuarios y a las cuentas de servicio los permisos exactos que necesitan para hacer sus tareas de forma eficaz.
• Debes saber cómo interactúan los usuarios y las cuentas de servicio, y debes conocer claramente la cadena de responsabilidad, desde la creación de una compilación hasta su ejecución con los efectos secundarios de la compilación.

Después, a medida que escales verticalmente este proceso, establece límites en torno a tu compilación en la medida de lo posible y, a continuación, usa la automatización para escalarla a través de la configuración como código y parametrización. Esto te permite auditar los cambios que hagas en el proceso de compilación de forma eficaz. Además, asegúrate de que cumples los requisitos de cumplimiento mediante pasarelas de aprobación para compilaciones y despliegues sensibles, solicitudes de extracción de cambios en la infraestructura y revisiones periódicas de los registros de auditoría humana.

Por último, comprueba que la red se adapte a tus necesidades. En la mayoría de los casos, es mejor alojar tu propio código fuente en redes privadas protegidas por cortafuegos. Google Cloud te da acceso a funciones como los grupos privados de Cloud Build, a un entorno de desarrollo sin servidor bloqueado dentro de tu propio perímetro de red privada y a funciones como los Controles de Servicio de VPC para evitar la filtración externa de tu propiedad intelectual.

Autorización binaria

Aunque IAM es un elemento imprescindible y un punto de partida lógico, no es infalible. Las credenciales filtradas representan un riesgo de seguridad grave. Por ello, para reducir la dependencia de IAM, puedes cambiar a un sistema basado en atestaciones, menos propenso a errores. Google utiliza un sistema llamado "autorización binaria", que solo permite desplegar cargas de trabajo de confianza.

El servicio de autorización binaria establece, verifica y mantiene una cadena de confianza mediante atestaciones y comprobaciones de las políticas durante todo el proceso. Esencialmente, la autorización binaria genera firmas criptográficas (atestaciones) a medida que el código y otros artefactos avanzan a la fase de producción y, antes de desplegarse, se comprueban estas atestaciones según las políticas.

Cuando se usa Google Cloud Build, se registra un conjunto de atestaciones y se añade a tu cadena general de confianza. Por ejemplo, se generan atestaciones de qué tareas se han ejecutado, qué herramientas de creación y procesos se han utilizado, etc. En concreto, Cloud Build te ayuda a conseguir el nivel 1 de SLSA, ya que captura el origen de la configuración de compilación, que se puede usar para validar que la compilación se ha programado. Las compilaciones con secuencias de comandos son más seguras que las compilaciones manuales y son necesarias para el nivel 1 de SLSA. Además, puedes consultar la procedencia y las atestaciones de tu compilación con el resumen de la imagen del contenedor, que crea una firma única para cualquier imagen y también es obligatorio para el nivel 1 de SLSA.

Una vez que se haya completado la compilación, dispones de una imagen de contenedor que está casi lista para producción. Es importante que tengas un lugar seguro donde almacenar tus imágenes para evitar que se manipulen imágenes que ya tengas y que se suban imágenes no autorizadas. Es probable que tu gestor de paquetes necesite tener imágenes tanto de compilaciones propias como de código abierto, así como de paquetes de los lenguajes que usen tus aplicaciones.

Artifact Registry de Google Cloud te proporciona este repositorio. Con Artifact Registry, tu empresa puede gestionar tanto imágenes de contenedor como paquetes de lenguajes (como Maven y npm). Está totalmente integrado con las herramientas y los entornos de ejecución de Google Cloud y, además, ofrece compatibilidad con protocolos de artefactos nativos. Por eso, es muy fácil integrar esta solución con tus herramientas de CI/CD mientras configuras flujos de procesamiento automáticos.

Al igual que en el paso de compilación, es esencial asegurarse de que los permisos de acceso a Artifact Registry se piensen detenidamente y sigan los principios de mínimos accesos. Además de restringir el acceso no autorizado, el repositorio de paquetes puede aportar mucho más valor. Por ejemplo, Artifact Registry incluye un análisis de vulnerabilidades para analizar tus imágenes y asegurarte de que se pueden desplegar con seguridad. Este servicio analiza las imágenes en una base de datos de vulnerabilidades actualizada continuamente para evaluar las nuevas amenazas y puede avisarte cuando se detecte una vulnerabilidad.

Con este paso, se generan metadatos adicionales, como una atestación que indique si los resultados de la vulnerabilidad de un artefacto cumplen determinados umbrales de seguridad. Luego, esta información se almacena en nuestro servicio de análisis, que estructura y organiza los metadatos del artefacto, de modo que la autorización binaria pueda acceder fácilmente a ellos. Puedes usarlo para impedir automáticamente que se desplieguen imágenes peligrosas en Google Kubernetes Engine (GKE).

Las dos fases finales de la cadena de suministro de seguridad de software se despliegan y ejecutan. Aunque son dos pasos independientes, es lógico pensar en ellos como una forma de asegurarse de que solo las compilaciones autorizadas lleguen a producción.

En Google, hemos desarrollado prácticas recomendadas para determinar qué tipos de compilaciones se deben autorizar. Lo primero es garantizar la integridad de la cadena de suministro, de modo que solo produzca artefactos de confianza. A continuación, incluye la gestión de vulnerabilidades como parte del ciclo de vida de la entrega de software. Por último, hemos unido ambas piezas para aplicar flujos de trabajo según las políticas de integridad y análisis de vulnerabilidades.

Cuando llegues a esta fase, ya habrás completado las fases de código, compilación y paquete; las atestaciones recogidas en la cadena de suministro se pueden comprobar para verificar su autenticidad mediante autorización binaria. En el modo de cumplimiento, las imágenes solo se despliegan cuando las atestaciones cumplen las políticas de tu empresa. En el modo de auditoría, las infracciones de las políticas se registran y activan alertas. También puedes usar la autorización binaria para impedir que se ejecuten las compilaciones, a menos que se hayan creado con el proceso de Cloud Build. La autorización binaria garantiza que solo se despliegue correctamente el código revisado y autorizado.

Es fundamental desplegar las imágenes en un entorno de ejecución de confianza. Nuestra plataforma de Kubernetes gestionada, GKE, adopta una estrategia de seguridad centrada en los contenedores.

GKE se ocupa de la mayoría de las cuestiones de seguridad de los clústeres de las que tienes que encargarte. Las actualizaciones automáticas de clústeres te permiten parchear y actualizar automáticamente Kubernetes mediante los canales de lanzamiento. El inicio seguro, los nodos blindados y las comprobaciones de integridad garantizan que los componentes del clúster y e kernel de tu nodo no se hayan modificado, ejecuten lo que quieres y que los nodos maliciosos no puedan unirse a tu clúster. Por último, Confidential Computing te permite ejecutar clústeres con nodos cuya memoria está cifrada para que los datos puedan seguir siendo confidenciales incluso mientras se procesan. Gracias a este servicio, puedes cifrar los datos mientras están en reposo y en tránsito por la red, y GKE proporciona un entorno muy seguro, privado y confidencial para ejecutar tus cargas de trabajo en contenedores.

Además de esto, GKE también ofrece una mejor seguridad para tus aplicaciones gracias a la gestión de certificados para tus balanceadores de carga, la identidad de las cargas de trabajo y las funciones avanzadas de red, gracias a un potente método de configuración y protección de la entrada en el clúster. GKE también ofrece entornos de espacio aislado para ejecutar aplicaciones que no son de confianza, al mismo tiempo que protege el resto de tus cargas de trabajo.

Con Autopilot de GKE, las funciones y las prácticas recomendadas de seguridad de GKE se implementan automáticamente, lo que reduce la superficie de ataque y minimiza las configuraciones erróneas que pueden provocar problemas de seguridad.

Además, no hace falta verificarla durante el despliegue. La autorización binaria también es compatible con la validación continua, lo que permite la conformidad constante de la política definida, incluso después del despliegue. Si una aplicación en ejecución no cumple una política que ya existe o que se acaba de añadir, se crea y se registra una alerta para que tengas la certeza de que lo que estás ejecutando en producción es exactamente lo que quieres.

Gestión de las vulnerabilidades

Además de garantizar la integridad, otro aspecto de la seguridad de la cadena de suministro es asegurarse de que las vulnerabilidades se encuentren y se les apliquen parches rápidamente. Los atacantes han evolucionado para insertar vulnerabilidades en proyectos upstream. La gestión de vulnerabilidades y la detección de defectos se deben incorporar en todas las fases del ciclo de vida de la entrega de software.

Una vez que el código esté listo para desplegarse, usa un flujo de procesamiento de CI/ CD y aprovecha las numerosas herramientas que pueden escanear los códigos fuente y los artefactos generados. Entre estas herramientas se incluyen analizadores estáticos, herramientas de fuzzing y varios tipos de analizadores de vulnerabilidades.

Cuando hayas desplegado tu carga de trabajo en producción y mientras se ejecuta y ofreces servicios a tus usuarios, debes monitorizar las amenazas emergentes y tener planes para resolver los problemas inmediatamente.

Conclusión

En resumen, para proteger una cadena de suministro de software, hay que seguir las prácticas recomendadas, como SLSA, y usar servicios gestionados de confianza que te ayuden a implementarlas.

Es fundamental:

• Empieza por el código y las dependencias, y asegúrate de que sean de confianza.
• Protege tu sistema de compilación y usa atestaciones para verificar que se hayan seguido todos los pasos de compilación necesarios.
• Asegúrate de que todos tus paquetes y artefactos sean de confianza y que no se puedan manipular.
• Aplica controles sobre quién puede desplegar qué elementos y mantén un registro de auditoría. Usa la autorización binaria para validar atestaciones de cada artefacto que quieras desplegar.
• Ejecuta las aplicaciones en un entorno de confianza y asegúrate de que nadie pueda manipularlas mientras se ejecutan. Presta atención a las vulnerabilidades recién descubiertas para proteger el despliegue.

En Google, seguimos las prácticas recomendadas para cada paso de este recorrido, dentro de nuestra cartera de productos, para que tengas una base fiable sobre la que desarrollar.

¿Todo listo para proteger tu cadena de suministro de software? Para empezar, está claro que el punto de partida es arbitrario, es decir, no hay ninguna acción que proteja toda la cadena de suministro, ni ninguna más importante que otra en cuanto a la seguridad de la cadena de suministro. No obstante, aquí tienes cuatro recomendaciones para empezar.

1. Reparar el software

Si has implementado código en tu entorno de producción con vulnerabilidades conocidas, ya le has facilitado el trabajo al atacante. En ese caso, no importa si has protegido la cadena de suministro de software, porque ya pueden entrar. Por ello, aplicar parches es fundamental.

2. Controlar lo que se ejecuta en tu entorno

Una vez que hayas aplicado los parches, podrás controlar la cadena de suministro de tu software. En primer lugar, se debe poder verificar que lo que se está ejecutando realmente procede de tus herramientas de compilación o de repositorios de confianza. Ese nivel de control ayuda a evitar ataques intencionados y errores involuntarios, como el caso de un desarrollador que desarrolló algo que no sabía que no era seguro. De este modo, sentará una base sólida para añadir herramientas como las pruebas de clics y la autorización binaria. 

3. Comprobar que los paquetes de proveedores externos sean seguros

Un problema emergente en la seguridad de la cadena de suministro es la frecuencia con la que se pone en riesgo el software de los proveedores para proporcionar un conducto de ransomware o acceso no autorizado a los despliegues de clientes de destino. Los paquetes de terceros que ejecutas en tu entorno (por ejemplo, productos de gestión de sistemas, de gestión de redes o de seguridad) suelen tener un alto grado de privilegios. Recomendamos a los proveedores que vayan más allá de las instrucciones de seguridad estándar para proporcionar un cierto nivel de garantía sobre los paquetes que usas. Podrías preguntar cuál es el nivel de conformidad de SLSA o si su ámbito cumple los requisitos de la reciente orden ejecutiva.

4. Ten una copia privada de tu código fuente

Si usas software de código abierto, no uses ninguna versión que hayas extraído directamente de Internet. Es mejor que cuentes con una copia privada con un parche aplicado para tener un sitio desde el que empezar con todas las compilaciones y saber con total confianza de dónde procede el código fuente. 

Prácticas recomendadas de DevOps

1. Seis años del informe State of DevOps, un conjunto de artículos con información detallada sobre las funciones que predicen el rendimiento del envío de software y una comprobación rápida para ayudarte a descubrir cómo te va y cómo mejorar
2. Informe "Google State 2021 Accelerate State of DevOps" 2021
3. Informe de Google Cloud: Re-architecting to cloud native: an evolutionary approach to increasing developer productivity at scale

Proteger la cadena de suministro de software

1. Blog de Google Cloud: ¿Qué es la seguridad de identidad de confianza cero?
2. Blog sobre seguridad de Google: Presentamos SLSA, un framework integral para la integridad de la cadena de suministro
3. Informe de Google Cloud: Shifting left on security: Securing software supply chains