Fuente de protección

En este documento, se describen las prácticas recomendadas para administrar el código fuente del software.

Un paso fundamental que toman los equipos de software para administrar su fuente es adoptar un sistema de control de versión (VCS). Los sistemas de control de versión proporcionan historial y auditabilidad para los cambios. Los sistemas de control de versión alojados, como GitHub, proporcionan beneficios adicionales, como la disponibilidad, estabilidad, controles de seguridad, integración a otros servicios en la nube y herramientas integradas de revisión de código.

Si bien la mayoría de los equipos usan el control de versión en la actualidad, existen muchas maneras de configurar un sistema de control de versión y sus integraciones con otras partes de la canalización de CI/CD.

En este documento, se exploran las consideraciones de seguridad de la cadena de suministro de software para configurar un sistema de control de versión. Se describen las prácticas recomendadas de Niveles de la cadena de suministro para artefactos de software, un framework para proteger la cadena de suministro de software. El framework incluye requisitos en varios niveles para ayudarte a implementar cambios de forma incremental, incluidos los requisitos de la fuente.

Un sistema de control de versión con historial de cambios y revisiones inmutables es un requisito de SLSA de nivel 2. Recomendamos la alineación con el nivel SLSA 2 como un nivel de referencia inicial para tu cadena de suministro de software.

En el nivel SLSA 3, las plataformas de origen y compilación cumplen con requisitos de seguridad más estrictos, incluido el historial de fuente verificado y la política de retención de la fuente. El nivel 4 de SLSA agrega opiniones de dos personas a los requisitos de origen.

Usa el control de versión para otros valores además del código fuente de la aplicación

Almacenar la fuente de la aplicación en el control de versión es una práctica consolidada cuando se necesitan revisiones y auditorías históricas. Sin embargo, hay otros tipos de fuentes que también se benefician del control de versión, incluida la configuración, las políticas y los datos. Esto incluye cualquier archivo con las siguientes características:

  • Afecta la disponibilidad y seguridad de la infraestructura de procesamiento
  • Requerir colaboración para finalizar
  • Exigir un proceso de aprobación repetible
  • Requiere un historial de cambios.

Por ejemplo:

  • Infraestructura como código: Las organizaciones que desean administrar su infraestructura de manera escalable y segura usan la infraestructura como código como una metodología clave. Por ejemplo, puedes almacenar módulos de Terraform en el control de versión que crean repositorios de Artifact Registry.
  • Administración de la configuración: La administración de la configuración es similar a la infraestructura como código, pero se enfoca en administrar la configuración de la aplicación con herramientas como Ansible, Puppet y Chef. Almacenas y administras los archivos de configuración de la aplicación en tu sistema de control de versión.
  • Configuración de la base de datos y secuencias de comandos de migración: Almacena la configuración y las secuencias de comandos para las bases de datos de productos y de estadísticas o de registro.
  • Notebooks de Jupyter: Existen varias formas de trabajar con notebooks almacenados en GitHub, incluida la [extensión para JupyterLab][jlab], Colaboratory y [Vertex AI Workbench][vertex]
  • Políticas de seguridad: Almacena archivos de políticas para la aplicación automatizada de políticas. Por ejemplo, puedes almacenar políticas de Gatekeeper que permitan o rechacen el comportamiento de implementación en GKE o políticas de Sentinel que evitan que Terraform aprovisione una infraestructura que incumpla la política.

El control de versión es una de las capacidades técnicas que identifica la investigación sobre DevOps de DORA y que impulsa una entrega de software y un rendimiento organizacional mayores. Almacenar tus secuencias de comandos, código fuente y archivos de configuración en el control de versión te ayuda a reproducir y recuperar entornos, realizar seguimientos y auditar los cambios, y responder a los defectos con rapidez.

Configuración del repositorio

Los repositorios son la unidad lógica fundamental para organizar el código y las funciones, permisos, integraciones y aprobaciones relacionadas.

Estos son algunos de los problemas que pueden ocurrir con la configuración del repositorio:

  • La configuración del repositorio no está estandarizada, por lo que se vuelve difícil garantizar que la seguridad del repositorio sea apropiada para la aplicación que representa, en especial en una situación común en la que una organización tiene cientos o miles de repositorios.
  • La persona que cree el repositorio se convierte en propietario con permisos administrativos completos, incluida la capacidad de realizar combinaciones con ningún otro moderador.
  • La integración de repositorios con análisis de código, servidores de compilación, herramientas de seguimiento de errores, servicios de notificaciones y otras partes de la infraestructura de CI/CD puede ser un trabajo considerable. Tener una forma estándar de crear y configurar repositorios guarda el trabajo repetitivo y admite las prácticas recomendadas.

Para abordar estos problemas, las prácticas recomendadas incluyen

  • Configura repositorios con un proceso automatizado, repetible y consciente de la seguridad. Por ejemplo, puedes configurar módulos de Terraform que incorporen los requisitos de seguridad de la aplicación para la que se usa el repositorio. Las aplicaciones de alta seguridad requieren más aprobadores de combinación y diferentes que las apps de menor seguridad.
  • Crea una manera para que los administradores de repositorios seleccionen entre un conjunto de plantillas de configuración de repositorios que impulsan la configuración de repositorios nuevos, en lugar de configurar cada repositorio desde cero. Estas plantillas deben reflejar los diferentes niveles de seguridad de tus aplicaciones y sincronizarse con las identidades de usuario que se requieren para cada nivel de seguridad. En la práctica, esto suele significar usar un sistema de control de identidad y acceso (IAM) jerárquico que refleja las aplicaciones y la infraestructura de tu organización y los usuarios responsables de ellas.
  • Requiere una administración de identidades centralizada con autenticación de varios factores para los usuarios del repositorio.
    • La administración de identidades centralizada garantiza que, cuando los usuarios abandonen la organización o se migren a equipos nuevos, mantengas privilegio mínimo en torno a la administración de fuentes.
    • La autenticación de varios factores reduce significativamente el riesgo de suplantación de identidad (phishing) y otros tipos de ataques en tu fuente. La autenticación de dos factores es uno de los requisitos de nivel 4 de SLSA para los aprobadores de código.
  • Limita los propietarios de repositorios a un número reducido de empleados de confianza. Esto puede requerir integrar el control de versión en un sistema de administración de identidades y trasladar la capacidad de establecer políticas más altas en la organización. Si es posible, quita la capacidad de los propietarios de repositorios de realizar combinaciones sin una segunda revisión.

Revisión de código

La revisión de código es la forma principal en que las organizaciones mantienen la calidad y seguridad de su software. La revisión de código intenta abordar varios modos de falla, como los siguientes:

  • Introducción de código con defectos de software o un diseño inflexible.
  • APIs mal definidas
  • Introducción de problemas de seguridad debidos al código no seguro que escribió el desarrollador
  • Introducción de problemas de seguridad debido a la adición de bibliotecas de terceros que son inseguras o podrían volverse inseguras.

Estas son algunas formas de mitigar el riesgo:

  • Implementa la automatización de pruebas durante todo el ciclo de vida del software. Las pruebas automatizadas que se activan cuando confirmas la fuente en el sistema de control de versión son una forma en que los desarrolladores obtienen comentarios con rapidez sobre los problemas que encuentran las pruebas.
  • Haz que el número y la identidad de los revisores sean apropiados para el nivel de seguridad de la aplicación. Por ejemplo, una app de intranet con poco uso tendrá requisitos de seguridad menores que una aplicación pública esencial.
  • Asigna revisores en función de la experiencia técnica y el nivel de confianza necesario para el cambio en la confirmación. El revisor debe ser un experto en el lenguaje que se está revisando, los sistemas con los que interactúa el código y los riesgos de seguridad en esta clase de aplicación. El requisito de experiencia técnica tiene muchas dimensiones. Por ejemplo:
    • ¿El código es legible?
    • ¿Es segura?
    • ¿Utiliza las bibliotecas de terceros adecuadas?
    • ¿Existe un proceso para proteger las bibliotecas de terceros?
    • ¿El código es componible?
    • ¿El diseño de la API sigue las prácticas recomendadas?

  • Las opiniones no deben ser un paso burocrático, sino una conversación continua en torno a las prácticas recomendadas. Crea listas de tareas, guías de estilo y estándares de diseño en torno a cada parte de tu pila tecnológica, junto con programas educativos para desarrolladores nuevos. Algunos IDE, como IntelliJ y VS Code, proporcionan linters que pueden marcar automáticamente errores programáticos o estilísticos. Los lintes ayudan a los desarrolladores a crear código más coherente y permiten que los revisores de código se enfoquen más en los problemas que no son fáciles de identificar con las verificaciones automatizadas.

    Developing Secure Software es un curso gratuito en línea creado por Open Source Security Foundation (OpenSSF). Describe las prácticas básicas de desarrollo de software en el contexto de la seguridad de la cadena de suministro de software.

  • Realizar revisiones de código con solicitudes de extracción de ramas de funciones tan pronto como un desarrollador individual esté listo No esperes hasta justo antes de que se ponga a prueba una nueva versión para realizar controles de seguridad y revisión de código.

  • La integración del análisis de vulnerabilidades, incluido el análisis de bibliotecas de terceros, en IDEs y solicitudes de extracción ayuda a identificar problemas lo antes posible. La API de On-Demand Scanning de Google Cloud te permite analizar contenedores de forma local en busca de vulnerabilidades.

  • Integra pruebas automatizadas previas a la combinación para que los desarrolladores puedan identificar y corregir los cambios que afectarán a la aplicación. Obtén más información sobre la automatización de pruebas.

Combinar aprobaciones

En las canalizaciones de CI/CD integradas de forma continua, la combinación del código en una rama de producción puede generar cambios posteriores, incluidos la compilación y el lanzamiento automatizados. Por este motivo, asegurar quién puede combinarse es una parte fundamental de la seguridad de las implementaciones de software. Se incluyen las siguientes consideraciones:

  • Configura propietarios de ramas protegidas en tus ramas de producción. El número y la identidad de aquellos permitidos para combinarse deben ser adecuados para los requisitos de seguridad de la aplicación. El nivel 4 de SLSA requiere dos responsables de aprobación altamente autenticados, pero la cantidad de responsables de aprobación debe ser adecuada para el contenido del repositorio.
  • Controla con precisión las identidades de los propietarios de repositorios, ya que, en la mayoría de los sistemas de control de versión, pueden realizar combinaciones por sí mismos.
  • Separa la implementación y combina los procesos de aprobación para lanzamientos de varios repositorios y artefactos.

Herramientas para asegurar el desarrollo

Software Delivery Shield es una solución de seguridad de la cadena de suministro de software de extremo a extremo completamente administrada. Proporciona un conjunto integral y modular de funciones y herramientas en los servicios de Google Cloud que los desarrolladores, DevOps y los equipos de seguridad pueden usar para mejorar la postura de seguridad de la cadena de suministro de software. Los siguientes componentes de Software Delivery Shield ayudan a proteger el código fuente de software:

  • Cloud Workstations (versión preliminar)

    Cloud Workstations proporciona entornos de desarrollo completamente administrados en Google Cloud. Permite que los administradores de TI y seguridad aprovisionen, escale, administren y protejan con facilidad sus entornos de desarrollo, y les permite a los desarrolladores acceder a los entornos de desarrollo con parámetros de configuración coherentes y herramientas personalizables.

    Cloud Workstations ayuda a cambiar la seguridad a la izquierda, ya que mejora la postura de seguridad de los entornos de desarrollo de aplicaciones. Tiene funciones de seguridad como los Controles del servicio de VPC, la entrada o salida privada, la actualización forzada de imágenes y las políticas de acceso de Identity and Access Management. Para obtener más información, consulta la documentación de Cloud Workstations.

  • Cloud Code source protect (versión preliminar)

    Cloud Code proporciona compatibilidad con IDE para crear, implementar y, también, integrar aplicaciones con Google Cloud. Permite a los desarrolladores crear y personalizar una aplicación nueva a partir de plantillas de muestra y ejecutar la aplicación finalizada. Source protect de Cloud Code les brinda a los desarrolladores comentarios de seguridad en tiempo real, como la identificación de dependencias vulnerables y los informes de licencias, mientras trabajan en sus IDE. Proporciona comentarios rápidos y prácticos que permiten a los desarrolladores hacer correcciones en su código al comienzo del proceso de desarrollo de software.

    Disponibilidad de la función: source protect de Cloud Code no está disponible para el acceso público. Para obtener acceso a esta función, consulta la página de solicitud de acceso.

¿Qué sigue?