Entrega software de forma segura
En la actualidad, las organizaciones se enfocan en la velocidad y el tiempo de salida al mercado de su software y sus aplicaciones. Sin embargo, las prácticas de seguridad existentes no pueden seguir el ritmo de esta velocidad, lo que provoca demoras en el desarrollo, riesgos y vulnerabilidad ante amenazas.
En este informe, aprenderás a solucionar el problema de la seguridad de la cadena de suministro de software mediante las siguientes acciones:
- Adoptar estándares y frameworks para toda la industria
- Implementar estos estándares con servicios administrados que usen principios de privilegio mínimo en una arquitectura de confianza cero
Descubre cómo migrar con rapidez del código a la compilación, al empaquetado, a la implementación y a la ejecución de software de forma segura.
Información sobre la cadena de suministro de software
Panorama de seguridad actual
La velocidad y el tiempo de salida al mercado son las prioridades principales para las organizaciones en todo el mundo que crean software y aplicaciones para satisfacer las necesidades de sus clientes. Estos imperativos estratégicos son la fuerza que impulsó el enorme crecimiento de los contenedores como plataforma preferida. Durante el último año, se cosecharon los beneficios de los contenedores, como un tiempo más rápido de salida al mercado, una mayor disponibilidad, una mayor seguridad, una mejor escalabilidad y menos costos, por lo que muchas de estas organizaciones comenzaron a trabajar en esta plataforma considerando, además, el enfoque sin servidores.
Si bien las soluciones de software reducen el tiempo que demora entregar una función nueva o incluso un producto nuevo, muchas de las prácticas de seguridad existentes no pueden ponerse al día con el aumento de velocidad, lo que genera uno de los siguientes tres problemas:
- Los desarrolladores ralentizan los procesos existentes, lo que provoca retrasos.
- Los equipos de seguridad y operaciones generan riesgos que abren las puertas de la organización a las amenazas.
- Los equipos de desarrollo trabajan con los procesos de seguridad existentes para cumplir con las fechas límite, por lo que son vulnerables.
En los últimos años, se vieron varios ataques de seguridad clasificados como ataques de “cadena de suministro de software”.
Log4Shell fue una vulnerabilidad peligrosa del software Apache Log4j que se identificó en diciembre de 2021. Con una puntuación máxima de CVSS de 10, esta vulnerabilidad fue devastadora, en particular debido a la popularidad de Log4j, un framework de registro basado en Java. Dos cosas contribuyeron a la gravedad: en primer lugar, fue muy fácil aprovechar y ejecutar por completo el código de forma remota; y, en segundo lugar, a menudo, el árbol de dependencias tenía muchas capas de profundidad por lo que fue muy sencillo pasar algunas por alto.
Solarwinds, una empresa de software de administración de TI, recibió el ataque de actores estatales y nacionales que insertaron un código malicioso en las compilaciones oficiales de software de código abierto que se utiliza en la empresa. Esta actualización maliciosa se envió a 18,000 clientes, incluidos los departamentos del Tesoro y Comercio de EE.UU.
Kaseya, otro proveedor de software de administración de TI, sufrió un ataque por medio de una vulnerabilidad de cero días que puso en riesgo el servidor de Kaseya VSA y envió una secuencia de comandos maliciosa para entregar un ransomware que encriptó todos los archivos en los sistemas afectados.
La necesidad urgente de responder a estos y otros incidentes similares hicieron que la Casa Blanca publicara una Orden ejecutiva en mayo de 2021, en la que se exige que las organizaciones que hacen negocios con el Gobierno federal mantengan ciertos estándares de seguridad de software.
La cadena de suministro de software
En muchos sentidos, el término “cadena de suministro de software” es muy apropiado: los procesos que se usan para crear una cadena de suministro de software son muy similares a los que se usan en la fabricación de un automóvil.
Un fabricante de automóviles obtiene varias piezas listas para usar, fabrica sus propios componentes y, luego, los une mediante un proceso altamente automatizado. Para garantizar la seguridad de sus operaciones, el fabricante se asegura de que cada componente de terceros provenga de una fuente confiable. Los componentes propios se prueban de manera exhaustiva para no tener problemas de seguridad. Por último, el ensamblaje se realiza a través de un proceso confiable que da como resultado el auto terminado.
La cadena de suministro de software es similar en muchos aspectos. Un fabricante de software obtiene componentes de terceros de código abierto por naturaleza, para realizar funciones específicas y desarrollar su propio software, que es su propiedad intelectual principal. Luego, el código se ejecuta en un proceso de compilación que combina estos componentes en artefactos implementables para aplicarlos en la producción.
El eslabón débil de la cadena
Solo se necesita un vínculo no seguro para vulnerar la cadena de suministro de software.
Al igual que los ataques de alto perfil del año pasado, cada uno de los pasos del proceso puede generar una debilidad que aprovecharían los atacantes.
Por ejemplo, el paquete de npm promedio tiene 12 dependencias directas y aproximadamente 300 dependencias indirectas. Además, sabemos que casi el 40% de los paquetes de npm publicados dependen de códigos con vulnerabilidades conocidas.
Es posible que esas vulnerabilidades no hagan que el código sea inseguro; por ejemplo, la vulnerabilidad podría formar parte de una biblioteca que nunca se usa. Sin embargo, se deben verificar.
La escala de este problema es monumental. Incluso si una de de estas vulnerabilidades quedara si parches, se generaría una oportunidad para que personas que actúan de mala fe ingresen a tu cadena de suministro de software.
Estos son algunos ejemplos de ataques que aprovecharon las vulnerabilidades en cada una de las etapas que se muestran en el diagrama anterior.
| Amenaza | Ejemplo conocido | |
| A | Envía un código incorrecto al repositorio de código fuente | Riesgos de la hipótesis de Linux: Un investigador intentó introducir vulnerabilidades de manera intencional en el kernel de Linux mediante parches en la lista de distribución. |
| B | Plataforma de control de código fuente comprometido | PHP: El atacante hackeó el servidor de git autoalojado de PHP y, luego, insertó dos confirmaciones maliciosas. |
| C | Compila con un proceso oficial, pero desde un código que no coincide con el control de fuentes | Webmin: El atacante modificó la infraestructura de compilación para que use archivos fuente que no coinciden con el control de fuente. |
| D | Plataforma de compilación comprometida | SolarWinds: El atacante comprometió la plataforma de compilación e instaló un implante para insertar comportamientos maliciosos durante cada compilación. |
| E | Uso de una dependencia errónea (p. ej., AH recurrente) | Transmisión de evento: El atacante agregó una dependencia inocua y, luego, la actualizó para incluir un comportamiento malicioso. La actualización no coincidió con el código enviado a GitHub (es decir, ataque F). |
| F | Se sube un artefacto que el sistema de CI/CD no compiló | Codecov: El atacante usó credenciales filtradas para subir un artefacto malicioso a un bucket de Google Cloud Storage, desde el cual los usuarios lo descargan directamente. |
| G | Riesgo en los repositorios de paquetes | Ataques a la duplicación de paquetes: El investigador ejecutó duplicaciónes para varios repositorios de paquetes populares, que se podrían haber usado para entregar paquetes maliciosos. |
| H | Engaño al consumidor para que use un paquete incorrecto | Errores ortográficos de Browserify: El atacante subió un paquete malicioso con un nombre similar al original. |
Fortalecimiento de la cadena de liderazgo: Liderazgo de pensamiento de Google Cloud en el código abierto
En Google, llevamos décadas creando apps a escala global. Con el tiempo, configuramos con código abierto muchos de nuestros proyectos internos para ayudar a aumentar la velocidad de los desarrolladores. Al mismo tiempo, desarrollamos varios procesos internos para ayudar a proteger la experiencia de software.
Estas son algunas de nuestras iniciativas para fortalecer las cadenas de suministro de software en todas partes.
- Aumento de la inversión: En agosto de 2020, anunciamos que invertiremos $10,000 millones en los próximos cinco años para fortalecer la seguridad cibernética, lo que incluye expandir los programas de confianza cero y proteger la cadena de suministro de software para mejorar la seguridad del código abierto.
- Niveles de la cadena de suministro para artefactos de software (SLSA): SLSA es un framework de extremo a extremo diseñado para la integridad de la cadena de suministro. Es un equivalente de código abierto de muchos de los procesos que implementamos internamente en Google. SLSA proporciona un origen auditable de lo que se creó y cómo lo hizo.
- DevOps Research and Assessment (DORA): Nuestro equipo de DORA realizó un programa de investigación de siete años en el que se validaron varias capacidades técnicas, culturales, de procesos y de medición que impulsan la entrega de software y el rendimiento de la organización.
- Base de seguridad de código abierto: Fundamos Open Source Security Foundation en 2019, un foro entre industrias sobre seguridad de la cadena de suministro.
- Allstar: Allstar es una app de GitHub instalada en organizaciones o repositorios para definir y aplicar políticas de seguridad. Esto permite la aplicación continua de las prácticas recomendadas de seguridad para los proyectos de GitHub.
- Cuadros de evaluación de código abierto: Estos paneles usan métricas de evaluación como políticas de seguridad bien definidas, procesos de revisión de código y cobertura de pruebas continua, mediante herramientas de fuzzing y análisis de código estático para proporcionar una puntuación del riesgo de los proyectos de código abierto.
Creemos que existen dos elementos necesarios para superar el problema de seguridad de la cadena de suministro del software:
- Estándares y frameworks para toda la industria.
- Los servicios administrados que implementan estos estándares mediante principios de mínimo privilegio se conocen como una arquitectura de confianza cero. Una arquitectura de confianza cero es aquella en la que ninguna persona, dispositivo o red disfruta de una confianza inherente. En su lugar, se debe obtener toda la confianza, lo que permite el acceso a la información.
Analicemos cada uno de ellos:
Estándares y frameworks de toda la industria
A fin de comprender los principios necesarios para proteger la cadena de suministro de software, comencemos con SLSA.
En su estado actual, la SLSA es un conjunto de lineamientos de seguridad que se puede implementar de forma incremental y se estableció por el consenso de la industria. En su forma final, la SLSA será diferente de una lista de prácticas recomendadas en lo que respecta a su aplicabilidad: admitirá la creación automática de metadatos auditables que se pueden ingresar en motores de políticas para otorgar la “certificación de SLSA” a un paquete o una plataforma de compilación en particular.
La SLSA está diseñada para ser incremental y práctica, y para proporcionar beneficios de seguridad en cada paso. Una vez que un artefacto califica en el nivel más alto, los consumidores pueden estar seguros de que no se alteró y se podrá rastrear de forma segura hasta su fuente; algo que es difícil, si no imposible de hacer con la mayoría de software.
La SLSA consta de cuatro niveles, con SLSA 4 que representa el estado final ideal. Los niveles inferiores representan hitos incrementales con las garantías de integridad incrementales correspondientes. Actualmente, los requisitos se definen de la siguiente manera:
SLSA 1 requiere que el proceso de compilación esté completamente planificado y automatizado, y que genere un origen. La procedencia son los metadatos sobre cómo se compiló un artefacto, incluido el proceso de compilación, la fuente de nivel superior y las dependencias. Conocer la procedencia permite que los consumidores de software tomen decisiones de seguridad basadas en riesgos. Aunque la procedencia de SLSA 1 no brinda protección contra la manipulación, ofrece un nivel básico de identificación de la fuente de código y puede ayudar en la administración de vulnerabilidades.
SLSA 2 requiere usar el control de versiones y un servicio de compilación alojado que genere una fuente autenticada. Estos requisitos adicionales le otorgan más confianza al consumidor en el origen del software. En este nivel, la fuente evita que se manipule en la medida en que el servicio de compilación sea de confianza. SLSA 2 también proporciona una ruta de actualización sencilla a SLSA 3.
SLSA 3 también requiere que las plataformas de origen y compilación cumplan con estándares específicos para garantizar la auditabilidad de la fuente y la integridad del origen, respectivamente. SLSA 3 ofrece protecciones mucho más sólidas contra la manipulación que los niveles anteriores, ya que previene clases específicas de amenazas, como la contaminación de la compilación cruzada.
SLSA 4 es actualmente el nivel más alto que requiere que dos personas revisen todos los cambios y un proceso de compilación hermético y reproducible. La opinión de dos personas es una práctica recomendada en la industria para detectar errores y disuadir comportamientos inadecuados. Las compilaciones herméticas garantizan que la lista de dependencias de la fuente se complete. Las compilaciones reproducibles, aunque no son estrictamente obligatorias, proporcionan muchos beneficios de auditabilidad y confiabilidad. En términos generales, la SLSA 4 otorga al consumidor un alto nivel de confianza en el que el software no se manipuló. Hay más detalles sobre estos niveles propuestos en el repositorio de GitHub, incluidos los requisitos de origen y compilación y procedencia correspondientes.
La cadena de suministro de software se puede desglosar en cinco fases distintas: código, compilación, paquete, implementación y ejecución. Abordaremos cada una de estas fases en términos de nuestro enfoque de seguridad.
Servicios administrados para cada etapa
En Google Cloud, proporcionamos herramientas completamente administradas, desde el código y la compilación hasta la implementación y la ejecución, con los estándares y las prácticas recomendadas mencionados que se implementaron de forma predeterminada.
Para proteger tu cadena de suministro de software, debes establecer, verificar y mantener una cadena de confianza que establezca la fuente de tu código y garantice que lo que ejecutas en producción sea lo que deseas. En Google, esto se logra mediante certificaciones que se generan y verifican durante el proceso de desarrollo e implementación de software, lo que permite un nivel de seguridad ambiental mediante aspectos como la revisión de código, la procedencia de los códigos verificados y la aplicación de políticas. En conjunto, estos procesos nos ayudan a minimizar el riesgo de la cadena de suministro de software y mejoran la productividad de los desarrolladores.
En la base, tenemos servicios comunes de infraestructura segura, como la administración de identidades y accesos, y el registro de auditoría. Luego, protegemos tu cadena de suministro de software con una forma de definir, verificar y aplicar certificaciones en todo el ciclo de vida del software.
Analicemos con más detalle cómo lograr la seguridad ambiental en tu proceso de desarrollo mediante políticas y orígenes en Google Cloud.
Fase 1: Código
La protección de tu cadena de suministro de software comienza cuando los desarrolladores comienzan a diseñar tu aplicación y escribir códigos. Esto incluye el software propio y los componentes de código abierto, cada uno de los cuales viene con desafíos propios.
Dependencias y software de código abierto
El código abierto les permite a los desarrolladores compilar proyectos más rápido para que las organizaciones puedan ser más ágiles y productivas. Sin embargo, el software de código abierto no es perfecto por completo y, si bien nuestra industria depende de él, a menudo tenemos muy pocas estadísticas sobre sus dependencias y los diferentes niveles de riesgo que conlleva. Para la mayoría de las empresas, el riesgo proviene principalmente de vulnerabilidades o licencias.
El software de código abierto, los paquetes, las imágenes base y otros artefactos de los que dependes forman la base de tu “cadena de confianza”.
Por ejemplo, considera que tu organización compila el software “a”. En este diagrama, se muestra la cadena de confianza. En otras palabras, la cantidad de dependencias implícitas de tu proyecto. En el diagrama, de la “b” a la “h” son dependencias directas, mientras que de la “i” a la “m” son dependencias indirectas.
Ahora, considera que hay una vulnerabilidad en lo más profundo en el árbol de dependencias. El problema puede aparecer en muchos componentes muy rápido. Además, las dependencias cambian con bastante frecuencia: en un día promedio, 40,000 paquetes de npm experimentan un cambio en sus dependencias.
Open Source Insights es una herramienta creada por Google Cloud que proporciona un gráfico de dependencia transitivo para que puedas ver tus dependencias y sus dependencias, es decir, todo en el árbol de dependencias. Las estadísticas de código abierto se actualizan continuamente, con información sobre licencias, datos de seguridad y otros datos de seguridad en varios lenguajes, todo en un solo lugar. Cuando se usa en conjunto con los Cuadros de evaluación de código abierto, que proporcionan una puntuación de riesgo para los proyectos de código abierto, Open Source Insights ayuda a tus desarrolladores a tomar mejores decisiones entre los millones de paquetes de código abierto disponibles.
Para abordar este problema, es clave enfocarse en las dependencias como código. A medida que estas dependencias se mueven hacia el final de la cadena de suministro, es más difícil inspeccionarlas. Para proteger tus dependencias, te recomendamos comenzar con el suministro:
- Utiliza herramientas como Open Source Insights y los cuadros de evaluación de OSS para comprender mejor tus dependencias.
- Analiza y verifica todo el código, los paquetes y las imágenes base con un proceso automatizado forman parte clave de tu flujo de trabajo.
- Controla cómo las personas acceden a estas dependencias. Es fundamental controlar estrictamente los repositorios para el código fuente y de código abierto, con restricciones en torno a la revisión exhaustiva del código y los requisitos de auditoría.
Más adelante, abordaremos los procesos de compilación e implementación con más detalle, aunque también es importante verificar el origen de la compilación, aprovechar un entorno de compilación seguro y garantizar que las imágenes estén firmadas y, luego, se validen en el momento de la implementación.
Los desarrolladores pueden usar varias prácticas de codificación segura:
- Automatizar las pruebas
- Usar lenguajes de software seguros para la memoria
- Revisar el código de mandatos
- Garantizar la autenticidad de la confirmación
- Identificar el código malicioso con anticipación
- Evitar exponer información sensible
- Exigir el registro y el resultado de la compilación
- Aprovechar la administración de licencias
Fase 2: Compilación
El siguiente paso para proteger tu cadena de suministro de software implica establecer un entorno de compilación seguro a gran escala. En esencia, el proceso de compilación comienza con la importación del código fuente en uno o varios lenguajes desde un repositorio y la ejecución de compilaciones para cumplir con las especificaciones que se establecen en los archivos de configuración.
Los proveedores de servicios en la nube, como Google, brindan acceso a un entorno de compilación administrado y actualizado que te permite compilar imágenes a cualquier escala que necesites.
A medida que avances por el proceso de compilación, debes tener en cuenta lo siguiente:
- ¿Tus secretos están protegidos durante el proceso de compilación y después de él?
- ¿Quién tiene acceso a tus entornos de compilación?
- ¿Qué ocurre con los vectores de ataque relativamente nuevos o los riesgos de robo de datos?
Para desarrollar un entorno de compilación seguro, debes comenzar con los Secrets. Son fundamentales y relativamente fáciles de proteger. Primero, asegúrate de que tus Secrets nunca sean de texto simple y, en la medida de lo posible, no formen parte de tu compilación. En su lugar, debes asegurarte de que estén encriptados y tus compilaciones estén parametrizadas para consultar Secrets externos y usarlos según sea necesario. Esto también simplifica la rotación periódica de los Secrets y minimiza el impacto de cualquier filtración.
El siguiente paso es configurar los permisos para tu compilación. Existen varios usuarios y cuentas de servicio involucrados en tu proceso de compilación. Por ejemplo, es posible que algunos usuarios necesiten administrar secretos, mientras que otros tengan que administrar el proceso de compilación agregando o modificando pasos. Además, es posible que otros solo necesiten ver los registros.
A medida que lo haces, es importante seguir estas prácticas recomendadas:
- El más importante es el principio de privilegio mínimo. Implementa permisos específicos que necesitan los usuarios y las cuentas de servicio a fin de realizar sus trabajos con eficacia.
- Asegúrate de conocer cómo interactúan los usuarios y las cuentas de servicio, y comprender claramente la cadena de responsabilidad, desde la configuración de una compilación hasta su ejecución y sus efectos descendentes.
A continuación, a medida que escalas este proceso, establece límites en torno a tu compilación en la medida de lo posible y, luego, usa la automatización para escalar verticalmente a través de la configuración, como el código y la parametrización. Esto te permite auditar de manera eficaz cualquier cambio en el proceso de compilación. Además, asegúrate de cumplir con las necesidades de cumplimiento a través del acceso de aprobación a implementaciones y compilaciones sensibles, las solicitudes de extracción para los cambios en la infraestructura y las revisiones manuales manuales de los registros de auditoría.
Por último, asegúrate de 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 detrás de firewalls. Google Cloud te brinda acceso a funciones como los grupos privados de Cloud Build, un entorno de compilación sin servidores y bloqueado en tu propio perímetro de red privada, y a funciones como los Controles del servicio de VPC, que te permiten evitar el robo de datos de la propiedad intelectual.
Autorización binaria
Si bien IAM es imprescindible y lógico, no es infalible. Las filtraciones representan un riesgo de seguridad grave, por lo que, para reducir la dependencia en IAM, puedes cambiar a un sistema basado en certificaciones que sea menos propenso a errores. Google usa un sistema llamado autorización binaria, que permite que solo se implementen cargas de trabajo de confianza.
El servicio de autorización binaria establece, verifica y mantiene una cadena de confianza mediante certificaciones y verificaciones de políticas durante todo el proceso. En esencia, la autorización binaria genera firmas criptográficas (certificaciones) a medida que el código y otros artefactos se mueven hacia la producción y, luego, antes de la implementación, se verifican estas certificaciones según las políticas.
Cuando usas Google Cloud Build, se captura un conjunto de certificaciones y se agrega a tu cadena de confianza general. Por ejemplo, se generan certificaciones para las tareas que se ejecutaron, las herramientas de compilación y los procesos que se usaron, etcétera. En particular, Cloud Build te ayuda a alcanzar la SLSA de nivel 1 mediante la captura de la fuente de la configuración de compilación, que se puede usar para validar que la compilación se haya escrito. Las compilaciones con secuencias de comandos son más seguras que las manuales y son necesarias para el nivel 1 de SLSA. Además, el origen de tu compilación y otras certificaciones se pueden buscar mediante el resumen de la imagen del contenedor, que crea una firma única para cualquier imagen y también es obligatorio para la SLSA de nivel 1.
Fase 3: Paquete
Cuando se complete la compilación, tendrás una imagen de contenedor casi lista para la producción. Es fundamental contar con una ubicación segura para almacenar las imágenes, ya que eso puede evitar la manipulación de las imágenes existentes y la carga de imágenes no autorizadas. Es probable que tu administrador de paquetes necesite imágenes tanto para compilaciones propias como de código abierto, así como para los paquetes de lenguaje que usan tus aplicaciones.
Artifact Registry de Google Cloud te proporciona un repositorio de este tipo. Artifact Registry permite que tu organización administre imágenes de contenedor y paquetes de lenguajes (como Maven y npm) en un solo lugar. Está completamente integrado a las herramientas y los entornos de ejecución de Google Cloud y viene con compatibilidad para protocolos de artefactos nativos. Esto facilita la integración en las herramientas de CI/CD mientras trabajas para configurar canalizaciones automáticas.
Al igual que en el paso de compilación, es fundamental garantizar que los permisos de acceso a Artifact Registry estén bien pensados y sigan los principios de privilegio mínimo. Además de restringir el acceso no autorizado, el repositorio de paquetes puede proporcionar mucho más valor. Por ejemplo, Artifact Registry incluye el análisis de vulnerabilidades para analizar tus imágenes y garantizar que sean seguras de implementar. Este servicio analiza imágenes con una base de datos de vulnerabilidades de actualización constante a fin de evaluar las nuevas amenazas, y puede alertarte cuando se encuentra una vulnerabilidad.
En este paso, se generan metadatos adicionales, incluida una certificación para determinar si los resultados de la vulnerabilidad de un artefacto cumplen con ciertos umbrales de seguridad. Luego, esta información se almacena en nuestro servicio de análisis, que estructura y organiza los metadatos del artefacto, lo que facilita su acceso a la autorización binaria. Puedes usar esta función para evitar que se implementen imágenes riesgosas en Google Kubernetes Engine (GKE) de forma automática.
Fases 4 y 5: Implementación y ejecución
Las dos fases finales de la cadena de suministro de seguridad de software son las de implementación y ejecución. Si bien estos son dos pasos independientes, tiene sentido pensar en ellos como una forma de garantizar que solo las compilaciones autorizadas lleguen a la producción.
En Google, desarrollamos prácticas recomendadas para determinar qué tipo de compilaciones se deben autorizar. Estas comienzan con la garantía de la integridad de la cadena de suministro, de modo que produzca solo artefactos que sean confiables. Luego, incluye la administración de vulnerabilidades como parte del ciclo de vida de la entrega de software. Por último, unimos esos dos elementos a fin de aplicar flujos de trabajo en función de políticas para el análisis de integridad y vulnerabilidades.
Cuando llegas a esta etapa, ya pasaste por las fases de código, compilación y paquete. Las certificaciones capturadas en la cadena de suministro se pueden verificar para comprobar su autenticidad mediante la autorización binaria. En el modo de aplicación, una imagen se implementa solo cuando las certificaciones cumplen con las políticas de la organización y, en el modo de auditoría, se registran los incumplimientos de políticas y se activan las alertas. También puedes usar la autorización binaria para evitar que se ejecuten las compilaciones, a menos que se hayan compilado mediante el proceso aprobado de Cloud Build. La autorización binaria garantiza que solo se implemente correctamente el código revisado y autorizado.
Implementar tus imágenes en un entorno de ejecución confiable es esencial. GKE, nuestra plataforma administrada de Kubernetes, adopta un enfoque que prioriza la seguridad para los contenedores.
GKE se encarga de muchas de las inquietudes de seguridad del clúster que necesitas resolver. Las actualizaciones automáticas del clúster te permiten mantener tus parches de Kubernetes actualizados automáticamente mediante el uso de canales de versiones. El inicio seguro, los nodos protegidos y las verificaciones de integridad garantizan que el kernel y los componentes del clúster de tu nodo no se hayan modificado y ejecuten lo que deseas, ya que los nodos maliciosos no pueden unirse a tu clúster. Por último, la computación confidencial te permite ejecutar clústeres con nodos cuya memoria está encriptada para que los datos se puedan mantener confidenciales mientras se procesan. Además, con la encriptación de datos en reposo y en tránsito a través de la red, GKE proporciona un entorno muy seguro, privado y confidencial para ejecutar tus cargas de trabajo alojadas en contenedores.
Más allá de esto, GKE también habilita una mayor seguridad para tus aplicaciones mediante la administración de certificados para los balanceadores de cargas, Workload Identity y capacidades de red avanzadas con una poderosa manera de configurar y proteger la entrada en su clúster. GKE también ofrece entornos de zona de pruebas para ejecutar aplicaciones no confiables y, al mismo tiempo, proteger el resto de tus cargas de trabajo.
Con GKE Autopilot, las prácticas recomendadas y las funciones de seguridad de GKE se implementan automáticamente, lo que reduce aún más la superficie de ataque y minimiza la configuración incorrecta, que puede generar problemas de seguridad.
Por supuesto, la necesidad de verificación no se detiene en la implementación. La autorización binaria también admite la validación continua, lo que permite el cumplimiento continuo de la política definida, incluso después de la implementación. Si una aplicación en ejecución no cumple con una política existente o que se agregó hace poco, se crea y registra una alerta, lo que te garantiza que lo que ejecutas en producción es exactamente lo que quieres.
Administración de vulnerabilidades
Además de garantizar la integridad, otro aspecto de la seguridad de la cadena de suministro es garantizar que cualquier vulnerabilidades se encuentre con rapidez y se aplique un parche. Los atacantes evolucionaron para insertar de forma activa las vulnerabilidades en proyectos ascendentes. La administración de vulnerabilidades y la detección de defectos debe estar incorporada en todas las etapas del ciclo de vida de la entrega de software.
Una vez que el código esté listo para la implementación, usa una canalización de CI/ CD y aprovecha las numerosas herramientas disponibles a fin de realizar un análisis completo del código fuente y los artefactos generados. Estas herramientas incluyen analizadores estáticos, herramientas de fuzzing y varios tipos de análisis de vulnerabilidades.
Después de implementar la carga de trabajo y mientras se ejecuta en producción y se entrega a los usuarios, es necesario supervisar las amenazas emergentes y tener planes para tomar medidas de solución inmediatas.
Conclusión
En resumen, para proteger una cadena de suministro de software se necesita implementar prácticas recomendadas como la SLSA y usar servicios administrados confiables para lograrlo.
Es fundamental que hagas lo siguiente:
- Comienza con tu código y tus dependencias, y asegúrate de que sean de confianza.
- Protege tu sistema de compilación y usa las certificaciones para verificar el seguimiento de todos los pasos de compilación necesarios.
- Asegúrate de que todos los paquetes y artefactos sean de confianza y que no se puedan manipular.
- Aplica controles sobre quién puede implementar qué y mantén registros de auditoría. Usa la autorización binaria para validar las certificaciones de cada artefacto que quieras implementar.
- Ejecuta tus aplicaciones en un entorno de confianza y asegúrate de que nadie pueda manipularlas mientras se ejecutan. Presta atención a las vulnerabilidades descubiertas recientemente para poder proteger tu implementación.
En Google, incorporamos las prácticas recomendadas para cada paso de este recorrido en nuestra cartera de productos a fin de que tengas una base confiable sobre la que puedas edificar.
Comenzar
¿Todo listo para comenzar a proteger tu cadena de suministro de software? Para que quede claro, tu punto de partida es bastante arbitrario: no existe ninguna acción que proteja toda tu cadena de suministro, y no hay una acción que sea más importante que cualquier otra en este asunto de seguridad. Dicho esto, aquí tienes cuatro recomendaciones para comenzar.
1. Aplica un parche al software
Si implementaste un código en el entorno de producción con vulnerabilidades conocidas, habrás hecho el trabajo del atacante por él. A partir de ese momento, no importa qué tan bien hayas protegido tu cadena de suministro de software porque ya habrán encontrado la forma de ingresar a ella. Por eso, la aplicación de parches es fundamental.
2. Toma el control de lo que se ejecuta en tu entorno
Una vez que completes la aplicación de parches, podrás controlar la cadena de suministro del software. Para comenzar, puedes confirmar que lo que ejecutas realmente proviene de tus herramientas de compilación o repositorios de confianza. Ese nivel de control ayuda a evitar ataques intencionales y errores involuntarios, como es el caso de un desarrollador que implementó algo que no se sabía que no era seguro. Esto proporciona una base sólida para agregar herramientas como pruebas de clics y autorización binaria.
3. Garantiza la seguridad de los paquetes de proveedores externos
Un problema que emerge en la seguridad de la cadena de suministro es la frecuencia con la que el software de los proveedores se ve comprometido a fin de proporcionar un conducto para el ransomware o el acceso no autorizado a las implementaciones de cliente objetivo. Los paquetes de proveedores externos que ejecutas en tu entorno (por ejemplo, productos de administración del sistema, productos de administración de redes o productos de seguridad) suelen tener altos niveles de privilegio. Sugerimos pedirles a esos proveedores que vayan más allá de las declaraciones de seguridad estándar para proporcionar un nivel de certeza sobre los paquetes que usas. Puedes preguntarle cuál es su nivel de cumplimiento con la SLSA o si se encuentra dentro del alcance de los requisitos de la Orden Ejecutiva reciente.
4. Establece una copia privada de tu código fuente
Si usas un software de código abierto, no uses una versión extraída directamente de Internet para compilar. En su lugar, realiza una copia privada que mantengas con un parche a fin de comenzar de forma segura cada compilación y que puedas saber con un 100% de confianza de dónde proviene el código fuente.
Lecturas adicionales
Prácticas recomendadas para DevOps
- Seis informes anuales del estado de DevOps, un conjunto de artículos con información detallada sobre las capacidades que predicen el rendimiento de la entrega de software y una verificación rápida que lo ayuda a descubrir en qué nivel se encuentra y cómo mejorar
- Informe de Google Cloud en 2021 sobre el estado de DevOps
- Informe de Google Cloud: Cambio de la arquitectura a una nativa de la nube: un enfoque evolutivo para aumentar la productividad de los desarrolladores a gran escala
Protege la cadena de suministro de software
- Blog de Google Cloud: ¿Qué es la seguridad de identidad de confianza cero?
- Blog de seguridad de Google: Presentamos SLSA, un marco de trabajo de extremo a extremo para la integridad de la cadena de suministro
- Informe de Google Cloud: Cambio a la izquierda en seguridad: Protección de las cadenas de suministro de software
¿Desea dar el siguiente paso?
Completa el formulario, y nos comunicaremos contigo. Ver formulario