Use FIPS base images for amd64/arm64, standard images for s390x

[buger]

Description

This PR adds FIPS-compliant Docker images for the Tyk Gateway, including both base image changes and a separate FIPS product line.

Changes

1. Conditional Base Images (Dockerfiles)

• Dockerfile.std and Dockerfile.distroless now use FIPS-compliant base images (tykio/dhi-debian-base:trixie-debian13-fips) for amd64/arm64
• s390x continues to use standard images (no FIPS base image available for this architecture)

Architecture	Base Image
amd64	tykio/dhi-debian-base:trixie-debian13-fips
arm64	tykio/dhi-debian-base:trixie-debian13-fips
s390x	debian:trixie-slim / gcr.io/distroless/base-debian12:latest

2. Separate FIPS Product Images (goreleaser + workflow)

• New fips-amd64 and fips-arm64 build targets with -tags=goplugin,ee,fips,boringcrypto and GOEXPERIMENT=boringcrypto
• New tyk-gateway-fips package (.deb/.rpm)
• New Docker image builds pushing to tykio/tyk-gateway-fips (amd64/arm64 only)
• FIPS images use boringssl for cryptographic operations

Problem Solved

The original attempt to use FIPS base images unconditionally failed because the FIPS base image only supports amd64/arm64, but the CI builds for s390x as well:

[linux/s390x internal] load metadata for docker.io/tykio/dhi-debian-base:trixie-debian13-fips
ERROR: no match for platform in manifest: not found

This PR solves this by:

1. Using Docker's TARGETARCH for conditional base image selection
2. Adding a separate FIPS product line built with boringcrypto

Test Plan

• Verify multi-platform Docker build succeeds for all three architectures (amd64, arm64, s390x)
• Verify amd64/arm64 standard images use the FIPS base
• Verify s390x images use the standard debian base
• Verify tyk-gateway-fips package is built correctly
• Verify tykio/tyk-gateway-fips Docker images are pushed (on tag release)

---

🤖 Generated with Claude Code

[probelabs]

This pull request enables the building of FIPS-compliant Docker images for amd64 and arm64 architectures by using a FIPS-certified base image. To accommodate the s390x architecture, for which a FIPS image is not available, the Dockerfiles are updated to conditionally select the base image using Docker's TARGETARCH build argument. This ensures s390x builds continue to use the standard Debian base images.

To support this, the release workflow and GoReleaser configurations are updated to introduce a parallel build and release pipeline for a new tyk-gateway-fips package and corresponding Docker image.
\

Files Changed Analysis\

• .github/workflows/release.yml: Adds new steps to the release workflow to build, tag, and push a distinct tyk-gateway-fips Docker image, specifically targeting linux/amd64 and linux/arm64.\
• ci/Dockerfile.distroless & ci/Dockerfile.std: These files are modified to use a multi-stage build pattern. They now dynamically select the base image (tykio/dhi-debian-base:trixie-debian13-fips for amd64/arm64 or debian:trixie-slim for s390x) based on the TARGETARCH variable. This allows a single Dockerfile to produce both FIPS and standard images.\
• ci/goreleaser/goreleaser.yml: Introduces new build configurations (fips-amd64, fips-arm64) that use the fips and boringcrypto build tags and the GOEXPERIMENT=boringcrypto environment variable to compile the gateway with FIPS-validated cryptographic modules. It also defines a new nfpms package and publisher for the resulting FIPS artifacts.
  \

Architecture & Impact Assessment\

• What this PR accomplishes: It allows the project to produce FIPS-compliant Tyk Gateway images for amd64 and arm64 platforms, which is a critical requirement for deployment in regulated environments, while maintaining build compatibility for the s390x platform.\
• Key technical changes introduced:\
  • Conditional base image selection within Dockerfiles using ARG TARGETARCH.\
  • A separate build pipeline for FIPS artifacts defined in GitHub Actions and GoReleaser.\
  • Compilation of the Go binary with BoringCrypto via the fips build tag and GOEXPERIMENT=boringcrypto.\
• Affected system components: The primary impact is on the CI/CD build and release pipeline. The runtime of the gateway is also affected for amd64/arm64 builds, as they will now use the BoringCrypto library for all cryptographic operations. The final container image for these architectures will also have a different base OS```mermaid
  graph TD
  subgraph Docker Build Process
  A[Start Multi-Platform Build] --> B{Check TARGETARCH};
  B --|amd64 or arm64|--> C[FROM tykio/dhi-debian-base:trixie-debian13-fips];
  B --|s390x|--> D[FROM debian:trixie-slim];
  C --> E[Build with FIPS Go binary];
  D --> F[Build with Standard Go binary];
  E --> G[FIPS-compliant Image];
  F --> H[Standard Image];
  end

        F --> H[Standard Image];\
    end\
```\
\
## Scope Discovery & Context Expansion\
- The changes are well-contained within the project's build, packaging, and deployment configurations. No core application logic has been modified in this PR.\
- The key runtime change is the compilation with `GOEXPERIMENT=boringcrypto`. A search for explicit `//go:build fips` tags in the source code yielded no results. This indicates that FIPS compliance is achieved implicitly by the Go toolchain replacing standard crypto libraries with their BoringCrypto counterparts when the experiment is enabled, rather than through conditional file compilation.
<!-- visor:section-end id="overview" -->

<!-- visor:thread-end key="TykTechnologies/tyk#7676@e8d99f3" -->

---

*Powered by [Visor](https://probelabs.com/visor) from [Probelabs](https://probelabs.com)*

*Last updated: 2026-01-16T13:15:38.926Z | Triggered by: pr_updated | Commit: e8d99f3*

💡 **TIP:** You can chat with Visor using `/visor ask <your question>`
<!-- /visor-comment-id:visor-thread-overview-TykTechnologies/tyk#7676 -->

[probelabs]

Security Issues (3)

Severity	Location	Issue
🟡 Warning	ci/Dockerfile.distroless:5-7	Base images in `ci/Dockerfile.distroless` and `ci/Dockerfile.std` are specified using mutable tags (e.g., `:trixie-debian13-fips`, `:trixie-slim`, `:latest`). This can lead to unpredictable behavior in the build pipeline if the image tag is updated, and poses a security risk if the tag is overwritten with a compromised image. Builds will not be reproducible. 💡 Suggestion Pin base images to their immutable SHA256 digest to ensure build reproducibility and security. For example, `FROM tykio/dhi-debian-base:trixie-debian13-fips@sha256:deadbeef...`.
🟡 Warning	.github/workflows/release.yml:201-246	GitHub Actions are referenced using floating major version tags (e.g., `@v5`, `@v6`). This practice can introduce unexpected breaking changes or security vulnerabilities if a new version is released under the same tag. 💡 Suggestion Pin actions to a specific commit SHA to ensure the workflow is deterministic and secure. For example, `uses: docker/metadata-action@599e35b...` instead of `uses: docker/metadata-action@v5`. This applies to all newly added `docker/metadata-action@v5` and `docker/build-push-action@v6` actions.
🟡 Warning	ci/Dockerfile.distroless:5	The change introduces a dependency on a new base image, `tykio/dhi-debian-base:trixie-debian13-fips`. The security of the final product is highly dependent on the maintenance and security posture of this base image. 💡 Suggestion Ensure that this new base image is regularly scanned for vulnerabilities and has a clear maintenance policy. Consider integrating container scanning for the final built images into the CI/CD pipeline to detect vulnerabilities inherited from the base image.

Architecture Issues (2)

Severity	Location	Issue
🟠 Error	ci/goreleaser/goreleaser.yml:174-231	The GoReleaser configuration for FIPS builds introduces a large amount of duplication. The `nfpms` package definition for `fips` (lines 174-231) is nearly identical to its `std` counterpart, as are the new `builds` (lines 63-104) and `publishers` (lines 240-245) sections. This violates the DRY principle and increases maintenance overhead, as future changes will need to be applied in multiple places. 💡 Suggestion Refactor the configuration to use YAML anchors and aliases. A common configuration block can be defined for shared settings (like `contents`, `scripts`, etc. in `nfpms`) and then merged into both the `fips` and `std` definitions. This will significantly reduce duplication and improve maintainability.
🟡 Warning	.github/workflows/release.yml:204-264	The GitHub Actions workflow adds a series of steps for building and pushing FIPS Docker images (lines 204-264) that are almost a direct copy of the existing steps for standard images. This duplication makes the workflow file verbose and harder to maintain. 💡 Suggestion To reduce this duplication, abstract the common logic into a reusable workflow or a composite action. This new workflow/action could accept parameters such as the package name (`tyk-gateway-fips` vs. `tyk-gateway`), target platforms, and image name, allowing you to invoke it for both FIPS and standard builds with minimal repeated code.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:238-254	The workflow builds the FIPS docker image twice on tagged releases: once for the CI registry and a second time for the production registry. This duplicates the build process, leading to inefficient use of CI resources and longer pipeline execution times. 💡 Suggestion To optimize the workflow, build the image only once. A recommended pattern is to have one job that builds and pushes the image to the CI registry. Then, for tagged releases, a subsequent job can pull the image from the CI registry, re-tag it for production, and push it to the production registry. This avoids the redundant build step entirely.

Quality Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:200-268	The workflow adds a large, duplicated block of steps for building and pushing FIPS Docker images. This pattern is likely repeated for other image types (std, ee), making the workflow file long, hard to read, and difficult to maintain. Any change to the build/push logic must be manually synchronized across multiple sections. 💡 Suggestion Refactor the workflow to use GitHub Actions' reusable workflows or composite actions. A reusable workflow could encapsulate the logic for metadata generation and image pushing, taking parameters like image name, package name, and other variants. This would significantly reduce duplication and improve maintainability.
🟡 Warning	ci/goreleaser/goreleaser.yml:60-241	The GoReleaser configuration introduces significant duplication for the new FIPS build. The `builds` for `fips-amd64` and `fips-arm64` are nearly identical, and the `nfpms` and `publishers` sections for `fips` are large blocks of configuration that appear to be copied from existing definitions. This makes the file harder to maintain, as any change to packaging or publishing logic will need to be replicated. 💡 Suggestion To improve maintainability, refactor this configuration to reduce duplication. For the `builds` section, consolidate `fips-amd64` and `fips-arm64` into a single definition using GoReleaser's matrix-like features or templating (e.g., setting `CC` based on `{{ .Arch }}`). For the `nfpms` and `publishers` sections, use YAML anchors and aliases to define common configuration blocks once and reuse them across different package types.

---

Powered by Visor from Probelabs

Last updated: 2026-01-16T13:15:41.859Z | Triggered by: pr_updated | Commit: e8d99f3

💡 TIP: You can chat with Visor using /visor ask <your question>

[github-actions]

API Changes

no api changes detected

[github-actions]

🚨 Jira Linter Failed

Commit: e8d99f3
Failed at: 2026-01-16 13:13:39 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to validate branch and PR title rules: branch name 'docker-fips' must contain a valid Jira ticket ID (e.g., ABC-123)

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

---

This comment will be automatically deleted once the linter passes.

[sonarqubecloud]

Quality Gate failed

Failed conditions
4 Security Hotspots

See analysis details on SonarQube Cloud