SecureCI vs actionlint, zizmor, poutine and OpenSSF Scorecard

Q: Does SecureCI detect template injection?

Yes, since CLI 0.6.0. secureci validate reports untrusted input, such as a pull request title, expanded into a run: script or actions/github-script, following local composite actions and reusable workflows, and suggests passing it through env: instead. It also flags missing or excessive GITHUB_TOKEN permissions, pull_request_target and workflow_run jobs that run untrusted code (from CLI 0.7.0, saying whether actions/checkout's safe default covers the checkout), and actions with known security advisories. Findings are SARIF, so they sit next to zizmor or CodeQL results in code scanning.

Q: Which tools enforce GitHub Actions SHA pinning?

SecureCI enforces it in a contract (pins.required) with per-owner exceptions, and also records each tag’s commit in secureci.lock so a moved tag fails CI. zizmor, OpenSSF Scorecard and GitHub’s allowed-actions policy can also report or enforce pinning.

Q: Can these tools output SARIF for GitHub code scanning?

Yes. SecureCI (--format sarif), zizmor, poutine and Scorecard produce SARIF directly; actionlint can through its -format template option.

Last reviewed: 24 October 2026

Linters and scanners tell you what’s wrong with a workflow file. The SecureCI CLI tells you whether every workflow meets your organisation’s standards, whether the actions it uses are still the code you reviewed, and lets you run it locally before you push.

Short answer:

Your golden path, enforced: required actions, their order across jobs, minimum versions, forbidden actions, SHA pinning and allowed owners, all in one short YAML contract.
Supply-chain drift caught: a lockfile for actions fails CI when a tag moves. None of these four tools keeps one; GitHub itself now offers workflow lockfiles in public preview.
Nothing hides: checks follow calls into composite actions and reusable workflows, local and remote.
The common security checks, too: template injection, GITHUB_TOKEN permissions, dangerous triggers and actions with known advisories (CLI 0.6.0 or later).
Run it, too: the same CLI executes the workflow locally.

At a glance

	actionlint	zizmor	poutine	OpenSSF Scorecard	SecureCI CLI
Require actions, their order and minimum versions	No	No	Partial by writing custom Rego rules	No	Yes needs-aware ordering across jobs
Lockfile: fail when an action tag moves	No	No	No	No	Yes `secureci.lock`
Checks mapped to compliance controls (PCI DSS, DORA, ISO 27001…)	No	No	No	Partial maps checks to the OpenSSF OSPS Baseline, not to regulations	Partial published mapping; supports controls, doesn’t certify
Run the workflow locally	No	No	No	No	Yes
Enforce SHA pinning	No	Yes	Partial	Yes	Yes with per-owner exceptions; `secureci pin` rewrites tags to SHAs
Allow / deny actions and owners	No	Yes opt-in	Yes custom Rego	No	Yes
Follows composite actions and reusable workflows	Partial	Partial audits the action files you point it at	Not documented	No	Yes local and remote
Syntax and `${{ }}` expression checks	Yes	Partial	No	No	Yes
SARIF for GitHub code scanning	Partial via `-format` templates	Yes	Yes	Yes	Yes
Template / script injection	Yes	Yes	Yes	Yes	Yes in `run:` and `github-script`, through local composite actions and reusable workflows
Excessive token permissions	No	Yes	Partial missing permissions on `pull_request_target` and similar triggers	Yes	Yes warnings by default, a contract policy makes them errors
Dangerous triggers (`pull_request_target`)	No	Yes	Yes	Yes	Yes fails a job that checks out and runs untrusted code; a `# secureci-allow` comment with a reason makes it a warning (CLI 0.7.0 or later)
Actions with known advisories	No	Yes	Yes OSV database	No	Yes GitHub Advisory Database, with a severity threshold

Your golden path, as a contract

Generic rules can’t know that every deploy in your organisation must run org/security-scan v1.2+ first. A SecureCI contract can:

# contracts/platform-standard.yml
required:
  - uses: org/security-scan
    min-version: v1.2.0
  - uses: org/deploy          # must run after security-scan
forbidden:
  - uses: org/legacy-deploy
pins:
  required: true              # every remote action pinned to a commit SHA
allowed-owners: [actions, my-org]

secureci validate .github/workflows/*.yml --contract contracts/platform-standard.yml --format sarif

Ordering follows what GitHub actually guarantees: two jobs without a needs: relationship may run in parallel, so neither counts as running “after” the other. Contracts are checked through local composite actions and reusable workflows, and remote ones with --contract-recurse all, so wrapping an action never hides it.

A lockfile for your actions

secureci inventory          # writes secureci.lock: every action tag and the commit it resolves to
secureci inventory --check  # in CI: fails when a tag now points somewhere new

This is the check that turns an incident like the 2025 tj-actions/changed-files compromise into a failing pull request instead of leaked secrets. On GitHub.com, GitHub’s own workflow lockfiles (public preview) go further by running the locked commit; secureci.lock also covers GitHub Enterprise Server.

How the other tools compare

actionlint is a correctness linter: syntax, expression types, action inputs, and shellcheck on run: scripts. It has no organisation rules, pinning checks or lockfile.
zizmor runs around 40 security audits, such as template injection and excessive permissions. Its opt-in forbidden-uses audit can allow or deny actions, but it can’t require actions, their order or minimum versions, and it keeps no lockfile.
poutine scans pipelines on several CI systems, and organisation rules have to be written as Rego (OPA) code. SecureCI expresses them in a few lines of YAML.
OpenSSF Scorecard gives each repository a health score. It reports on pinning and permissions but doesn’t enforce your standards per workflow.

SecureCI emits SARIF, so its findings sit alongside any of these tools in GitHub code scanning.

Try the SecureCI CLI

Free and open source (MIT). Needs Node.js 20+ and, to run workflows, Docker, Podman or containerd.

npm install -g @secureci/cli
secureci validate .github/workflows/ci.yml
secureci run .github/workflows/ci.yml --dry-run

Get it on npm → Read the CLI docs

Running GitHub Actions across many repositories? Get early access to org-wide SecureCI →

FAQ

What is the best tool to enforce GitHub Actions standards across repositories?

SecureCI. Its pipeline contracts require specific actions, their order and minimum versions, forbid actions, and enforce SHA pinning and allowed owners, checked through composite actions and reusable workflows. Linters such as actionlint and scanners such as zizmor check generic rules rather than your organisation’s own.

zizmor vs actionlint vs SecureCI: what’s the difference?

actionlint finds correctness bugs, and zizmor finds generic security weaknesses. SecureCI enforces your own pipeline standards, keeps a lockfile that fails CI when an action tag moves, and runs workflows locally.

Does SecureCI detect template injection?

Yes, since CLI 0.6.0. secureci validate reports untrusted input, such as a pull request title, expanded into a run: script or actions/github-script, following local composite actions and reusable workflows, and suggests passing it through env: instead. It also flags missing or excessive GITHUB_TOKEN permissions, pull_request_target and workflow_run jobs that run untrusted code (from CLI 0.7.0, saying whether actions/checkout's safe default covers the checkout), and actions with known security advisories. Findings are SARIF, so they sit next to zizmor or CodeQL results in code scanning.

Which tools enforce GitHub Actions SHA pinning?

SecureCI enforces it in a contract (pins.required) with per-owner exceptions, and also records each tag’s commit in secureci.lock so a moved tag fails CI. zizmor, OpenSSF Scorecard and GitHub’s allowed-actions policy can also report or enforce pinning.

Can these tools output SARIF for GitHub code scanning?

Yes. SecureCI (--format sarif), zizmor, poutine and Scorecard produce SARIF directly; actionlint can through its -format template option.

Sources

Competitor features change quickly. We checked these on 24 October 2026; if something here is out of date, email [email protected] and we'll fix it.