Build, Scan, Push, and Sign a Container Image

Ship containers through a secure software supply chain with a built-in vulnerability gate. This blueprint orchestrates Docker image build, Trivy CVE scanning, registry push, and cosign image signing in one declarative Kestra flow: build a Docker image, scan it for HIGH and CRITICAL vulnerabilities with Trivy, push only clean images to your container registry, and sign the published image with cosign so downstream consumers can verify provenance and attestation. It closes the gap most CI scripts leave open, where images get pushed to production registries before anyone checks them for known CVEs or signs them for supply chain integrity.

How it works

1. build uses io.kestra.plugin.docker.Build to build the image from an inline Dockerfile with push: false, tagging it as {{ inputs.image }} so nothing leaves the worker until it passes the gate.
2. scan runs io.kestra.plugin.trivy.cli.TrivyCLI with trivy image --exit-code 1 --severity HIGH,CRITICAL, which fails the run and stops the pipeline if any qualifying CVE is found.
3. push uses io.kestra.plugin.docker.Push to publish the scanned image to ghcr.io using REGISTRY_USERNAME and REGISTRY_PASSWORD credentials.
4. sign runs io.kestra.plugin.scripts.shell.Commands on a bitnami/cosign Docker taskRunner and calls cosign sign --yes --key env://COSIGN_KEY to sign the pushed image.
5. The on_build_request io.kestra.plugin.core.trigger.Webhook trigger lets CI POST a request to build, scan, and publish a new image on demand.

What you get

• A single image reference ({{ inputs.image }}) that flows through build, scan, push, and sign.
• A hard quality gate: HIGH or CRITICAL CVEs abort the run before the image is ever pushed.
• Signed, verifiable images for provenance and supply chain attestation.
• A webhook entry point so the same flow serves manual runs and CI triggers.

Who it's for

• Platform and DevOps engineers building golden image pipelines.
• Security teams enforcing CVE policy at build time.
• Application teams that want signed, scanned images without writing custom CI glue.

Why orchestrate this with Kestra

Docker, Trivy, and cosign each solve one step, but none of them sequence the steps, gate on results, or react to events. Kestra ties them into one declarative YAML pipeline: the Webhook trigger fires the flow on a CI event, failed scans short-circuit the run automatically, and you can add retries, alerting, and full execution lineage across every step. Plain build scripts give you none of the observability, replay, or event orchestration that the underlying CLIs cannot provide on their own.

Prerequisites

• A worker with Docker daemon access for the build, scan, and push steps.

Secrets

• REGISTRY_USERNAME and REGISTRY_PASSWORD: registry push credentials.
• COSIGN_PRIVATE_KEY and COSIGN_PASSWORD: cosign signing key and its password.
• DOCKER_BUILD_WEBHOOK_KEY: key guarding the webhook trigger.

Quick start

1. Set the secrets above in your Kestra namespace.
2. Replace the sample Dockerfile in the build task with your application's Dockerfile.
3. Run the flow manually with the target image reference, or POST to the on_build_request webhook from CI.

How to extend

• Swap keyed signing for keyless cosign signing with OIDC.
• Add severity tiers or an allowlist to the Trivy command, or emit the scan report as an output.
• Push to multiple registries, add SBOM generation, or fan out to multi-architecture builds.
• Notify Slack or open a ticket on scan failure using Kestra error handlers.

Links

• Docker plugin documentation
• Orchestrate Docker with Kestra