O GitHub Actions tem sido alvo de muitos ataques à Supply chain , e as configurações incorretas dos fluxos de trabalho têm desempenhado um papel importante. É perigoso agir sozinho! Consulte esta (lista de verificação).
Por que razão existem tantos problemas de segurança com o GitHub Actions?
O GitHub Actions, o sistema integrado de CI/CD e automação do GitHub, não apresenta, por si só, falhas de segurança, mas oferece certamente muitas oportunidades para nos prejudicarmos a nós próprios.
A plataforma funciona conforme previsto, mas as configurações predefinidas são, em geral, definidas com vista à conveniência e flexibilidade, e não à segurança. pull_request_target isso existe por uma razão, e as etiquetas mutáveis são, sem dúvida, convenientes. Mas essas decisões de design criaram uma superfície de ataque que só se tornou evidente mais tarde.
O GitHub Actions é também o sistema de CI/CD padrão para a maioria dos projetos de código aberto, e a apropriação de um projeto de código aberto permite que os hackers atinjam as vítimas mais a jusante. Os fluxos de trabalho contêm frequentemente credenciais que permitem a publicação no npm e no PyPI; assim, um fluxo de trabalho comprometido pode enviar uma versão maliciosa de um pacote, e todos os programadores que instalarem esse pacote também a receberão.
Outra razão pela qual continuamos a ver tantos vetores semelhantes a surgir em incidentes é o facto de a superfície de ataque estar bem documentada em estudos públicos há anos. Por vezes, os atacantes limitam-se a analisar repositórios à procura destas configurações incorretas para encontrar alvos fáceis de atacar (ver prt-scan). O GitHub está a dar prioridade a proteções mais robustas ao longo do próximo ano para proteger melhor os utilizadores, mas continua a recair sobre o utilizador grande parte da responsabilidade de configurar o GitHub de forma segura e correta.
Seguir todas as melhores práticas não tornará os seus fluxos de trabalho totalmente à prova de falhas. Embora não seja possível proteger-se totalmente contra um mantenedor comprometido ou uma vulnerabilidade de dia zero na infraestrutura do GitHub, pode bloquear muitos dos vetores que os atacantes têm vindo a explorar ativamente nos últimos tempos, tornando os seus repositórios um alvo mais difícil do que a maioria.
Melhores práticas para manter a segurança dos seus fluxos de trabalho do GitHub Actions
Comece por aqui. Se só fizer cinco coisas desta lista de verificação:
- Associar todas as ações de terceiros a um SHA de commit completo
- Definir como padrão
GITHUB_TOKENpermissões de leitura - Nunca
pull_request_targetem repositórios públicos - Nunca faça interpolação
${{ github.* }}diretamente paraexecutar:passos - Utilize o OIDC para credenciais na nuvem em vez de secrets de longa duração
No entanto, recomendamos que leia a lista de verificação em pormenor, onde explicamos todas as nossas recomendações de segurança para o GitHub Actions e por que razão são necessárias. Consulte também as ferramentas indicadas no final, que o ajudarão a implementar e a aplicar estas melhores práticas.
Configuração do gatilho
1. Nunca utilize pull_request_target em repositórios públicos
pull_request_target Existe para permitir que os fluxos de trabalho acionados por PRs de fork sejam executados com acesso aos secrets do repositório base. Permite-lhe etiquetar ou comentar automaticamente PRs de colaboradores externos. É uma boa ideia, mas o acesso aos secrets isto perigoso.
Ao contrário do padrão solicitação de pull gatilho, pull_request_target é executado no contexto do repositório base, independentemente da origem do PR. Qualquer pessoa pode abrir um PR num repositório público. Se o seu fluxo de trabalho for acionado por esse PR, mesmo que este não tenha sido incorporado, quaisquer secrets referenciados no fluxo de trabalho são carregados no ambiente do executor e tornam-se acessíveis a qualquer código executado nesse executor. O script do atacante pode facilmente ler qualquer um deles através de uma consulta ao ambiente, como os.environ.get('MY_SECRET') e reenviá-los ao atacante sem deixar vestígios.
Se precisar de o fazer num repositório privado, exija que os colaboradores de primeira vez obtenham a aprovação de um mantenedor antes de poderem acionar quaisquer fluxos de trabalho. O GitHub suporta esta funcionalidade de forma nativa em Configurações > Ações > Fluxos de trabalho de pull requests de forks.
Na prática: O Trivy de março de 2026 resultou da exploração de pull_request_target. Os engenheiros pensaram que era seguro, uma vez que não seria permitido executar nada, mas isso não foi suficiente. O PR enviou as secrets atacante, que as utilizou para aceder às suas contas. Pouco tempo depois, um atacante Comecei a pesquisar no GitHub especificamente para repositórios com pull_request_target ativou e abriu algumas centenas de PRs em cerca de um dia.
2. Evite utilizar o `workflow_run` em repositórios públicos
workflow_run permite encadear fluxos de trabalho, de modo que um fluxo de trabalho a jusante seja acionado quando um a montante for concluído. O problema é que o fluxo de trabalho a jusante é executado com permissões de gravação e acesso a segredos, independentemente do que tenha acionado o fluxo de trabalho a montante, incluindo um PR de bifurcação de um colaborador externo.
Se um fornecedor solicitação de pull O fluxo de trabalho está vulnerável à injeção de scripts; um atacante pode corromper o artefacto de saída através de um PR. O fluxo de trabalho a jusante consome então conteúdo controlado pelo atacante num contexto privilegiado com acesso a segredos, pelo que o conteúdo controlado pelo atacante proveniente de um PR não confiável chegou agora a um fluxo de trabalho com acesso a segredos através de um passo adicional. O caminho do ataque é mais longo do que pull_request_target mas chega ao mesmo sítio.
A melhor solução é evitar esse padrão. Se uma implementação só precisa de ser efetuada quando há envios para o branch «main», acione-a diretamente com um envio para o «main», em vez de a encadear através de workflow_run. Se realmente precisares workflow_run, verifique github.event.workflow_run.event antes de realizar qualquer ação com privilégios. Se o gatilho a montante foi um solicitação de pull em vez de esperar por uma indicação de um mantenedor, é melhor desistir antes de implementar ou escrever qualquer coisa.
tarefas:
implementar:
se: github.event.workflow_run.event == 'push'
zizmor irá sinalizar workflow_run fluxos de trabalho que executam ações com privilégios sem a verificação de eventos, se pretender uma deteção automatizada em todo o seu conjunto de repositórios.
3. Auditar fluxos de trabalho utilizando outros gatilhos privilegiados
Além de pull_request_target e workflow_run, tenha cuidado com outros gatilhos que são executados com acesso a secrets. Estes incluem comentar_publicação, questões, revisão de pull request, e comentário_de_revisão_de_pull_request. Como todos eles são executados com acesso secreto, podem ser afetados por intervenções externas. Aplicam-se as mesmas regras de injeção de scripts, ou seja, nunca se deve interpolar valores destes eventos diretamente em executar: passos. Abordamos este assunto mais detalhadamente na secção seguinte.
Tratamento de entradas não confiáveis
1. Evitar a injeção de scripts, tratando todos os nomes de ramos, títulos de PR, mensagens de commit e corpos de issues como entradas não confiáveis
Este é o mesmo princípio da injeção de SQL. Os valores controlados pelo utilizador que acabam por ser incluídos num comando shell são interpretados como código, e não como dados; por isso, nunca se deve interpolar github.* valores diretamente em executar: passos. A solução consiste em atribuir primeiro o valor a uma variável de ambiente e, em seguida, referenciar essa variável no script do shell:
# vulnerable
- run: echo "Branch is ${{ github.head_ref }}"
# safe
- run: echo "Branch is $BRANCH"
env:
BRANCH: ${{ github.head_ref }}
Quando o valor é atribuído a uma variável de ambiente, o shell lê-o como uma cadeia de caracteres em tempo de execução, em vez de o interpretar como sintaxe na fase de análise. Isto aplica-se a qualquer elemento proveniente de entradas controladas pelo utilizador: github.head_ref, github.event.pull_request.title, github.event.issue.body, github.event.commits[0].message, e valores de contexto semelhantes. Um bom SAST , como Aikido detetar isto e fornecer a correção numa solicitação de integração.
Na natureza: Na Ataque da Ultralytics, um atacante nomeou um ramo com um comando curl que um fluxo de trabalho inseriu diretamente num executar: passo, executando-o como código. O Ataque Nx/s1ngularity, detetado inicialmente pela Aikido , combinou isto com pull_request_target, onde um PR para um ramo desatualizado ativou um fluxo de trabalho vulnerável que causou uma fuga de GITHUB_TOKEN com permissões de leitura e escrita, que foi posteriormente utilizado para publicar pacotes npm maliciosos.
2. No caso de agentes de IA em fluxos de trabalho personalizados, utilize tokens de leitura exclusiva e evite incluir dados brutos introduzidos pelo utilizador nos prompts
Os agentes de IA executados nos fluxos de trabalho do GitHub Actions têm o mesmo acesso a segredos que qualquer outra etapa. Se um agente processar títulos de issues, descrições de PR ou mensagens de commit como parte do seu prompt, um invasor pode inserir instruções nesse texto e manipular o agente para que este execute ações privilegiadas, como modificar ficheiros ou extrair dados através de quaisquer ferramentas às quais tenha acesso. Como não há forma de impedir a injeção de prompts em LLMs, não permita que os agentes de IA tenham acesso além da leitura e não permita que recebam títulos de issues, descrições de PR ou mensagens de commit em formato bruto como entrada de prompt.
Na prática: Aikido demonstraram isto com PromptPwnd: um título de issue malicioso introduzido num fluxo de trabalho da CLI do Gemini levou o agente a escrever secrets do repositório secrets tópico público de issue utilizando o seu próprio gh acesso à ferramenta.
3. Tratar os resultados gerados por modelos de linguagem de grande escala (LLM) como dados de entrada não confiáveis
Quando um fluxo de trabalho utiliza um LLM para gerar um comando, um script ou um caminho de ficheiro e passa esse resultado diretamente para um executar: Desta forma, cria o mesmo risco de injeção que a interpolação de um nome de ramificação ou do título de um PR. Não é garantido que a saída do LLM seja segura, e um atacante capaz de influenciar o prompt pode influenciar o que é executado. Tal como discutimos no ponto anterior sobre a injeção de prompts, atribua primeiro a saída do LLM a uma variável de ambiente, valide-a sempre que possível e nunca a encaminhe diretamente para um comando de shell.
4. Nunca grave dados não confiáveis em GITHUB_ENV ou GITHUB_PATH
Escrevendo para GITHUB_ENV define variáveis de ambiente para todas as etapas subsequentes do trabalho. Escrever em GITHUB_PATH acrescenta entradas ao PATH do sistema para todas as etapas seguintes. Se conteúdo não confiável chegar a qualquer um desses ficheiros, um invasor pode definir variáveis de ambiente arbitrárias, como OPÇÕES_DO_NÓ que desencadeiam a execução de código. Também poderiam injetar um ficheiro binário de malware no início do PATH, que seria chamado em vez de uma ferramenta de confiança. O padrão vulnerável consiste num fluxo de trabalho que descarrega um artefacto ou lê dados introduzidos pelo utilizador e os grava diretamente em $GITHUB_ENV sem sanitização. Trate tudo o que for gravado nestes ficheiros com a mesma cautela que um executar: passo.
Manuseamento de artefactos
5. Extraia os ficheiros para um diretório temporário, como /tmp em vez da área de trabalho, para evitar a substituição de ficheiros do fluxo de trabalho
A extração de um arquivo diretamente para a área de trabalho pode permitir que um arquivo com conteúdo malicioso substitua ficheiros de fluxo de trabalho, scripts ou ferramentas dos quais as etapas seguintes dependem. Extrair para /tmp ou um diretório isolado mantém o conteúdo dos artefactos separado de tudo o que o seu fluxo de trabalho considera confiável. O GitHub também suporta a verificação de resumos SHA256 se precisar de garantias de integridade mais sólidas.
6. Excluir ficheiros confidenciais (.env, ficheiros de configuração, credenciais) dos artefactos carregados e evitar caminho: . tendências que arrasam com tudo
O caminho: . padrão num ações/carregar-artefacto O comando «step» carrega tudo o que se encontra no diretório de trabalho, o que pode incluir .env ficheiros, ficheiros de configuração com credenciais incorporadas ou secrets armazenados em cache secrets no disco por outras etapas. Seja explícito quanto ao que está a carregar, para não publicar acidentalmente as suas credenciais na Internet. Indique diretórios ou tipos de ficheiros específicos, em vez de incluir todo o espaço de trabalho, e adicione .env, *.pem, e ficheiros semelhantes para o seu .gitignore e padrões de exclusão de artefactos.
Referências de ação mutáveis
7. Associe todas as ações de terceiros a um SHA de commit completo, e não a uma etiqueta ou a um ramo
As etiquetas são úteis como forma de abreviar, mas a desvantagem é que não são estáticas. As etiquetas e os ramos são mutáveis, o que significa que o proprietário do repositório pode redirecioná-los para um commit diferente a qualquer momento, e isso é esperado com etiquetas como @main. Ao referir-se a uma versão específica com utiliza: some-action@v3, esperamos que o commit permaneça o mesmo. No entanto, se a conta do responsável pela ação for comprometida, um invasor pode redirecionar essa tag para um commit malicioso e todos os fluxos de trabalho a jusante irão incorporá-lo na próxima execução, sem um PR ou qualquer outra indicação. Para evitar isso, a melhor prática é fixar a tag no SHA completo do commit: utiliza: some-action@abc123def456..... É claro que isto pode ser um pouco incómodo de gerir, por isso pode usar Dependabot, o Renovate ou o pinact para manter os SHA fixados atualizados. Os ficheiros de bloqueio nativos fazem parte do roteiro do GHA, pelo que esperamos que estejam disponíveis até 2027.
Na prática: Em março de 2025, os atacantes redirecionaram 76 das 77 etiquetas de versão em trivy a commits maliciosos que continham um programa de roubo de dados. Todos os fluxos de trabalho que referenciavam essas etiquetas pelo nome incluíam automaticamente o código malicioso.
8. Analisar as ações de terceiros antes da adoção
Antes de adicionar um utilizações: Dedique dois minutos a analisar o repositório da ação. Verifique se o criador é verificado pelo GitHub, quando foi a última vez que o repositório foi atualizado, quantos colaboradores tem e qual é a sua pontuação no OpenSSF Scorecard. Uma ação amplamente utilizada, criada por um único mantenedor não verificado e sem atividade recente, constitui um alvo de alto risco para a apropriação de contas.
9. Dê preferência a ações com menos dependências transitivas
Quanto mais dependências houver, maior será a sua vulnerabilidade a ataques à Supply chain; por isso, opte por ações com menos dependências sempre que houver alternativas. Uma ação pode, por sua vez, fazer referência a outras ações, e essas dependências transitivas são resolvidas em tempo de execução. Fixar a SHA da sua dependência direta não o protege se esta incluir as suas próprias dependências de forma mutável.
Na natureza: O Ações de tj comprometem propagadas em parte através deste mecanismo. Os fluxos de trabalho a jusante associados a tj-actions/changed-files, mas ficheiros alterados referenciado transitivamente reviewdog/action-setup devido a uma falha de segurança, pelo que, quando o Reviewdog foi comprometido, todos os pipelines a jusante executaram o código malicioso.
Dependências mutáveis de pacotes
10. Definir explicitamente as versões dos pacotes do npm e do PyPI
As gamas de versões flutuantes, como ^1.2.0 ou >=2.0.0 significa que o seu fluxo de trabalho instala a versão mais recente compatível no momento da execução. Se um pacote for comprometido e for publicada uma nova versão maliciosa dentro do seu intervalo, o seu fluxo de trabalho irá descarregá-la automaticamente na próxima execução. Fixar a versões exatas (1.2.3) para que o seu fluxo de trabalho instale apenas o que escolheu explicitamente. Não utilize a opção «flutuar no intervalo».
Na natureza: O ataque da Ultralytics demonstrou como uma versão de pacote comprometida publicada no PyPI pode chegar a fluxos de trabalho que não estão fixados. A primeira versão maliciosa esteve ativa durante horas antes de ser detetada, tempo suficiente para afetar compilações que utilizam dependências flutuantes.
11. Defina uma idade mínima de lançamento, caso o seu gestor de pacotes o suporte (pnpm, yarn)
Mesmo com versões fixadas, um pacote malicioso recém-publicado pode corresponder exatamente à versão para a qual mais tarde decida atualizar. As definições de idade mínima de lançamento indicam ao seu gestor de pacotes para recusar pacotes publicados há menos do que um período de tempo especificado, normalmente 72 horas, dando tempo à comunidade para detetar e comunicar lançamentos maliciosos antes de estes chegarem às suas compilações. O pnpm e o yarn suportam esta funcionalidade de forma nativa, mas o npm ainda não. Aikido Chain pode resolver esta questão para o npm (ver abaixo).
12. Verificar a proveniência do pacote utilizando certificados, sempre que disponíveis
Alguns registos de pacotes já suportam atestados de proveniência, que consistem em registos criptográficos que associam um pacote publicado ao commit de código-fonte específico e ao pipeline de compilação que o produziu. A verificação desses atestados antes da instalação de um pacote confirma que este foi compilado a partir do código-fonte que alega. O npm suporta esta funcionalidade para pacotes publicados através do GitHub Actions. Trata-se ainda de uma prática recente e o suporte das ferramentas não está totalmente disponível, mas vale a pena ativá-la sempre que o seu registo e gestor de pacotes a suportarem.
Secrets
13. Indique secrets variáveis de ambiente, nunca através de argumentos da linha de comandos
Os argumentos da linha de comando são visíveis nas listas de processos, pelo que outros processos no executor com acesso a /proc pode lê-los. Passar um segredo como variável de ambiente mantém-no fora da tabela de processos. No seu fluxo de trabalho, defina o segredo numa env: bloco e referência $SECRET_NAME no comando do shell, em vez de ${{ secrets.MY_SECRET }} em linha.
Na prática: o tj-actions divulgou secrets imprimi-los no registo (o problema do echo/mascaramento), e o Trivy resultou no roubo de um PAT. Secrets consiste em limitar o acesso aos secrets o sistema, de modo a que, caso algo corra mal, um atacante não consiga obter credenciais válidas.
14. Limite secrets nível do repositório a ambientes específicos do GitHub, sempre que possível
Os ambientes do GitHub permitem-lhe restringir o acesso secrets regras de proteção de implementação, pelo que um segredo como PROD_DB_PASSWORD está disponível apenas para fluxos de trabalho destinados ao ambiente de produção. Sem esta configuração, qualquer fluxo de trabalho no repositório pode aceder a qualquer segredo ao nível do repositório. Pode configurar esta opção em «Configurações > Ambientes».
15. Defina secrets fluxo de trabalho ao nível das etapas, e não ao nível das tarefas
A delimitação secrets etapas individuais de uma tarefa que deles necessita aplica o princípio do privilégio mínimo para limitar o alcance dos danos caso uma ação seja comprometida. Um segredo declarado ao nível da tarefa env: O bloco é legível por todas as etapas desse trabalho, incluindo ações de terceiros.
Na natureza: No ataque Shai-Hulud, os tokens com âmbito de fluxo de trabalho foram reutilizados entre as vítimas. Um âmbito mais restrito teria contido o raio de ação.
16. Utilize o OIDC para obter credenciais de curta duração na nuvem, em vez de secrets estáticos de longa duração, secrets o fornecedor de serviços na nuvem o suporte (AWS, Azure, GCP)
As credenciais estáticas na nuvem armazenadas como secrets do GitHub secrets validade ilimitada; por isso, se forem roubadas, o risco de danos é muito elevado. O OIDC permite que o seu fluxo de trabalho solicite diretamente um token de curta duração à AWS, Azure ou GCP, limitado ao âmbito da tarefa e válido por alguns minutos, pelo que não existem credenciais que um invasor possa roubar. A AWS, o Azure e o GCP suportam todos isto de forma nativa. A implementação deste processo envolve a configuração de uma relação de confiança entre o seu fornecedor de serviços na nuvem e o ponto de extremidade OIDC do GitHub.
17. Exigir aprovação humana nas execuções de fluxos de trabalho que utilizam ambientes de produção
Configure o seu ambiente GitHub para exigir que alguém revise um fluxo de trabalho antes que este possa aceder secrets de um ambiente secrets efetuar uma implementação nesse ambiente. Esta abordagem é mais adequada para equipas mais pequenas ou para aquelas que realizam implementações com pouca frequência. Para equipas maiores, a versão mais escalável desta abordagem é o OIDC com credenciais de curta duração.
18. Evite imprimir ou exibir valores confidenciais, mesmo na saída de depuração
O GitHub oculta valores secretos conhecidos nos registos, mas apenas no caso de correspondências exatas; por isso, se um segredo for codificado em base64 ou dividido em duas chamadas de `echo`, a ocultação não funciona. A regra mais segura é simplesmente nunca exibir secrets . Se precisar de verificar se um segredo está definido, verifique se existe uma cadeia de caracteres não vazia, em vez de imprimir o valor.
Corredores
19. Não utilize executores auto-hospedados em repositórios públicos
Qualquer pessoa pode abrir um PR num repositório público, o que significa que qualquer pessoa pode, potencialmente, acionar a execução de um fluxo de trabalho. As definições de aprovação predefinidas do GitHub para colaboradores de primeira vez mitigam este risco nos executores hospedados pelo GitHub, onde o ambiente é, de qualquer forma, efémero e isolado. Num executor auto-hospedado, uma configuração de aprovação mal definida ou excessivamente permissiva significa que esse mesmo PR desencadeia a execução de código na sua infraestrutura. O GitHub recomenda a utilização de executores hospedados pelo GitHub para repositórios públicos e o reforço da política de aprovação para «exigir aprovação para todos os colaboradores externos».
Na prática: Os investigadores realizaram um ataque à cadeia de abastecimento no PyTorch ao submeterem um PR trivial que desencadeou um fluxo de trabalho num executor auto-hospedado, obtendo acesso de root à máquina.
20. Utilize processos temporários em vez de processos estáticos e persistentes
Um executor estático mantém o estado entre tarefas, o que significa que uma tarefa comprometida pode deixar ficheiros maliciosos, binários modificados ou caches corrompidos que afetam as execuções seguintes nessa máquina. Os executores efémeros iniciam-se com um estado limpo e são eliminados após cada tarefa. Utilize o Actions Runner Controller para configurações baseadas em Kubernetes ou passe o --efémero sinalizar ao registar um corredor manualmente.
Na natureza: Shai-Hulud registou executáveis auto-hospedados persistentes em repositórios comprometidos e utilizou-os como um canal C2 persistente, invisível à monitorização da rede, uma vez que todo o tráfego passava pelo github.com.
21. Restringir a saída da rede do executor a uma lista de permissões
A ação mais perigosa de um fluxo de trabalho comprometido consiste, muitas vezes, na exfiltração secrets um servidor controlado pelo atacante. Restringir o acesso de rede de saída apenas aos domínios de que o seu fluxo de trabalho realmente necessita torna isso significativamente mais difícil. O Harden-Runner e o bullfrog funcionam ambos em executores alojados no GitHub. No caso de executores auto-alojados, as regras de firewall ao nível da rede cumprem o mesmo objetivo.
Se estiver a utilizar o GitHub Enterprise com executores auto-hospedados, as listas de IPs autorizados para tokens proporcionam um controlo na direção oposta. Estas listas restringem os IPs que podem utilizar um token, impedindo assim que um token roubado seja utilizado a partir da infraestrutura de um atacante.
Permissões do token
22. Definir como padrão GITHUB_TOKEN permissões de leitura apenas no nível da organização ou do repositório
O GITHUB_TOKEN está automaticamente disponível em todas as execuções do fluxo de trabalho. Por predefinição, dispõe de amplos direitos de leitura e escrita em todo o repositório, pelo que qualquer fluxo de trabalho comprometido pode escrever no seu repositório, criar versões ou aprovar PRs. Defina a predefinição como «apenas leitura» em «Definições > Ações > Geral» e, em seguida, conceda permissões de escrita explicitamente apenas quando necessário.
23. Declarar explicitamente permissões: restrições ao nível do fluxo de trabalho ou da tarefa para limitar tarefas individuais
Definir uma configuração padrão de «somente leitura» ao nível da organização cria essa configuração padrão, mas é claro que algumas tarefas necessitam de mais permissões. Quando uma tarefa necessitar de acesso com privilégios elevados, declare um permissões: bloquear ao nível da tarefa, em vez de ao nível do fluxo de trabalho. Dessa forma, o token com privilégios elevados fica restrito apenas a essa tarefa, e todas as outras tarefas do fluxo de trabalho permanecem em modo de leitura.
tarefas:
implementação:
permissões:
conteúdos: leitura
token de identificação: gravaçãoNa prática: os ataques tj-actions, Trivy e prt-scan beneficiaram-se todos do facto de os tokens terem mais acesso do que o necessário. O reforço das permissões dos tokens reduz o alcance dos danos em geral.
Definições da organização e do repositório
24. Desativar a possibilidade de as Ações aprovarem PRs
Por predefinição, o GitHub permite que os fluxos de trabalho aprovem pedidos de integração utilizando o GITHUB_TOKEN. Isto significa que um fluxo de trabalho comprometido poderia aprovar as suas próprias alterações maliciosas sem passar por qualquer processo de revisão. Desative esta opção em Configurações > Ações > Geral > «Permitir que o GitHub Actions crie e aprove pull requests». (Algumas equipas mantêm esta opção ativada para Dependabot , mas é preferível atribuir Dependabot conta de bot dedicada com permissões explícitas de revisor, em vez de ativar a aprovação do fluxo de trabalho para toda a organização.)
25. Limitar as fontes de ação a criadores verificados ou repositórios específicos
A configuração predefinida no GitHub permite que qualquer ação publicada no GitHub Marketplace seja utilizada nos seus fluxos de trabalho. Restringir as fontes a criadores verificados ou a uma lista de permissões específica significa que uma ação maliciosa recém-publicada não pode ser adotada nos seus fluxos de trabalho sem aprovação explícita. Em vez disso, os programadores devem solicitar aprovação a quem detém as definições da sua organização no GitHub (normalmente a plataforma ou a equipa de DevOps), que pode adicioná-la à lista de permissões. Configure isto em Definições > Ações > Geral > «Permitir ações e fluxos de trabalho reutilizáveis».
Na prática: As vulnerabilidade tj-actions afetou 23 000 repositórios, em parte porque as equipas não tinham restrições quanto às ações que podiam incorporar.
26. Monitorize registos inesperados de runners auto-hospedados e repositórios públicos recém-criados na sua organização
Um token roubado permite que um invasor registe um executor malicioso para instalar uma porta traseira persistente. Os invasores também costumam criar repositórios públicos para descarregar credenciais roubadas. Tanto o registo de executores como a criação de repositórios são eventos que a sua equipa precisa de ver imediatamente, mas o GitHub não emite alertas sobre eles por predefinição. A solução alternativa é monitorizar isso manualmente. Transmita o registo de auditoria da sua organização para um SIEM e configure alertas para self_hosted_runners.register eventos e criação de repositórios. Sem um SIEM, pode consultar o registo de auditoria através da API do GitHub ou verificar manualmente em Configurações > Registo de auditoria.
Na prática: No ataque Shai-Hulud, as máquinas comprometidas foram registadas como executores auto-hospedados denominados SHA1HULUD, e as credenciais roubadas foram utilizadas para criar repositórios públicos usados como depósitos de exfiltração. A monitorização de ambos teria alertado para a campanha numa fase inicial.
27. Utilize CODEOWNERS para exigir uma revisão com foco na segurança para alterações em .github/workflows/
Os ficheiros de fluxo de trabalho são código que é executado com acesso aos seus secrets tokens. Sem regras explícitas de propriedade, qualquer programador com acesso de escrita ao repositório pode modificar um fluxo de trabalho e integrá-lo sem uma revisão de segurança. Adicione uma entrada CODEOWNERS indicando .github/workflows/ a um revisor ou equipa que compreenda as questões de segurança e combiná-lo com regras de proteção do ramo que exijam a aprovação dos CODEOWNERS antes da fusão.
Proteja os fluxos de trabalho do GitHub Actions com Aikido
Aikido deteta fluxos de trabalho inseguros do GitHub Actions e ajuda os programadores a corrigi-los antes que sejam explorados.
Deteta problemas como:
- Utilização insegura de
pull_request_target - Injeção de código através de fontes não confiáveis
github.*entrada - Injeção de modelos e prompts em fluxos de trabalho baseados em IA
- Ações de terceiros não fixadas
- Excessivamente privilegiado
GITHUB_TOKENpermissões - Gestão de riscos na gestão de informações confidenciais nos fluxos de trabalho
Aikido também Aikido :
- Criar automaticamente PRs de correção
- Detetar padrões de fluxo de trabalho inseguros em todos os repositórios
- Assinalar referências mutáveis de GitHub Actions que devem ser fixadas a um SHA de commit completo
A correnteAikido ajuda a proteger as instalações de pacotes ao:
- Bloquear pacotes maliciosos conhecidos do npm e do PyPI
- Aplicação das políticas relativas à idade mínima para a compra de pacotes
Por exemplo, Aikido entradas de utilizador não sanitizadas em executar: segue esses passos e sugere automaticamente o padrão de variável de ambiente mais seguro.
Pronto para proteger os fluxos de trabalho do GitHub Actions
Mantenha esta lista de verificação à mão enquanto trabalha na segurança dos fluxos de trabalho do GitHub Actions. Tente implementar rapidamente as medidas que puder e que demorem apenas alguns minutos, e partilhe-a com os seus colegas de equipa para que todos estejam a par das alterações.
Perguntas frequentes: Segurança do GitHub Actions
Qual é a forma mais comum de os fluxos de trabalho do GitHub Actions serem explorados?
A injeção de scripts é o vetor mais frequente. Os atacantes inserem código malicioso nos nomes das ramificações, nos títulos dos PR ou no corpo das issues, e os fluxos de trabalho que interpolam esses valores diretamente em executar: executá-las como comandos do shell. Fixar ações para confirmar SHA e utilizar variáveis de ambiente em vez de interpolação inline elimina grande parte desse risco.
O que é pull_request_target e por que é que isso é perigoso?
pull_request_target é um gatilho de fluxo de trabalho que é executado com acesso aos secrets do repositório base, mesmo quando o PR que o aciona provém de um fork. Como qualquer pessoa pode abrir um PR num repositório público, qualquer fluxo de trabalho que utilize este gatilho expõe secrets seus secrets colaboradores externos. Evite-o completamente em repositórios públicos.
O que significa «associar ações a um SHA de commit» e por que é que isso é importante?
A maioria dos fluxos de trabalho faz referência a ações de terceiros por meio de etiquetas, como utiliza: some-action@v3. As etiquetas são mutáveis, pelo que, se a conta de um responsável por uma ação for comprometida, um invasor pode redirecionar essa etiqueta para código malicioso sem que ninguém se aperceba. Fixar a uma SHA de commit completa, como utiliza: some-action@abc123... significa que o seu fluxo de trabalho executa sempre e apenas o que você revisou.
Devo utilizar runners auto-hospedados em repositórios públicos?
Não. Qualquer pessoa pode abrir um PR num repositório público e acionar um fluxo de trabalho. Nos runners hospedados no GitHub, isso é controlável porque o ambiente é efémero e isolado. Num runner auto-hospedado, uma política de aprovação mal configurada significa que os colaboradores externos podem executar código diretamente na sua infraestrutura.
O que é o OIDC e por que é que é melhor do que guardar credenciais na nuvem como secrets?
As credenciais estáticasarmazenadas como secrets do GitHub secrets válidas por tempo indeterminado, pelo que um segredo roubado continua a representar um risco muito tempo depois da violação. O OIDC permite que o seu fluxo de trabalho solicite um token de curta duração à AWS, ao Azure ou ao GCP, limitado a essa tarefa específica e válido por alguns minutos. Não há credenciais de longa duração que possam ser roubadas.
