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 dan los equipos de software para administrar su fuente es adoptar 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 de revisión de código integradas 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. Se describen las prácticas recomendadas de Niveles de cadena de suministro para artefactos de software, un framework 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 SLSA nivel 2. Recomendamos la alineación con SLSA nivel 2 como un 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 origen verificado y la política de retención de origen. El nivel 4 de SLSA agrega revisiones de dos personas a los requisitos de origen.

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 son necesarias las revisiones históricas y la auditoría. Sin embargo, existen otros tipos de fuentes que también se benefician del control de versión, incluidos la configuración, la política y los datos. Esto incluye cualquier archivo que cumpla con lo siguiente:

  • Afecte la disponibilidad y la seguridad de tu infraestructura de procesamiento
  • Requiera colaboración para finalizar
  • Requiera un proceso de aprobación repetible
  • Requiera un historial de cambios

Por ejemplo:

  • Infraestructura como código: Las organizaciones que desean administrar su infraestructura de una 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 versiones que crean 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. Almacenas y administras archivos de configuración de aplicaciones en tu sistema de control de versión.
  • Configuraciones de bases de datos y secuencias de comandos de migración: Almacena la configuración y las secuencias de comandos para las bases de datos de tus productos y las bases de datos de análisis o registro.
  • Notebooks de Jupyter: Existen varias formas de trabajar con notebooks almacenados en GitHub, incluida 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 denieguen el comportamiento de implementación en GKE o políticas de Sentinel que impidan que Terraform aprovisione la infraestructura que incumple la política.

El control de versiones es una de las capacidades técnicas identificadas por la investigación de DevOps de DORA que impulsa una mayor entrega de software y rendimiento organizacional. 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, rastrear 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 las funciones, los permisos, las integraciones y las aprobaciones relacionados.

Los problemas que pueden ocurrir con la configuración del repositorio incluyen los siguientes:

  • La configuración del repositorio no está estandarizada, por lo que se dificulta garantizar que la seguridad del repositorio sea adecuada para la aplicación que representa, en especial en la situación común cuando 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 combinaciones sin otros revisores.
  • Integrar repositorios con análisis de código, servidores de compilación, sistemas de seguimiento de problemas, 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, las prácticas recomendadas incluyen lo siguiente:

  • 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 es el repositorio. Las aplicaciones de alta seguridad requieren más aprobadores de combinación y diferentes que las aplicaciones de menor seguridad.
  • Crea una forma para que los administradores de repositorios seleccionen un conjunto de plantillas de configuración de repositorios 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 significar usar un sistema jerárquico de administración de identidades y accesos (IAM) que refleje las aplicaciones y la infraestructura de tu organización, y los usuarios responsables de ellas.
  • Requiere la administración de identidades centralizada con la 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 muden a equipos nuevos, mantengas el principio de 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 y otros tipos de ataques a tu fuente. La autenticación de dos factores es uno de los requisitos de SLSA nivel 4 para los aprobadores de código.
  • Limita los propietarios del repositorio a una pequeña cantidad de empleados de confianza. Esto podría requerir la integración del control de versión con un sistema de administración de identidades y la capacidad de establecer políticas más altas en la organización. Si es posible, quita la capacidad de los propietarios del repositorio para realizar combinaciones 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 código inseguro escrito por 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

Algunas formas de mitigar el riesgo incluyen las siguientes:

  • 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ápidos sobre los problemas que encuentran las pruebas.
  • Haz que la cantidad y la identidad de los revisores sean adecuadas para el 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 crítica para la empresa orientada al 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 tecnológica, junto con programas educativos para desarrolladores nuevos. Algunos IDEs, como VS Code y 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 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). Describe las 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 coloque un nuevo lanzamiento en la prueba para realizar verificaciones de seguridad y revisión de 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 problemas lo antes posible. La API de On-Demand Scanning te per Google Cloud mite 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 interrumpirán la aplicación. Obtén más información sobre la automatización de pruebas.

Aprobaciones de combinación

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 quién puede combinar es una parte fundamental de la protección de las implementaciones de software. Comprende las siguientes consideraciones:

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

Herramientas para proteger el desarrollo

Google Cloud proporciona un conjunto de capacidades y herramientas modulares que puedes usar para mejorar la postura de 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 completamente administrados en Google Cloud. Permite que los administradores de TI y de seguridad aprovisionen, escalen, administren y protejan sus entornos de desarrollo con facilidad, y permite que los desarrolladores accedan a entornos de desarrollo con configuraciones coherentes y herramientas personalizables.

    Cloud Workstations ayuda a cambiar la seguridad a la izquierda mejorando 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 de imágenes forzada 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 (vista previa)

    Cloud Code proporciona compatibilidad con IDE para crear, implementar y, también, integrar aplicaciones en Google Cloud. Permite que los desarrolladores creen y personalicen una aplicación nueva a partir de plantillas de muestra y ejecuten la aplicación terminada. Source protect de Cloud Code brinda 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 realizar 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?