Protección de la fuente

En este documento se describen las prácticas recomendadas para gestionar el código fuente de software.

Un paso fundamental que dan los equipos de software para gestionar su código fuente es adoptar un sistema de control de versiones (VCS). Los sistemas de control de versiones proporcionan un historial y una auditabilidad de los cambios. Los sistemas de control de versiones alojados, como GitHub, ofrecen ventajas adicionales, como disponibilidad, estabilidad, controles de seguridad, herramientas de revisión de código integradas e integración con otros servicios en la nube.

Aunque la mayoría de los equipos usan el control de versiones, hay muchas formas de configurar un sistema de control de versiones y sus integraciones con otras partes del flujo de procesamiento de CI/CD.

En este documento se analizan las consideraciones de seguridad de la cadena de suministro de software para configurar un sistema de control de versiones. Describe las prácticas recomendadas de Niveles de la cadena de suministro para artefactos de software, un framework para proteger tu cadena de suministro de software. El marco incluye requisitos en varios niveles para ayudarte a implementar los cambios de forma incremental, incluidos los requisitos de la fuente.

Un sistema de control de versiones con historial de cambios y revisiones inmutables es un requisito de SLSA de nivel 2. Te recomendamos que te ciñas al nivel 2 del SLSA como nivel de referencia inicial para tu cadena de suministro de software.

En el nivel 3 de SLSA, las plataformas de origen y compilación cumplen requisitos de seguridad más estrictos, como el historial de origen verificado y la política de conservación del origen. El nivel 4 de SLSA añade revisiones por parte de dos personas a los requisitos de la fuente.

Usar el control de versiones para más que el código fuente de la aplicación

Almacenar el código fuente de la aplicación en un sistema de control de versiones es una práctica habitual cuando se necesitan revisiones e auditorías históricas. Sin embargo, hay otros tipos de fuentes que también se benefician del control de versiones, como la configuración, las políticas y los datos. Esto incluye los archivos que:

  • Afectar a la disponibilidad y la seguridad de tu infraestructura de computación
  • Requerir colaboración para finalizar
  • Requerir un proceso de aprobación repetible
  • Requerir un historial de cambios

Algunos ejemplos:

  • Infraestructura como código: las organizaciones que quieren gestionar su infraestructura de forma escalable y segura utilizan la infraestructura como código como metodología clave. Por ejemplo, puedes almacenar módulos de Terraform en un sistema de control de versiones que cree repositorios de Artifact Registry.
  • Gestión de la configuración: es similar a la infraestructura como código, pero se centra en gestionar la configuración de las aplicaciones con herramientas como Ansible, Puppet y Chef. Almacena y gestiona los archivos de configuración de la aplicación en tu sistema de control de versiones.
  • Configuraciones de bases de datos y secuencias de comandos de migración: almacena la configuración y las secuencias de comandos de las bases de datos de tus productos, así como de las bases de datos de analíticas o de registro.
  • Cuadernos de Jupyter: hay varias formas de trabajar con cuadernos almacenados en GitHub, como la extensión para JupyterLab, Colaboratory y Vertex AI Workbench.
  • Políticas de seguridad: almacena archivos de políticas para automatizar la implementación obligatoria de las políticas. Por ejemplo, puedes almacenar políticas de Gatekeeper que permitan o denieguen el comportamiento de implementación en GKE o políticas de Sentinel que impidan que Terraform aprovisione infraestructura que infrinja las políticas.

El control de versiones es una de las capacidades técnicas identificadas por la investigación de DevOps de DORA que mejora el envío de software y el rendimiento de las organizaciones. Almacenar tus secuencias de comandos, código fuente y archivos de configuración en un sistema de control de versiones te ayuda a reproducir y recuperar entornos, a monitorizar y auditar cambios, y a responder rápidamente a los defectos.

Configuración del repositorio

Los repositorios son la unidad lógica fundamental para organizar el código y los roles, permisos, integraciones y aprobaciones relacionados.

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

  • La configuración de los repositorios no está estandarizada, por lo que resulta difícil asegurarse de que la seguridad de los repositorios sea adecuada para la aplicación que representan, sobre todo en el caso habitual de que una organización tenga cientos o miles de repositorios.
  • Quien cree el repositorio se convertirá en propietario con permisos administrativos completos, incluida la capacidad de realizar combinaciones sin otros revisores.
  • Integrar repositorios con análisis de código, servidores de compilación, sistemas de seguimiento de incidencias, servicios de notificaciones y otras partes de la infraestructura de integración y entrega continuas puede suponer una gran cantidad de trabajo. Tener una forma estándar de crear y configurar repositorios evita el trabajo repetitivo y favorece las prácticas recomendadas.

Para solucionar estos problemas, se recomienda

  • 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 de otro tipo que las aplicaciones de menor seguridad.
  • Crea un método para que los administradores de repositorios puedan elegir entre un conjunto de plantillas de configuración de repositorios que impulsen la configuración de nuevos repositorios 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 requieran en cada nivel de seguridad. En la práctica, esto suele significar usar un sistema de gestión de identidades y accesos (IAM) jerárquico que refleje las aplicaciones y la infraestructura de tu organización, así como los usuarios responsables de ellas.
  • Requerir una gestión de identidades centralizada con autenticación multifactor para los usuarios del repositorio.
    • La gestión de identidades centralizada asegura que, cuando los usuarios abandonan la organización o se trasladan a nuevos equipos, se mantenga el principio de privilegio mínimo en la gestión de fuentes.
    • La autenticación multifactor reduce significativamente el riesgo de phishing y otros tipos de ataques a tu fuente. La autenticación de dos factores es uno de los requisitos del nivel 4 de SLSA para los aprobadores de código.
  • Limita el número de propietarios del repositorio a unos pocos empleados de confianza. Para ello, puede que sea necesario integrar el control de versiones con un sistema de gestión de identidades y trasladar la capacidad de definir políticas a un nivel superior de la organización. Si es posible, elimina la posibilidad de que los propietarios de repositorios realicen fusiones sin un segundo revisor.

Revisión de código

La revisión del código es la forma principal en que las organizaciones mantienen la calidad y la seguridad de su software. La revisión del código intenta abordar varios modos de fallo, 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 debido a código no seguro escrito por el desarrollador
  • Introducción de problemas de seguridad debido a la adición de bibliotecas de terceros que no son seguras o que podrían dejar de serlo.

Estas son algunas formas de mitigar los riesgos:

  • Implementa la automatización de pruebas a lo largo del ciclo de vida del software. Las pruebas automatizadas que se activan cuando confirmas el código fuente en el sistema de control de versiones permiten a los desarrolladores recibir rápidamente comentarios sobre los problemas detectados en las pruebas.
  • El número y la identidad de los revisores deben ser adecuados para el nivel de seguridad de la aplicación. Por ejemplo, una aplicación de intranet con poco uso tendrá requisitos de seguridad más bajos que una aplicación empresarial pública de importancia crítica.
  • Asigna revisores en función de sus conocimientos técnicos y del nivel de confianza necesario para el cambio en la confirmación. El revisor debe ser un experto en el idioma que se está revisando, los sistemas con los que interactúa el código y los riesgos de seguridad de este tipo de aplicación. Los conocimientos técnicos necesarios tienen muchas dimensiones. Por ejemplo:
    • ¿El código es legible?
    • ¿Es seguro?
    • ¿Utiliza bibliotecas de terceros adecuadas?
    • ¿Se ha implementado un proceso para proteger las bibliotecas de terceros?
    • ¿Se puede componer el código?
    • ¿El diseño de la API sigue las prácticas recomendadas?

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

    Developing Secure Software es un curso online gratuito 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.

  • Realiza revisiones de código con solicitudes de extracción de ramas de funciones en cuanto un desarrollador esté listo. No esperes hasta justo antes de que se publique una nueva versión para hacer comprobaciones de seguridad y revisar el código.

  • Integrar el análisis de vulnerabilidades, incluido el análisis de bibliotecas de terceros, en las solicitudes de extracción y los IDEs ayuda a identificar los problemas lo antes posible. La API On-Demand Scanning de Google Cloud te permite analizar contenedores localmente 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. Más información sobre la automatización de pruebas

Fusionar aprobaciones

En los flujos de procesamiento de CI/CD integrados de forma continua, la combinación de código en una rama de producción puede provocar cambios posteriores, como la compilación y el lanzamiento automatizados. Por este motivo, proteger quién puede combinar es una parte fundamental de la protección de las implementaciones de software. Estas son algunas de las competencias que se evaluarán:

  • Configura propietarios de ramas protegidas en tus ramas de producción. El número y la identidad de las personas que tengan permiso para combinar deben ser adecuados a los requisitos de seguridad de la aplicación. El nivel 4 de SLSA requiere dos aprobadores con autenticación reforzada, pero el número de aprobadores debe ser adecuado al contenido del repositorio.
  • Controla estrictamente las identidades de los propietarios de los repositorios, ya que, en la mayoría de los sistemas de control de versiones, pueden realizar fusiones por sí mismos.
  • Procesos de aprobación de despliegue y de combinación independientes para lanzamientos de varios repositorios y de varios artefactos.

Herramientas para proteger el desarrollo

Google Cloud proporciona un conjunto de funciones y herramientas modulares que puedes usar para mejorar la seguridad de tu cadena de suministro de software. Los siguientes componentes ayudan a proteger el código fuente del software:

  • Cloud Workstations (vista previa)

    Cloud Workstations proporciona entornos de desarrollo totalmente gestionados enGoogle Cloud. Permite a los administradores de TI y de seguridad aprovisionar, escalar, gestionar y proteger fácilmente sus entornos de desarrollo, así como a los desarrolladores acceder a entornos de desarrollo con configuraciones coherentes y herramientas personalizables.

    Cloud Workstations ayuda a mejorar la seguridad de los entornos de desarrollo de aplicaciones. Cuenta con funciones de seguridad como Controles de Servicio de VPC, entrada o salida privadas, actualizaciones de imágenes forzadas y políticas de acceso de gestión de identidades y accesos. Para obtener más información, consulta la documentación de Cloud Workstations.

  • Protección de código fuente de Cloud Code (vista previa)

    Cloud Code proporciona compatibilidad con IDEs para crear, desplegar e integrar aplicaciones con Google Cloud. Permite a los desarrolladores crear y personalizar una nueva aplicación a partir de plantillas de ejemplo y ejecutar la aplicación terminada. Source Protect de Cloud Code ofrece a los desarrolladores comentarios de seguridad en tiempo real, como la identificación de dependencias vulnerables y la generación de informes de licencias, mientras trabajan en sus IDEs. Proporciona comentarios rápidos y prácticos que permiten a los desarrolladores corregir su código al principio del proceso de desarrollo de software.

    Disponibilidad de las funciones: la protección del código fuente de Cloud Code no está disponible para el acceso público. Para acceder a esta función, consulta la página de solicitud de acceso.

Siguientes pasos