Protege la fuente

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

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

Si bien la mayoría de los equipos usan el control de versión en la actualidad, existen muchas formas 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. En él, se describen las prácticas recomendadas de los niveles de cadena de suministro para artefactos de software, un marco de trabajo para proteger tu cadena de suministro de software. El framework incluye requisitos en varios niveles para ayudarte a implementar cambios de forma incremental, incluidos los requisitos de origen.

Un sistema de control de versión con historial de cambios y revisiones inmutables es un requisito de nivel 2 de la SLSA. Recomendamos la alineación con el nivel 2 de 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 con requisitos de seguridad más estrictos, incluido el historial de fuentes verificado y la política de retención de fuentes. El nivel 4 de SLSA agrega revisiones de dos personas a los requisitos de la fuente.

Usa el control de versión para más que la fuente de tu aplicación

Almacenar la fuente de la aplicación en el control de versión es una práctica bien establecida cuando se necesitan revisiones históricas y auditorías. Sin embargo, existen otros tipos de fuente que también se benefician del control de versión, como la configuración, la política y los datos. Esto incluye los siguientes archivos:

  • Afecta la disponibilidad y la seguridad de tu infraestructura de procesamiento
  • Requiere colaboración para finalizar
  • Exigen un proceso de aprobación repetible
  • Solicita un historial de cambios

Por ejemplo:

  • Infraestructura como código: Las organizaciones que desean administrar su infraestructura de forma 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 versiones que crea repositorios de Artifact Registry.
  • Administración de configuración: La administración de 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. Almacena y administra los archivos de configuración de la aplicación en tu sistema de control de versión.
  • Parámetros de configuración y secuencias de comandos de migración de bases de datos: Almacena la configuración y las secuencias de comandos de las bases de datos de productos y de las bases de datos de análisis o registro.
  • Notebooks de Jupyter: Existen varias formas de trabajar con notebooks almacenados en GitHub, como la extensión para JupyterLab, Colaboratory y Vertex AI Workbench.
  • Políticas de seguridad: Almacena archivos de políticas para la aplicación automática 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 impidan que Terraform aprovisione infraestructura que incumpla la política.

El control de versión es una de las capacidades técnicas que identificó la investigación de DevOps de DORA que impulsa una entrega de software y un rendimiento organizativo más altos. 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, hacer un seguimiento y auditar cambios, y responder a defectos con rapidez.

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.

Entre los problemas que pueden ocurrir con la configuración del repositorio, se incluyen los siguientes:

  • La configuración del repositorio no está estandarizada, por lo que resulta difícil garantizar que la seguridad del repositorio sea adecuada para la aplicación que representa, en particular en el caso común en el que una organización tiene cientos o miles de repositorios.
  • Quien crea el repositorio se convierte en propietario con permisos administrativos completos, incluida la capacidad de realizar fusiones sin otros revisores.
  • La integración de repositorios con análisis de código, servidores de compilación, sistemas de seguimiento de errores, servicios de notificación y otras partes de la infraestructura de CI/CD puede ser un trabajo considerable. Tener una forma estándar de crear y configurar repositorios ahorra trabajo repetitivo y admite prácticas recomendadas.

Para abordar estos problemas, se recomiendan las prácticas recomendadas:

  • Configura repositorios con un proceso automatizado, repetible y orientado a la seguridad. Por ejemplo, puedes configurar módulos de Terraform que incorporen los requisitos de seguridad de la aplicación para la que se creó el repositorio. Las aplicaciones de alta seguridad requieren más revisores de combinación y diferentes que las apps de menor seguridad.
  • Crea una forma para que los administradores del repositorio seleccionen entre un conjunto de plantillas de configuración de repositorio que impulsen 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 implicar el uso de un sistema de control de acceso (IAM) jerárquico que refleje las aplicaciones y la infraestructura de tu organización, así como los usuarios que son responsables de ellas.
  • Solicita la 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 cambien a equipos nuevos, mantengas privilegio mínimo en la administración de fuentes.
    • La autenticación de varios factores reduce significativamente el riesgo de suplantación de identidad y otros tipos de ataques a tu fuente. La autenticación de dos factores es uno de los requisitos de nivel 4 de la SLSA para los revisores de código.
  • Limita los propietarios del repositorio a una pequeña cantidad de empleados de confianza. Esto podría requerir integrar el control de versión con un sistema de administración de identidades y mover la capacidad de establecer políticas a un nivel superior en la organización. Si es posible, quita la capacidad de los propietarios del repositorio para realizar fusiones sin un segundo revisor.

Revisión de código

La revisión de código es la forma principal en que las organizaciones mantienen la calidad y la 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 debido a un código no seguro escrito por el desarrollador
  • Aparición de problemas de seguridad debido a la adición de bibliotecas de terceros que no son seguras o que podrían no serlo.

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 versiones son una forma para que los desarrolladores obtengan comentarios rápidamente sobre los problemas que encuentran las pruebas.
  • La cantidad y la identidad de los revisores deben ser adecuadas al nivel de seguridad de la aplicación. Por ejemplo, una app de intranet con poco uso tendrá requisitos de seguridad más bajos que una aplicación empresarial crítica para el público.
  • Asigna revisores en función de la experiencia técnica y el nivel de confianza requerido para el cambio en la confirmación. El revisor debe ser un experto en el lenguaje que se revisa, 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 seguro?
    • ¿Usa 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 revisiones no deben ser un paso burocrático, sino una conversación continua sobre 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 de tecnología, junto con programas educativos para desarrolladores nuevos. Algunos IDE, como VS Code y IntelliJ, proporcionan linters que pueden marcar automáticamente errores programáticos o estilísticos. Los linters ayudan a los desarrolladores a crear un 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.

    Desarrollo de software seguro es un curso en línea gratuito creado por Open Source Security Foundation (OpenSSF). En él, se describen prácticas fundamentales 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 individual esté listo. No esperes hasta justo antes de que se pruebe una nueva versión para realizar verificaciones de seguridad y revisiones de código.

  • La integración del 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 de On-Demand Scanning en 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 dañarán la aplicación. Obtén más información sobre la automatización de pruebas.

Combina aprobaciones

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

  • Configura propietarios de ramas protegidos en tus ramas de producción. La cantidad y la identidad de las personas autorizadas para realizar la combinación deben ser adecuadas a los requisitos de seguridad de la aplicación. El nivel 4 de la SLSA requiere dos revisores con autenticación sólida, pero la cantidad de revisores debe ser adecuada para el contenido del repositorio.
  • Controla de forma estricta las identidades de los propietarios del repositorio, ya que, en la mayoría de los sistemas de control de versiones, pueden realizar combinaciones por su cuenta.
  • Separa los procesos de aprobación de implementación y combinación para lanzamientos de varios artefactos y repositorios.

Herramientas para proteger el desarrollo

Google Cloud proporciona un conjunto de herramientas y capacidades modulares que puedes usar para mejorar la posición de seguridad de tu cadena de suministro de software. Los siguientes componentes ayudan a proteger el código fuente del 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, escalen, administren y protejan sus entornos de desarrollo con facilidad, y permite a los desarrolladores acceder a entornos de desarrollo con configuraciones coherentes y herramientas personalizables.

    Cloud Workstations ayuda a cambiar el enfoque de seguridad, ya que mejora la postura de seguridad de tus entornos de desarrollo de aplicaciones. Tiene funciones de seguridad, como los Controles del servicio de VPC, la entrada o salida privadas, la actualización obligatoria 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.

  • Protección de source protect de Cloud Code (versión preliminar)

    Cloud Code proporciona compatibilidad con IDE para crear, implementar e 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 terminada. 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 corregir su código al comienzo del proceso de desarrollo de software.

    Disponibilidad de las funciones: 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?