Cache de CI existe para acelerar pipelines, mas também cria um ponto de confiança entre execuções. Um build salva dependências, ferramentas ou artefatos intermediários; outro build restaura aquilo e segue trabalhando. Quando todos os gatilhos são confiáveis, isso parece apenas otimização. Quando um workflow pode ser influenciado por alguém sem permissão de escrita, o cache passa a ser uma fronteira de segurança.
O GitHub reforçou esse ponto em 26 de junho ao anunciar cache read-only para gatilhos não confiáveis no GitHub Actions. A mudança reduz o risco de cache poisoning: um workflow acionado por entrada externa grava conteúdo malicioso no cache do branch padrão, e um workflow mais privilegiado restaura esse conteúdo depois, já com acesso a segredos ou permissões maiores.
A documentação de dependency caching do GitHub Actions também traz um aviso direto: não coloque tokens, credenciais ou dados sensíveis no caminho salvo em cache. Quem tem capacidade de abrir pull request pode conseguir acesso indireto ao conteúdo restaurado em determinados cenários. Essa regra vale para além do GitHub; qualquer CI que compartilha cache entre contextos diferentes precisa tratar o cache como artefato de confiança limitada.
Neste artigo
Cache não é armazenamento neutro
Um erro comum é pensar que cache de CI é só uma pasta temporária. Ele pode carregar binários, dependências compiladas, scripts gerados, pacotes baixados, índices e arquivos de configuração. Se o pipeline confia cegamente no que veio do cache, alguém que consegue gravar ali pode alterar comportamento de builds futuros.
O risco cresce quando o cache é compartilhado entre branches, forks, comentários, schedules e releases. Gatilhos diferentes têm níveis diferentes de confiança. Um push no branch principal feito por colaborador autenticado não tem o mesmo perfil de risco de um pull_request_target, de um comentário em issue ou de um workflow encadeado a partir de código externo.
Separar restore de save reduz superfície
Em muitos casos, workflow de baixa confiança só precisa restaurar cache para economizar tempo. Ele não precisa salvar cache novo. Essa distinção parece pequena, mas muda o modelo de ameaça. Restaurar conteúdo mantido por um workflow confiável é uma coisa; permitir que um workflow de entrada externa substitua esse conteúdo é outra.
No GitHub Actions, o novo comportamento dá acesso read-only a alguns gatilhos não confiáveis no escopo do branch padrão. A documentação também descreve cache-mode, que permite controlar leitura, escrita, escrita isolada ou nenhum acesso. O uso de escrita explícita em um gatilho de baixa confiança deve ser exceção justificada, porque reabre o caminho que o padrão seguro tenta fechar.
Quando cache vira sinal de arquitetura ruim
Cache também pode esconder fragilidade. Se o pipeline só roda rápido quando restaura uma pasta enorme, talvez a instalação esteja pesada demais. Se o build depende de um cache que ninguém sabe reconstruir, ele deixou de ser otimização e virou dependência operacional. Se uma falha de cache derruba release, a equipe precisa rever o que está sendo salvo e por quê.
O post sobre GitHub Actions e controle de disparo ajuda a olhar o outro lado da mesma fronteira: quem pode acionar o workflow. Cache seguro depende de duas perguntas juntas. Quem pode disparar esta execução? Esta execução pode gravar algo que uma execução mais privilegiada vai consumir depois?
Critérios práticos para revisar pipelines
Comece listando quais workflows salvam cache e quais apenas restauram. Depois marque o gatilho de cada workflow, o branch ou escopo usado, o caminho salvo, a chave de cache e se há segredos disponíveis na mesma execução. Essa matriz costuma mostrar rapidamente onde há mistura perigosa.
Dependências baixadas de registries públicos podem ir para cache quando a chave é reprodutível e o workflow não aceita gravação de contexto externo. Artefatos de build usados dentro da mesma execução podem ser melhores como artifacts do que como cache, porque cache foi feito para reuso entre execuções. Arquivos com token, chave privada, configuração de acesso ou sessão autenticada não devem entrar em nenhum dos dois sem criptografia, expiração e motivo forte.
Um desenho mais seguro
Um padrão simples é deixar workflows confiáveis alimentarem cache no branch principal e workflows de menor confiança apenas restaurarem esse cache. Quando a execução precisa processar código externo, reduza permissões, evite segredos, use restore-only e trate tudo que vem do workspace como entrada não confiável. Quando um release precisa de credenciais, ele não deveria restaurar cache escrito por um fluxo que recebeu contribuição externa.
Cache de CI continua sendo uma das melhores formas de acelerar builds, principalmente em projetos com dependências pesadas. O ganho, porém, precisa vir com fronteiras claras: quem escreve, quem lê, em qual escopo, com quais permissões e com qual plano de reconstrução. Pipeline rápido que carrega confiança indevida só antecipa o problema para uma etapa mais sensível.
