Comprometimento do TJ Actions: autoridade de execução e divulgação em logs

Visão Geral do Incidente

Tier A (confirmed): Entre 14 e 15 de março de 2025, tags de versão de changed-files foram redirecionadas para código malicioso que extraía segredos do executor para logs de workflows. O mantenedor identifica a versão 46.0.0 como corrigida. Aviso do mantenedor.

Tier A (confirmed): A StepSecurity registra confirmação às 17:00 UTC de 14 de março, remoção do repositório às 14:00 UTC de 15 de março e restauração às 22:00 UTC. São marcos da investigação, não um intervalo de exposição medido para cada consumidor. Investigação.

Tier C (unknown): Execuções por organização, reutilização de credenciais e perdas posteriores exigem telemetria privada. Esta análise arquitetural é retrospectiva; a data de publicação não é a data do incidente.

Tier B (inferred), premissa delimitada: o modelo de isolamento aplica-se a jobs que executam código de terceiros; a exposição de chaves de entrega depende de credenciais alcançáveis nesse contexto de execução.

Mapeamento da Superfície de Falha

Defina S = {C, N, K, I, O}: plano de controle, camada de rede, ciclo de vida de chaves, fronteira de identidade e orquestração operacional. Tier B (inferred): o mecanismo dominante é o vazamento de privilégios de CI/CD pela admissão de dependências executáveis e pelo acesso compartilhado a credenciais.

| Camada | Classe de falha e fronteira | | --- | --- | | C | Referência de dependência bizantina; autoridade externa de versão influencia execução local | | N | Obtenção de payload e transporte de logs; não exige indisponibilidade de rede | | K | Divulgação exige revogação; a completude da rotação é desconhecida | | I | Execução da ação alcança autoridade além da comparação de arquivos | | O | Omissão de admissão/isolamento permite propagação; o tempo de detecção prolonga exposição |

Falha por parada não é necessária neste modelo. Bizantina descreve comportamento malicioso de um componente, não comprometimento do consenso da plataforma.

Modelagem Formal de Falhas

Tier B (inferred): S_t = (E_t, A_t, K_t, L_t) representa digests executáveis admitidos, digests aprovados, credenciais acessíveis e conteúdo dos logs. T(S_t) resolve dependências, executa código e persiste a saída. R(E_t) representa o alcance de credenciais; K_release é o conjunto de credenciais de entrega.

I(S_t):\quad E_t \subseteq A_t \quad\land\quad R(E_t)\cap K_{\mathrm{release}}=\varnothing

O invariante proposto exige conteúdo executável aprovado e ausência de acesso a chaves de entrega pelo código de análise. Uma tag movida pode admitir um digest não aprovado; autoridade compartilhada pode violar a segunda cláusula. Não se afirma que todo consumidor afetado possuía chaves de entrega. A admissão deve rejeitar digests desconhecidos antes da execução. A aprovação deve abranger código transitivo e downloads em execução; fixar apenas o componente externo é insuficiente.

Modelo de Exploração Adversária

Tier B (inferred): A_supply_chain altera código executável upstream; A_passive lê logs acessíveis; A_active usa uma credencial exposta ainda válida; A_internal abusa do acesso existente a logs ou executores; A_economic busca valor na autoridade sobre entregas ou artefatos. Somente a cadeia de suprimentos e a divulgação estão sustentadas pelo incidente; as demais classes são extensões condicionais.

X = \Delta t \times W \times P_s

Δt é o tempo entre a primeira exposição e a invalidação efetiva, W conta domínios de confiança alcançáveis e P_s é uma pontuação de privilégio normalizada localmente. X prioriza resposta; não estima probabilidade de invasão nem perda monetária. Compare apenas sob a mesma escala. Reduza primeiro a latência de invalidação das credenciais que atravessam fronteiras de produção. Ausência de horários de detecção exige um intervalo, não um valor pontual inventado.

Fragilidade Arquitetural Raiz

Tier B (inferred): a fragilidade estrutural é a compressão de confiança: um utilitário de comparação herda o contexto de execução de um job com credenciais. Rótulos de versão expressam intenção de seleção, mas não estabelecem conteúdo revisado imutável. Logs criam outra fronteira, da execução transitória para retenção com leitores potencialmente numerosos.

O GitHub recomenda fixação em commits completos e tokens com privilégio mínimo. Esses controles reduzem riscos distintos; nenhum prova que o código escolhido seja benigno. Orientação da plataforma. Um digest malicioso fixado continua malicioso. Uma etapa posterior no mesmo executor comprometido não constitui fronteira independente de entrega.

Reconstrução em Nível de Código

Tier B (inferred): o fluxo vulnerável é referência mutável -> execução privilegiada -> acesso a credenciais -> saída retida. O desenho abaixo propõe admissão e promoção; não é código recuperado do incidente. Funções de política devem negar em caso de falha e operar sob administração independente do workflow submetido.

# Policy pseudocode; enforcement lives outside the workflow checkout.
admit(job, policy):
    closure = resolve_transitive_code(job, network_fetches="deny")
    require closure.complete
    require every_digest(closure) in policy.reviewed_digests
    require no_digest(closure) in policy.revoked_digests
    require job.runner.is_ephemeral and job.runner.has_no_host_credentials
    require job.permissions <= policy.analysis_permissions
    require job.release_secrets == empty
    require job.oidc_token_minting == disabled
    return isolated_run(job, timeout=policy.max_runtime,
                        egress=policy.analysis_allowlist)

promote(artifact, evidence, approval):
    require verify_digest_and_provenance(artifact, evidence)
    require evidence.builder in policy.release_builders
    require approval.binds(artifact.digest, policy.version)
    # A signature alone does not establish that a build was trustworthy.
    require independent_release_checks(artifact)
    return isolated_deploy(artifact, credential_ttl=policy.release_ttl)

O executor de análise não deve executar código de implantação após a emissão de credenciais. Artefatos permanecem não confiáveis até passarem pelas verificações de entrega. Comparações de reprodutibilidade exigem construtores independentes e toolchain definida; saídas iguais não comprovam segurança do código-fonte.

Análise de Impacto Operacional

Tier B (inferred): um nó corresponde a uma execução distinta de job em um executor dentro de uma janela fixa de revisão, não à instalação em um repositório.

B = \frac{\text{affected\_nodes}}{\text{total\_nodes}}

Conte execuções do digest malicioso no numerador e todas as execuções no escopo no denominador. Tier C (unknown): nenhuma população está disponível aqui; não se justifica um B numérico. Adoção não substitui exposição por execução.

A exposição de credenciais exige inventário separado por identidade, intervalo de validade e escopo de recursos. Efeitos sobre latência e vazão dependem da política de suspensão e reconstrução, não apenas da divulgação. Para capacidade, a fila Q escoa em Q/(μ−λ) somente quando a taxa de serviço após recuperação μ supera a chegada λ; caso contrário, restrinja admissão. A perda financeira permanece indeterminada.

Camada de Tradução Empresarial

Tier B (inferred), decisões propostas:

CTO: exigir fronteira documentada entre análise e implantação; bloquear entregas com proveniência executável não resolvida.
CISO: inventariar credenciais alcançáveis, revogá-las e verificar invalidação com evidência do emissor. Remover logs não invalida segredos copiados.
DevSecOps: impor política de digests fora do controle do repositório, reconstruir em executores limpos e medir o tempo entre exposição e revogação.
Conselho: exigir evidência de cobertura da contenção e aceitação explícita do escopo de credenciais não resolvido antes de restabelecer autoridade de entrega de alto impacto.

Modelo STIGNING de Hardening

Tier B (inferred), controles propostos: isolar administração de políticas dos mantenedores de workflows; separar credenciais de análise de identidades de implantação; exigir dois aprovadores independentes para exceções e promoções de alto impacto. Esse quórum é um controle organizacional, não consenso bizantino.

External action -> digest review -> admission policy
                                      |
                                      v
                            ephemeral analysis runner
                            no release credentials
                                      |
                              untrusted artifact
                                      v
                    provenance + independent release checks
                                      |
                             protected approval
                                      v
                         isolated deployment identity

Definir tolerância zero para digests executáveis não revisados e credenciais de entrega em jobs de análise. Restringir destinos de saída, tratando também o canal autorizado de logs como caminho de divulgação. Monitorar digests resolvidos, processos, emissão de tokens e acesso a logs sem registrar segredos brutos.

Definir teto de concorrência c por tenant segundo a capacidade de executores limpos e limitar filas; excesso deve ser rejeitado ou adiado antes de emitir credenciais. Definir SLO de revogação medido por emissor, sem presumir prazo universal. Usar identidades de implantação curtas com restrições de repositório, ambiente e audiência.

O rollback deve restaurar conjuntamente workflow revisado, imagem do executor e versão da política. Nunca restaurar credenciais revogadas nem digest bloqueado por comprometimento. Preservar evidências forenses restritas antes de remover logs expostos; verificar migrações necessárias antes de reverter estado da aplicação.

Implicação Estratégica

Tier B (inferred): tipo primário: falha de governança. A classificação trata da admissão de executáveis e autoridade de credenciais, não atribui negligência organizacional. A lente Infrastructure Doctrine trata dependências de build como privilégios delegados de execução.

Em um horizonte de 5–10 anos, preservar proveniência de artefato até código-fonte, revisões de dependências, versões de políticas e evidências de revogação através de migrações de ferramentas. É um horizonte de projeto, não previsão de frequência de ataques. Superfície institucional primária: Mission-Critical DevSecOps. Linhas de capacidade: Reproducible and signed build pipelines; Policy-as-code enforcement; Immutable rollout and rollback control.

Referências

Conclusão

O objetivo de controle é impedir que comprometimento de dependências se converta em autoridade de entrega ou divulgação durável de credenciais. Tier A estabelece o mecanismo histórico; Tier B especifica controles condicionais; Tier C impede estimativas de exposição sem suporte. A recuperação só termina com evidência de proveniência executável, invalidação de credenciais e separação da entrega.

STIGNING Infrastructure Risk Commentary Series
Engineering Under Adversarial Conditions