[TT-16968] chore(ci): update to Debian 13 + Go 1.25 + FIPS support (release-1.14.1)

[buger]

Summary

• Update distroless base to Debian 13
• Go 1.25 build environment
• Add FIPS builds with GOFIPS140=v1.0.0
• Add dep-guard

Gromit PR

TykTechnologies/gromit#444

🤖 Generated with Claude Code

[probelabs]

This PR updates the CI/CD pipeline to use Go 1.25 and Debian 13, and introduces official FIPS 140-3 support.

Files Changed Analysis

• .github/workflows/release.yml: The core CI workflow is significantly updated. It now runs on Go 1.25 and a Debian 13 (bookworm) base. A dep-guard job has been added to check dependencies on pull requests. The FIPS build process is updated to use a new base image (tykio/dhi-busybox:1.37-fips) and includes a new step to attach VEX (Vulnerability Exploitability eXchange) attestations using cosign. The standard (non-FIPS) build no longer produces s390x images. All GitHub Actions have been updated and pinned to specific commit hashes for improved security and reproducibility.
• ci/Dockerfile.distroless: The Dockerfile for the standard build is updated to use Debian 13 as its base. The base image is now configurable via a BASE_IMAGE build argument.
• ci/goreleaser/goreleaser.yml: The GoReleaser configuration is modified to support the new FIPS build process. It replaces the GOEXPERIMENT=boringcrypto flag with GOFIPS140=v1.0.0 and switches the build tag from boringcrypto to fips. An s390x build is now included for FIPS packages.

Architecture & Impact Assessment

This PR overhauls the build environment and enhances security features for generated artifacts.

• Accomplishments: Modernizes the build toolchain to Go 1.25 and Debian 13, and transitions from a boringcrypto-based FIPS implementation to the official Go FIPS 140-3 compliant mode.
• Key Technical Changes:
  • Go FIPS 140-3: Adopts the standard GOFIPS140 environment variable for building FIPS-compliant binaries, replacing the previous boringcrypto experiment.
  • Dependency Guard: Integrates a dep-guard workflow to vet dependencies before merging.
  • VEX Attestation: Adds a step to attach VEX data to FIPS container images, providing consumers with information on vulnerability exploitability.
• Affected System Components: The changes are isolated to the CI/CD pipeline and build process. The core application logic remains untouched, but the resulting binaries, packages, and container images will be built with the new toolchain and security features.

CI Workflow Visualization

graph TD
    A[Pull Request] --> B(dep-guard);
    B -- Success --> C[goreleaser];
    C --|Binaries and Images|--> D["Parallel Tests"];

    subgraph goreleaser
        direction LR
        g1["Build std/FIPS binaries w/ Go 1.25"]
        g2["Package .deb/.rpm"]
        g3["Build & Push Docker Images"]
        g4["Attach VEX to FIPS Image"]
    end

    subgraph "Parallel Tests"
        T1[api-tests]
        T2[deb-install-tests]
        T3[rpm-install-tests]
    end

    D --> T1;
    D --> T2;
    D --> T3;
    
    T1 --> F[Aggregated CI Status];
    T2 --> F;
    T3 --> F;

Loading

Scope Discovery & Context Expansion

• The changes are confined to the build and release infrastructure (.github/workflows, ci/). No application source code is modified.
• The primary impact is on the consumers of the build artifacts (Docker images, DEB/RPM packages), who will now receive packages built on a newer toolchain with enhanced, standardized FIPS support.
• The introduction of dep-guard and VEX attestations points to a broader initiative to harden the software supply chain security for this project.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-04-15T14:15:28.538Z | Triggered by: pr_opened | Commit: d3ae02b

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

[probelabs]

Security Issues (3)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:213	The `docker/scout-cli` is installed by downloading and executing a script from GitHub without any integrity check. If the source repository is compromised, this could lead to arbitrary code execution in the CI runner. 💡 Suggestion Download the installer script, verify its checksum (SHA256) against a known value, and only then execute it. Alternatively, if a more secure installation method is available (e.g., a pre-built binary with checksums), use that.
🟡 Warning	.github/workflows/release.yml:460	The packagecloud repository setup script for Debian-based systems is executed via `curl | bash`. This is a security risk as it executes unverified code from the internet. A compromise of packagecloud or a MITM attack could lead to arbitrary code execution within the Docker build environment used for testing. 💡 Suggestion As noted in the code comment, this is a security risk. The script should be downloaded, its integrity verified (e.g., with a checksum), and then executed. A more robust solution is to follow the manual installation instructions from packagecloud, which typically involve adding a GPG key and repository configuration, allowing the system's package manager to handle installation securely.
🟡 Warning	.github/workflows/release.yml:505	The packagecloud repository setup script for RPM-based systems is executed via `curl | bash`. This is a security risk as it executes unverified code from the internet. A compromise of packagecloud or a MITM attack could lead to arbitrary code execution within the Docker build environment used for testing. 💡 Suggestion As noted in the code comment, this is a security risk. The script should be downloaded, its integrity verified (e.g., with a checksum), and then executed. A more robust solution is to follow the manual installation instructions from packagecloud, which typically involve adding a GPG key and repository configuration, allowing the system's package manager to handle installation securely.

Architecture Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:232-266	The `s390x` architecture has been removed from the standard (non-FIPS) container image builds, while simultaneously being added for FIPS builds. This change effectively makes `s390x` a FIPS-only supported platform, which could be a breaking change for users of the standard `s390x` image. This represents a significant architectural decision regarding platform support that should be justified. 💡 Suggestion If this change is intentional, please document the rationale and ensure it is communicated clearly in release notes. If unintentional, please add `linux/s390x` back to the `platforms` list for the `push std image to CI` and `push std image to prod` steps.
🟡 Warning	.github/workflows/release.yml:446-495	The distro installation tests use `curl | bash` to set up package repositories. This pattern executes a remote script without verification, creating a security risk. A compromise of the script's source could inject malicious code into the CI environment. While this is noted in the code as an accepted risk, it is an architectural weakness in the test harness. 💡 Suggestion To improve security, modify the process to download the script, verify its integrity (e.g., via checksum), and then execute it. For example: `curl -fsSL ... -o setup.sh && echo "<EXPECTED_CHECKSUM> setup.sh" | sha256sum -c - && bash ./setup.sh`.

Security Issues (3)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:213	The `docker/scout-cli` is installed by downloading and executing a script from GitHub without any integrity check. If the source repository is compromised, this could lead to arbitrary code execution in the CI runner. 💡 Suggestion Download the installer script, verify its checksum (SHA256) against a known value, and only then execute it. Alternatively, if a more secure installation method is available (e.g., a pre-built binary with checksums), use that.
🟡 Warning	.github/workflows/release.yml:460	The packagecloud repository setup script for Debian-based systems is executed via `curl | bash`. This is a security risk as it executes unverified code from the internet. A compromise of packagecloud or a MITM attack could lead to arbitrary code execution within the Docker build environment used for testing. 💡 Suggestion As noted in the code comment, this is a security risk. The script should be downloaded, its integrity verified (e.g., with a checksum), and then executed. A more robust solution is to follow the manual installation instructions from packagecloud, which typically involve adding a GPG key and repository configuration, allowing the system's package manager to handle installation securely.
🟡 Warning	.github/workflows/release.yml:505	The packagecloud repository setup script for RPM-based systems is executed via `curl | bash`. This is a security risk as it executes unverified code from the internet. A compromise of packagecloud or a MITM attack could lead to arbitrary code execution within the Docker build environment used for testing. 💡 Suggestion As noted in the code comment, this is a security risk. The script should be downloaded, its integrity verified (e.g., with a checksum), and then executed. A more robust solution is to follow the manual installation instructions from packagecloud, which typically involve adding a GPG key and repository configuration, allowing the system's package manager to handle installation securely.

\n\n ### Architecture Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:232-266	The `s390x` architecture has been removed from the standard (non-FIPS) container image builds, while simultaneously being added for FIPS builds. This change effectively makes `s390x` a FIPS-only supported platform, which could be a breaking change for users of the standard `s390x` image. This represents a significant architectural decision regarding platform support that should be justified. 💡 Suggestion If this change is intentional, please document the rationale and ensure it is communicated clearly in release notes. If unintentional, please add `linux/s390x` back to the `platforms` list for the `push std image to CI` and `push std image to prod` steps.
🟡 Warning	.github/workflows/release.yml:446-495	The distro installation tests use `curl | bash` to set up package repositories. This pattern executes a remote script without verification, creating a security risk. A compromise of the script's source could inject malicious code into the CI environment. While this is noted in the code as an accepted risk, it is an architectural weakness in the test harness. 💡 Suggestion To improve security, modify the process to download the script, verify its integrity (e.g., via checksum), and then execute it. For example: `curl -fsSL ... -o setup.sh && echo "<EXPECTED_CHECKSUM> setup.sh" | sha256sum -c - && bash ./setup.sh`.

\n\n ### Performance Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:465-475	The Dockerfile for Debian distribution tests is generated in an order that prevents effective layer caching. The `COPY` command, which uses a build artifact that changes on every run, is placed before `apt-get update` and other setup commands. This invalidates the cache for these subsequent, time-consuming steps, forcing them to re-run on every execution and slowing down the CI pipeline. 💡 Suggestion To leverage Docker's layer caching and speed up the CI job, reorder the commands in the generated Dockerfile. Perform all system setup and dependency installation (`apt-get update`, `apt-get install`, `curl`) before copying the build-specific `.deb` artifact. This ensures the setup layers are cached and reused across runs.
🟡 Warning	.github/workflows/release.yml:501-512	The Dockerfile for RPM distribution tests is generated in an order that prevents effective layer caching. The `COPY` command, which uses a build artifact that changes on every run, is placed before `yum install` and other setup commands. This invalidates the cache for these subsequent, time-consuming steps, forcing them to re-run on every execution and slowing down the CI pipeline. 💡 Suggestion To leverage Docker's layer caching and speed up the CI job, reorder the commands in the generated Dockerfile. Perform all system setup and dependency installation (`yum install`, `curl`) before copying the build-specific `.rpm` artifact. This ensures the setup layers are cached and reused across runs.

---

Powered by Visor from Probelabs

Last updated: 2026-04-15T14:14:50.609Z | Triggered by: pr_opened | Commit: d3ae02b

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

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🚨 Jira Linter Failed

Commit: d3ae02b
Failed at: 2026-04-17 09:40:45 UTC

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

🔍 Click to view error details

failed to get Jira issue: failed to fetch Jira issue TT-16968: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

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.