[TT-16946][TT-16951] feat(ci): FIPS base image for FIPS Docker builds (release-5.12.1)

[buger]

$(gh pr view 8003 --repo TykTechnologies/tyk --json body -q .body)

Related Tickets

• https://tyktech.atlassian.net/browse/TT-16946
• https://tyktech.atlassian.net/browse/TT-16951

[github-actions]

API Changes

no api changes detected

[probelabs]

This PR introduces a dedicated build and release pipeline for a FIPS-compliant version of the Tyk Gateway. It utilizes a new FIPS base image (tykio/dhi-busybox:1.37-fips) and enables FIPS-validated cryptographic modules in Go by building with the fips tag and GOFIPS140=v1.0.0 environment variable.

Key changes include updating the GoReleaser configuration to define FIPS-specific builds and packages, and modifying the GitHub Actions release workflow to build, publish, and attest the new tyk-gateway-fips Docker image. Additionally, the base image for standard distroless builds is upgraded to Debian 13, and all GitHub Actions are pinned to specific commit hashes for improved security and reproducibility.

Files Changed Analysis

• .github/workflows/release.yml: Heavily modified to introduce a parallel build pipeline for the FIPS Docker image. This includes new steps for metadata generation, building, pushing to ECR and production registries, and attaching a VEX statement using cosign. The Go version for the build environment is updated to 1.25-bullseye, and all GitHub Actions are pinned to full commit SHAs.
• ci/goreleaser/goreleaser.yml: Significantly expanded to define the new fips build variant. This includes build configurations for amd64, arm64, and s390x architectures with the fips tag, and packaging rules for creating tyk-gateway-fips DEB and RPM packages.
• ci/Dockerfile.distroless: The base image is updated from Debian 12 to Debian 13 (trixie) and parameterized using a BASE_IMAGE build argument. This allows the FIPS build to substitute a different base image while upgrading the default for other builds.

Architecture & Impact Assessment

• What this PR accomplishes: It creates a new FIPS-compliant build artifact (tyk-gateway-fips) for users in regulated environments requiring FIPS 140-3 validated cryptography, without altering the standard builds.

• Key technical changes introduced:

  • A new FIPS build process is established using the fips Go build tag and the GOFIPS140=v1.0.0 environment variable.
  • A new FIPS-specific base Docker image is used for the final container.
  • The CI/CD pipeline is extended to handle the entire lifecycle of this new build variant, from compilation to publication and security attestation.
  • The base OS for existing distroless images is upgraded to Debian 13.

• Affected system components: The changes are primarily isolated to the CI/CD and packaging systems. The core application code is not modified but is compiled differently. The most significant impact is on the release process, which now produces and manages an additional set of artifacts.

• CI Flow Visualization:

graph TD
subgraph sg1 ["GitHub Actions Workflow (release.yml)"]
A[Start PR/Tag] --> B(dep-guard);
B --> C{goreleaser job};
C --> D{Build Binaries};
D -- tags=ee --> E[Build EE Packages];
D --|"tags=fips, GOFIPS140=v1.0.0"|--> F[Build FIPS Packages];
D -- tags=std --> G[Build STD Packages];

    subgraph sg2 ["Docker Image Push"]
        E --> H(Push tyk-gateway-ee);
        F --> I(Push tyk-gateway-fips);
        G --> J(Push tyk-gateway);
    end

    I --> K[Attach VEX statement];
end

## Scope Discovery & Context Expansion

- The introduction of the `fips` build tag implies the existence of conditional compilation (`//go:build fips`) within the Go source code to enable FIPS-compliant crypto modules. While the application logic remains unchanged, the underlying cryptographic libraries will differ in the FIPS build.
- The upgrade of the distroless base image to Debian 13 affects the non-FIPS `tyk-gateway` and `tyk-gateway-ee` images. This could introduce subtle changes related to the underlying system libraries and should be tested accordingly.
- Pinning all GitHub Actions to commit SHAs is a significant security hardening measure for the CI/CD pipeline, reducing the risk of supply chain attacks by ensuring the exact version of an action is always used.


<details>
  <summary>Metadata</summary>

  - Review Effort: 4 / 5
  - Primary Label: feature


</details>
<!-- visor:section-end id="overview" -->

<!-- visor:thread-end key="TykTechnologies/tyk#8003@65d5605" -->

---

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

*Last updated: 2026-04-14T17:10:50.385Z | Triggered by: pr_opened | Commit: 65d5605*

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

[probelabs]

Security Issues (4)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:198	The workflow uses a 'curl-to-sh' pattern to install the Docker Scout CLI. This executes a remote script without integrity verification, creating a risk of arbitrary code execution on the build runner if the source is compromised or the connection is intercepted. This pattern is also used on lines 832 and 881 for package repository setup. 💡 Suggestion Download the script to a file, verify its checksum (e.g., SHA256) against a known, trusted value, and only then execute it. This ensures the integrity of the script being run.
🟡 Warning	.github/workflows/release.yml:200-204	Security-critical steps for fetching Vulnerability Exploitability eXchange (VEX) data and creating a cosign attestation are configured to ignore failures using `|| true`. This can lead to an image being released without the required security metadata while the pipeline still reports success, creating a false sense of security. 💡 Suggestion Remove `|| true` from the `docker scout` and `cosign attest` commands. The build should fail if security attestations cannot be generated, ensuring that all released artifacts meet the defined security standards.
🟡 Warning	.github/workflows/release.yml:832	The workflow uses `curl | bash` to set up a packagecloud repository. This pattern executes a remote script without integrity verification, which is a security risk. A comment in the code acknowledges this risk. A similar issue exists on line 881. 💡 Suggestion Instead of executing the remote script, manually perform the steps to add the repository's GPG key and source list entry within the workflow. This avoids executing unverified remote code.
🟡 Warning	.github/workflows/release.yml:881	The workflow uses `curl | bash` to set up a packagecloud repository. This pattern executes a remote script without integrity verification, which is a security risk. A comment in the code acknowledges this risk. A similar issue exists on line 832. 💡 Suggestion Instead of executing the remote script, manually perform the steps to add the repository's GPG key and source list entry within the workflow. This avoids executing unverified remote code.

Quality Issues (4)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:195-263	The workflow steps for building and pushing the 'fips' Docker image are heavily duplicated from the existing 'ee' and 'std' image build steps. The sections for CI metadata, CI push, tag metadata, and production push are nearly identical, differing only in parameters like package names and labels. This increases maintenance overhead, as any change to the build logic must be manually replicated across all similar sections. 💡 Suggestion To reduce duplication and improve maintainability, refactor these steps into a reusable GitHub composite action. Alternatively, use a matrix strategy to iterate over the different image types ('ee', 'fips', 'std'), passing the specific parameters for each type as matrix variables. This would centralize the build and push logic.
🟡 Warning	.github/workflows/release.yml:833	The command `curl -fsSL ... | bash` executes a remote script without verification. This practice is insecure because if the downloaded script is compromised or the connection is intercepted (MITM attack), arbitrary code can be executed on the CI runner. While a comment acknowledges this risk, it remains a potential security vulnerability. 💡 Suggestion Download the script to a file, verify its integrity using a checksum (e.g., SHA256), and then execute it. This ensures that the script has not been tampered with. For example: `curl -fsSL ... -o script.deb.sh && echo '<expected_checksum> script.deb.sh' | sha256sum -c - && bash script.deb.sh`.
🟡 Warning	.github/workflows/release.yml:889	The command `curl -fsSL ... | bash` executes a remote script without verification. This practice is insecure because if the downloaded script is compromised or the connection is intercepted (MITM attack), arbitrary code can be executed on the CI runner. While a comment acknowledges this risk, it remains a potential security vulnerability. 💡 Suggestion Download the script to a file, verify its integrity using a checksum (e.g., SHA256), and then execute it. This ensures that the script has not been tampered with. For example: `curl -fsSL ... -o script.rpm.sh && echo '<expected_checksum> script.rpm.sh' | sha256sum -c - && bash script.rpm.sh`.
🟡 Warning	ci/goreleaser/goreleaser.yml:170-227	The `nfpms` configuration for `id: fips` is a near-verbatim copy of the configuration for `id: ee`. Sections such as `contents`, `scripts`, `rpm`, and `deb` are identical. This duplication makes the configuration file unnecessarily long and difficult to maintain, as any changes to packaging logic must be applied in multiple places. 💡 Suggestion Utilize YAML anchors and aliases to define the common configuration blocks once. Then, reference these anchors in both the `ee` and `fips` `nfpms` sections. This will significantly reduce code duplication and ensure consistency between the package configurations.

---

Powered by Visor from Probelabs

Last updated: 2026-04-14T16:56:04.009Z | Triggered by: pr_opened | Commit: 65d5605

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

[github-actions]

🚨 Jira Linter Failed

Commit: 65d5605
Failed at: 2026-04-15 09:12:25 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 'feat/fips-base-image-5.12.1' 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.