Skip to main content

Explorando la prueba empresarial de GitHub Code Security

Introducción a las características del análisis de código y dependencias disponibles en GitHub Code SecurityGitHub Enterprise Cloud para que pueda evaluar su ajuste a sus necesidades empresariales.

En esta guía se supone que ha planeado e iniciado una prueba de GitHub Advanced Security para una cuenta empresarial existente o una cuenta de prueba GitHub, consulte Planificación de una prueba de GitHub Advanced Security.

Introducción

          Code scanning y el análisis de dependencias funcionan de la misma manera en repositorios públicos y en repositorios privados e internos con Code Security habilitado. Además, Code Security le permite crear campañas de seguridad en las que los especialistas y desarrolladores de seguridad pueden colaborar para reducir eficazmente la deuda técnica.

Este artículo se centra en cómo puedes combinar estas características con controles a nivel de empresa para estandarizar y aplicar el proceso de desarrollo.

Perfeccionamiento de las configuraciones de seguridad

A diferencia de Secret Protection, donde normalmente se aplica una única configuración de seguridad a todos los repositorios, es probable que usted quiera ajustar la configuración de code scanning para distintos tipos de repositorios. Por ejemplo, es posible que tengas que crear configuraciones adicionales para que:

  •         Code scanning usa ejecutores con una etiqueta específica para aplicar a repositorios que requieren un entorno especializado o que usan registros privados.
    
  •         Code scanning es "No establecido" y se aplica a los repositorios que necesitan usar la configuración avanzada o que requieren una herramienta de terceros.
    

Para la prueba, es más sencillo crear una configuración de seguridad principal a nivel de empresa y aplicarla a los repositorios de prueba. A continuación, puedes crear cualquier configuración de seguridad adicional que necesites y aplicarla a un subconjunto de repositorios seleccionados mediante un lenguaje de código, una propiedad personalizada, la visibilidad y otras opciones de filtro. Para más información, consulta Habilitación de características de seguridad en la empresa de prueba y Aplicación de una configuración de seguridad personalizada.

Proporcionar acceso para ver los resultados de code scanning

De forma predeterminada, solo el administrador del repositorio y el propietario de la organización pueden ver todas las code scanning alertas de su área. Debes asignar el rol predefinido de administrador de seguridad a todos los equipos y usuarios de la organización que quieres que accedan a las alertas que se encuentren durante la prueba. Es posible que también quieras conceder este rol al propietario de la cuenta empresarial de cada una de las organizaciones de la prueba. Para más información, consulta Gestionar a los administradores de seguridad en tu organización y Uso de los roles de la organización.

Evaluación y perfeccionamiento de los resultados de la configuración predeterminada

La configuración predeterminada para code scanning ejecuta un conjunto de consultas de elevada confianza. Estos se eligen para asegurarse de que, cuando se implementa code scanning en todo el código base, los desarrolladores ven un conjunto limitado de resultados de alta calidad, con pocos resultados falsos positivos.

Puede ver un resumen de cualquier resultado encontrado en las organizaciones de la empresa de prueba en la pestaña Security de la empresa. También hay vistas independientes para cada tipo de alerta de seguridad. Consulta Visualización de información de seguridad.

Si no ve los resultados esperados para code scanning, puede actualizar la configuración predeterminada para ejecutar un conjunto de consultas extendido para repositorios en los que esperaba encontrar más resultados. Se controla a nivel de repositorio (consulta Editar la configuración predeterminada).

Sugerencia

Si está bloqueado para editar la configuración del repositorio para code scanning, edite la configuración de seguridad usada por el repositorio para que no se aplique la configuración.

Si el conjunto ampliado sigue sin encontrar los resultados esperados, es posible que tengas que habilitar la configuración avanzada para personalizar el análisis por completo. Para más información, consulta Usar la página de estado de la herramienta para el examen de código y Establecimiento de la configuración avanzada para el examen del código.

Aplicación de análisis automatizado a solicitudes de incorporación de cambios

Hay tres tipos diferentes de análisis automatizado de solicitudes de incorporación de cambios integradas en GitHub:

  •         **
            Code scanning el análisis** usa consultas para resaltar patrones de codificación incorrectos conocidos y vulnerabilidades de seguridad. 
            Autofijo de Copilot sugiere correcciones a los problemas identificados por code scanning.
    
  •         **Revisión de dependencias**: resume los cambios de dependencia realizados por la solicitud de incorporación de cambios y resalta las dependencias con vulnerabilidades conocidas o que no cumplen los estándares de desarrollo.
    
  •         **
            Copilot la revisión de código** usa IA para proporcionar comentarios acerca de tus cambios con correcciones sugeridas cuando sea posible.
    

Estas revisiones automatizadas son una extensión valiosa para la autorrevisión y ayudan a los desarrolladores a presentar una solicitud de incorporación de cambios más completa y segura para la revisión por homólogos. Además, code scanning y las revisiones de dependencias pueden imponerse para proteger la seguridad y el cumplimiento de su código.

Nota:

          GitHub Copilot Corrección automática se incluye en la licencia para GitHub Code Security. 
          Copilot la revisión de código requiere un plan de pago Copilot .

          Code scanning análisis

Cuando code scanning está habilitado, puede bloquear las fusiones en ramas importantes a menos que el pull request cumpla con sus requisitos creando un conjunto de reglas de código para la empresa u organización. Normalmente, necesitaría que los resultados de code scanning estén presentes y que se resuelvan las alertas importantes.

  •         **Tipo de conjunto de reglas:** rama.
    
  •         **Requerir code scanning resultados:** habilite para bloquear la combinación hasta que los resultados se generen correctamente para la confirmación y la referencia a los destinos de la solicitud de incorporación de cambios.
    
  •         **Herramientas necesarias y umbrales de alerta:** Defina el nivel de alertas que se deben resolver antes de que se pueda combinar una solicitud de incorporación de cambios para cada code scanning herramienta que use.
    

Al igual que con los conjuntos de reglas, puedes controlar exactamente sobre qué organizaciones (nivel de empresa), repositorios y ramas actúa y definir roles o equipos que puedan omitir la regla. Para más información, consulta Acerca de los conjuntos de reglas.

Revisión de dependencias

Cuando Code Security y el gráfico de dependencias están habilitados para un repositorio, los archivos de manifiesto tienen una vista de diferencias enriquecida que muestra un resumen de las dependencias que agrega o actualiza. Se trata de un resumen útil para las personas que revisen solicitudes de incorporación de cambios, pero no proporciona ningún control sobre qué dependencias se agregan al código base.

La mayoría de las empresas establecen comprobaciones automáticas para bloquear el uso de dependencias con vulnerabilidades conocidas o términos de licencia no admitidos.

  1. Crea un repositorio privado que sirva como lugar central desde el que almacenar flujos de trabajo reutilizables para la empresa.
  2. Edita la configuración de acciones del repositorio para permitir que todos los repositorios privados de la empresa accedan a los flujos de trabajo de este repositorio central (consulta Permitir el acceso a los componentes en un repositorio privado).
  3. En el repositorio central, crea un flujo de trabajo reutilizable para ejecutar la acción de revisión de dependencias y configura la acción de modo que se ajuste a tus necesidades empresariales (consulta Configuración de la acción de revisión de dependencias).
  4. Crea o actualiza los conjuntos de reglas de rama en cada organización para agregar el nuevo flujo de trabajo a las comprobaciones de estado necesarias (consulta Aplicación de la revisión de dependencias en una organización).

Esto te permite actualizar la configuración en una sola ubicación, pero usar el flujo de trabajo en muchos repositorios. Es posible que quieras usar este repositorio central para mantener otros flujos de trabajo. Para más información, consulta Reutilización de flujos de trabajo.

revisión de código Copilot

Nota:

De forma predeterminada, los usuarios solicitan una revisión de Copilot de la misma manera en que la solicitan de los revisores humanos. Sin embargo, puede actualizar o crear un conjunto de reglas de rama de nivel de organización para agregar Copilot automáticamente como revisor a todas las solicitudes de incorporación de cambios realizadas a ramas seleccionadas en todos o repositorios seleccionados. Consulte Configuración de la revisión automática de código mediante GitHub Copilot en la GitHub Enterprise Cloud documentación.

          Copilot deja un comentario de revisión en cada solicitud de incorporación de cambios que revisa, sin aprobar la solicitud de incorporación de cambios ni solicitar cambios. Esto garantiza que su revisión sea de asesoramiento y no bloquee el trabajo de desarrollo. Del mismo modo, no debe aplicar la resolución de las sugerencias realizadas por Copilot porque las sugerencias de IA tienen limitaciones conocidas, vea [AUTOTITLE](/enterprise-cloud@latest/copilot/responsible-use-of-github-copilot-features/responsible-use-of-github-copilot-code-review#limitations-of-github-copilot-code-review) en la GitHub Enterprise Cloud documentación.

Definir dónde Autofijo de Copilot está permitido y habilitado

          Autofijo de Copilot ayuda a los desarrolladores a comprender y corregir code scanning las alertas encontradas en sus solicitudes de incorporación de cambios. Se recomienda habilitar esta característica para todos los repositorios con Code Security habilitado para ayudar a los desarrolladores a resolver alertas de forma eficaz y a aumentar su comprensión de la codificación segura.

Hay dos niveles de control:

Participación de los desarrolladores en correcciones de seguridad

Las campañas de seguridad permiten a los equipos de seguridad interactuar con los desarrolladores para corregir la deuda técnica de seguridad. También son una manera práctica de combinar la educación en codificación segura con ejemplos de código vulnerable en código con el que los desarrolladores están familiarizados. Para obtener más información, consulte Acerca de las campañas de seguridad y Ejecución de una campaña de seguridad para corregir alertas a escala en la GitHub Enterprise Cloud documentación.

Provisión de un entorno de desarrollo seguro

El entorno de desarrollo tiene muchos componentes. Algunas de las características más útiles para escalar y estandarizar un entorno de desarrollo seguro en GitHub son:

  •         **Configuraciones de seguridad:** define la configuración de características de seguridad de la empresa, la organización, un subconjunto de repositorios de la organización o repositorios nuevos, (consulta [Perfeccionamiento de las configuraciones de seguridad](#refine-your-security-configurations)).
    
  •         **Directivas:** protege y controla el uso de recursos de la empresa o una organización (consulta [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise)).
    
  •         **Conjuntos de reglas:** protegen y controlan ramas, etiquetas y envíos de una organización, un subconjunto de repositorios de la organización o un único repositorio (consulta [AUTOTITLE](/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization)).
    
  •         **Plantillas de repositorio:** define los flujos de trabajo de seguridad y los procesos necesarios para cada tipo de entorno (consulta [AUTOTITLE](/repositories/creating-and-managing-repositories/creating-a-template-repository)). Por ejemplo, cada plantilla puede contener un elemento especializado:
    
    • Archivo de directivas de seguridad que define la postura de seguridad de la empresa y cómo notificar cualquier problema de seguridad.
    • Flujo de trabajo para habilitar Dependabot version updates en gestores de paquetes usados por la empresa.
    • Flujo de trabajo que define la configuración avanzada para code scanning en lenguajes de desarrollo admitidos donde los resultados de configuración predeterminados no son suficientes.

Además, cuando un desarrollador crea un repositorio a partir de una plantilla, debe definir el valor de las propiedades personalizadas necesarias. Las propiedades personalizadas son muy útiles para seleccionar un subconjunto de repositorios a los que desea aplicar configuraciones, directivas o conjuntos de reglas, consulte Administración de propiedades personalizadas para repositorios de tu empresa en la GitHub Enterprise Cloud documentación.

Pasos siguientes

Cuando haya terminado de explorar estas opciones y secret scanning características, estará listo para probar sus descubrimientos hasta ahora en relación con sus necesidades empresariales y luego explorar más a fondo.

Lectura adicional

  •         [AUTOTITLE](/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions)
    
  •         [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise)
    
  •         [AUTOTITLE](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/governing-how-people-use-repositories-in-your-enterprise) en la GitHub Enterprise Cloud documentación
    
  •         [Aplicar GitHub Advanced Security a escala](https://wellarchitected.github.com/library/application-security/recommendations/enforce-ghas-at-scale/)