Exploración de la versión de prueba empresarial de GitHub Code Security

En esta guía se presupone que has planificado e iniciado una evaluación de GitHub Advanced Security para una cuenta empresarial de GitHub existente o de prueba (consulta Planificación de una evaluación 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 los privados e internos con Code Security habilitado. Además, Code Security te permite crear campañas de seguridad en las que los especialistas y desarrolladores de seguridad puedan 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 del Secret Protection, donde normalmente se aplica una única configuración de seguridad a todos los repositorios, es probable que quieras ajustar la configuración de code scanning según el tipo de repositorio. Por ejemplo, es posible que tengas que crear configuraciones adicionales para que:

• Code scanning usa ejecutores con una etiqueta específica para aplicarla a repositorios que requieren un entorno especializado o que usen registros privados.
• Code scanning tenga el valor "Sin establecer" para aplicarlo a repositorios que necesitan usar la configuración avanzada o que requieran 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.

Provisión de 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 alertas de code scanning en 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 de code scanning ejecuta un conjunto de consultas de confianza alta. Se eligen para garantizar que, al implementar el code scanning en todo el código base, los desarrolladores vean un conjunto limitado de resultados de alta calidad, con pocos resultados que sean falsos positivos.

Puedes ver un resumen de los resultados que se encuentren en las organizaciones de tu 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 ves los resultados esperados tras el code scanning, puedes actualizar la configuración predeterminada para ejecutar un conjunto de consultas ampliado para aquellos repositorios en los que esperabas encontrar más resultados. Se controla a nivel de repositorio (consulta Editar la configuración predeterminada).

Si el conjunto ampliar 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 Acerca de 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 automatizados de solicitudes de incorporación de cambios integradas en GitHub:

•         **Code scanning**: análisis que usa consultas para resaltar patrones de codificación incorrectos conocidos y vulnerabilidades de seguridad. Corrección automática de Copilot sugiere correcciones para problemas identificados por el 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.
  

•         **Revisión de código de Copilot**: usa IA para proporcionar comentarios sobre los cambios con correcciones sugeridas siempre que 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, el code scanning y las revisiones de dependencias se pueden aplicar con fines de seguridad y cumplimiento del código.

Análisis de Code scanning

Si el code scanning está habilitado, puedes crear un conjunto de reglas de código para la empresa u organización que permita bloquear las combinaciones en ramas importantes a menos que la solicitud de incorporación de cambios cumpla sus requisitos. Normalmente, sería necesario que los resultados del code scanning estuviesen presentes y que se resolviesen las alertas importantes.

•         **Tipo de conjunto de reglas:** rama.
  

•         **Requerir resultados de code scanning:** habilita esta opción para bloquear la fusión mediante combinación hasta que los resultados de la confirmación y la referencia a la que se dirige la solicitud de incorporación de cambios se generen correctamente.
  

•         **Herramientas necesarias y umbrales de alerta:** define, para cada herramienta de code scanning que uses, el nivel de alertas que se deben resolver para poder fusionar una solicitud de incorporación de cambios.
  

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

Si Code Security y el gráfico de dependencias están habilitados para un repositorio, los archivos de manifiesto tienen una vista de diferencias enriquecida en la que se muestra un resumen de las dependencias que se agregan o actualizan. 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 Copilot

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

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. Por esto mismo, no debes aplicar la resolución de sugerencias realizadas por Copilot, ya que las sugerencias de la IA tienen limitaciones conocidas, consulta Uso responsable de la revisión de código de GitHub Copilot en la documentación de GitHub Enterprise Cloud.

Permiso y habilitación de Corrección automática de Copilot

Corrección automática de Copilot ayuda a los desarrolladores a reconocer y corregir las alertas de code scanning que se detectan 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 mejorar su comprensión de la codificación segura.

Hay dos niveles de control:

• Las empresas pueden permitir o bloquear el uso de Corrección automática de Copilot en toda la empresa mediante una directiva "Advanced Security", consulte: Aplicación de directivas de seguridad y análisis de código de la empresa.
• Las organizaciones pueden habilitar o deshabilitar Corrección automática de Copilot para todos los repositorios propiedad de la organización en la "Configuración global" de la organización (consulta Configuración de seguridad global para su organización).

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 más información, consulta Acerca de las campañas de seguridad y Procedimientos recomendados para resolver alertas de seguridad a gran escala en la documentación de GitHub Enterprise Cloud.

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 las siguientes:

•         **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:** protege y controla ramas, etiquetas e inserciones de una organización, un subconjunto de repositorios de la organización o un 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 para administradores de paquetes usados por la empresa.
  • Flujo de trabajo que define la configuración avanzada para code scanning de los lenguajes de desarrollo admitidos en los que 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 quieres aplicar configuraciones, directivas o conjuntos de reglas, consulta Administración de propiedades personalizadas para repositorios de la empresa en la documentación de GitHub Enterprise Cloud.

Pasos siguientes

Cuando hayas terminado de explorar estas opciones y las características de secret scanning, podrás ver en qué medida se ajustan a las necesidades de tu empresa y, luego, seguir explorando.

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 documentación de GitHub Enterprise Cloud
  

•         [Aplicación de GitHub Advanced Security a gran escala](https://wellarchitected.github.com/library/application-security/recommendations/enforce-ghas-at-scale/)