Refuerzo práctico de la seguridad para las acciones de GitHub

Inicio » Python » Refuerzo práctico de la seguridad para las acciones de GitHub

GitHub Actions se ha convertido en el motor de CI/CD de facto para los repositorios alojados en GitHub, lo que impulsa todo, desde pruebas unitarias hasta implementaciones de producción y cambios de infraestructura. Esta comodidad conlleva una desventaja importante: los flujos de trabajo suelen ejecutarse con amplios privilegios, gestionan tokens y secretos importantes, y pueden acceder directamente a los sistemas de producción. Si no los refuerza deliberadamente, está dando acceso rápido a cualquier configuración incorrecta, error de dependencia o cuenta comprometida a sus pipelines y cuentas en la nube.

Esta guía recorre una lista de verificación amplia y con opiniones para proteger GitHub Actions de extremo a extremo.Cómo gestionar secretos correctamente, evitar la inyección de scripts, bloquear tokens y activadores, evaluar acciones de terceros, gestionar ejecutores y aprovechar las funciones de seguridad integradas, como el escaneo de código, OIDC, Dependabot y los registros de auditoría. El objetivo es reunir las mejores prácticas dispersas, las lecciones aprendidas con esfuerzo de incidentes recientes y la guía de refuerzo de GitHub en una única referencia práctica que puedas aplicar en proyectos reales.

El perfil de riesgo real de GitHub Actions

En un nivel alto, un flujo de trabajo de GitHub Actions es solo un archivo YAML bajo .github/workflows Que define uno o más trabajos, cada uno compuesto por pasos. Los pasos pueden ejecutar comandos de shell o invocar acciones reutilizables publicadas por GitHub o la comunidad. Los flujos de trabajo se activan mediante eventos como envíos, solicitudes de extracción, actividad de incidencias, programaciones o envíos manuales.

Desde una perspectiva de seguridad, esos flujos de trabajo se ubican justo encima de su cadena de suministro de software.Crean y firman artefactos de lanzamiento, envían imágenes de Docker, implementan en entornos de nube, aprovisionan infraestructura, ejecutan migraciones y más. Si un atacante puede controlar el código, la configuración o el entorno en el que se ejecuta un flujo de trabajo privilegiado, a menudo puede:

• Artefactos compilados de puerta trasera (binarios, contenedores, paquetes) que luego envía a los clientes.
• Exfiltrar tokens y secretos poderosos y de larga duración de la memoria, registros, cachés o artefactos.
• Abusar de roles privilegiados en la nube otorgado a CI para implementar servicios adicionales, alterar la red o acceder a datos.
• Proyectos de envenenamiento aguas abajo comprometiendo los canales de lanzamiento de código abierto y distribuyendo versiones troyanizadas.

Incidentes recientes en el mundo real han subrayado lo atractivo que es GitHub Actions como superficie de ataque.Los atacantes han abusado de flujos de trabajo vulnerables para inyectar criptomineros en paquetes publicados, y el popular tj-actions/changed-files La acción se vio comprometida en un ataque multietapa que intentó alcanzar Coinbase. El código malicioso extrajo información confidencial de los flujos de trabajo y la registró en los registros de compilación, lo que generó una posible cascada de ataques posteriores a la cadena de suministro.

La idea clave a tener en cuenta es que la mayoría de los ataques de GitHub Actions se basan en "probabilidad × impacto".Quiere reducir la probabilidad de adoptar componentes maliciosos o con errores (acciones de terceros, ejecutores inseguros, desencadenadores riesgosos) y, al mismo tiempo, limitar drásticamente el radio de explosión si un solo componente se ve comprometido.

Bloquear secretos en GitHub Actions

Los secretos suelen ser el objetivo más atractivo en cualquier sistema CI/CDEn GitHub Actions, aparecen como secretos de repositorio, organización o entorno, y como valores ad hoc que puedes volcar accidentalmente en configuraciones, registros, cachés o artefactos.

Lo primero que hay que internalizar es el modelo de acceso: cualquiera con acceso de escritura a un repositorio puede leer efectivamente todos los secretos a nivel de repositorio.Pueden simplemente modificar un flujo de trabajo existente en una rama no protegida, inyectar código de registro o exfiltración y ejecutar ese flujo de trabajo para imprimir o filtrar secretos. El enmascaramiento de registros de GitHub es una defensa eficaz, no una garantía infalible.

Para mantener los secretos vigentes bajo ese modelo, siga estas reglas básicas:

• Aplicar el principio de privilegio mínimo.Cualquier credencial utilizada en un flujo de trabajo debe tener solo los permisos mínimos imprescindibles. Evite compartir tokens de administrador de uso general como secretos de flujo de trabajo.
• Prefiera los secretos del entorno a los secretos del repositorio o de la organización para valores confidencialesLos secretos de entorno solo están disponibles para los trabajos que declaran ese entorno, y puedes envolverlos en protecciones adicionales como revisores obligatorios y restricciones de rama.
• Nunca almacene secretos en texto sin formato en archivos YAML del flujo de trabajo o en código registrado en el repositorio. Toda información confidencial debe pasar por el mecanismo de secretos de GitHub o por un gestor de secretos externo.
• Evite utilizar blobs estructurados (JSON, YAML, XML) como un único valor secretoEl enmascaramiento se basa principalmente en la coincidencia exacta de cadenas; los blobs multicampo son mucho más difíciles de redactar de forma fiable. En su lugar, divida los datos confidenciales en múltiples entradas secretas dedicadas.
• Registrar explícitamente todos los secretos derivadosSi transforma un secreto (Base64, codificación de URL, firma JWT, etc.) y ese resultado pudiera aparecer en los registros, registre el valor transformado como su propio secreto para que GitHub pueda intentar enmascararlo.

La rotación y la higiene son tan importantes como la configuración inicialRevise periódicamente qué secretos existen, quién y qué aún los necesita, y elimine o rote los que estén obsoletos. Ante cualquier sospecha de exposición (por ejemplo, un secreto impreso sin editar en registros o utilizado en una acción comprometida), elimine inmediatamente los registros afectados, revoque las credenciales y cree nuevas.

Cómo evitar la inyección de scripts y la interpolación insegura

Una de las clases de errores más comunes, pero sutiles, de GitHub Actions es la inyección de scripts a través de expresionesGitHub proporciona “contextos” enriquecidos como github, env, secrets y cargas útiles de eventos, a las que hace referencia en flujos de trabajo mediante el ${{ ... }} Sintaxis. Esas expresiones son evaluadas por GitHub. antes Tu paso de shell se ejecuta.

Cuando integras un contexto no confiable directamente en un comando de shell, invitas a la inyección de comandos.Por ejemplo, si haces:

run: echo "new issue ${{ github.event.issue.title }} created"

y un atacante puede controlar el título del problema, pueden enviar un título como $(id)Después de la evaluación de la expresión, el paso es:

echo "new issue $(id) created"

que ejecuta id en el corredorNinguna cantidad de ajustes a las comillas o de agregar una validación simple en el shell lo salvará de este patrón de manera confiable.

El patrón seguro que recomienda GitHub es utilizar una variable de entorno intermedia:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

Aquí el valor potencialmente hostil permanece en la memoria como una variable de entorno., y la concha solo ve $TITLENo es una línea de comandos construida dinámicamente. Sigue siendo necesaria la higiene normal del shell (entrecomillar variables, evitar eval innecesarios, etc.), pero se elimina el peligroso paso de interpolación.

Siempre que tengas la tentación de incrustar ${{ github.* }} u otros datos controlados por el usuario directamente en run: Bloquea, detente y empújalo. env: Este hábito elimina toda una clase de problemas de inyección de scripts en sus flujos de trabajo.

Configurar permisos y tokens de forma segura

El elemento GITHUB_TOKEN que GitHub inyecta en cada ejecución del flujo de trabajo es increíblemente poderoso si se deja con los valores predeterminadosPuede leer y escribir contenido, abrir y actualizar solicitudes de extracción e interactuar con el repositorio de diversas maneras. Históricamente, muchas organizaciones lo tenían configurado como lectura y escritura sin darse cuenta.

El primer paso de fortalecimiento debe ser establecer los permisos de token de flujo de trabajo predeterminados como de solo lectura. A nivel de organización o repositorio. Existe una configuración específica para esto en la configuración de Acciones. Desde allí, se pueden otorgar permisos adicionales de forma selectiva por flujo de trabajo o por trabajo, por ejemplo:

permissions:
contents: read
pull-requests: write

Este modelo de “denegar por defecto, permitir donde sea necesario” reduce drásticamente lo que un atacante puede hacer con un flujo de trabajo comprometido.. También obliga a los autores a pensar en qué capacidades requiere realmente su trabajo en lugar de heredar un token general.

Si su organización se creó antes de principios de 2023, debe auditar explícitamente estos valores predeterminados.Muchas organizaciones antiguas aún tienen tokens de flujo de trabajo habilitados para escritura porque son anteriores a la configuración predeterminada más segura y nunca optaron por el cambio.

Además de los alcances de token, tenga mucho cuidado con las configuraciones que permiten que GitHub Actions apruebe o cree solicitudes de extracción.Permitir que los flujos de trabajo aprueben automáticamente las solicitudes de registro (PR) lo expone a rutas de abuso donde los trabajos comprometidos fusionan código malicioso sin revisión humana. A menos que tenga un caso de uso sólido y medidas de seguridad estrictas, mantenga esta función deshabilitada.

Seleccionar y fijar acciones de terceros

Cada acción externa que utiliza es un fragmento de código remoto que se ejecuta con los mismos privilegios que el resto de su trabajo.Si esa acción se vuelve maliciosa, se ve comprometida o se abandona con dependencias vulnerables, se convierte en un punto de apoyo listo para usar dentro de su canalización.

Hay varias capas de defensa que puedes aplicar al consumir acciones de terceros:

• Comience con una lista pequeña y confiable de permitidosAcciones mantenidas por GitHub (como actions/checkout, actions/setup-node) y las acciones del mercado de creadores verificados suelen ser una base más segura que los repositorios aleatorios. Muchas organizaciones implementan esto mediante la opción "Permitir acciones específicas y flujos de trabajo reutilizables" a nivel de organización.
• Favorecer acciones populares y mantenidas activamenteLas investigaciones muestran que muchas acciones del mercado tienen puntuaciones bajas en el cuadro de mando de OpenSSF, cuentan con un solo mantenedor y cuentas de propietario de corta duración o muy jóvenes. Las acciones ampliamente utilizadas tienden a acumular mayor escrutinio y soluciones más rápidas.
• Esté atento a una gran cantidad de PR de Dependabot abiertos en el repositorio de la acción. Esto suele ser una señal de que el mantenedor no está aplicando actualizaciones de seguridad, dejando vulnerabilidades transitivas sin parchear.
• Prefiera acciones con más de un mantenedor y una base de código activa y no archivadaCientos de acciones en el mercado están archivadas, lo que significa que no hay nuevas correcciones ni actualizaciones de compatibilidad y el riesgo aumenta con el tiempo.

La fijación de versiones es otro tema críticoSi especifica una acción solo por etiqueta, como some-org/some-action@v2Confías en que esa etiqueta nunca se moverá a código malicioso. Las etiquetas pueden redireccionarse si la cuenta o el repositorio del mantenedor se ven comprometidos.

El enfoque más defensivo hoy en día es fijar a un SHA de confirmación completa:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

Fijar a un SHA hace que el código sea efectivamente inmutable desde su perspectiva (a menos que se produzca un ataque de colisión SHA-1 en objetos de Git). La desventaja es operativa: debes actualizar el SHA cuando quieras nuevas funciones o correcciones, y los diferentes flujos de trabajo pueden derivar hacia diferentes SHA si no tienes cuidado.

Para aliviar ese dolor, algunos equipos centralizan el uso de acciones de terceros en flujos de trabajo compartidos o compuestos.Los repositorios individuales hacen referencia a esos flujos de trabajo compartidos por etiqueta, mientras que los flujos de trabajo compartidos fijan las acciones subyacentes a los SHA examinados y se actualizan con una cadencia controlada, a veces con herramientas que abren solicitudes de incorporación de cambios para nuevos SHA.

Cualquiera que sea la estrategia que elijas, recuerda que la fijación no es un cortafuegos mágico.Una acción aún puede obtener código dinámicamente en tiempo de ejecución (por ejemplo, a través de curl | bash patrones) y omitir tu PIN. Aún necesitas revisar el código fuente en busca de patrones obviamente inseguros antes de confiar una acción con secretos o tokens con capacidad de escritura.

Diseño de flujos de trabajo y trabajos más seguros

La forma en que se estructuran los flujos de trabajo y los trabajos influye fuertemente en el radio de explosión de un compromisoUn antipatrón común es un único trabajo gigantesco que revisa el código, compila, prueba, empaqueta e implementa, todo ello con amplios permisos y acceso a secretos de producción.

Dividir el trabajo en tareas separadas e incluso flujos de trabajo separados proporciona tanto aislamiento como claridad.Por ejemplo, podrías tener:

• A trabajo de construcción y prueba que se ejecuta con permisos mínimos y sin secretos de implementación.
• A trabajo de paquete que produce artefactos firmados pero todavía no habla con la producción.
• A implementar trabajo que depende de los demás y es el único autorizado a acceder a los secretos del entorno y asumir roles en la nube.

En los ejecutores alojados en GitHub, cada trabajo en un flujo de trabajo se ejecuta en una máquina virtual nueva, lo que proporciona cierto grado de aislamiento entre trabajos. No es equivalente a un entorno protegido, y existen vectores conocidos entre trabajos (como cachés de ramas compartidas), pero dividir los trabajos obliga a los atacantes a trabajar más y reduce la filtración accidental de secretos en pasos no relacionados.

Utilice entornos para vincular pasos sensibles a las proteccionesUn trabajo de implementación podría declarar:

environment: production

y la production Luego, el entorno se puede configurar para aceptar solo implementaciones de una rama protegida., posiblemente con aprobaciones manuales obligatorias. Al combinar esto con reglas estrictas de protección de ramas (revisiones obligatorias, sin impulsos de avance rápido, rechazo de aprobaciones obsoletas), se acerca al principio de "cuatro ojos" para los cambios en producción.

Por último, tenga cuidado con los artefactos, los cachés y los registros.Son formas convenientes de compartir datos entre trabajos y flujos de trabajo, pero:

• No agrupes secretos en cachés, especialmente lugares no muy conocidos como ~/.docker/config.json que puede contener credenciales simples de Docker.
• Evite registrar secretos o volcar contextos completos en los registros, ya que esto puede anular el enmascaramiento o revelar valores derivados que GitHub no sabe cómo redactar.
• Recuerde que cualquier persona con acceso de lectura al repositorio generalmente puede descargar artefactos y explorar registros., incluidos los colaboradores externos si les concede acceso.

OIDC y credenciales de nube de corta duración

Uno de los cambios más impactantes que puede realizar es dejar de almacenar credenciales de proveedores de nube de larga duración como secretos de GitHub por completo.En su lugar, utilice OpenID Connect (OIDC) para obtener tokens de corta duración y con un alcance definido vinculados a una identidad de flujo de trabajo específica.

El flujo de alto nivel es simple:

• Su proveedor de nube (AWS, Azure, GCP, etc.) está configurado para confiar en el proveedor OIDC de GitHub.
• Define una política de identidad que diga “solo aceptar tokens de esta organización/repositorio/rama o entorno”.
• Durante un trabajo, GitHub puede solicitar un token OIDC y su flujo de trabajo utiliza una acción específica de la nube (por ejemplo aws-actions/configure-aws-credentials) para intercambiarlo por un token de cuenta de servicio o rol de corta duración.

La condición de confianza es donde puedes obtener información muy granular.Para AWS, una política típica podría incluir:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

Esto garantiza que solo los flujos de trabajo de un repositorio y una rama específicos puedan asumir la función.Si desea un alcance aún más preciso, puede vincular el rol a un entorno específico en lugar de a una rama y, luego, requerir ese entorno solo para el trabajo de implementación. Una acción de terceros comprometida en un trabajo que no sea de implementación provocará que las llamadas OIDC simplemente fallen.

El uso de OIDC no elimina la necesidad de políticas de roles con privilegios mínimos en la nube, pero elimina las claves de acceso estáticas que se encuentran en GitHub Secrets, donde podrían ser robadas y reutilizadas indefinidamente desde fuera de GitHub.

Protección de sucursales, conjuntos de reglas y entornos que trabajan en conjunto

Muchas de las rutas de ataque más peligrosas en GitHub Actions se reducen a que "el atacante inyecta cambios maliciosos en una rama protegida".La protección de ramas y los conjuntos de reglas son su principal línea de defensa allí.

En ramas como main or production, normalmente quieres al menos:

• Requerir una solicitud de extracción antes de fusionar – no permitir empujones directos.
• Requerir al menos una (a menudo más) revisión de aprobación de alguien que no sea el último empujador.
• Descartar aprobaciones obsoletas cuando se agregan nuevas confirmaciones – para que los atacantes no puedan introducir código después de la revisión.
• Requerir la aprobación del push revisable más reciente – evita que un atacante secuestre las relaciones públicas de otra persona, envíe código incorrecto y se autoapruebe.

Luego puedes conectar estas protecciones a entornos... Por ejemplo, un production Es posible que el entorno solo acepte implementaciones de main rama, y ​​quizás también requiera la aprobación manual de un pequeño grupo de revisores (con la opción "evitar la autorevisión" habilitada). De esta manera, una sola cuenta de colaborador comprometida no puede enviar código arbitrario a producción sin la participación explícita de otra persona.

Tenga cuidado con las reglas del entorno que dependen de las propias implementaciones (por ejemplo, "requerir que las implementaciones se realicen correctamente antes de permitir actualizaciones de etiquetas"). Si la estructura es deficiente, se pueden crear dependencias circulares o pseudocontroles que un colaborador puede omitir editando los flujos de trabajo. El patrón más seguro sigue siendo: protección robusta de ramas → entornos con un alcance limitado → uso explícito de esos entornos solo en los trabajos mínimos que realmente los necesitan.

Gestión de ejecutores: alojados en GitHub vs. autoalojados

Los corredores son las máquinas que realmente ejecutan sus flujos de trabajo.Los ejecutores alojados en GitHub son máquinas virtuales efímeras administradas por GitHub; los ejecutores autoalojados son máquinas o contenedores que usted aprovisiona y controla.

Los ejecutores alojados en GitHub son generalmente mucho más seguros de forma predeterminada:

• Son efímeros y se reinician para cada trabajo., por lo que no hay ningún compromiso persistente entre las ejecuciones.
• GitHub publica SBOM para imágenes estándar (Ubuntu, Windows, macOS), permitiéndole analizar el software preinstalado en busca de vulnerabilidades.
• Ciertos hosts maliciosos están bloqueados de fábrica (por ejemplo, los pools de criptominería conocidos) a través de /etc/hosts configuración.

Los corredores autoalojados son potentes pero peligrosos Si no los tratas como servidores de producción:

• Por lo general no son efímeros a menos que los construyas tú mismo., por lo que cualquier flujo de trabajo malicioso puede intentar la persistencia, el movimiento lateral o el robo de datos.
• A menudo tienen un acceso más amplio a la red y a secretos locales. (claves SSH, CLI en la nube, servicios de metadatos), lo que aumenta los riesgos de cualquier compromiso.
• Los repositorios públicos casi nunca deberían utilizar ejecutores autoalojados, porque cualquiera puede abrir una solicitud de extracción que termine ejecutando código en su infraestructura.

Si debe utilizar ejecutores autoalojados, divídalos por límites de confianzaUtilice grupos de corredores y restricciones para que:

• Los proyectos públicos y privados nunca comparten el mismo grupo de corredores.
• Los repositorios de alta sensibilidad (por ejemplo, infraestructura de producción) tienen sus propios ejecutores estrictamente controlados.
• Sólo repositorios u organizaciones específicos pueden enviar trabajos a un grupo determinado.

Puede reducir aún más el riesgo con ejecutores justo a tiempo (JIT) aprovisionados a través de la API RESTEstos ejecutores se registran dinámicamente, ejecutan como máximo un trabajo y luego se eliminan automáticamente. Aun así, es necesario asegurarse de que el host subyacente se limpie o destruya, pero esto reduce el margen de tiempo en el que un trabajo comprometido puede afectar a los siguientes.

Trate a los ejecutores autoalojados como cualquier otro sistema de producción:monitorear la actividad del proceso, bloquear las rutas de red salientes, mantener el sistema operativo y las herramientas parcheados, y asumir que cualquier usuario con permiso para activar flujos de trabajo efectivamente tiene ejecución de código en esa máquina.

Funciones de seguridad integradas: escaneo de código, Scorecards y Dependabot

GitHub incluye una serie de funciones de primera clase específicamente dirigidas a exponer los riesgos del flujo de trabajo y de las dependencias.y valen el pequeño costo de instalación.

El escaneo de código (por ejemplo, con CodeQL) ahora puede analizar los flujos de trabajo de GitHub Actions por sí mismos, no solo el código fuente de la aplicación. Reglas como "Exposición excesiva de secretos" pueden detectar patrones donde GitHub no puede determinar qué secretos son necesarios (por ejemplo, datos dinámicos). secrets[myKey] uso en compilaciones de matrices), lo que lleva a cargar más secretos de los necesarios en la memoria del trabajo.

Los cuadros de mando de OpenSSF y la acción Cuadros de mando agregan otra capa al calificar la postura de seguridad de sus dependenciasPara las acciones en el mercado, los cuadros de mando pueden identificar prácticas inseguras en la cadena de suministro, como:

• No fijar dependencias.
• Faltan protecciones de sucursales o requisitos de revisión de código.
• Falta de políticas de seguridad o procesos de respuesta a vulnerabilidades.

Dependabot juega dos papeles aquí:

• Alertas de Dependabot advertirle cuando una dependencia de sus acciones o flujos de trabajo tiene una vulnerabilidad conocida, según la base de datos de avisos de GitHub.
• Actualizaciones de versión y seguridad de Dependabot Puede abrir automáticamente solicitudes de modificación para actualizar versiones de acción y parchar versiones vulnerables.

El gráfico de dependencia para flujos de trabajo es otra característica subestimadaGitHub trata los archivos de tu flujo de trabajo como manifiestos y puede mostrarte:

• De qué acciones y flujos de trabajo reutilizables depende.
• ¿Qué cuentas u organizaciones son sus propietarias?
• ¿A qué versiones o SHA tienes anclados?

Esto hace que sea más fácil responder preguntas como "¿Dónde estamos utilizando esta acción comprometida?" cuando aparecen nuevos avisos y para planificar una remediación masiva.

Monitoreo, auditoría y gobernanza

La seguridad no termina en la configuración; también necesita visibilidad de lo que sucede a lo largo del tiempo.GitHub proporciona registros de auditoría y registros de seguridad tanto a nivel de usuario como de organización.

Desde el punto de vista de las acciones, hay varias cosas que vale la pena seguir:

• Eventos relacionados con secretos, como org.update_actions_secret o cambios en secretos del repositorio. Estos indican la creación, actualización o eliminación de credenciales confidenciales.
• Cambios en el flujo de trabajo y en el conjunto de reglas:quién modificó las reglas de protección, quién editó los flujos de trabajo de implementación, quién cambió las protecciones del entorno.
• Acciones de mercado nuevas o modificadas y aplicaciones de GitHub instalados en la organización, especialmente aquellos a los que se les ha concedido un amplio alcance de repositorio o de organización.

Puede complementar los propios controles de GitHub con aplicaciones de aplicación de políticas como Allstar de OpenSSF, que verifica continuamente que los repositorios cumplan con la línea base de seguridad de su organización (protecciones de sucursales, escaneo de código habilitado, revisiones requeridas, etc.).

En el lado de los "flujos de trabajo en ejecución", esté atento a los patrones que podrían sugerir abuso.: picos inusuales en los tiempos de ejecución de trabajos, tráfico saliente inesperado de los ejecutores o trabajos que fallan frecuentemente en pasos que manejan secretos o tokens OIDC. Estos no siempre son maliciosos, pero son un buen punto de partida para las investigaciones.

Poner todo esto junto significa pensar en GitHub Actions como parte de su superficie de producción principal.No solo scripts de pegado. Con secretos y tokens cuidadosamente definidos, protección estricta de ramas y entornos, uso conservador de acciones de terceros, ejecutores reforzados y monitorización continua con herramientas como CodeQL, Scorecards y Dependabot, le brinda a su organización una oportunidad de luchar contra la creciente clase de ataques de CI/CD y a la cadena de suministro que atacan explícitamente los flujos de trabajo de GitHub.