Referência de uso seguro

Práticas de segurança para gravar fluxos de trabalho e usar recursos do GitHub Actions.

Neste artigo

Encontre informações sobre as práticas recomendadas de segurança ao escrever fluxos de trabalho e usar os recursos de segurança do GitHub Actions.

Escrevendo fluxos de trabalho

Usar segredos para informações confidenciais

Como há várias maneiras de transformar o valor de um segredo, a ocultação automática não é garantida. Siga as práticas recomendadas a seguir para limitar os riscos associados aos segredos.

  •         **Princípio de privilégios mínimos**
    • Qualquer usuário com permissão de escrita no seu repositório tem acesso de leitura a todos os segredos configurados no repositório. Portanto, você deve garantir que as credenciais que estão sendo usadas nos fluxos de trabalho tenham os privilégios mínimos necessários.
    • Ações podem usar o GITHUB_TOKEN acessando-o a partir do contexto github.token. Para saber mais, confira Referência de contextos. Portanto, você deve verificar se o GITHUB_TOKEN recebeu as permissões mínimas necessárias. É uma boa prática de segurança definir a permissão padrão para o GITHUB_TOKEN como somente acesso de leitura no conteúdo do repositório. As permissões podem ser aumentadas, conforme necessário, para tarefas individuais dentro do arquivo do fluxo de trabalho. Para saber mais, confira Usar GITHUB_TOKEN para autenticação em fluxos de trabalho.
  •         **Mascarar dados confidenciais**
    • Dados confidenciais nunca devem ser armazenados como texto sem formatação em arquivos de fluxo de trabalho. Mascara todas as informações confidenciais que não são um segredo GitHub usando ::add-mask::VALUE. Isso faz com que o valor seja tratado como um segredo e ocultado dos logs. Para obter mais informações sobre como colocar máscara em dados, confira Comandos de fluxo de trabalho para o GitHub Actions.
  •           **Excluir e girar segredos expostos**
    • A ocultação dos segredos é realizada pelos seus executores de fluxos de trabalho. Isso significa que um segredo será ocultado somente se tiver sido usado em um trabalho e for acessível pelo executor. Caso um segredo não ocultado seja enviado para um log de execução de fluxos de trabalho, você deverá excluir o log e substituir o segredo. Para obter mais informações sobre como excluir logs, confira Usando logs de execução de fluxo de trabalho.
  •         **Nunca usar dados estruturados como um segredo**
    • Os dados estruturados podem fazer com que ocorra uma falha nos registros de segredos, pois a redação depende, em grande parte, de encontrar uma correspondência exata para o valor específico do segredo. Por exemplo, não use um blob de JSON, XML, ou YAML (ou similar) para encapsular o valor de um segredo, já que isso reduz significativamente a probabilidade de os segredos serem devidamente redigidos. Em vez disso, crie segredos individuais para cada valor sensível.
  •         **Registrar todos os segredos usados nos fluxos de trabalho**
    • Se um segredo for usado para gerar outro valor confidencial em um fluxo de trabalho, esse valor gerado deverá ser formalmente registrado como um segredo, para que seja editado se aparecer nos logs. Por exemplo, se, ao usar uma chave privada para gerar um JWT assinado para acessar uma API web, certifique-se de registrar que JWT é um segredo ou não será redigido se entrar na saída de do registro.
    • O registro de segredos também aplica-se a qualquer tipo de transformação/codificação. Se seu segredo foi transformado de alguma forma (como Base64 ou URL codificada), certifique-se de registrar o novo valor como um segredo também.
  •         **Auditar a forma como os segredos são tratados**
    • Audite como os segredos são usados, para ajudar a garantir que estejam sendo tratados conforme o esperado. Você pode fazer isso revisando o código-fonte do repositório que executa o fluxo de trabalho e verificando quaisquer ações usadas no fluxo de trabalho. Por exemplo, verifique se eles não são enviados para hosts não pretendidos, ou impressos explicitamente na saída de um registro.
    • Visualize os registros de execução do seu fluxo de trabalho depois de testar entradas válidas/inválidas e, em seguida, verifique se os segredos estão sendo editados corretamente ou não são mostrados. Nem sempre é óbvio como um comando ou uma ferramenta que você está invocando enviará erros para STDOUT e STDERR, e os segredos podem acabar nos logs de erros. Como resultado, considera-se uma boa prática rever manualmente os registros do fluxo de trabalho depois de testar entradas válidas e inválidas. Para obter informações sobre como limpar logs de fluxo de trabalho que podem conter dados confidenciais involuntariamente, consulte Usando logs de execução de fluxo de trabalho.
  •           **Auditar e substituir os segredos registrados**
    • Reveja, periodicamente, os segredos registrados para confirmar se ainda são necessários. Remova aqueles que não são mais necessários.
    • Gire os segredos periodicamente para reduzir a janela de tempo durante a qual um segredo comprometido é válido.
  •         **Considerar a necessidade de revisão para acesso a segredos**
    • Você pode usar revisores necessários para proteger os segredos do ambiente. Um trabalho de fluxo de trabalho não pode acessar segredos de ambiente até que a aprovação seja concedida por um revisor. Para obter mais informações sobre como armazenar segredos em ambientes ou exigir revisões de ambientes, confira Usar segredos em ações do GitHub e Gerenciar ambientes para implantação.

Práticas recomendadas para mitigar ataques de injeção de script

Abordagens recomendadas para atenuar o risco de injeção de script em seus fluxos de trabalho:

Usar uma ação em vez de um script embutido

A abordagem recomendada é criar uma ação JavaScript que processa o valor do contexto como um argumento. Essa abordagem não é vulnerável ao ataque de injeção, pois o valor do contexto não é usado para gerar um script do shell, mas é passado para a ação como um argumento:

uses: fakeaction/checktitle@v3
with:
  title: ${{ github.event.pull_request.title }}

Usar uma variável de ambiente intermediária

Para scripts em linha, a abordagem preferida para manipular entradas não confiáveis é definir o valor da expressão para uma variável de ambiente intermediário. O seguinte exemplo usa o Bash para processar o valor github.event.pull_request.title como uma variável de ambiente:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Neste exemplo, a tentativa de injeção de script não é bem-sucedida, o que é refletido pelas seguintes linhas no log:

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

Com esta abordagem, o valor da expressão ${{ github.event.pull_request.title }} é armazenado na memória e usada como uma variável e não interage com o processo de geração de script. Além disso, considere usar aspas duplas em variáveis de shell para evitar a divisão de palavras, mas essa é uma das muitas recomendações gerais para a escrita de scripts de shell e não é específica do GitHub Actions.

Usando modelos de fluxo de trabalho para o code scanning

Code scanning permite que você encontre vulnerabilidades de segurança antes de atingirem a produção. O GitHub fornece modelos de fluxo de trabalho para o code scanning. Você pode usar esses fluxos de trabalho sugeridos para construir seus fluxos de trabalho de code scanning, ao invés de começar do zero. O fluxo de trabalho do GitHub, o Fluxo de trabalho de análise do CodeQL, é ativado pelo CodeQL. Também existem modelos de fluxo de trabalho de terceiros disponíveis.

Para saber mais, confira Sobre a varredura de código e Como definir a configuração avançada para verificação de código.

Restringir permissões para tokens

Para ajudar a mitigar o risco de um token exposto, considere restringir as permissões atribuídas. Para saber mais, confira Usar GITHUB_TOKEN para autenticação em fluxos de trabalho.

Mitigando os riscos do check-out de código não confiável

De maneira semelhante aos ataques de injeção de script, conteúdos de pull request não confiáveis que disparam automaticamente o processamento de ações também podem representar um risco de segurança. Os gatilhos de fluxo de trabalho pull_request_target e workflow_run, quando usados com o check-out de uma pull request não confiável, expõem o repositório a comprometimentos de segurança. Esses fluxos de trabalho são privilegiados, o que significa que compartilham o mesmo cache da ramificação principal com outros gatilhos de fluxo de trabalho privilegiados, e podem ter acesso de gravação ao repositório e acesso a segredos referenciados. Essas vulnerabilidades podem ser exploradas para roubar um repositório.

Para saber mais sobre esses gatilhos, como usá-los e os riscos associados, confira Eventos que disparam fluxos de trabalho e Eventos que disparam fluxos de trabalho.

Para obter exemplos adicionais e diretrizes sobre os riscos do check-out de código não confiável, consulte Preventing pwn requests em GitHub Security Lab e a documentação sobre Dangerous-Workflow no OpenSSF Scorecard.

Boas práticas

  • Evite usar o gatilho do fluxo de trabalho pull_request_target se não for necessário. Para fins de separação de privilégios entre fluxos de trabalho, workflow_run é um gatilho melhor. Use esses gatilhos de fluxo de trabalho somente quando o fluxo de trabalho realmente precisar do contexto privilegiado.

  • Evite usar os gatilhos de fluxo de trabalho pull_request_target e workflow_run com conteúdo de código ou pull requests não confiáveis. Fluxos de trabalho que usam esses gatilhos não devem fazer check-out explicitamente de código não confiável, incluindo forks de pull requests ou repositórios que não estão sob seu controle. Fluxos de trabalho disparados em workflow_run devem tratar artefatos carregados de outros fluxos de trabalho com cautela.

  • O CodeQL pode escanear e detectar fluxos de trabalho do GitHub Actions potencialmente vulneráveis. Você pode definir a configuração padrão para o repositório e garantir que a verificação do GitHub Actions esteja habilitada. Para saber mais, confira Como definir a configuração padrão da verificação de código.

  • Os OpenSSF Scorecards podem ajudar você a identificar fluxos de trabalho potencialmente vulneráveis, juntamente com outros riscos de segurança ao usar GitHub Actions. Confira Como usar o OpenSSF Scorecards para proteger dependências de fluxo de trabalho mais adiante neste artigo.

Usando ações de terceiros

Os trabalhos individuais em fluxo de trabalho podem interagir com (e comprometer) outros trabalhos. Por exemplo, um trabalho que consulta as variáveis de ambiente usadas por um trabalho posterior, que escreve arquivos para um diretório compartilhado que um trabalho posterior processa, ou ainda mais diretamente, que interage com o conector do Docker e inspeciona outros contêineres em execução e executa comandos neles.

Isso significa que comprometer uma só ação em um fluxo de trabalho pode ser muito significativo, pois essa ação comprometida terá acesso a todos os segredos configurados no repositório e poderá usar o GITHUB_TOKEN para fazer gravações no repositório. Consequentemente, há um risco significativo em fornecer de ações de repositórios de terceiros no GitHub. Para obter mais informações sobre algumas das etapas que um invasor pode executar, confira Referência de uso seguro.

Você pode ajudar a mitigar esse risco seguindo estas boas práticas:

  •           **Fixar as ações em um SHA de commit de comprimento completo**

    Fixar uma ação para um commit SHA de comprimento completo é, atualmente, a única maneira de usar uma ação como uma versão imutável. Fixar um SHA em particular ajuda a mitigar o risco de um ator malicioso adicionar uma porta traseira ao repositório da ação, porque precisariam gerar uma colisão de SHA-1 para uma carga válida do objeto de Git. Ao selecionar um SHA, verifique se ele está no repositório da ação e não em uma bifurcação do repositório.

    Para obter um exemplo de como usar um SHA de commit de comprimento completo em um fluxo de trabalho, confira Usando blocos de construção pré-gravados no seu fluxo de trabalho.

    O GitHub oferece políticas no nível de repositório, organização e empresa para exigir que ações sejam fixadas a um SHA de commit de comprimento completo:

  •         **Auditar o código-fonte da ação**

    Certifique-se de que a ação está tratando o conteúdo do seu repositório e os segredos, como esperado. Por exemplo, verifique se os segredos não são enviados para hosts não autorizados ou se não estejam registrados inadvertidamente.

  •           **Fixar ações em uma marca somente se você confiar no criador**

    Embora a fixação de um commit de SHA seja a opção mais segura, especificar uma etiqueta é a opção mais conveniente, além de ser amplamente usada. Se você desejar de especificar uma etiqueta, certifique-se de que você confia nos criadores da ação. O selo "Criador verificado" em GitHub Marketplace é um sinal útil, já que indica que a ação foi escrita por uma equipe cuja identidade foi verificada por GitHub. Observe que há risco para esta abordagem, mesmo que você confie no autor, porque uma etiqueta pode ser movida ou excluída se um ator malicioso obtiver acesso ao repositório que armazena a ação.

Reutilizando fluxos de trabalho de terceiros

Os mesmos princípios descritos acima para o uso de ações de terceiros também se aplicam ao uso de fluxos de trabalho de terceiros. Você pode ajudar a mitigar os riscos associados à reutilização de fluxos de trabalho, seguindo as mesmas práticas recomendadas descritas acima. Para saber mais, confira Reutilizar fluxos de trabalho.

Recursos de segurança do GitHub

GitHub fornece muitos recursos para tornar seu código mais seguro. Você pode usar os recursos internos do GitHub para entender as ações das quais dependem seus fluxos de trabalho, garantir que receba notificações sobre vulnerabilidades nas ações que consome ou para automatizar o processo de manter as ações em seus fluxos de trabalho atualizadas. Se você publicar e manter ações, poderá usar GitHub para se comunicar com sua comunidade sobre vulnerabilidades e como corrigi-las. Para obter mais informações sobre os recursos de segurança oferecidos pelo GitHub confira Recursos de segurança do GitHub.

Como usar CODEOWNERS para monitorar alterações

Use o recurso CODEOWNERS para controlar como são feitas alterações nos seus arquivos de fluxo de trabalho. Por exemplo, se todos os arquivos de fluxo de trabalho forem armazenados em .github/workflows, você poderá adicionar esse diretório à lista de proprietários do código, de modo que todas as alterações propostas nesses arquivos exijam primeiro a aprovação de um revisor designado.

Para saber mais, confira Sobre os proprietários de código.

Gerenciar as permissões de configurações do GitHub Actions na sua organização

Você pode praticar o princípio de menor privilégio para o pipeline de CI/CD da sua organização com GitHub Actions administrando funções personalizadas da organização. Uma função de organização personalizada é uma maneira de conceder a uma pessoa ou equipe da organização a capacidade de controlar determinados subconjuntos de configurações sem conceder controle administrativo total da organização e de seus repositórios.

Para GitHub Actions, você pode habilitar qualquer uma das seguintes permissões para indivíduos ou equipes em sua organização.

  • Gerenciar políticas de Ações da organização: acesso para gerenciar todas as configurações na página de configurações "Ações Gerais", exceto as configurações de executores auto-hospedados.
  • Gerenciar executores e grupos de executores da organização: acesse para criar e gerenciar executores hospedados no GitHub, executores auto-hospedados e grupos de executores, e controle onde os executores auto-hospedados podem ser criados.
  • Gerenciar segredos de ações da organização: acesse para criar e gerenciar segredos de ações da organização.
  • Gerenciar variáveis de ações da organização: acesse para criar e gerenciar variáveis de ações da organização.

Para saber mais, confira Sobre as funções da organização personalizadas.

Usando o OpenID Connect para acessar os recursos da nuvem

Se os seus fluxos de trabalho de GitHub Actions tiverem de acessar recursos de um provedor de nuvem compatível com o OpenID Connect (OIDC), você poderá configurar seus fluxos de trabalho para efetuar a autenticção diretamente no provedor de nuvem. Isso permitirá que você pare de armazenar essas credenciais como segredos de longa duração e proporcione outros benefícios de segurança. Para saber mais, confira OpenID Connect.

Observação

O suporte para declarações personalizadas de OIDC não está disponível na AWS.

Usar Dependabot version updates para manter as ações atualizadas

Você pode usar o Dependabot para garantir que as referências a ações e a fluxos de trabalho reutilizáveis usados no seu repositório sejam mantidas atualizadas. Ações são frequentemente atualizadas com correções de bugs e novos recursos para tornar os processos automatizados mais rápidos, seguros e confiáveis. O Dependabot reduz o seu esforço para manter dependências, pois ele faz isso automaticamente para você. Para saber mais, confira Manter as suas ações atualizadas com o Dependabot e Sobre as atualizações de segurança do Dependabot.

Permitir que os fluxos de trabalho acessem repositórios internos e privados

Para tornar um repositório privado acessível aos fluxos de trabalho do GitHub Actions em outros repositórios, os colaboradores externos nos outros repositórios podem acessar indiretamente o repositório privado, mesmo que não tenham acesso direto a esses repositórios. Os colaboradores externos podem exibir os logs das execuções do fluxo de trabalho quando ações ou fluxos de trabalho do repositório privado são usados. Para obter mais informações, confira Compartilhando ações e fluxos de trabalho com sua empresa.

Para permitir que os executores baixem essas ações, o GitHub transmite um token de instalação com escopo para o executor. Esse token tem acesso de leitura no repositório e expira automaticamente após uma hora.

Como impedir que GitHub Actions crie ou aprove solicitações de pull

Você pode optar por permitir ou impedir que fluxos de trabalho do GitHub Actions criem ou aprovem pull requests. Permitir que os fluxos de trabalho ou qualquer outra automação criem ou aprovem pull requests pode ser um risco de segurança se o pull request for mesclado sem a devida supervisão.

Para obter mais informações sobre como definir essa configuração, consulte Aplicando políticas para o GitHub Actions na sua empresa, Desabilitando ou limitando GitHub Actions para sua organização e Gerenciando as configurações do GitHub Actions para um repositório.

Como usar a code scanning para proteger fluxos de trabalho

A Code scanning pode detectar e sugerir aprimoramentos automaticamente para padrões vulneráveis comuns usados em fluxos de trabalho do GitHub Actions. Para obter mais informações sobre como habilitar a code scanning, confira Como definir a configuração padrão da verificação de código.

Como usar o OpenSSF Scorecards para proteger dependências de fluxo de trabalho

O Scorecards é uma ferramenta de segurança automatizada que sinaliza as práticas suspeitas da cadeia de fornecedores. Você poderá usar a ação Scorecards e o modelo de fluxo de trabalho para seguir as melhores práticas de segurança. Uma vez configurada, a ação Scorecards é executada automaticamente nas alterações de repositórios e alerta de desenvolvedores sobre práticas arriscadas em cadeia de suprimentos que usam a experiência de code scanning. O projeto Scorecards executa um número de verificações, incluindo ataques de injeção de script, permissões de token e ações fixadas.

Proteção para executores hospedados pelo GitHub

Os executores hospedados pelo GitHub tomam medidas para ajudar você a reduzir os riscos de segurança.

Como revisar a supply chain para GitHub-hosted runners

Para executores hospedados pela GitHub criados a partir de imagens mantidas pela GitHub, você pode exibir uma lista de materiais de software (SBOM) para ver qual software foi pré-instalado no runner. Você pode fornecer a SBOM aos usuários, e eles podem executá-la por meio de um verificador de vulnerabilidades, que pode validar se há vulnerabilidades no produto. Se você estiver criando artefatos, poderá incluir essa SBOM na sua lista de materiais para obter uma lista completa de tudo o que foi feito para criar o software.

SBOMs estão disponíveis para imagens de executores Ubuntu, Windows e macOS, mantidas pela GitHub. Você pode localizar a SBOM do seu build nos ativos de versão, em https://github.com/actions/runner-images/releases. Uma SBOM com um nome de arquivo em formato de sbom.IMAGE-NAME.json.zip pode ser encontrada nos anexos de cada versão.

Para imagens de terceiros, como as imagens para corredores com ARM, você pode encontrar detalhes do software incluído na imagem no repositório actions/partner-runner-images.

Negar acesso a hosts

Os executores hospedados pelo GitHub são provisionados com um arquivo etc/hosts que bloqueia o acesso à rede a vários pools de mineração de criptomoedas e sites mal-intencionados. Hosts como MiningMadness.com e cpu-pool.com são redirecionados para localhost para que não apresentem um risco de segurança significativo. Para obter mais informações, confira Executores hospedados no GitHub.

Fortalecimento para executores auto-hospedados

Os executores hospedados pelo GitHub executam o código em máquinas virtuais isoladas efêmeras e limpas. Ou seja, não é possível comprometer de maneira persistente este ambiente ou obter, de outro modo, acesso a mais informações do que foram colocadas no ambiente durante o processo de inicialização.

Os executores Auto-hospedados do GitHub não fornecem garantias de serem executados em máquinas virtuais efêmeras e limpas e podem ser comprometidos de maneira persistente por um código não confiável em um fluxo de trabalho.

Como resultado, os executores auto-hospedados quase nunca devem ser usados para repositórios públicos no GitHub, porque qualquer usuário pode abrir pull requests no repositório e comprometer o ambiente. Da mesma forma,tenha cuidado ao usar executores auto-hospedados em repositórios privados ou internos, pois qualquer pessoa que possa criar um fork do repositório e abrir uma solicitação de pull (geralmente aqueles com acesso de leitura no repositório) pode comprometer o ambiente do executor auto-hospedado, incluindo a obtenção do acesso a segredos e ao GITHUB_TOKEN que, dependendo das configurações, pode permitir o acesso de gravação no repositório. Embora os fluxos de trabalho possam controlar o acesso a segredos de ambiente usando os ambientes e revisões necessários, estes fluxos de trabalho não são executados em um ambiente isolado e continuam sendo susceptíveis aos mesmos riscos quando são executados por um executor auto-hospedado.

Proprietários de empresas e organizações podem escolher que repositórios têm permissão para criar executores auto-hospedados no nível do repositório. Usuários com a permissão "Gerenciar executores e grupos de executores da organização" só podem escolher quais repositórios têm permissão para criar executores auto-hospedados no nível do repositório para repositórios em sua organização.

Para obter mais informações sobre funções de organização personalizadas, confira Sobre as funções da organização personalizadas.

Para obter mais informações, confira Aplicando políticas para o GitHub Actions na sua empresa e Desabilitar ou limitar o GitHub Actions para sua organização.

Quando um executor auto-hospedado é definido no nível da organização ou empresa, o GitHub pode programar fluxos de trabalho de vários repositórios para o mesmo executor. Consequentemente, uma falha de segurança nestes ambientes pode ter um grande impacto. Para ajudar a reduzir o escopo de um compromisso, você pode criar limites organizando seus executores auto-hospedados em grupos separados. É possível restringir quais fluxos de trabalho, organizações e repositórios podem acessar os grupos de executores. Para saber mais, confira Gerenciar o acesso a executores auto-hospedados usando grupos.

Você também deve considerar o ambiente das máquinas de executores auto-hospedadas:

  • Que informação sensível reside na máquina configurada como um executor auto-hospedado? Por exemplo, chaves SSH privadas, tokens de acesso à API, entre outros.
  • A máquina tem acesso à rede a serviços sensíveis? Por exemplo, serviços de metadados do Azure ou AWS. A quantidade de informações confidenciais neste ambiente deve ser limitada ao mínimo, e você deve estar sempre ciente de que qualquer usuário capaz de invocar fluxos de trabalho terá acesso a esse ambiente.

Alguns clientes podem tentar mitigar parcialmente esses riscos implementando sistemas que destroem automaticamente o executor autogerenciado após cada execução da tarefa. No entanto, esta abordagem poderá não ser tão eficaz como pretendido, uma vez que não há forma de garantir que um executor auto-hospedado execute apenas um trabalho. Alguns trabalhos usarão segredos como argumentos de linha de comando que podem ser vistos por outro trabalho em execução no mesmo executor, como ps x -w. Isso pode levar a vazamento de segredos.

Usar os executores just-in-time

Para melhorar a segurança de registro do executor, você pode usar a API REST para criar executores JIT (just-in-time) efêmeros. Esses executores auto-hospedados executam no máximo um trabalho antes de serem removidos automaticamente do repositório, da organização ou da empresa. Para obter mais informações sobre como configurar executores JIT, confira Pontos de extremidade da API REST para executores auto-hospedados.

Observação

A reutilização de hardware para hospedar executores JIT pode gerar o risco de exposição das informações do ambiente. Use a automação para garantir que o executor JIT use um ambiente limpo. Para saber mais, confira Referência de executores auto-hospedados.

Assim que tiver o arquivo de configuração da resposta da API REST, você poderá passá-lo para o executor na inicialização.

./run.sh --jitconfig ${encoded_jit_config}

Planejando sua estratégia de gerenciamento para executores auto-hospedados

Um executor auto-hospedado pode ser adicionado aos vários níveis na sua hierarquia de GitHub: empresa, organização ou repositório. Este posicionamento determina quem será poderá de gerenciar o executor:

          **Gerenciamento centralizado:**

  • Se você planeja ter uma equipe centralizada que detém os executores auto-hospedados, recomenda-se adicionar seus executores ao nível mais alto da organização mútua ou da empresa. Isto fornece à sua equipe um único local para visualizar e gerenciar seus executores.

  • Se você tiver apenas uma única organização, adicionar seus executores ao nível da organização é, de fato, a mesma abordagem, mas você pode encontrar dificuldades se você adicionar outra organização no futuro.

            **Gerenciamento descentralizado:**

  • Se cada equipe gerenciar seus próprios corredores hospedados, a recomendação será adicionar os executores ao mais alto nível de propriedade da equipe. Por exemplo, se cada equipe possui sua própria organização, será mais simples se os executores também forem adicionados ao nível da organização.

  • Você também pode adicionar executores no nível de repositório, mas isso adicionará uma sobrecarga de gerenciamento e também aumentará o número de executores necessários já que você não pode compartilhar executores entre repositórios.

Efetuando a autenticação para seu provedor de nuvem

Se você está usando GitHub Actions para implantar em um provedor de nuvem, ou pretende usar o HashiCorp Vault para o gerenciamento de segredos, recomenda-se considerar usar o OpenID Connect para criar tokens de acesso curtos e com escopos bem definidos para as execuções do seu fluxo de trabalho. Para saber mais, confira OpenID Connect.

Auditar eventos de GitHub Actions

Você pode usar o log de segurança para monitorar a atividade da conta de usuário e o log de auditoria para monitorar a atividade da organização ou da empresa. Os logs de segurança e auditoria registram o tipo de ação, quando ela foi executada e qual conta pessoal a executou.

Por exemplo, você pode usar o log de auditoria para acompanhar o evento org.update_actions_secret, que acompanha as alterações nos segredos da organização.

Captura de tela mostrando uma busca por "action:org.update_actions_secret" no log de auditoria de uma organização. Dois resultados são mostrados.

Para obter a lista completa de eventos que você pode encontrar no log de auditoria de cada tipo de conta, confira os seguintes artigos:

  •         [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/security-log-events)

  •           [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization)

  •         [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise)

Noções básicas sobre dependências em seus fluxos de trabalho

Você pode usar o grafo de dependência para explorar as ações que os fluxos de trabalho em seu repositório usam. O grafo de dependência é um resumo do manifesto e dos arquivos de bloqueio armazenados em um repositório. Ele também reconhece arquivos em ./github/workflows/ como manifestos, o que significa que quaisquer ações ou fluxos de trabalho referenciados usando a sintaxe jobs[*].steps[*].uses ou jobs.<job_id>.uses serão analisados como dependências.

O grafo de dependência mostra as seguintes informações sobre ações usadas em fluxos de trabalho:

  • A conta ou organização proprietária da ação.
  • O arquivo de fluxo de trabalho que faz referência à ação.
  • A versão ou SHA à qual a ação está fixada.

No grafo de dependência, as dependências são classificadas automaticamente pela gravidade da vulnerabilidade. Se qualquer uma das ações que você usar tiver avisos de segurança, eles serão exibidos na parte superior da lista. Você pode navegar até o aviso pelo grafo de dependência e acessar as instruções para resolver a vulnerabilidade.

O grafo de dependência é habilitado para repositórios públicos, e você pode optar por habilitá-lo em repositórios privados. Para obter mais informações sobre como usar o gráfico de dependência, confira Explorar as dependências de um repositório.

Estar ciente das vulnerabilidades de segurança nas ações que você usa

Para ações disponíveis no mercado, GitHub revisa os avisos de segurança relacionados e, em seguida, adiciona esses avisos ao GitHub Advisory Database. Você pode pesquisar no banco de dados as ações que você usa para encontrar informações sobre vulnerabilidades existentes e instruções sobre como corrigi-las. Para simplificar sua pesquisa, use o filtro GitHub Actions no GitHub Advisory Database.

Você pode configurar seus repositórios para:

Monitorar as ações em seus fluxos de trabalho

Você pode usar Dependabot para monitorar as ações em seus fluxos de trabalho e habilitar Dependabot alerts para receber notificações quando uma ação usada tiver uma vulnerabilidade relatada. O Dependabot executa uma varredura do branch padrão dos repositórios em que está habilitado para detectar dependências inseguras. O Dependabot gera Dependabot alerts quando um novo aviso é adicionado ao GitHub Advisory Database ou quando uma ação usada é atualizada.

Observação

O Dependabot só cria alertas para ações vulneráveis que usam controle de versão semântico e não criará alertas para ações fixadas em valores SHA.

Você pode habilitar Dependabot alerts para sua conta pessoal, para um repositório ou para uma organização. Para obter mais informações, confira Configurando alertas do Dependabot.

Você pode exibir todos os Dependabot alerts abertos e fechados e as Dependabot security updates correspondentes na guia Dependabot alerts do seu repositório. Para obter mais informações, confira Visualizando e atualizando alertas do Dependabot.

Ações de triagem para vulnerabilidades em fluxos de trabalho novos ou atualizados

Quando você abre pull requests para atualizar seus fluxos de trabalho, é uma boa prática usar a revisão de dependência para entender o impacto na segurança das alterações feitas nas ações usadas. Revisão de dependências ajuda você a entender as alterações de dependência e o impacto de segurança dessas alterações em cada pull request. Ele fornece uma visualização facilmente compreensível de mudanças de dependência, com um diff avançado na aba "Arquivos alterados" de uma solicitação de pull. A revisão de dependências informa você:

  • Quais dependências foram adicionadas, removidas ou atualizadas, junto com as datas de lançamento
  • Quantos projetos usam esses componentes
  • Dados de vulnerabilidade para essas dependências

Se qualquer uma das alterações feitas em seus fluxos de trabalho for sinalizada como vulnerável, você poderá evitar adicioná-las ao seu projeto ou atualizá-las para uma versão segura.

Para obter mais informações sobre a revisão de dependência, confira Sobre a análise de dependência.

O "ação de revisão de dependência" se refere à ação específica que pode relatar diferenças em um pull request dentro do contexto do GitHub Actions. Consulte dependency-review-action. É possível usar o ação de revisão de dependência no repositório para impor revisões de dependência em solicitações de pull. A ação examina versões vulneráveis de dependências introduzidas por alterações de versão do pacote em solicitações de pull e avisa você sobre as vulnerabilidades de segurança associadas. Isso oferece uma melhor visibilidade do que está mudando em uma solicitação de pull e ajuda a evitar que vulnerabilidades sejam adicionadas ao repositório. Para obter mais informações, consulte Sobre a análise de dependência.

Manter as ações em seus fluxos de trabalho seguras e atualizadas

Você pode usar o Dependabot para garantir que as referências a ações e a fluxos de trabalho reutilizáveis usados no seu repositório sejam mantidas atualizadas. Ações são frequentemente atualizadas com correções de bugs e novos recursos para tornar os processos automatizados mais rápidos, seguros e confiáveis. O Dependabot reduz o seu esforço para manter dependências, pois ele faz isso automaticamente para você. Para saber mais, confira Manter as suas ações atualizadas com o Dependabot e Sobre as atualizações de segurança do Dependabot.

Os recursos a seguir podem atualizar automaticamente as ações em seus fluxos de trabalho.

  •           **Dependabot version updates** abre pull requests para atualizar ações para a última versão quando uma nova versão for lançada.

  •           **Dependabot security updates** abre pull requests para atualizar ações com vulnerabilidades relatadas para a versão mínima corrigida.

Observação

  • Dependabot apenas suporta atualizações para GitHub Actions usando a sintaxe de repositório do GitHub, como actions/checkout@v5 ou actions/checkout@<commit>. O Dependabot ignorará ações ou fluxos de trabalho reutilizáveis referenciados localmente (por exemplo, ./.github/actions/foo.yml).
  • Dependabot atualiza a documentação de versão do GitHub Actions quando o comentário está na mesma linha, como actions/checkout@<commit> #<tag or link> ou actions/checkout@<tag> #<tag or link>.
  • Se a confirmação que você usa não estiver associado a nenhuma tag, Dependabot atualizará o GitHub Actions para a confirmação mais recente (que pode ser diferente do lançamento mais recente).
  • Não há suporte atualmente para URLs Container registry do Docker Hub e do GitHub Packages. Por exemplo, não há suporte para referências a ações de contêiner do Docker usando a sintaxe docker://.
  • Dependabot suporta repositórios públicos e privados para GitHub Actions. Para opções de configuração de registro privado, consulte git em Referência de opções do Dependabot.

Para obter informações sobre como configurar Dependabot version updates, confira Configuração de atualizações de versão do Dependabot.

Para obter informações sobre como configurar Dependabot security updates, confira Configuração de atualizações de segurança do Dependabot.

Proteger ações que você criou

O GitHub permite a colaboração entre pessoas que publicam e mantêm ações e relatores de vulnerabilidade para promover a codificação segura. Os avisos de segurança do repositório permitem que os mantenedores dos repositórios públicos discutam e corrijam de modo privado as vulnerabilidades de segurança em um projeto. Depois de colaborar em uma correção, os responsáveis pelo repositório podem publicar o aviso de segurança para divulgar publicamente a vulnerabilidade de segurança na comunidade do projeto. Ao publicar avisos de segurança, os responsáveis pelo repositório facilitam para a comunidade a atualização das dependências do pacote e a pesquisa sobre o impacto das vulnerabilidades de segurança.

Se você for alguém que mantém uma ação usada em outros projetos, poderá usar os seguintes recursos do GitHub para aumentar a segurança das ações publicadas.