Pular para conteúdo

Capítulo 4.9 — Supply chain security para IA

🎯 Objetivo

Tratar o pipeline de IA como cadeia de suprimentos auditável -incluindo código, dependências, containers, modelos, datasets, prompts, schemas, MCP servers e A2A peers.

🧠 Conceitos base

  • SBOM (Software Bill of Materials) - inventário de dependências de um artefato.
  • SPDX - formato de SBOM mantido pela Linux Foundation, padrão ISO/IEC 5962:2021.
  • CycloneDX - formato de SBOM mantido pela OWASP, focado em componentes, vulnerabilidades, serviços e ML/AI components.
  • SLSA (Supply-chain Levels for Software Artifacts) - framework com níveis (1 a 4) que descrevem o quanto um artefato tem proveniência verificável e build hardenado. Versão atual: SLSA v1.x.
  • OpenSSF Scorecard - projeto da OpenSSF que avalia automaticamente práticas de segurança de repositórios open-source.
  • Sigstore / cosign - assinatura e verificação de artefatos.
  • in-toto - atestações verificáveis ao longo do pipeline.
  • Provenance - atestado verificável de origem (quem buildou, com qual fonte, em qual ambiente).

🛡️ Aplicado a IA

Eixo O que controlar Forma típica
Código Build, dependências, lint, vulns SBOM (SPDX/CycloneDX), Scorecard, dependabot/renovate, SLSA provenance
Containers Base image, layers, vulns Scanners (Trivy, Grype), assinatura (cosign), pinning de digests
Modelos Origem, hash, versão, licença Model card + hash do artefato; SBOM-ML (CycloneDX inclui ML-BOM); registro no model registry
Datasets Origem, licença, versão, viés Dataset card; data contracts; lineage no orchestrator
Prompts Versão, owner, eval regression Prompts em repo, semver, eval gate no CI
Schemas / Tools Versão, owner, contract test Semver + contract tests + registry
MCP servers Origem, version, capabilities Pinning de versão; review periódico de capabilities; assinatura
A2A peers Versão do Agent Card, capabilities Versionar Agent Card; revisão de breaking changes
Embeddings / Índices Modelo + dimensão + versão Tag no índice; dual-read em migração
Policy bundles Versão + hash + assinatura Bundle service do OPA com auth e signing

🚨 Modos de falha

  • Modelo carregado de hub público sem hash fixado.
  • Dataset com licença incompatível usado em fine-tuning.
  • MCP server de terceiro atualizado silenciosamente expandindo capabilities.
  • Container base com vulnerabilidade conhecida em modelo de produção.
  • Prompt alterado sem registro no registry; regression nunca detectada.
  • Sem sbom.json para artefato final -> impossível responder "o que está rodando?".

🛡️ Controles e mitigações

  • Gerar SBOM (SPDX ou CycloneDX) em cada build; armazenar com o artefato.
  • Adotar CycloneDX ML-BOM para descrever modelos, datasets, hyperparameters e fontes.
  • Atestar provenance via SLSA + Sigstore.
  • Avaliar projetos open-source críticos via OpenSSF Scorecard.
  • Pinar versões e digests (containers, MCP servers).
  • Bloquear build se SBOM mostrar vuln crítica não justificada.
  • Manter model registry e dataset registry com lineage.
  • Revisar capabilities de MCP servers a cada upgrade.

📈 Métricas

  • % de artefatos com SBOM atualizado.
  • % de modelos com hash + model card + licença documentada.
  • Tempo entre disclosure de CVE e patch em produção.
  • Score do OpenSSF Scorecard para dependências-chave.
  • Tentativas de carregar artefato sem provenance.

📌 Checklist

  • [ ] Builds geram SBOM (SPDX ou CycloneDX) automaticamente?
  • [ ] Modelos têm hash, model card e licença no registry?
  • [ ] Datasets têm dataset card e licença documentada?
  • [ ] Containers têm assinatura (cosign) e digest fixado?
  • [ ] MCP servers/A2A peers têm versão pinada e revisão periódica?
  • [ ] Existe processo para responder "o que está em produção?" em minutos?

📚 Referências