[releng release-1.13] releng: sync templates

[probelabs]

Auto-generated from gromit templates by policy sync.

[probelabs]

This pull request introduces a comprehensive update to the CI/CD pipeline, synchronizing it with the latest organization-wide templates. The changes focus on enhancing security, improving build reproducibility, and expanding platform support.

Files Changed Analysis

• .github/workflows/release.yml: The main release workflow has been significantly overhauled. Key changes include switching to a GitHub App for authentication, pinning actions to commit SHAs, upgrading the Go version to 1.25, and moving Docker image builds from GoReleaser into dedicated workflow steps. New security and validation steps have been added, such as Go version validation, Docker layer compression verification, and VEX attestation for FIPS images.
• ci/Dockerfile.distroless: The Dockerfile is updated to use a newer Debian 13 base image (trixie-slim). It now includes more robust permission handling and support for different base images via build arguments.
• ci/goreleaser/goreleaser.yml: The GoReleaser configuration has been simplified. The responsibility for building and publishing Docker images has been removed, as this is now handled directly in the GitHub workflow. FIPS builds are expanded to support arm64 and s390x architectures, and the associated build tags and descriptions have been updated.

Architecture & Impact Assessment

• What this PR accomplishes: This PR modernizes the build and release process for tyk-pump, aligning it with current best practices for security, efficiency, and multi-platform support.

• Key technical changes introduced:

  • CI Process: Docker image construction is now managed by docker/build-push-action within the workflow, rather than by GoReleaser. This provides finer-grained control over the build process.
  • Security Enhancements:
    • Authentication is switched from a PAT to a short-lived GitHub App token.
    • GitHub Actions are pinned to specific commit hashes to prevent supply chain attacks.
    • A new step validates that the Go version in the build container is the latest available patch release.
    • Docker Scout and Cosign are used to attach VEX (Vulnerability Exploitability eXchange) attestations to FIPS images.
  • Build & Platform Updates:
    • The Go build version is updated from 1.24 to 1.25.
    • FIPS-compliant builds are now produced for linux/amd64, linux/arm64, and linux/s390x.
  • Quality Gates: New steps have been added to verify that all Docker image layers are consistently compressed with gzip, ensuring efficient distribution.

• Affected system components: The entire continuous integration and delivery pipeline is affected. This includes how source code is built, how artifacts (binaries, packages) are created, how Docker images are built and published, and how tests are executed.

graph TD
    subgraph PR Workflow
        A[Start] --> B{dep-guard};
        B --> C[goreleaser];
        C --> D[test-controller-api];
        C --> E[test-controller-distros];
        D --> F[api-tests];
        E --> G[upgrade-deb];
        E --> H[upgrade-rpm];
        B --> I[aggregator-ci-test]
        C --> I;
        F --> I;
    end

    subgraph "goreleaser Job Details"
        direction LR
        C1(Checkout) --> C2("Validate Go Version") --> C3("Build Binaries & Packages") --> C4("Build & Push Docker Images");
        C4 --> C5("Verify Compression");
        C4 --> C6("Attach VEX Attestation");
    end

    style C4 fill:#f9f,stroke:#333,stroke-width:2px
    linkStyle 2 stroke:red,stroke-width:2px,color:red

    subgraph "Key Changes"
      K1["GoReleaser no longer builds images"];
      K2["Workflow now uses 'docker/build-push-action'"];
      K3["Added: dep-guard, Go validation, VEX, compression checks"];
      K4["Auth: PAT -> GitHub App Token"];
    end

Loading

Scope Discovery & Context Expansion

• The changes in this PR are part of a broader, centralized effort to standardize and secure CI/CD pipelines across the organization, as indicated by the use of shared templates and reusable actions (TykTechnologies/github-actions).
• The expansion of FIPS support to ARM64 and s390x suggests a growing customer or strategic requirement for running Tyk components in FIPS-compliant mode on these architectures.
• The removal of the dedicated sbom job and the sbom: true flag from the Docker build action is a notable change. Further investigation would be needed to understand if SBOM generation is now handled by a different mechanism (e.g., Docker Scout) or has been deferred. This change impacts software supply chain security visibility.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-06-30T12:24:07.612Z | Triggered by: pr_opened | Commit: 3b9b429

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

[probelabs]

Architecture Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:180-230	The shell script logic to verify that Docker image layers are gzip-compressed is duplicated four times in the workflow (for fips CI, fips prod, std CI, and std prod images). This adds over 200 lines of complex, repeated code, which makes the workflow difficult to read, maintain, and update. 💡 Suggestion Extract this verification logic into a reusable composite action within the `.github/actions` directory or a separate script file that can be called from each step. This would centralize the logic, reduce duplication, and improve the workflow's clarity.
🟡 Warning	.github/workflows/release.yml:463	The `upgrade-deb` job hardcodes a specific previous version (`1.6.0`) of `tyk-pump` to test the upgrade from. The `upgrade-rpm` job does the same on line 498. This makes the test brittle and dependent on a specific old version being available in the package repository. 💡 Suggestion To make the upgrade test more robust and representative of a real-world scenario, consider dynamically fetching and installing the latest stable release from the package repository before upgrading. If testing from a specific version is required, this should be a configurable variable, not a hardcoded value.

\n\n

Architecture Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:180-230	The shell script logic to verify that Docker image layers are gzip-compressed is duplicated four times in the workflow (for fips CI, fips prod, std CI, and std prod images). This adds over 200 lines of complex, repeated code, which makes the workflow difficult to read, maintain, and update. 💡 Suggestion Extract this verification logic into a reusable composite action within the `.github/actions` directory or a separate script file that can be called from each step. This would centralize the logic, reduce duplication, and improve the workflow's clarity.
🟡 Warning	.github/workflows/release.yml:463	The `upgrade-deb` job hardcodes a specific previous version (`1.6.0`) of `tyk-pump` to test the upgrade from. The `upgrade-rpm` job does the same on line 498. This makes the test brittle and dependent on a specific old version being available in the package repository. 💡 Suggestion To make the upgrade test more robust and representative of a real-world scenario, consider dynamically fetching and installing the latest stable release from the package repository before upgrading. If testing from a specific version is required, this should be a configurable variable, not a hardcoded value.

\n\n ### Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:101-131	The "Validate Go version" step is executed on every workflow run triggered by a pull request. This step involves multiple shell commands and a network request to `go.dev/dl/` to check for the latest Go patch version. While this ensures the build environment is up-to-date, it adds overhead to every PR build, slowing down the feedback loop for developers. 💡 Suggestion To reduce CI latency on pull requests, consider running this validation check less frequently. For example, it could be extracted into a separate workflow that runs on a schedule (e.g., weekly) and automatically creates an issue or pull request to update the Go version when a new patch is available. This would provide the same benefit without impacting every developer's PR build time.

Quality Issues (4)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:461	The workflow executes a script directly from a URL using `curl | bash`. This is a security risk because the script is not verified before execution. A man-in-the-middle attack or a compromised server could lead to arbitrary code execution on the runner. While the risk is acknowledged in a comment, it remains a potential vulnerability. 💡 Suggestion As a more secure alternative, download the script to a file, verify its checksum or signature if one is provided by the source, and then execute it. This ensures the integrity of the script.
🟡 Warning	.github/workflows/release.yml:462	The `.deb` package upgrade test hardcodes the previous version to install (`tyk-pump=1.6.0`). This makes the test static and it will not test upgrades from newer previous versions unless manually updated. 💡 Suggestion To make the test more dynamic and maintainable, consider modifying it to fetch the latest available version from the package repository to test a more realistic upgrade path.
🟡 Warning	.github/workflows/release.yml:493	The workflow executes a script directly from a URL using `curl | bash`. This is a security risk because the script is not verified before execution. A man-in-the-middle attack or a compromised server could lead to arbitrary code execution on the runner. While the risk is acknowledged in a comment, it remains a potential vulnerability. 💡 Suggestion As a more secure alternative, download the script to a file, verify its checksum or signature if one is provided by the source, and then execute it. This ensures the integrity of the script.
🟡 Warning	.github/workflows/release.yml:494	The `.rpm` package upgrade test hardcodes the previous version to install (`tyk-pump-1.6.0-1`). This makes the test static and it will not test upgrades from newer previous versions unless manually updated. 💡 Suggestion To make the test more dynamic and maintainable, consider modifying it to fetch the latest available version from the package repository to test a more realistic upgrade path.

---

Powered by Visor from Probelabs

Last updated: 2026-06-30T12:23:06.085Z | Triggered by: pr_opened | Commit: 3b9b429

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