Cadeia de suprimentos¶
A partir da versão 1.0.0, as imagens de contêiner publicadas pelo Turbo EA no GHCR carregam metadados verificáveis da cadeia de suprimentos para que os operadores possam confirmar que uma imagem veio do CI deste projeto antes de instalá-la em produção.
Esta página cobre o que é assinado, como verificar, onde fica o SBOM e como o scan do Trivy (atualmente informativo) se encaixa.
O que é assinado¶
Cada imagem construída por .github/workflows/docker-publish.yml e enviada para ghcr.io/vincentmakes/turbo-ea/<imagem> é assinada com cosign usando OIDC sem chave: não há chave de assinatura de longa duração. O certificado é emitido pelo Fulcio da Sigstore para a identidade do workflow, registrado no registro de transparência público do Rekor e descartado assim que a assinatura é criada.
Imagens assinadas:
ghcr.io/vincentmakes/turbo-ea/dbghcr.io/vincentmakes/turbo-ea/backendghcr.io/vincentmakes/turbo-ea/frontendghcr.io/vincentmakes/turbo-ea/nginxghcr.io/vincentmakes/turbo-ea/mcp-server
A imagem ollama é reconstruída manualmente fora da matrix e não está assinada atualmente. Se você depende do perfil Ollama incluído e precisa de verificação, construa-a a partir do código-fonte.
A assinatura se aplica ao digest da lista de manifesto OCI, portanto uma única assinatura cobre de forma transparente tanto linux/amd64 quanto linux/arm64.
Verificando uma imagem¶
Instale o cosign e execute:
cosign verify \
--certificate-identity-regexp 'https://github.com/vincentmakes/turbo-ea/.+' \
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
ghcr.io/vincentmakes/turbo-ea/backend:1.0.0
O que os parâmetros fazem:
--certificate-identity-regexp— aceita qualquer caminho de workflow neste repositório. Para ser mais restritivo, substitua por--certificate-identity 'https://github.com/vincentmakes/turbo-ea/.github/workflows/docker-publish.yml@refs/tags/v1.0.0'.--certificate-oidc-issuer— fixa o emissor OIDC ao endpoint de tokens do GitHub. Uma assinatura emitida por qualquer outro emissor (p. ex., o CI de um fork) falhará na verificação.
Uma verificação bem-sucedida imprime o payload assinado e uma URL de entrada no registro de transparência do Rekor. Uma falha termina com código diferente de zero — faça seu deploy falhar com isso.
Você também pode verificar por digest, que é a forma mais rigorosa (imune ao remapeamento de tags):
DIGEST=$(docker buildx imagetools inspect ghcr.io/vincentmakes/turbo-ea/backend:1.0.0 --format '{{ .Manifest.Digest }}')
cosign verify \
--certificate-identity-regexp 'https://github.com/vincentmakes/turbo-ea/.+' \
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
ghcr.io/vincentmakes/turbo-ea/backend@${DIGEST}
SBOM¶
Um software bill of materials SPDX é gerado automaticamente pelo buildkit (sbom: true na etapa de build) e anexado a cada imagem como um referente OCI. Nenhuma instalação adicional é necessária.
Obtenha-o com:
docker buildx imagetools inspect --format '{{ json .SBOM }}' \
ghcr.io/vincentmakes/turbo-ea/backend:1.0.0 | jq .
O SBOM lista todos os pacotes observados pelo buildkit na imagem final (pacotes apk, wheels Python, módulos Node, etc.) com versões e URLs de origem.
Varredura de vulnerabilidades (Trivy)¶
O workflow de publicação executa o Trivy contra cada imagem construída para CVEs HIGH e CRITICAL e faz upload do resultado como SARIF na aba Security do repositório.
A varredura é atualmente não bloqueante (exit-code: 0). Se os resultados do Trivy forem relevantes para seu ambiente, execute seu próprio scanner na imagem baixada. O SBOM publicado é uma entrada limpa.
Para contribuidores: se você identificar uma vulnerabilidade genuinamente explorável, relate-a por meio de um aviso de segurança privado em vez de em uma issue pública.
Fixação de SHA de Actions¶
Cada GitHub Action usada pelo workflow de publicação está fixada a um SHA de commit de 40 caracteres, não a uma tag de versão principal flutuante. As atualizações passam pelo Dependabot do ecossistema github-actions com cadência mensal.