Reforço de segurança prático para o GitHub Actions

Início » Python » Reforço de segurança prático para o GitHub Actions

O GitHub Actions se tornou o mecanismo de CI/CD padrão para repositórios hospedados no GitHub., que dão suporte a tudo, desde testes unitários até implantações em produção e alterações de infraestrutura. Essa conveniência tem um preço sério: os fluxos de trabalho geralmente são executados com amplos privilégios, lidam com tokens e segredos poderosos e podem acessar diretamente os sistemas de produção. Se você não os reforçar deliberadamente, estará efetivamente dando a qualquer erro de configuração, bug de dependência ou conta comprometida um caminho direto para seus pipelines e contas na nuvem.

Este guia apresenta uma lista de verificação abrangente e opinativa para proteger o GitHub Actions de ponta a ponta.Como lidar corretamente com segredos, evitar injeção de scripts, proteger tokens e gatilhos, avaliar ações de terceiros, gerenciar executores e aproveitar recursos de segurança integrados, como verificação de código, OIDC, Dependabot e logs de auditoria. O objetivo é reunir as melhores práticas dispersas, as lições aprendidas com incidentes recentes e as próprias diretrizes de segurança do GitHub em uma única referência prática que você pode aplicar em projetos reais.

O verdadeiro perfil de risco do GitHub Actions

Em linhas gerais, um fluxo de trabalho do GitHub Actions é apenas um arquivo YAML em .github/workflows que define uma ou mais tarefas, cada uma composta por etapas. As etapas podem executar comandos do shell ou invocar ações reutilizáveis ​​publicadas pelo GitHub ou pela comunidade. Os fluxos de trabalho são acionados por eventos como pushes, pull requests, atividade em issues, agendamentos ou despachos manuais.

Do ponto de vista da segurança, esses fluxos de trabalho estão diretamente no topo da sua cadeia de suprimentos de software.Eles criam e assinam artefatos de lançamento, enviam imagens Docker, implantam em ambientes de nuvem, provisionam infraestrutura, executam migrações e muito mais. Se um invasor puder controlar o código, a configuração ou o ambiente em que um fluxo de trabalho privilegiado é executado, ele geralmente poderá:

• Artefatos compilados por backdoor (binários, contêineres, pacotes) que você posteriormente envia aos clientes.
• Extrair tokens e segredos poderosos e de longa duração. da memória, registros, caches ou artefatos.
• Abusar de funções privilegiadas na nuvem Concedido ao CI para implantar serviços adicionais, alterar a rede ou acessar dados.
• projetos de envenenamento a jusante comprometendo os sistemas de distribuição de código aberto e distribuindo versões infectadas por cavalos de Troia.

Incidentes recentes no mundo real destacaram o quão atraente o GitHub Actions é como superfície de ataque.Os atacantes exploraram fluxos de trabalho vulneráveis ​​para injetar mineradores de criptomoedas em pacotes publicados, e o popular tj-actions/changed-files A operação foi comprometida em um ataque de múltiplas etapas que tentou atingir a Coinbase. O código malicioso extraiu segredos de fluxos de trabalho e os gravou em registros de compilação, criando uma potencial cascata de comprometimentos subsequentes na cadeia de suprimentos.

A ideia principal a ter em mente é que a maioria dos ataques ao GitHub Actions se resume a "probabilidade × impacto".Você deseja reduzir a probabilidade de adotar componentes maliciosos ou com bugs (ações de terceiros, executores inseguros, gatilhos arriscados) e, ao mesmo tempo, limitar drasticamente o impacto caso algum componente seja comprometido.

Protegendo segredos no GitHub Actions

Os segredos costumam ser o alvo mais atraente em qualquer sistema de CI/CD.No GitHub Actions, eles aparecem como segredos de repositório, organização ou ambiente, e como valores ad-hoc que você pode acidentalmente inserir em configurações, logs, caches ou artefatos.

A primeira coisa a internalizar é o modelo de acesso: qualquer pessoa com acesso de escrita a um repositório pode efetivamente ler todos os segredos em nível de repositório.Eles podem simplesmente modificar um fluxo de trabalho existente em um branch não protegido, injetar código de registro ou exfiltração e executar esse fluxo de trabalho para imprimir ou vazar segredos. O mascaramento de logs do GitHub é uma defesa que exige o máximo empenho, não uma garantia infalível.

Para que os segredos sobrevivam nesse modelo, siga estas regras básicas.:

• Aplique o princípio do privilégio mínimoQualquer credencial usada em um fluxo de trabalho deve ter apenas as permissões mínimas estritamente necessárias. Evite compartilhar tokens de administrador de uso geral como segredos de fluxo de trabalho.
• Prefira segredos de ambiente em vez de segredos de repositório ou organização para valores sensíveis.Os segredos de ambiente só estão disponíveis para tarefas que declaram esse ambiente, e você pode envolvê-los em proteções adicionais, como revisores obrigatórios e restrições de ramificação.
• Nunca armazene segredos em texto simples em arquivos YAML de fluxo de trabalho. ou em código incluído no repositório. Tudo que for sensível deve passar pelo mecanismo de Segredos do GitHub ou por um gerenciador de segredos externo.
• Evite usar blocos estruturados (JSON, YAML, XML) como um único valor secreto.A ocultação de dados depende em grande parte da correspondência exata de strings; blocos de dados com vários campos são muito mais difíceis de ocultar de forma confiável. Em vez disso, divida os dados confidenciais em várias entradas secretas dedicadas.
• Registre explicitamente todos os segredos derivadosSe você transformar um segredo (Base64, codificação de URL, assinatura JWT, etc.) e esse resultado puder ser registrado nos logs, registre o valor transformado como um segredo separado para que o GitHub possa tentar mascará-lo.

A rotação e a higiene são tão importantes quanto a configuração inicial.Periodicamente, revise quais segredos existem, quem e o que ainda precisa deles e remova ou substitua quaisquer segredos obsoletos. Após qualquer suspeita de exposição (por exemplo, um segredo impresso sem redação em registros ou usado em uma ação comprometida), exclua imediatamente os registros afetados, revogue as credenciais e crie novas.

Evitando injeção de scripts e interpolação insegura

Um dos tipos de bugs mais comuns, porém sutis, do GitHub Actions é a injeção de scripts por meio de expressões.O GitHub oferece "contextos" ricos, como: github, env, secrets e cargas úteis de eventos, às quais você faz referência em fluxos de trabalho usando o ${{ ... }} sintaxe. Essas expressões são avaliadas pelo GitHub. antes Seu passo de shell é executado.

Ao incorporar um contexto não confiável diretamente em um comando do shell, você abre caminho para a injeção de comandos.Por exemplo, se você fizer:

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

e um atacante pode controlar o título da edição, eles podem enviar um título como $(id)Após a avaliação da expressão, a etapa passa a ser:

echo "new issue $(id) created"

que executa id no corredorNenhuma alteração nas aspas ou a adição de validação simples no shell irá protegê-lo de forma confiável desse padrão.

O padrão seguro recomendado pelo GitHub é usar uma variável de ambiente intermediária.:

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

Nesse caso, o valor potencialmente hostil permanece na memória como uma variável de ambiente.e a concha vê apenas $TITLENão se trata de uma linha de comando construída dinamicamente. Você ainda precisa seguir as normas básicas de segurança do shell (colocar variáveis ​​entre aspas, evitar o uso desnecessário de `eval`, etc.), mas a etapa perigosa de interpolação foi removida.

Sempre que você se sentir tentado a incorporar ${{ github.* }} ou outros dados controlados pelo usuário diretamente em run: blocos, pare e empurre-o através env: em vez dissoEsse simples hábito elimina toda uma classe de problemas de injeção de scripts em seus fluxos de trabalho.

Configurando permissões e tokens com segurança

O GITHUB_TOKEN O recurso que o GitHub injeta em cada execução do fluxo de trabalho é incrivelmente poderoso se mantido com as configurações padrão.Ele pode ler e escrever conteúdo, abrir e atualizar solicitações de pull e interagir com o repositório de diversas maneiras. Historicamente, muitas organizações o tinham configurado como leitura e gravação por padrão sem perceber.

O primeiro passo para reforçar a segurança deve ser definir as permissões padrão do token de fluxo de trabalho como somente leitura. no nível da organização e/ou do repositório. Existe uma configuração específica para isso nas configurações de Ações. A partir daí, você concede permissões extras seletivamente, por fluxo de trabalho ou por tarefa, por exemplo:

permissions:
contents: read
pull-requests: write

Esse modelo de “negar por padrão, permitir quando necessário” reduz drasticamente o que um invasor pode fazer com um fluxo de trabalho comprometido.Isso também força os autores a pensarem sobre quais capacidades seu trabalho realmente exige, em vez de herdarem um token genérico.

Se sua organização foi criada antes do início de 2023, você deve auditar explicitamente essas configurações padrão.Muitas organizações mais antigas ainda possuem tokens de fluxo de trabalho com permissão de gravação, pois são anteriores à configuração padrão mais segura e nunca optaram por essa mudança.

Além dos escopos de token, tenha muita cautela com as configurações que permitem que o GitHub Actions aprove ou crie solicitações de pull request.Permitir que os fluxos de trabalho aprovem automaticamente as solicitações de pull abre caminho para abusos, nos quais tarefas comprometidas mesclam código malicioso sem revisão humana. A menos que você tenha um caso de uso forte e medidas de segurança rigorosas, mantenha esse recurso desativado.

Selecionar e fixar ações de terceiros

Cada ação externa que você utiliza é um trecho de código remoto que é executado com os mesmos privilégios do restante do seu trabalho.Se essa ação se tornar maliciosa, for comprometida ou abandonada com dependências vulneráveis, ela se torna um ponto de apoio pronto para uso dentro do seu pipeline.

Existem várias camadas de defesa que você pode aplicar ao consumir ações de terceiros.:

• Comece com uma lista de permissões pequena e confiável.Ações mantidas pelo GitHub (como actions/checkout, actions/setup-nodeAções de criadores verificados no marketplace geralmente representam uma base mais segura do que repositórios aleatórios. Muitas organizações implementam essa prática por meio da opção "Permitir ações específicas e fluxos de trabalho reutilizáveis" no nível da organização.
• Favorecer ações populares e ativamente mantidasPesquisas mostram que muitas ações do marketplace têm baixas pontuações no OpenSSF Scorecard, um único mantenedor e contas de proprietários com vida curta ou muito recentes. Ações amplamente utilizadas tendem a receber mais atenção e correções mais rápidas.
• Fique atento a um grande número de PRs (Pull Requests) do Dependabot abertos no repositório da ação.Isso geralmente indica que o responsável pela manutenção não está aplicando as atualizações de segurança, deixando vulnerabilidades transitivas sem correção.
• Dê preferência a ações com mais de um mantenedor e um código-fonte ativo e não arquivado.Centenas de ações no marketplace estão arquivadas, o que significa que não haverá novas correções ou atualizações de compatibilidade, aumentando o risco ao longo do tempo.

A fixação de versões é outro tópico crítico.Se você especificar uma ação apenas por meio de uma tag, como some-org/some-action@v2Ao fazer isso, você está confiando que essa tag nunca será usada para código malicioso. Tags podem ser redirecionadas se a conta do mantenedor ou o repositório forem comprometidos.

A abordagem mais defensiva hoje em dia é fixar um SHA de compromisso total.:

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

Ao fixar um valor em um SHA, o código se torna efetivamente imutável do seu ponto de vista. (exceto em casos de ataque de colisão SHA-1 em objetos Git). A desvantagem é operacional: você precisa atualizar o SHA quando quiser novos recursos ou correções, e diferentes fluxos de trabalho podem migrar para SHAs diferentes se você não tomar cuidado.

Para amenizar esse problema, algumas equipes centralizam o uso de ações de terceiros em fluxos de trabalho compartilhados ou compostos.Repositórios individuais fazem referência a esses fluxos de trabalho compartilhados por meio de tags, enquanto os fluxos de trabalho compartilhados vinculam as ações subjacentes a SHAs verificadas e são atualizados em uma cadência controlada, às vezes com ferramentas que abrem PRs para novas SHAs.

Independentemente da estratégia escolhida, lembre-se de que o pinning não é um firewall mágico.Uma ação ainda pode buscar código dinamicamente em tempo de execução (por exemplo, via curl | bash padrões) e contornar seu PIN. Você ainda precisa examinar o código-fonte em busca de padrões obviamente inseguros antes de confiar em uma ação com segredos ou tokens com permissão de escrita.

Projetando fluxos de trabalho e empregos mais seguros

A forma como você estrutura os fluxos de trabalho e as tarefas influencia fortemente o impacto de uma falha de segurança.Um antipadrão comum é uma única tarefa gigantesca que realiza o checkout do código, compila, testa, empacota e implanta, tudo isso com amplas permissões e acesso a segredos de produção.

Dividir o trabalho em tarefas separadas e até mesmo em fluxos de trabalho distintos proporciona tanto isolamento quanto clareza.Por exemplo, você pode ter:

• A trabalho de construção e teste que é executado com permissões mínimas e sem segredos de implantação.
• A trabalho de pacote Isso produz artefatos assinados, mas ainda não se comunica com o sistema de produção.
• A implantar tarefa Isso depende dos outros e é o único autorizado a acessar segredos do ambiente e assumir funções na nuvem.

Em servidores hospedados no GitHub, cada tarefa em um fluxo de trabalho é executada em uma nova máquina virtual.O que proporciona um certo grau de isolamento entre as tarefas. Não é equivalente a um sandbox reforçado, e existem vetores conhecidos de vulnerabilidade entre tarefas (como caches de ramificação compartilhados), mas dividir as tarefas ainda força os atacantes a trabalharem mais e reduz o vazamento acidental de segredos em etapas não relacionadas.

Utilize ambientes para vincular etapas sensíveis a proteções.Uma tarefa de implantação pode declarar:

environment: production

e production O ambiente pode então ser configurado para aceitar apenas implantações de uma ramificação protegida., possivelmente com aprovações manuais obrigatórias. Combinar isso com regras rígidas de proteção de ramificação (revisões obrigatórias, proibição de implementações aceleradas, rejeição de aprovações desatualizadas) aproxima você do princípio dos quatro olhos para alterações em produção.

Por fim, tenha cuidado com artefatos, caches e registros.São formas convenientes de compartilhar dados entre tarefas e fluxos de trabalho, mas:

• Não agrupe segredos em caches., especialmente locais pouco conhecidos como ~/.docker/config.json que pode conter credenciais Docker em texto simples.
• Evite registrar segredos ou despejar contextos inteiros nos logs.pois isso pode impedir o mascaramento ou revelar valores derivados que o GitHub não sabe que devem ser ocultados.
• Lembre-se de que qualquer pessoa com acesso de leitura ao repositório geralmente pode baixar artefatos e navegar pelos registros., incluindo colaboradores externos, caso você lhes conceda acesso.

OIDC e credenciais de nuvem de curta duração

Uma das mudanças mais impactantes que você pode fazer é parar de armazenar credenciais de provedores de nuvem de longa duração como segredos do GitHub.Em vez disso, use o OpenID Connect (OIDC) para obter tokens de curta duração e com escopo bem definido, vinculados a uma identidade de fluxo de trabalho específica.

O fluxo de alto nível é simples.:

• Seu provedor de nuvem (AWS, Azure, GCP, etc.) está configurado para confiar no provedor OIDC do GitHub.
• Você define uma política de identidade que diz "aceitar apenas tokens desta organização/repositório/ramificação ou ambiente".
• Durante a execução de uma tarefa, o GitHub pode solicitar um token OIDC e seu fluxo de trabalho utiliza uma ação específica da nuvem (por exemplo, aws-actions/configure-aws-credentials) para trocar isso por um token de função ou conta de serviço de curta duração.

A condição de confiança é onde você pode obter detalhes muito específicos.Para a AWS, uma política típica pode incluir:

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

Isso garante que apenas fluxos de trabalho de um repositório e branch específicos possam assumir a função.Se você deseja um escopo ainda mais restrito, pode vincular a função a um ambiente específico em vez de uma ramificação e, em seguida, exigir esse ambiente apenas para a tarefa de implantação. Uma ação de terceiros comprometida em uma tarefa que não seja de implantação fará com que as chamadas OIDC simplesmente falhem.

O uso do OIDC não elimina a necessidade de políticas de privilégio mínimo na nuvem.Mas elimina as chaves de acesso estáticas armazenadas nos Segredos do GitHub, que poderiam ser roubadas e reutilizadas indefinidamente fora do GitHub.

Proteção de ramificações, conjuntos de regras e ambientes trabalhando juntos

Muitos dos caminhos de ataque mais perigosos no GitHub Actions se resumem a "o invasor injeta alterações maliciosas em um branch protegido".A proteção de ramificações e os conjuntos de regras são sua principal linha de defesa nesse caso.

Em ramos como main or production, geralmente você quer pelo menos:

• Exigir um pull request antes de mesclar – Impedir notificações push diretas.
• Exija pelo menos uma (frequentemente mais) revisão de aprovação. de alguém que não seja o último a empurrar.
• Descartar aprovações antigas quando novos commits forem adicionados. – para que os atacantes não consigam inserir código sem serem notados após a revisão.
• Exigir aprovação da versão revisável mais recente – Impede que um invasor se aproprie do PR de outra pessoa, envie código malicioso e se autoaprove.

Em seguida, você pode conectar essas proteções aos ambientes.. Por exemplo, um production O ambiente pode aceitar apenas implantações do main ramificação, e talvez também exigir aprovação manual de um pequeno grupo de revisores (com a opção “impedir autoavaliação” ativada). Dessa forma, uma única conta de colaborador comprometida não poderá enviar código arbitrário para produção sem o envolvimento explícito de outra pessoa.

Tenha cuidado com as regras de ambiente que dependem das próprias implantações. (por exemplo, “exigir que as implantações sejam bem-sucedidas antes de permitir atualizações de tags”). Se mal estruturado, você pode criar dependências circulares ou pseudocontroles que um colaborador pode contornar editando os fluxos de trabalho. O padrão mais seguro ainda é: forte proteção de ramificação → ambientes com escopo restrito → uso explícito desses ambientes apenas nos trabalhos mínimos que realmente precisam deles.

Gerenciando executores: hospedados no GitHub vs. hospedados localmente

Os executores são as máquinas que efetivamente executam seus fluxos de trabalho.Os runners hospedados pelo GitHub são VMs efêmeras gerenciadas pelo GitHub; os runners autohospedados são máquinas ou contêineres que você provisiona e controla.

Os executores hospedados no GitHub são geralmente muito mais seguros por padrão.:

• São efêmeros e reiniciados para cada trabalho., portanto não há compromisso persistente entre as execuções.
• O GitHub publica SBOMs para imagens padrão (Ubuntu, Windows, macOS)., permitindo que você analise softwares pré-instalados em busca de vulnerabilidades.
• Determinados hosts maliciosos são bloqueados por padrão. (por exemplo, pools de mineração de criptomoedas conhecidos) através do /etc/hosts configuração.

Corredores autossuficientes são poderosos, mas perigosos. Se você não os tratar como servidores de produção:

• Geralmente não são efêmeros, a menos que você os construa você mesmo.Assim, qualquer fluxo de trabalho malicioso pode tentar persistência, movimentação lateral ou roubo de dados.
• Eles geralmente têm acesso mais amplo à rede e a segredos locais. (Chaves SSH, CLIs na nuvem, serviços de metadados), o que aumenta os riscos de qualquer comprometimento.
• Repositórios públicos quase nunca devem usar servidores de execução auto-hospedados., porque qualquer pessoa pode abrir uma solicitação de pull request que acaba executando código em sua infraestrutura.

Se precisar usar servidores de execução auto-hospedados, divida-os por limites de confiança.Utilize grupos de corredores e restrições para que:

• Projetos públicos e privados nunca compartilham o mesmo grupo de corredores.
• Repositórios de alta sensibilidade (por exemplo, infraestrutura de produção) possuem seus próprios executores rigorosamente controlados.
• Somente repositórios ou organizações específicas podem enviar tarefas para um determinado grupo.

Você pode reduzir ainda mais o risco com executores just-in-time (JIT) provisionados por meio da API REST.Esses executores se registram dinamicamente, executam no máximo uma tarefa e são removidos automaticamente. Você ainda precisa garantir que o host subjacente seja limpo ou destruído, mas isso reduz a janela de tempo em que uma tarefa comprometida pode afetar as subsequentes.

Trate os runners auto-hospedados como qualquer outro sistema de produção.Monitorar a atividade dos processos, bloquear caminhos de rede de saída, manter o sistema operacional e as ferramentas atualizados e presumir que qualquer usuário com permissão para acionar fluxos de trabalho efetivamente tenha execução de código nessa máquina.

Recursos de segurança integrados: leitura de código, Scorecards e Dependabot

O GitHub oferece uma série de recursos de primeira linha voltados especificamente para revelar riscos de fluxo de trabalho e dependência.E valem o pequeno custo de instalação.

A análise de código (por exemplo, com CodeQL) agora pode analisar os fluxos de trabalho do GitHub Actions por conta própria., não apenas o código-fonte do seu aplicativo. Regras como "Exposição Excessiva de Segredos" podem detectar padrões em que o GitHub não consegue determinar quais segredos são necessários (por exemplo, dinâmicos). secrets[myKey] uso em construções matriciais), o que leva ao carregamento de mais segredos do que o necessário na memória do trabalho.

Os Scorecards do OpenSSF e a ação Scorecards adicionam outra camada, classificando o nível de segurança das suas dependências.Para ações no mercado, os Scorecards podem sinalizar práticas inseguras na cadeia de suprimentos, tais como:

• Não fixar dependências.
• Ausência de proteções de ramificação ou requisitos de revisão de código.
• Ausência de política de segurança ou de processos de resposta a vulnerabilidades.

O Dependebot desempenha duas funções aqui.:

• Alertas do Dependabot Avisa quando uma dependência de suas ações ou fluxos de trabalho apresenta uma vulnerabilidade conhecida, com base no banco de dados de avisos do GitHub.
• Atualizações de versão e segurança do Dependabot Pode abrir automaticamente PRs para atualizar versões de ação e corrigir versões vulneráveis.

O gráfico de dependências para fluxos de trabalho é outro recurso subestimado.O GitHub trata seus arquivos de fluxo de trabalho como manifestos e pode mostrar a você:

• Quais ações e fluxos de trabalho reutilizáveis ​​você utiliza?
• Quais contas ou organizações são proprietárias delas?
• Quais versões ou SHAs você fixou?

Isso torna mais fácil responder a perguntas como "Onde estamos usando essa ação comprometida?" Quando novos alertas forem emitidos, e para planejar a remediação em massa.

Monitoramento, auditoria e governança

A segurança não termina na configuração; você também precisa de visibilidade do que está acontecendo ao longo do tempo.O GitHub fornece registros de auditoria e registros de segurança tanto no nível do usuário quanto no nível da organização.

Do ponto de vista das Ações, há várias coisas que vale a pena acompanhar.:

• Eventos relacionados a segredos, como org.update_actions_secret ou alterações em segredos do repositório. Isso indica a criação, atualização ou exclusão de credenciais confidenciais.
• Alterações no fluxo de trabalho e no conjunto de regrasQuem modificou as regras de proteção, quem editou os fluxos de trabalho de implantação, quem alterou as proteções do ambiente.
• Ações novas ou modificadas do Marketplace e aplicativos do GitHub instalados na organização, especialmente aqueles com amplos escopos de repositório ou da organização.

Você pode complementar os controles nativos do GitHub com aplicativos de aplicação de políticas como o Allstar da OpenSSF., que verifica continuamente se os repositórios estão em conformidade com os padrões de segurança da sua organização (proteção de ramificações, verificação de código ativada, revisões obrigatórias, etc.).

No que diz respeito aos "fluxos de trabalho em execução", fique atento a padrões que possam sugerir abuso.Picos incomuns no tempo de execução das tarefas, tráfego de saída inesperado dos executores ou falhas frequentes nas tarefas em etapas que lidam com segredos ou tokens OIDC. Esses sinais nem sempre são maliciosos, mas são bons pontos de partida para investigações.

Em resumo, considere o GitHub Actions como parte essencial da sua plataforma de produção.Não se trata apenas de "scripts de integração". Com segredos e tokens cuidadosamente definidos, proteções rigorosas de ramificação e ambiente, uso conservador de ações de terceiros, executores reforçados e monitoramento contínuo com ferramentas como CodeQL, Scorecards e Dependabot, você dá à sua organização uma chance de lutar contra a crescente classe de ataques de CI/CD e cadeia de suprimentos que visam explicitamente os fluxos de trabalho do GitHub.