TT-17286: add actions for static analysis

[olamilekan000]

Jira Ticket

add zizmor for static analysis

TT-17286

Description

Type of Change

• Bug fix
• New feature / action
• Refactor / improvement
• Documentation update
• CI/CD / workflow change
• Other (please describe):

Changes Made

Testing

• Manually triggered the affected workflow(s) and verified expected behaviour
• Checked that existing workflows are not broken

Checklist

• My changes follow the existing conventions in this repo
• I have updated relevant documentation (e.g. README.md, action description fields)
• For changed shell scripts (if applicable): I ran shellcheck, used an appropriate shebang and error handling, and preserved required executable permissions
• For changed actions/scripts (if applicable): I added or updated validation, tests, or clear manual verification steps
• For changed JavaScript files (if applicable): I ran the relevant tests and linting/formatting checks
• For changed Python files (if applicable): I ran the relevant tests and linting/formatting checks
• For Dockerfile changes (if applicable): I reviewed the base image, build context, image size, and runtime security
• For changed actions (if applicable): I updated the action.yml interface, defaults, outputs, and examples as needed
• I reviewed security implications, including least-privilege permissions and safe handling of inputs, secrets, and tokens (if applicable)
• For workflow changes (if applicable): I reviewed triggers, permissions, concurrency, and fork safety
• I have assigned a reviewer

[probelabs]

This PR introduces a new static analysis workflow using zizmor to audit the repository's GitHub Actions for security and best practices.

Files Changed Analysis

• .github/workflows/zizmor.yml: A new reusable workflow that performs the zizmor scan. It is configurable, supports SARIF uploads, Slack notifications, and can enforce failure based on finding severity.
• .github/workflows/zizmor-self.yml: A new workflow that uses the reusable zizmor.yml to scan this repository on pushes to main and on pull requests.
• .github/zizmor.yml: A configuration file for zizmor, specifying that first-party Tyk actions should be pinned by reference (ref-pin), while all other actions must be pinned by hash (hash-pin).
• .pre-commit-config.yaml: Adds a zizmor pre-commit hook to enable local scanning for developers before committing changes.

Architecture & Impact Assessment

• Accomplishment: Integrates automated security scanning for GitHub Actions into the CI/CD pipeline, improving the security posture of the repository's automation.
• Key Technical Changes:
  • Addition of a reusable, event-driven security scanning workflow.
  • Enforcement of action pinning policies to prevent supply chain attacks.
  • Integration with local development workflows via pre-commit hooks.
• Affected Components: The primary impact is on the CI/CD system. All current and future GitHub Actions workflows in this repository will be subject to these new security checks.

Here is a visualization of the new workflow process:

graph TD
    A[Push or PR] --> B{Trigger zizmor-self.yml};
    B --> C[Call reusable zizmor.yml];
    C --> D[Run zizmor Scan];
    D --> E{Findings Found?};
    E -- Yes --> F["Generate Reports (SARIF, JSON)"];
    F --> G[Upload SARIF to Code Scanning];
    F --> H[Annotate PR with Findings];
    F --> I[Send Slack Notification];
    F --> J{Enforcement Enabled?};
    J --|Yes and Threshold Exceeded|--> K[Fail Workflow];
    J --|No or Threshold OK|--> L[Pass];
    E -- No --> L[Pass];

Loading

Scope Discovery & Context Expansion

The introduction of a reusable workflow (zizmor.yml) and an organization-specific rule in .github/zizmor.yml (for TykTechnologies/*) suggests this implementation is a pattern intended for wider adoption across other repositories in the organization. The workflow is self-contained and introduces a new security gate for any changes to GitHub Actions within this repository.

Metadata

• Review Effort: 2 / 5
• Primary Label: enhancement

---

Powered by Visor from Probelabs

Last updated: 2026-08-06T03:40:53.811Z | Triggered by: pr_opened | Commit: a149839

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

[probelabs]

Security Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/zizmor.yml:20-23	The `zizmor` tool is installed from a package repository using a version tag (`1.29.0` by default), not a content hash. This creates a potential supply chain risk if the package is compromised. An attacker could publish a malicious version under the same tag, leading to arbitrary code execution in the CI environment. 💡 Suggestion For enhanced security, use a dependency management system that supports hash-pinning (e.g., a `requirements.txt` file with `--hash` options) and install dependencies from it. This ensures the integrity of the tool being executed.
🟡 Warning	.pre-commit-config.yaml:4	The pre-commit hook for `zizmor` is pinned to a mutable git tag (`v1.29.0`) instead of an immutable commit hash. This poses a supply chain risk, as the tag could be moved to point to a malicious commit. 💡 Suggestion To mitigate this, update the `rev` to the full commit SHA corresponding to the `v1.29.0` tag. You can get the commit hash by inspecting the tag in the source repository or by running `pre-commit autoupdate --freeze`.

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/zizmor.yml:72-97	The `zizmor` scanner is executed three separate times (on lines 76, 77, and 97) to produce `sarif`, `json`, and `github` (annotations) formats. This is inefficient as it requires scanning the same files multiple times within the same job. 💡 Suggestion To improve performance and reduce redundancy, run `zizmor` once to generate a JSON report. Then, use this single JSON output to generate other required artifacts. A script can parse the JSON to create annotations using workflow commands (e.g., `::warning file=<file>,line=<line>::<message>`). If a JSON-to-SARIF converter is not available, this would still reduce the number of scans from three to two (one for JSON/annotations, one for SARIF).

Security Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/zizmor.yml:20-23	The `zizmor` tool is installed from a package repository using a version tag (`1.29.0` by default), not a content hash. This creates a potential supply chain risk if the package is compromised. An attacker could publish a malicious version under the same tag, leading to arbitrary code execution in the CI environment. 💡 Suggestion For enhanced security, use a dependency management system that supports hash-pinning (e.g., a `requirements.txt` file with `--hash` options) and install dependencies from it. This ensures the integrity of the tool being executed.
🟡 Warning	.pre-commit-config.yaml:4	The pre-commit hook for `zizmor` is pinned to a mutable git tag (`v1.29.0`) instead of an immutable commit hash. This poses a supply chain risk, as the tag could be moved to point to a malicious commit. 💡 Suggestion To mitigate this, update the `rev` to the full commit SHA corresponding to the `v1.29.0` tag. You can get the commit hash by inspecting the tag in the source repository or by running `pre-commit autoupdate --freeze`.

\n\n ### Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/zizmor.yml:72-97	The `zizmor` scanner is executed three separate times (on lines 76, 77, and 97) to produce `sarif`, `json`, and `github` (annotations) formats. This is inefficient as it requires scanning the same files multiple times within the same job. 💡 Suggestion To improve performance and reduce redundancy, run `zizmor` once to generate a JSON report. Then, use this single JSON output to generate other required artifacts. A script can parse the JSON to create annotations using workflow commands (e.g., `::warning file=<file>,line=<line>::<message>`). If a JSON-to-SARIF converter is not available, this would still reduce the number of scans from three to two (one for JSON/annotations, one for SARIF).

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

Severity	Location	Issue
🟠 Error	.github/workflows/zizmor.yml:71-89	The workflow executes the `zizmor` static analysis tool three times on the same codebase to generate three different output formats (`sarif`, `json`, and `github`). This is inefficient and triples the execution time and resource consumption for the scanning part of the job. 💡 Suggestion To optimize the workflow, run `zizmor` only once to generate a single structured output like SARIF. The SARIF file (which is JSON-based) can then be parsed using `jq` to both generate the summary for Slack and create the GitHub annotations. This would reduce the number of `zizmor` executions from three to one, significantly speeding up the workflow.
🟡 Warning	.github/workflows/zizmor.yml:94-100	The 'Summarise findings' step invokes the `jq` command five separate times to parse the same `results.json` file. Each invocation starts a new process and reads and parses the file from scratch, which is inefficient. 💡 Suggestion Consolidate the counting logic into a single `jq` command that parses the file once and computes all severity counts simultaneously. This reduces process overhead and file I/O.

---

Powered by Visor from Probelabs

Last updated: 2026-08-06T03:40:18.722Z | Triggered by: pr_opened | Commit: a149839

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