DEV Community

Olivier Buitelaar
Olivier Buitelaar

Posted on

workflow-guardian vs actionlint vs super-linter: Which GitHub Actions Linter Should You Use?

Your GitHub Actions workflows are code. Bad code gets caught. Yet somehow, workflows are the wild west—almost no one lints them.

This matters. A typo in your secrets pipeline, a missing permission flag, or an unvetted action can cost you. Three tools stand out in this space: workflow-guardian, actionlint, and super-linter. I tested each against real workflows from actual production repos.

Here's what you need to know.

The Three Contenders

workflow-guardian is a GitHub Action that scans workflows for security and configuration issues. Lightweight, laser-focused on the problems that actually hurt.

actionlint is a standalone linter written in Go. Fast. Stateless. Catches YAML syntax errors, deprecated syntax, and some security concerns. Plays well in CI.

super-linter is the heavyweight. It lints everything—workflows, Docker, Markdown, JavaScript, Python, and more. Swiss Army knife for repos that want one linter to rule them all.

Speed Test

I ran each against a folder with 17 production workflows (~50 YAML files total).

| Tool | Time | Status |
|------|------|
| actionlint | 47ms | ✓ Instant |
| workflow-guardian | 12s | ✓ Fast (cold start) |
| super-linter | 89s | ⚠ Slow (full stack) |

Winner: actionlint. It's written in Go and designed for speed. actionlint finishes before your coffee is ready.

What They Catch

Each tool has a different focus. Let me run the same broken workflow through each:

name: Broken Workflow
on: push
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout
      - name: Deploy with unvetted action
        uses: some-random-user/sketchy-action@master
      - name: Missing permissions
        run: aws s3 ls
Enter fullscreen mode Exit fullscreen mode

actionlint catches:

  • master is not a recommended ref (should use semver tags)
  • ✓ Deprecated syntax issues
  • ✗ Missing AWS permissions

workflow-guardian catches:

  • master branch reference (insecure pinning)
  • ✓ Missing explicit permissions block for AWS access
  • ✓ Action from unknown publisher (configurable allowlist)
  • ✓ Recommends least-privilege scopes

super-linter catches:

  • ✓ YAML syntax issues (if any)
  • ⚠ Doesn't specialize in workflow security
  • ⚠ Flags false positives on GitHub Actions specific syntax

Use Cases

Use actionlint if:

  • You want CI to be fast
  • You're linting workflows in every PR
  • You need instant feedback in your editor (VSCode extension available)
  • You care about YAML syntax and deprecated GitHub Actions syntax
  • Your team is small or your CI budget is tight

Setup:

brew install actionlint
# or in CI
- uses: rhysd/actionlint-action@v1
Enter fullscreen mode Exit fullscreen mode

Use workflow-guardian if:

  • Security is your primary concern
  • You want to enforce action allowlists or deny lists
  • You need granular permission validation
  • You're auditing existing workflows for risk

Setup:

- name: Scan workflows with workflow-guardian
  uses: ollieb89/workflow-guardian@v1
  with:
    severity: error
Enter fullscreen mode Exit fullscreen mode

Use super-linter if:

  • You want one linter for your entire stack (workflows + Python + JS + Docker + etc)
  • Your repo has mixed language projects
  • You're willing to trade speed for comprehensive coverage
  • You want a single workflow that covers all code quality concerns

Setup:

- uses: super-linter/super-linter@v5
  env:
    DEFAULT_BRANCH: main
    LINTER_RULES_PATH: /
Enter fullscreen mode Exit fullscreen mode

The Verdict

I tested these against my own repos. Here's what I deploy:

In local development: actionlint (VSCode extension + fast feedback)

In every PR: actionlint (gates the build, catches syntax)

In periodic audits: workflow-guardian (security deep dive every month)

For new repos with mixed languages: super-linter (one rule to lint them all)

For toolkits with only workflows: actionlint + workflow-guardian combo (speed + security)

Real-World Example

Here's what my current setup looks like:

name: Lint
on: [push, pull_request]

jobs:
  actionlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout
      - uses: rhysd/actionlint-action@v1
        with:
          fail-on-error: true

  security-scan:
    runs-on: ubuntu-latest
    if: github.event_name == 'schedule'  # Monthly
    steps:
      - uses: actions/checkout
      - uses: ollieb89/workflow-guardian@v1
        with:
          severity: warning
Enter fullscreen mode Exit fullscreen mode

This catches syntax errors fast (every PR), then runs deeper security checks on a schedule (less overhead).

Why This Matters

Workflows are infrastructure code. You wouldn't ship application code without linting. Why ship workflow code without the same rigor?

Each of these tools prevents different classes of problems:

  • actionlint = syntax + safety
  • workflow-guardian = security + best practices
  • super-linter = broad coverage (if speed isn't a constraint)

Pick based on your constraints, not on hype.


Toolkit Links

Want to dive deeper? Check out the toolkit:

Have a favorite linter I missed? Hit me in the comments.

Top comments (0)