[releng master] gromit: sync templates

[probelabs]

Auto-generated from gromit templates by policy sync.

[probelabs]

This pull request, automatically generated by the gromit policy sync tool, introduces the zizmor security scanner to the repository's CI/CD pipeline. The change adds a new GitHub Actions workflow and its corresponding configuration file.

Files Changed Analysis

• .github/workflows/zizmor.yml (Added): This file defines a new GitHub Actions workflow named zizmor. It is configured to run on pull requests and pushes to the master branch. The workflow utilizes a reusable workflow from a centralized repository (TykTechnologies/github-actions), which is a good practice for maintaining consistency across projects.
• .github/zizmor.yml (Added): This is a configuration file for the zizmor tool. It specifies rules for checking GitHub Actions versions, enforcing that third-party actions are pinned to a specific commit hash (hash-pin) while allowing internal TykTechnologies actions to use more flexible tags (ref-pin).

Architecture & Impact Assessment

• What this PR accomplishes: It integrates an automated security check into the CI pipeline to enforce best practices for GitHub Actions usage, specifically regarding version pinning to mitigate supply-chain risks.
• Key technical changes introduced:
  • A new CI job is added that runs on every PR and push to master.
  • It leverages a reusable workflow, centralizing the logic and allowing for easier updates.
  • A local configuration file (.github/zizmor.yml) is added to customize the tool's behavior for this specific repository.
• Affected system components: This change only affects the repository's CI/CD process. There is no impact on the application's runtime behavior.

graph TD
    subgraph "tyk-pump Repository"
        A["GitHub Event<br>(push to master / pull_request)"] --> B{"Run 'zizmor' workflow"};
        B --> C{Reads .github/zizmor.yml config};
    end
    subgraph "TykTechnologies/github-actions Repository"
        D["Reusable Workflow<br>zizmor.yml@production"];
    end
    C --> D;
    B -- uses --> D;
    D --> E["Executes action pinning scan"];
    E -- Reports results --> F["GitHub Security Events"];
    E -- Notifies on failure --> G["Slack via Webhook"];

Loading

Scope Discovery & Context Expansion

• This change is likely part of a broader, automated initiative to enforce consistent security policies across all repositories within the TykTechnologies organization using the gromit tool.
• The core scanning logic is defined externally in the TykTechnologies/github-actions repository. To fully understand the check's implementation, the zizmor.yml file in that repository would need to be reviewed.
• The workflow itself uses a mutable tag (@production). While the added configuration explicitly allows this for first-party actions, it is a security trade-off. Pinning to an immutable commit SHA is the most secure practice to prevent supply-chain attacks.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-08-11T14:43:51.985Z | Triggered by: pr_updated | Commit: 3f1eaf5

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

[probelabs]

Architecture Issues (1)

Severity	Location	Issue
🟠 Error	.github/workflows/zizmor.yml:12	The reusable workflow `TykTechnologies/github-actions/.github/workflows/zizmor.yml` is referenced using a mutable tag (`@production`) instead of an immutable commit SHA. This creates a supply-chain security risk. If the source repository is compromised, the `production` tag could be moved to a malicious commit, which would then be executed by this workflow, compromising the CI/CD pipeline. 💡 Suggestion For improved security and build reproducibility, pin the reusable workflow to a specific commit SHA instead of a branch or tag. Find a specific commit hash from the `production` branch of the `TykTechnologies/github-actions` repository and replace `@production` with it (e.g., `@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2`). While the accompanying `zizmor.yml` configuration explicitly allows this for first-party actions, this policy represents an architectural decision that accepts a significant security risk.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/zizmor.yml:4-8	The `zizmor` workflow is configured to run on every pull request and push to the `master` branch, regardless of the files changed. Since this workflow validates GitHub Actions configurations, it only needs to run when workflow files are modified. Triggering it on every change leads to unnecessary CI runs, consuming resources and increasing developer wait times. 💡 Suggestion To optimize CI resource usage, add a `paths` filter to the trigger configuration so the workflow only runs when files under `.github/workflows/` are changed. 🔧 Suggested Fix on: pull_request: paths: - '.github/workflows/**' push: branches: - master paths: - '.github/workflows/**'

\n\n

Architecture Issues (1)

Severity	Location	Issue
🟠 Error	.github/workflows/zizmor.yml:12	The reusable workflow `TykTechnologies/github-actions/.github/workflows/zizmor.yml` is referenced using a mutable tag (`@production`) instead of an immutable commit SHA. This creates a supply-chain security risk. If the source repository is compromised, the `production` tag could be moved to a malicious commit, which would then be executed by this workflow, compromising the CI/CD pipeline. 💡 Suggestion For improved security and build reproducibility, pin the reusable workflow to a specific commit SHA instead of a branch or tag. Find a specific commit hash from the `production` branch of the `TykTechnologies/github-actions` repository and replace `@production` with it (e.g., `@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2`). While the accompanying `zizmor.yml` configuration explicitly allows this for first-party actions, this policy represents an architectural decision that accepts a significant security risk.

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

Severity	Location	Issue
🟡 Warning	.github/workflows/zizmor.yml:4-8	The `zizmor` workflow is configured to run on every pull request and push to the `master` branch, regardless of the files changed. Since this workflow validates GitHub Actions configurations, it only needs to run when workflow files are modified. Triggering it on every change leads to unnecessary CI runs, consuming resources and increasing developer wait times. 💡 Suggestion To optimize CI resource usage, add a `paths` filter to the trigger configuration so the workflow only runs when files under `.github/workflows/` are changed. 🔧 Suggested Fix on: pull_request: paths: - '.github/workflows/**' push: branches: - master paths: - '.github/workflows/**'

\n\n ### Quality Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/zizmor.yml:12	The reusable workflow is pinned to a mutable tag (`@production`) instead of an immutable commit SHA. This introduces a supply-chain risk, as the code executed by the workflow can change without any modification to this repository. If the upstream `production` tag is compromised or maliciously updated, this workflow could execute untrusted code. The SonarQube scan also failed with a 'C Security Rating on New Code', which is likely related to this issue. 💡 Suggestion For improved security and deterministic builds, pin the action to a specific, immutable commit SHA. You can find the commit SHA corresponding to the desired version of the `production` tag in the `TykTechnologies/github-actions` repository and replace `@production` with it. Consider using a tool like Dependabot to manage updates to the pinned SHA automatically.

---

Powered by Visor from Probelabs

Last updated: 2026-08-11T14:43:30.528Z | Triggered by: pr_updated | Commit: 3f1eaf5

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

[github-actions]

🚨 Jira Linter Failed

Commit: 3f1eaf5
Failed at: 2026-08-11 14:43:33 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: neither branch name 'releng/master' nor PR title '[releng master] gromit: sync templates' contains 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
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