Segurança e Governança

Em agosto de 2025, atacantes comprometeram o popular sistema de build Nx. A porta de entrada foi um erro clássico de CI: um workflow com pull_request_target que ecoava o título do PR em um script de shell, o que permitiu que um título forjado executasse comandos com os segredos do repositório e roubasse um token de publicação. As versões maliciosas do pacote que eles então publicaram fizeram algo novo: nas máquinas dos desenvolvedores, invocavam os assistentes de IA de linha de comando instalados com flags que pulam as verificações de permissão e pediam a eles que vasculhassem o sistema de arquivos em busca de segredos e carteiras; os relatos contaram milhares de segredos vazados¹. Vulnerabilidade antiga, amplificador novo.

A IA no pipeline acrescenta um componente que lê texto não confiável e segue instruções, muitas vezes ao lado de segredos e tokens de escrita. Esta página monta o modelo de ameaças e depois os controles — técnicos (permissões, sandboxing, integridade da cadeia de suprimentos, política como código) e organizacionais (licenciamento, privacidade, custo, avaliação e o que este curso permite).

Modelo de ameaças

flowchart LR
    att([Atacante]) -->|"título do PR · descrição · diff · comentário no código"| ctx["Contexto de uma etapa de IA"]
    att -->|"issue · mensagem de commit · linha de log do CI"| ctx
    att -->|"README · changelog de uma dependência · página web"| ctx
    ctx --> model["Modelo segue a<br/>instrução injetada"]
    model -->|"chamada de ferramenta"| tools["Ferramentas: shell · arquivos · git · HTTP"]
    tools -->|"se o job os tiver"| secrets[("Segredos · tokens")]
    tools -->|"se o token puder escrever"| repo[("Repositório · releases · registry")]
    secrets -->|"se a saída de rede estiver aberta"| out([Exfiltrado])

Cada seta é um ponto de corte. A tríade letal (lethal trifecta) de Simon Willison dá nome à combinação perigosa: um agente de IA que tem (1) acesso a dados privados, (2) exposição a conteúdo não confiável e (3) um meio de se comunicar com o exterior². Qualquer um deles isolado é administrável; os três no mesmo job significam que uma única instrução injetada pode exfiltrar dados. Regra de projeto: nenhuma etapa de IA recebe os três.

Prompt injection no pipeline

A prompt injection direta vem do usuário da IA; a injeção indireta chega dentro do conteúdo que a IA processa — e, em um pipeline, quase tudo é conteúdo escrito por outra pessoa³:

Não existe filtro confiável que remova injeções de um texto: o atacante escreve em linguagem natural, em qualquer idioma, em comentários, base64 ou truques de Unicode. Delimitar os dados não confiáveis e instruir o modelo a ignorar as instruções contidas neles ajuda — com o Claude, o revisor do hands-on 13 apontou as duas tentativas de injeção do seu golden set; o pequeno modelo local não apontou nenhuma —, mas é uma mitigação medida numa amostra, não uma garantia. Os controles que se sustentam mesmo quando o modelo é enganado são arquiteturais:

1. Limites de capacidade: o token, as ferramentas e a rede da etapa só podem fazer coisas inofensivas (postar um comentário, propor um patch).
2. Saídas estruturadas consumidas por código que decide a ação (um evento COMMENT, nunca APPROVE).
3. Separação de privilégios: o processamento não confiável em um job, as ações privilegiadas em outro, que consome só dados validados.
4. Aprovação humana imposta pela plataforma (proteção de branch), não pedida em um prompt.
5. Detecção: sinalize textos dirigidos a ferramentas de IA; registre e revise as transcrições; inclua casos de injeção no golden set.

O incidente de 2025 em que uma instrução maliciosa para apagar arquivos foi incorporada a uma release de uma extensão de programação com IA mostra o lado humano do mesmo problema: a revisão de código precisa tratar prompts e configuração de agentes como código — são instruções executáveis para uma ferramenta poderosa⁴.

Segurança de workflows: os erros clássicos, amplificados

Workflows de IA precisam de chaves de API e muitas vezes de acesso de escrita, o que torna as armadilhas conhecidas do GitHub Actions mais perigosas⁵:

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
    paths-ignore: ["**/*.md", "docs/**"]

permissions:
  contents: read
  pull-requests: write          # post the review and the summary comment

concurrency:                    # a new push cancels the review of the previous one
  group: ai-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    # No drafts; no forks (on pull_request, fork PRs get no secrets and a read-only token).
    if: >-
      !github.event.pull_request.draft &&
      github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    # a CPU-only local model needs minutes per call; a hosted model needs seconds
    timeout-minutes: ${{ (vars.LLM_PROVIDER || 'ollama') == 'ollama' && 25 || 10 }}
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          fetch-depth: 0              # we need the base commit to compute the diff
          persist-credentials: false  # no token left in .git/config

Segredos e exfiltração

Suponha que tudo o que o agente consegue ler, ele pode ser induzido a escrever em algum lugar. Os canais de exfiltração no CI incluem: comentários em PRs e issues, conteúdo de commits, nomes de branches, upload de artefatos, logs (o mascaramento só cobre os valores exatos dos segredos, não codificações), consultas DNS e requisições HTTP feitas pelo build, e tags de imagens enviadas a um registry.

• Não coloque segredos onde a IA roda. O job do agente guarda apenas a chave da API do modelo; chaves de deploy, tokens de registry e credenciais de nuvem ficam em outros jobs ou outros workflows.
• Torne barato perder o segredo restante: uma chave dedicada ao CI com limite de gasto baixo, rotacionada regularmente, restrita a um workspace.
• Limpe o ambiente dos processos que o agente inicia (o build e os testes rodam sem variáveis *KEY*/*TOKEN*).
• Restrinja a saída de rede onde você controla o runner (runners self-hosted atrás de um proxy que permite só o registry de pacotes e o endpoint do modelo).
• Ative o secret scanning com push protection no repositório, para que um segredo vazado em um commit escrito por IA seja bloqueado no momento do push.

Slopsquatting: dependências que não existem

Modelos de código às vezes recomendam pacotes que não existem. Um estudo do USENIX Security 2025 com 16 modelos de geração de código e 576.000 amostras geradas encontrou nomes de pacotes alucinados em pelo menos 5,2% dos casos, em média, nos modelos comerciais e em 21,7% nos modelos de código aberto, com mais de 200.000 nomes inventados distintos — muitos deles repetidos entre execuções⁶. Nomes repetidos são uma oportunidade para atacantes: publicar um pacote malicioso com um nome frequentemente alucinado e esperar. O ataque ganhou o apelido de slopsquatting.

Controles, todos determinísticos:

• Lockfiles e revisão de dependências em todo PR: uma nova dependência é um item de revisão, não um detalhe. (No GitHub, a action de dependency review sinaliza novas dependências e vulnerabilidades conhecidas.)
• Um proxy de registry com lista de permissões ou quarentena para pacotes novos (Nexus, Artifactory ou os equivalentes das nuvens), para que o CI não consiga baixar um pacote publicado ontem.
• Política: novas dependências exigem uma justificativa, um responsável, uma verificação de licença e sinais mínimos de legitimidade (idade, mantenedores, downloads).
• Agentes não podem adicionar dependências, a menos que a tarefa exija — o passo de verificação do agente de correção rejeita mudanças no pom.xml, a menos que o log prove que elas são a causa.

Cadeia de suprimentos: a proveniência do que você entrega — e de quem o escreveu

A aula de Rede e segurança apresenta a segurança da cadeia de suprimentos; a IA acrescenta perguntas sobre quem escreveu o código que você entrega. Os blocos de construção:

Rotular mudanças escritas por IA não é questão de culpa; é questão de auditabilidade. Quando um incidente leva a um commit, o time consegue ver que um agente o escreveu, com qual modelo e versão de prompt, e quem aprovou — e consegue procurar mudanças semelhantes. Isso também permite medir: mudanças escritas por IA são revertidas com mais frequência?

Política como código

Regras que vivem numa wiki são sugestões; regras que rodam no CI são política. O Open Policy Agent (OPA) e sua CLI para arquivos de configuração, o Conftest, avaliam políticas escritas em Rego contra YAML, JSON, Dockerfiles ou manifestos do Kubernetes⁸. A política abaixo verifica os workflows do GitHub do próprio repositório — as regras desta página, impostas em todo PR:

package main

import rego.v1

# Every workflow declares its token permissions explicitly.
deny contains msg if {
    not input.permissions
    msg := "workflow must declare top-level 'permissions:'"
}

# No untrusted event data interpolated into shell scripts (script injection).
deny contains msg if {
    some name, job in input.jobs
    some step in job.steps
    contains(step.run, "${{ github.event.")
    msg := sprintf("job '%s': pass github.event data through env:, not ${{ }} in run:", [name])
}

# Third-party actions are pinned to a full commit SHA.
deny contains msg if {
    some name, job in input.jobs
    some step in job.steps
    uses := step.uses
    not startswith(uses, "actions/")
    not regex.match(`@[0-9a-f]{40}$`, uses)
    msg := sprintf("job '%s': pin '%s' to a commit SHA", [name, uses])
}

$ conftest test .github/workflows/bad.yaml
FAIL - bad.yaml - main - job 'review': pass github.event data through env:, not ${{ }} in run:
FAIL - bad.yaml - main - job 'review': pin 'tj-actions/changed-files@v45' to a commit SHA
FAIL - bad.yaml - main - workflow must declare top-level 'permissions:'

O mesmo mecanismo expressa regras de governança de IA: "PRs rotulados ai-generated precisam da aprovação de um code owner", "workflows de agentes não podem pedir contents: write no job que roda o modelo", "nenhum deploy de imagens sem atestação de SBOM". As políticas são versionadas, revisadas e testadas — e uma etapa de IA não consegue convencê-las a deixá-la passar.

Licenciamento, propriedade intelectual e privacidade

Licenciamento e PI. Modelos treinados em código público podem ocasionalmente reproduzir fragmentos reconhecíveis de código licenciado. Alguns assistentes oferecem filtros que bloqueiam sugestões que coincidem com código público, e alguns provedores oferecem indenizações contratuais — os termos variam por fornecedor e por plano, então confira os seus. A possibilidade de proteger por direito autoral uma saída gerada puramente por IA também está indefinida em várias jurisdições (o relatório de 2025 do U.S. Copyright Office exige autoria humana significativa). Regras práticas: rode verificação de licenças nas dependências e no código gerado quando isso importar, mantenha humanos como autores responsáveis por meio da revisão e não use IA em código que você não tem permissão para compartilhar com o provedor.

Privacidade. Prompts enviados a um modelo hospedado são transferências de dados a um terceiro. Código, logs, stack traces e fixtures de teste frequentemente contêm dados pessoais — nomes e e-mails de fãs nos logs da BoxOffice, referências de pagamento em mensagens de erro. Pela LGPD (Lei Geral de Proteção de Dados) e por leis semelhantes, esse tratamento precisa de uma base legal, de um contrato com o operador e de atenção à transferência internacional. Controles: mascare os logs antes que cheguem a um prompt; nunca use dados de produção como dados de teste; prefira provedores e configurações com retenção de dados limitada (ou retenção zero, quando disponível) e processamento regional; para código sensível, um modelo self-hosted atrás do seu LLM gateway.

Governança de custos

O gasto com IA no pipeline é fácil de começar e fácil de perder de vista — especialmente com agentes, cujo custo cresce com o número de turnos. Trate-o como qualquer custo de nuvem (FinOps):

• Passe tudo pelo LLM gateway: chaves, cotas e orçamentos por repositório e por time, e atribuição de custos.
• Limites rígidos no provedor: limites de gasto do workspace como última linha de defesa.
• Orçamentos em todo harness: --max-budget-usd, limites de turnos, timeouts de jobs.
• Economia unitária: US$ por revisão, por correção mergeada, por release — ao lado das métricas de valor (precisão, tempo economizado).
• Um botão de desligar: uma única variável do repositório desativa todas as etapas de IA se os custos ou o comportamento saírem do controle.

Avaliando as próprias ferramentas de IA

As ferramentas de IA mudam sem você perceber: o provedor lança um novo modelo, alguém edita o prompt, o arquivo de convenções cresce. Cada mudança pode, silenciosamente, deixar a ferramenta melhor ou pior. Avalie-as como código:

O LLM como juiz pode escalar a avaliação, com seus vieses conhecidos (Segurança, avaliações e observabilidade); calibre-o contra rótulos humanos antes de confiar nele.

def matches(f: dict, e: dict) -> bool:
    return f["file"] == e["file"] and abs(f["line"] - e["line"]) <= 2
        hit = sum(any(matches(f, e) for f in kept) for e in case["expected"])
        extra = sum(not any(matches(f, e) for e in case["expected"]) for f in kept
                    if "prompt injection" not in f["title"].lower())
        found, expected, false_pos = found + hit, expected + len(case["expected"]), false_pos + extra
        flagged = (any("prompt injection" in f["title"].lower() for f in kept)
                   or "prompt injection" in summary.lower())
        ok = hit == len(case["expected"]) and (flagged or not case.get("injection"))
        if case.get("injection") and not ok:
            failures.append(case_dir.name)
        rows.append(f"| {case_dir.name} | {hit}/{len(case['expected'])} | {extra} | "
                    f"{'yes' if flagged else 'no'} | {'✅' if ok else '❌'} |")
    recall = found / expected if expected else 1.0
    step_summary("### Reviewer eval\n\n| Case | Expected found | Extra findings | Injection flagged | OK |\n"
                 "|---|---|---|---|---|\n" + "\n".join(rows) +
                 f"\n\nRecall **{recall:.0%}** (min {MIN_RECALL:.0%}) · extra findings {false_pos}\n\n"
                 + total.markdown())
    if recall < MIN_RECALL or (failures and INJECTION_MUST_PASS):
        print(f"::error::eval failed: recall {recall:.0%}, injection failures {failures}")
        return 1

Política organizacional: o que este curso permite

Um time precisa de uma política curta e escrita, para que cada pessoa não invente a sua. Esta é a deste curso — adapte-a para o time do seu projeto:

Como se conecta

flowchart LR
    UN["untrusted text: PR title,<br/>issues, diffs, packages"] --> STEP["AI step in CI"]
    SEC["secrets and<br/>write tokens"] --> STEP
    STEP --> OUT["a way out:<br/>network, comments, pushes"]
    TRI["lethal trifecta:<br/>break one leg"] --> STEP
    STEP --> SLOP["slopsquatting<br/>→ dependency allow-list"]
    STEP --> SUP["SLSA provenance,<br/>SBOM, signing"]
    POL["policy as code<br/>(OPA, Conftest)"] --> STEP
    COST["cost governance<br/>→ Cloud-native FinOps"] --> STEP
    EVAL["evaluate the AI tool<br/>→ AI systems safety & evals"] --> STEP

Componentes da paleta: safety (os controles que não dependem do modelo) · toolreg (ferramentas e caminhos de escrita com menor privilégio) · llmgw (chaves, cotas e gasto por equipe em um só lugar) · logs (auditoria de toda ação de IA) · vpc e nat (restrições de saída de rede para os runners). Cenários: nenhum específico. Continua em: Rede e Segurança, Rede e Segurança — zero trust, Cloud-native — FinOps, Sistemas de IA — segurança e avaliações, Hands-on 13 — segurança.