Seguridad de contenedores y procedencia de builds

Este documento describe cómo Fystack garantiza builds de contenedores verificables y resistentes a manipulaciones mediante procedencia conforme a SLSA, firma criptográfica sin claves y logs públicos de transparencia. Esto nos permite demostrar que cada imagen de contenedor de producción proviene de un commit de Git específico y que no ha sido manipulada.

1. Descripción general

Cada imagen de producción se construye con Docker BuildKit e incluye metadatos de procedencia SLSA nivel 3 y SBOM SPDX. Todos los artefactos se firman sin claves con Sigstore Cosign y se registran en el log de transparencia Rekor, lo que crea un registro de auditoría inmutable.

Cadena de integridad:

Git Commit → SLSA Provenance → Cosign Signature → Rekor Transparency Log

Imágenes base distroless

Fystack usa imágenes distroless para minimizar los vectores de ataque provenientes del sistema operativo. Las imágenes distroless contienen solo la aplicación y sus dependencias de ejecución, y eliminan gestores de paquetes, shells y otras utilidades que podrían explotarse.

FROM golang:1.25 AS builder

ARG TARGETOS=linux
ARG TARGETARCH=amd64

WORKDIR /src

COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod \
    go mod download

COPY . .

RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} \
    go build -o /out/mpcium ./cmd/mpcium

FROM gcr.io/distroless/base-debian12:latest

USER nonroot:nonroot
WORKDIR /app

COPY --from=builder /out/mpcium /app/mpcium

ENTRYPOINT ["/app/mpcium"]

Este enfoque:

• Reduce la superficie de ataque al eliminar paquetes del sistema operativo innecesarios
• Se ejecuta como usuario no root para mayor seguridad
• Usa montajes de caché de BuildKit para builds más rápidos y eficientes
• Produce imágenes finales mínimas (normalmente <20MB para binarios de Go)

2. Procedencia y firma de builds

Pipeline de CI/CD seguro: procedencia SLSA nivel 3 con firma sin claves y logs de transparencia

Procedencia SLSA nivel 3

Workflow: .github/workflows/docker-push.yml Disparador: push: tags: ['v*.*.*'] Permisos: id-token: write

Cada build etiquetado produce:

• Procedencia SLSA: incluye la URI del código fuente y el SHA del commit.
• SBOM (SPDX 2.3): enumera las dependencias y los metadatos de los paquetes.
• Tags inmutables: docker.io/fystack/apex/{service}:{version} y {version}-{sha}.

docker buildx imagetools inspect docker.io/fystack/apex/api:v1.0.0 \
  --format '{{ json .Provenance.SLSA }}' | jq -r '.predicate.buildDefinition.resolvedDependencies[0].uri'
# Expected: https://github.com/fystack/apex/commit/<sha>

Firma criptográfica (Cosign sin claves)

Cada imagen y cada atestación se firman con la identidad OIDC de GitHub Actions, lo que elimina los riesgos de gestionar claves privadas. Las firmas se almacenan en Rekor, un log de transparencia público de solo anexado.

Generación de la firma (dentro de CI):

cosign sign \
  --identity-token "https://token.actions.githubusercontent.com" \
  docker.io/fystack/apex/api@sha256:<digest>

Verificación de la firma:

cosign verify \
  --certificate-identity-regexp="github.com/fystack/apex/.github/workflows/docker-push.yml@*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  docker.io/fystack/apex/api:v1.0.0

Esto demuestra que:

• La imagen fue construida por un workflow de GitHub de confianza.
• La firma es válida y tiene una marca de tiempo en Rekor.
• No existen claves de firma manuales que puedan robarse o usarse indebidamente.

3. Verificación y recuperación ante incidentes

Si sospechas de un hackeo, una manipulación de imágenes o un ataque interno, sigue esta secuencia de verificación para demostrar la autenticidad:

Paso 1: Obtener la procedencia

cosign verify-attestation --type slsaprovenance docker.io/fystack/apex/api:v1.0.0 | jq .

Muestra la URI del commit de origen, el repositorio y la identidad del workflow.

Paso 2: Verificar la firma y el registro de transparencia

cosign verify \
  --certificate-identity-regexp="github.com/fystack/apex/.github/workflows/docker-push.yml@*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  docker.io/fystack/apex/api:v1.0.0

rekor-cli search --artifact docker.io/fystack/apex/api:v1.0.0

Confirma que la firma de la imagen es válida y que su registro existe en el log público de Rekor con una marca de tiempo.

Paso 3: Verificar la integridad del commit de Git

git show <commit-sha>

Confirma que el commit referenciado en la procedencia todavía existe y no fue reescrito.

Paso 4: Contrastar el SBOM

docker buildx imagetools inspect docker.io/fystack/apex/api:v1.0.0 | jq '.SBOM'

Confirma que las dependencias coinciden con el repositorio de origen verificado y con los metadatos del SBOM.

Cadena de prueba final:

Rekor Timestamp → Cosign Signature → Provenance Commit URI → Git Commit Hash

Si los cuatro elementos coinciden, queda demostrado que la imagen proviene de un commit de confianza y sin manipular.

Lista de verificación

4. Hardening y buenas prácticas

5. Resumen

Este pipeline de build le da a Fystack un linaje demostrable y verificable criptográficamente desde el commit de Git hasta el contenedor desplegado.

Garantiza:

• Procedencia de la cadena de suministro transparente y auditable.
• Ninguna dependencia de claves secretas.
• Resistencia a manipulaciones internas o externas.
• Alineación con el cumplimiento de SLSA nivel 3 y las buenas prácticas de Sigstore.

En resumen: cada contenedor de Fystack no solo es reproducible, sino también demostrablemente auténtico.