Hummingbird's images

Project Hummingbird builds a collection of minimal, hardened, and secure container images with a significantly reduced attack surface. This strong focus on security combined with a highly automated update workflow aims to minimize CVE counts, targeting near-zero vulnerabilities. All images support amd64 and arm64 architectures.

All images are available from the Red Hat Hardened Images registry and work directly with Podman, Docker, or Kubernetes:

Example container build using the Hummingbird Python image:

Documentation for each image is available on the Red Hat Hardened Images Catalog .

Available images span language runtimes, databases, web servers, CLI tools, and base runtime images.

Browse the complete catalog at the Red Hat Hardened Images Catalog .

Hummingbird applies several measures to harden container images:

Hummingbird builds distroless containers — images that do not ship with a package manager and most do not even provide a shell.

The distroless design makes the bundled application the container’s entrypoint, offering a streamlined experience. For example, with the curl image , arguments can be passed directly: podman run registry.access.redhat.com/hi/curl:latest -v .

Purpose-built containers reduce the burden on users. Instead of building custom container images and managing their vulnerabilities, a Hummingbird image with the needed application avoids CVE management overhead entirely.

Hummingbird provides different variants to support various use cases while maintaining security by default.

Some images provide additional variants such as PHP’s FPM variant .

FIPS variants ship FIPS 140-3 validated cryptographic modules for workloads that require certified cryptography. Validation applies only when running on RHEL systems installed in FIPS mode .

Two cryptographic stacks are available depending on the image:

FIPS is available in both distroless ( :latest-fips ) and builder ( :latest-fips-builder ) variants. FIPS variants are available for the Hummingbird distro only (not Rawhide). For implementation details, see the FIPS Variant Guide .

Images are published under two support levels:

Tool images used by pipelines (e.g., quay.io/hummingbird-ci/gitlab-ci ) are published from the tools repository.

Images follow a version-based tagging scheme:

Use versioned tags in production for reproducible builds. The :latest tag is convenient for development but may introduce unexpected changes.

For best practices on tag selection and digest pinning, see How to name, version, and reference container images .

Multi-version images:

For languages with multiple supported version families (Python, Node.js, .NET, etc.), separate images exist for each major version:

Version constraints prevent these images from accidentally upgrading to incompatible versions. See version constraints for details.

The recommended pattern for compiled languages:

This approach provides build-time flexibility while maintaining a minimal production image.

Hummingbird images are signed and can be verified using cosign :

Use Syft and Grype to locally inspect and scan images. For details on how production SBOMs are generated, see Software Bill of Materials .

To scan an image for vulnerabilities:

For current vulnerability information across all variants and versions, see the Red Hat Hardened Images Catalog .

On systems with SELinux enabled (such as Fedora and RHEL), mounted volumes must be relabeled to allow container access. Use the :z or :Z option:

The :z option relabels content to be accessible by any container sharing the mount. The :Z option relabels content to be uniquely accessible to one container.

Most Hummingbird images default to a non-root user. When mounting host directories that the container needs to write to, either make the directory world-writable (within a private directory):

Or run as the root user (recommended only with rootless Podman, where the root user in the container maps to the calling user on the host):

For read-only access, no permission changes are needed as long as files are world-readable.

Hummingbird images can be configured to trust custom Certificate Authority (CA) certificates for TLS connections. The approach depends on the image’s TLS stack.

Mount a CA bundle to replace or extend the system trust store:

For details on building derived images with merged trust stores, see the Custom CA (OpenSSL) guide .

Java uses its own PKCS12 truststore format. A custom truststore can be created using keytool and mounted at runtime:

For step-by-step truststore creation, see the Custom CA (Java) guide .

Hummingbird images are designed for compatibility with popular images from Docker Hub, Red Hat UBI, and other registries, enabling straightforward migration of existing workloads.

Key difference : Hummingbird images default to a non-root user (UID 65532) where technically possible, while most traditional images run as root. This may require adjusting file permissions on mounted volumes:

For detailed comparisons (environment variables, ports, sizes, default users), see the compatibility report , also available in machine-readable form .

Reproducible builds ensure that the same inputs and build environment always produce bit-for-bit identical output. This allows independent verification that a published image corresponds to its claimed source materials, making it straightforward to detect if malware was injected during the build process.

Hummingbird images are fully reproducible. Given the signed SLSA provenance attestation that accompanies each image, anyone can rebuild the image from its inputs (this git repo and the RPMs it describes) to verify it matches the published version exactly.

For further background, see Reproducible builds: Project Hummingbird .

The cosign and podman tools are required. First, download and verify the SLSA provenance attestation using cosign (see Image Verification for key details):

Then, feed the attestation into the rebuild tool (capture the image ID for comparison):

[!NOTE] The --privileged flag is required because the build process uses nested containerization. However, this command is expected to be run rootless. A rootless container cannot gain more privileges than the calling user.

To verify reproducibility, pull the published image and compare image IDs:

[!NOTE] The containers-storage image ID (a hash over the manifest and uncompressed content) is used here, not the repo digest (a hash over compressed content). Comparing uncompressed content avoids depending on the exact compression algorithm or registry format.

To keep the rebuilt image for further inspection, use the DUMP_OCIARCHIVE environment variable:

Most container images have layers that mirror the Containerfile structure: each RUN or COPY instruction creates a layer. A single package update can invalidate a layer much larger than the package itself, requiring clients to re-pull content that has not changed.

Hummingbird images use chunkah to split images into content-based layers. Instead of layers reflecting the build process, files are grouped by the packages they belong to. This benefits both the network level (only new layers need downloading) and the storage level (common layers are stored once on disk).

Inspect which packages live in which layers using podman history (or docker history ):

The source code for all Hummingbird containers is available as source containers. A source container includes RPM and non-RPM content shipped in an image, pushed alongside each available tag with the -source suffix.

Inspect source container contents with skopeo :

Hummingbird builds and maintains its own RPM packages independently. Spec files are derived from Fedora but built in Hummingbird’s own infrastructure, allowing project-specific modifications and optimizations. Key differences from Fedora:

There is a natural affinity between the two projects, and opportunities exist to contribute work from Hummingbird back into Fedora.

Interested in contributing? The following resources cover the development workflow:

This project is licensed under the MIT License - see the LICENSE.txt file for details.