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

[buger]

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

Related Tickets:

• TT-16946
• TT-16951

[probelabs]

This PR introduces a dedicated FIPS-compliant build pipeline for Tyk Gateway, enabling its deployment in regulated environments. The changes primarily focus on the CI/CD process to produce a new tyk-gateway-fips artifact, which is built using a hardened base image and Go's native FIPS 140-3 validated cryptographic module.

Files Changed Analysis

• .github/workflows/release.yml: The core release workflow has been significantly modified to accommodate the new FIPS build. This includes adding a parallel build and push pipeline for the FIPS Docker image, upgrading the Go version to 1.25-bullseye, and introducing steps for security attestation using cosign and Docker Scout to attach VEX statements. The trigger conditions for the workflow have also been simplified.
• ci/Dockerfile.distroless: This Dockerfile is now parameterized using a BASE_IMAGE build argument. This change allows the same Dockerfile to be used for both the standard build (defaulting to gcr.io/distroless/base-debian13) and the new FIPS build, which overrides the argument to use the hardened tykio/dhi-busybox:1.37-fips base image.
• ci/goreleaser/goreleaser.yml: The GoReleaser configuration is expanded to define new build targets (fips-amd64, fips-arm64, fips-s390x). These builds are configured with the fips build tag and the GOFIPS140=v1.0.0 environment variable to enable Go's FIPS module. Corresponding packaging (nfpms) and publishing configurations are also added for the new tyk-gateway-fips artifacts.

Architecture & Impact Assessment

• What this PR accomplishes: It introduces a new FIPS-compliant build variant of the Tyk Gateway Enterprise Edition. This allows Tyk to be deployed in environments with strict cryptographic compliance requirements.
• Key technical changes introduced:
  1. FIPS Build Variant: A new build is created that compiles the gateway with Go's native FIPS module by setting GOFIPS140=v1.0.0 and using the fips build tag.
  2. Hardened Base Image: The FIPS Docker image is built upon tykio/dhi-busybox:1.37-fips, a minimal, hardened base image, enhancing its security posture.
  3. CI/CD Pipeline Expansion: The release workflow and GoReleaser configuration are extended to build, package, publish, and attest the new FIPS build variant alongside the existing EE and Standard builds.
  4. Security Attestation: The workflow now includes steps to attach a VEX (Vulnerability Exploitability eXchange) statement from the base image to the final FIPS artifact using cosign, improving software supply chain security.
• Affected system components: The changes are confined to the CI/CD pipeline and build artifacts. The runtime behavior is only affected in the new FIPS build, where standard crypto libraries are replaced by FIPS-validated modules. The existing builds are unaffected, apart from being compiled with an updated Go version.

Build & Containerization Flow

graph TD
    subgraph sg1 ["GoReleaser Build Matrix"]
        A[Source Code] --> B{Build Variants}
        B -- tags: ee --> C[EE Binary]
        B -- "tags: ee, fips<br/>env: GOFIPS140=v1.0.0" --> D[FIPS Binary]
        B -- tags: std --> E[Standard Binary]
    end

    subgraph sg2 ["GitHub Actions: Docker Image Build"]
        C & E --> F[Build Standard/EE Image]
        F -- FROM gcr.io/distroless/base-debian13 --> G[Dockerfile.distroless]
        
        D --> H[Build FIPS Image]
        H -- "ARG BASE_IMAGE=tykio/dhi-busybox:1.37-fips" --> G

        H --> I[Attach VEX Attestation w/ Cosign]
    end

    subgraph sg3 ["Publish"]
        F --> J[Push to Registries]
        I --> J
    end

Loading

Scope Discovery & Context Expansion

• The changes are entirely self-contained within the build and deployment configuration (.github/workflows/, ci/). No application source code is modified, indicating that the FIPS compliance is achieved through Go's compile-time module replacement rather than custom application logic.
• The introduction of cosign for attestation suggests a move towards stronger software supply chain security practices, which could be expanded to other build artifacts in the future.
• To further understand the impact, one could investigate the tykio/dhi-busybox:1.37-fips image to understand its contents and security hardening. Additionally, searching the codebase for any other uses of the fips build tag would confirm if any FIPS-specific code paths exist or are planned.

Metadata

• Review Effort: 3 / 5
• Primary Label: feature

---

Powered by Visor from Probelabs

Last updated: 2026-04-14T14:59:02.811Z | Triggered by: pr_updated | Commit: 60414af

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

[github-actions]

API Changes

no api changes detected

[probelabs]

\n\n

Architecture Issues (2)

Severity	Location	Issue
🟠 Error	ci/goreleaser/goreleaser.yml:171-233	The configuration for the new `fips` build variant is almost entirely a copy of the `ee` variant's configuration across the `builds`, `nfpms`, and `publishers` sections. This introduces significant duplication, making the file difficult to maintain. For example, a change to the package contents or installation scripts would need to be manually synchronized between the `ee`, `fips`, and `std` `nfpms` blocks. 💡 Suggestion Use YAML anchors and aliases to define common templates for builds and packaging. A base template can be defined for `nfpms` containing the shared `contents` and `scripts`, and then extended for each variant (`ee`, `fips`, `std`) to set the specific `package_name`, `description`, and build `ids`. This will centralize the common logic, reduce the file size, and make future maintenance much simpler and less error-prone.
🟡 Warning	.github/workflows/release.yml:211-267	The `goreleaser` job contains duplicated sets of steps for building and pushing Docker images for `ee`, `fips`, and `std` variants. Each variant has separate steps for metadata generation and pushing to CI/production registries, resulting in over 150 lines of repeated logic. This copy-paste approach increases maintenance overhead, as any change to the push logic must be replicated across all variants. 💡 Suggestion Refactor the job to use a matrix strategy for the different variants (`ee`, `fips`, `std`). This would define the variant-specific parameters (e.g., package name, base image, platforms) in the matrix and use a single, parameterized set of steps for the build and push logic. This would significantly reduce the workflow's length and improve its maintainability.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:45-296	The 'goreleaser' job has been expanded to build and publish three different artifacts (ee, fips, std), including their respective Docker images. These operations are performed sequentially within a single job, which will significantly increase its runtime and the overall feedback loop for the workflow. The Docker build-and-push operations for each variant are independent and can be parallelized. 💡 Suggestion To reduce the total wall-clock time of the workflow, consider restructuring the CI pipeline to run independent tasks in parallel. The 'goreleaser' job could be split. For example, one job could build all the binaries and packages, and then subsequent parallel jobs could each handle the Docker image creation and pushing for a specific variant (ee, fips, std).

Quality Issues (6)

Severity	Location	Issue
🟠 Error	ci/goreleaser/goreleaser.yml:63-357	The GoReleaser configuration contains a large amount of duplication. The build definitions (`builds`), packaging rules (`nfpms`), and publisher configurations (`publishers`) for the new `fips` variant are almost identical copies of the `ee` and `std` variants. This significantly increases maintenance overhead and the risk of inconsistent updates when changes are required. 💡 Suggestion Refactor the configuration to use YAML anchors. Define common blocks for `ldflags`, `nfpms.contents`, `nfpms.scripts`, etc., and reference them in the `ee`, `fips`, and `std` sections. This will make the file much shorter, easier to read, and simpler to maintain.
🟡 Warning	.github/workflows/release.yml:262-268	The script to attach a VEX SBOM uses `|| true` to suppress errors from `docker scout` and `cosign`. This means if the VEX generation or attestation fails for any reason, the failure will be silently ignored, and the workflow will proceed as if successful. This can result in a false sense of security, as images may be pushed without the required attestations. 💡 Suggestion Remove `|| true` to ensure the step fails if attestation is a critical part of the process. If certain errors (like a missing VEX file for the base image) are expected and should not fail the build, the script should explicitly check for and handle those specific cases rather than silencing all errors.
🟡 Warning	.github/workflows/release.yml:850	The workflow executes a remote script directly from the internet using `curl | bash`. This is a security risk because the script could be maliciously modified without notice. While a comment has been added to acknowledge this, the underlying risk remains. 💡 Suggestion For improved security, download the script, verify its integrity using a checksum (if one is provided by the source), and then execute it. Alternatively, consider vendoring the script in the repository.
🟡 Warning	.github/workflows/release.yml:900	The workflow executes a remote script directly from the internet using `curl | bash`. This is a security risk because the script could be maliciously modified without notice. While a comment has been added to acknowledge this, the underlying risk remains. 💡 Suggestion For improved security, download the script, verify its integrity using a checksum (if one is provided by the source), and then execute it. Alternatively, consider vendoring the script in the repository.
🟡 Warning	.github/workflows/release.yml:211-268	The GitHub Actions workflow contains duplicated logic for building and pushing Docker images. The steps for the `fips` image are largely a copy of the steps for the `ee` image. This makes the workflow file long and harder to maintain. 💡 Suggestion To improve maintainability and reduce redundancy, consider refactoring the common steps into a reusable workflow (using `workflow_call`) or a composite action. This would centralize the build and push logic, making it easier to update across all image types.
🟡 Warning	.github/workflows/release.yml:241	The FIPS Docker image is built for `linux/amd64` and `linux/arm64`, but not `linux/s390x`, which is included for the standard and EE builds. This inconsistency might be unintentional or undocumented. 💡 Suggestion If `s390x` is a supported platform for FIPS builds, it should be added to the `platforms` list for consistency. If it is not supported, a comment explaining why would improve the clarity of the workflow.

---

Powered by Visor from Probelabs

Last updated: 2026-04-14T14:58:32.123Z | Triggered by: pr_updated | Commit: 60414af

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

[asutosh]

@buger Is this intentional, do we not need depguard here? Or is that run as a separate workflow somewhere else?

[asutosh]

Isn't this is a bit risky? If the main has a change due to a supply chain attack similar to trivy, the install script could be compromised. Might be better to fetch using a known good SHA, and pass the latest known immutable release tag as argument. This scripts support this as an option.
Something like:

curl -fssL https://raw.githubusercontent.com/docker/scout-cli/0390daf32edeaee9aca29829ac63aacde4e2ca9b/install.sh | sh -s "1.20.4" -- 2>/dev/null

This fetches the script from the corresponding commit hash for 1.20.4 tag and installs the 1.20.4 tag.

[asutosh]

If trimpath is removed from here, it also needs to be removed from the plugin compiler build flag, otherwise built plugins would be incompatible.
Unless it's required, I think it might be better to keep trimpath

[github-actions]

🚨 Jira Linter Failed

Commit: 60414af
Failed at: 2026-04-14 14:56:04 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' 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
1 Security Hotspot
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[buger]

/release to release-5.12.1

[probelabs]

⚠️ Cherry-pick encountered conflicts. A draft PR was created: #8002