Forem: depmedicdev-byte

ci-doctor vs octoscan: when to use which

depmedicdev-byte — Tue, 28 Apr 2026 13:06:33 +0000

octoscan is a Go-based security scanner from Synacktiv that audits GitHub Actions workflows for supply-chain vulnerabilities. People keep asking how it stacks up against ci-doctor. Honest answer: they're complementary - run both.

tl;dr

octoscan: pure security focus. Goes deep on injection, dangerous triggers, runner take-over patterns.
ci-doctor: security + cost + reliability. Broader scope, less depth on pure security.

Where octoscan wins

Deep injection analysis. Tracks user-controllable context (github.event.*) into shell commands across step boundaries.
Dangerous trigger combinations. Sub-rule precise on pull_request_target + checkout patterns.
Self-hosted runner take-over patterns. Catches non-ephemeral runner usage that lets a forked PR hijack the runner.
Synacktiv pedigree. They're a real offsec firm with public publications.
Single Go binary. No runtime dependency.

Where ci-doctor wins

Cost rules octoscan does not have. missing-concurrency, missing-cache, expensive-runner, cron-storm, wide-paths, service-no-healthcheck. These hit the bill, not the build log.
Reliability rules octoscan does not have. missing-timeout-minutes, flaky-retries, legacy-actions-version.
Auto-fix mode. npx ci-doctor --fix rewrites four safe categories in place. octoscan is read-only.
Sister CIs. gitlab-ci-doctor, bitbucket-ci-doctor, azure-pipelines-ci-doctor, circleci-ci-doctor. octoscan is GitHub-only.
Zero install via npx ci-doctor. No compile, no PATH wiring.
Companion ci-doctor-action with sticky PR comment + SARIF.

Run them side by side

name: ci-audit
on: pull_request
permissions:
  contents: read
  security-events: write
jobs:
  octoscan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          curl -fsSL -o octoscan https://github.com/synacktiv/octoscan/releases/latest/download/octoscan_linux_amd64
          chmod +x ./octoscan
          ./octoscan scan . > octoscan.json || true
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: octoscan.sarif
          category: octoscan
  ci-doctor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: depmedicdev-byte/ci-doctor-action@v1

Both reports show under the Security tab in different categories. They don't conflict.

Why I bother writing these

Same reason I wrote the zizmor comparison and the actionlint comparison. Every "X vs Y" comparison written by one of the maintainers is suspicious by default; I'd rather you have the honest version.

Open an issue if anything here is wrong or outdated.

Full version with styled comparison: /compare/ci-doctor-vs-octoscan.html.

ci-doctor vs actionlint: when to use which

depmedicdev-byte — Tue, 28 Apr 2026 13:06:32 +0000

I maintain ci-doctor. The most common question I get is "isn't this what actionlint does?"

Short answer: no, and you should run both. Here's why.

tl;dr

Run both. We do, on every depmedic repo. actionlint for correctness, ci-doctor for cost and reliability. They take roughly 6 ms each on a typical repo.

Where actionlint wins

Shell script linting via shellcheck. Catches [[ $foo == "bar" ]] instead of [[ "$foo" == "bar" ]], missing quotes, unsafe glob expansion, the whole shellcheck rule library inside run: blocks.
Expression / context typing. Knows github.event.repository.private is a boolean and complains if you compare it to a string.
Action input validation. Reads each action's action.yml and verifies you're passing the right inputs.
Matrix matrix matrix. Rich validation for strategy.matrix.include / exclude patterns.
Pure Go binary, very fast, very mature, written by rhysd who knows GitHub Actions cold.

Where ci-doctor wins

Cost rules actionlint does not have. missing-concurrency, missing-cache, expensive-runner, cron-storm, wide-paths. These show up in the bill, not in the build log.
Reliability rules actionlint does not have. missing-timeout-minutes, flaky-retries, legacy-actions-version, service-no-healthcheck.
Auto-fix mode. npx ci-doctor --fix rewrites four safe categories in place.
$-denominated cost via gha-budget. Pairs cleanly.
SARIF + sticky PR comment via ci-doctor-action.
Same engine ports to GitLab, Bitbucket, Azure Pipelines, CircleCI with CI-native rules. One mental model across stacks.

Run them side by side

name: ci-audit
on: pull_request
permissions:
  contents: read
  security-events: write
jobs:
  actionlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: reviewdog/action-actionlint@v1
  ci-doctor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: depmedicdev-byte/ci-doctor-action@v1

12 seconds total. Reports go to different categories (actionlint inline review comments, ci-doctor sticky comment + Code Scanning). They don't conflict.

Honest comparison styled

Full table at /compare/ci-doctor-vs-actionlint.html. Other comparisons in the family:

vs zizmor (security-focused analyzer)
vs super-linter
vs mega-linter
vs octoscan

Why I bother writing these

Because every "X vs Y" comparison written by one of the maintainers is suspicious by default, and I'd rather you have the honest version than discover the trade-offs after committing one to your CI pipeline. If anything here is wrong or outdated, open an issue and I'll fix it.

We do not pay for placement and we do not accept paid placement.

ci-doctor vs zizmor: when to use which (honest take from one of the maintainers)

depmedicdev-byte — Tue, 28 Apr 2026 12:32:04 +0000

I maintain ci-doctor. People keep asking how it stacks up against zizmor, William Woodruff's Rust-based GitHub Actions security analyzer. So here's the honest version, not the marketing version.

tl;dr — If your priority is supply-chain security and you only care about that, run zizmor first. If you also want cost waste catches and reliability rules in the same pass, add ci-doctor. Both have SARIF output, both are MIT.

Where zizmor wins

Deeper template-injection analysis. Traces user-controlled context (github.event.issue.title, github.event.pull_request.head.ref) into run: blocks across step boundaries.
Sub-rule precision on pull_request_target + checkout patterns. Knows the difference between checking out a PR head, checking out the base, and the new "trusted" mode you can opt into.
Audits self-hosted runner labels, impostor commits, ref confusion, cache poisoning. ci-doctor does not have any of these.
23+ pure security rules vs ci-doctor's 6 security rules.
Native Rust binary, no Node runtime needed. Single download, fast cold start.
Maintained by a well-known supply-chain security researcher who's been doing this for years.

Where ci-doctor wins

Cost rules zizmor does not have. missing-concurrency, missing-cache, expensive-runner, cron-storm, wide-paths, service-no-healthcheck. These are real money on free-tier and paid-tier alike.
Reliability rules zizmor does not have. missing-timeout-minutes, flaky-retries, legacy-actions-version.
Auto-fix mode. npx ci-doctor --fix rewrites four safe categories in place. zizmor is read-only.
Pairs with gha-budget for $-denominated cost numbers per workflow.
Zero install via npx ci-doctor — no compile, no PATH wiring.
Same engine ports to GitLab, Bitbucket, Azure, CircleCI. One mental model across CIs.

Rule overlap, side by side

Concern	zizmor	ci-doctor
Pin `uses:` to SHAs	yes	yes
Template injection from user input	deep	basic
`pull_request_target` + checkout	yes (sub-rule precise)	yes
Container image not pinned to digest	no	yes
Self-hosted runner label spoofing	yes	no
Cache poisoning vectors	yes	no
Service container missing healthcheck	no	yes
Missing `concurrency:` (cost)	no	yes
Missing `timeout-minutes:` (cost+reliability)	no	yes
Missing language/dep cache (cost)	no	yes
Expensive runner (cost)	no	yes
Auto-fix mode	no	yes (`--fix`)
SARIF output	yes	yes
Other CIs (GitLab, Bitbucket, Azure, CircleCI)	no (GHA-only)	yes

Run them side by side

This is what I recommend for any team that takes both security and cost seriously:

name: ci-audit
on: pull_request
permissions:
  contents: read
  security-events: write
jobs:
  zizmor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: '3.12' }
      - run: pip install zizmor
      - run: zizmor --format sarif . > zizmor.sarif
      - uses: github/codeql-action/upload-sarif@v3
        with: { sarif_file: zizmor.sarif, category: zizmor }
  ci-doctor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: depmedicdev-byte/ci-doctor-action@v1

Both reports land in the same Security tab under different categories. No conflict.

What about actionlint, super-linter, MegaLinter, woodpecker?

Woodpecker is a CI system, not a workflow linter, so it isn't in the same category.
actionlint is the gold standard for syntactic and shell-safety checks. ci-doctor is cost and reliability first. They're complementary - I run both on my own repos. Honest comparison: /compare/ci-doctor-vs-actionlint.html.
super-linter and MegaLinter are heavyweight wrappers that bundle 50+ language linters and incidentally include actionlint. Different problem entirely.

Why I wrote this

Because every "X vs Y" comparison written by one of the maintainers is suspicious by default, and I'd rather you have the honest version than discover the trade-offs after committing one to your CI.

If anything here is wrong or outdated, open an issue and I'll fix it. We do not pay for placement and we do not accept paid placement.

Full version with the table styled and link colors fixed: /compare/ci-doctor-vs-zizmor.html.

I shipped 4 things this week: a GitHub Action, an Azure Pipelines auditor, a CircleCI auditor, and a comparison page nobody asked for

depmedicdev-byte — Tue, 28 Apr 2026 12:30:33 +0000

Week 2 of depmedic. Four shipments, all free, all MIT.

1. ci-doctor-action - the easiest way to put ci-doctor on a PR

Until now you'd have to write a workflow that ran npx ci-doctor, piped output to tee, then either uploaded SARIF or posted a comment. That's three steps, and most people never got past step one.

ci-doctor-action is a composite Action that does it all in three lines:

name: ci-doctor
on:
  pull_request:
    paths:
      - '.github/workflows/**'
permissions:
  contents: read
  pull-requests: write
  security-events: write
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: depmedicdev-byte/ci-doctor-action@v1

You get:

a sticky markdown PR comment with the findings table (one per PR, updated in place when you push fixes)
SARIF uploaded to GitHub Code Scanning so findings show under the Security tab
a configurable fail-on threshold (default error; bump to warn for stricter teams)
pinnable down to a SHA for fully reproducible audits

v1 mutable tag is already pushed at the same commit so consumers can use @v1. Pinning the action AND its CLI is the gold-standard pattern - more on that below.

2. azure-pipelines-ci-doctor - the fourth sister CLI

The depmedic family now covers GitHub Actions, GitLab CI, Bitbucket Pipelines, and Azure Pipelines.

azure-pipelines-ci-doctor ships with eight rules tuned to the quirks of Azure DevOps:

expensive-vm-image - flags macOS-latest (~10x cost) and windows-latest (~2x) when the steps don't actually need them
container-no-pin - floating container.image tags
missing-timeout-in-minutes - default is 60 min hosted, 360 min self-hosted; one hang can burn the whole window
missing-cache - npm/pip/maven/gradle/cargo/go/bundler installs without a Cache@2 task
wide-trigger - unscoped trigger: or pr:
inline-secret-leak - $(SECRET_NAME) macros that expand inline in build logs (the #1 Azure secret-handling mistake)
legacy-task-version - outdated built-in task majors (e.g. UseNode@1)
unbounded-parallelism - strategy.parallel >= 5 without maxParallel

npx azure-pipelines-ci-doctor              # audit current repo
npx azure-pipelines-ci-doctor --markdown   # PR-comment friendly
npx azure-pipelines-ci-doctor --rules      # list all 8

In-browser scanner at /scan-azure.html alongside the GitHub, GitLab, and Bitbucket equivalents.

3. circleci-ci-doctor - the fifth sister CLI

I promised this was "drafting now" in last week's newsletter, so I shipped it the same day. circleci-ci-doctor is 8 rules over .circleci/config.yml:

expensive-resource-class - xlarge / 2xlarge / 3xlarge without heavy build commands (each tier roughly doubles credits/min)
macos-executor - macos: executor without xcodebuild/swift/fastlane (~10x Linux Docker cost)
docker-no-pin - docker.image not pinned to @sha256:...
missing-cache - install commands with no restore_cache/save_cache pair
orb-no-pin - orb ref not MAJOR.MINOR.PATCH (e.g. circleci/node@5 or @volatile)
missing-no-output-timeout - hang-prone run: step (tests, deploys, migrations) without no_output_timeout
secret-echo - env, printenv, set -x, echo $TOKEN in a run: block
wide-filters - workflow job has no filters: (runs on every branch)

Browser scanner at /scan-circleci.html.

4. ci-doctor vs zizmor - an honest comparison nobody asked for

zizmor is great. It's a Rust-based static analyzer focused on supply-chain and template-injection security audits. People keep asking which to use.

The honest answer is: run both.

Concern	zizmor	ci-doctor
Pin `uses:` to SHAs	yes	yes
Template injection from user input	deep	basic
`pull_request_target` + checkout	yes (sub-rule precise)	yes
Container image not pinned to digest	no	yes
Self-hosted runner label spoofing	yes	no
Cache poisoning vectors	yes	no
Service container missing healthcheck	no	yes
Missing `concurrency:` (cost)	no	yes
Missing `timeout-minutes:` (cost+reliability)	no	yes
Missing language/dep cache (cost)	no	yes
Expensive runner (cost)	no	yes
Auto-fix mode	no	yes (`--fix`)
SARIF output	yes	yes
Other CIs (GitLab, Bitbucket, Azure, CircleCI)	no	yes

Side-by-side workflow:

name: ci-audit
on: pull_request
permissions:
  contents: read
  security-events: write
jobs:
  zizmor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: '3.12' }
      - run: pip install zizmor
      - run: zizmor --format sarif . > zizmor.sarif
      - uses: github/codeql-action/upload-sarif@v3
        with: { sarif_file: zizmor.sarif, category: zizmor }
  ci-doctor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: depmedicdev-byte/ci-doctor-action@v1

Full comparison: /compare/ci-doctor-vs-zizmor.html.

Pattern of the week: pin the action AND its CLI

If you adopt ci-doctor-action for production gating, pin both:

- uses: depmedicdev-byte/ci-doctor-action@1bd71901bbe5b1630ceea73d27597364c9af683 # v1.0.0
  with:
    ci-doctor-version: '0.5.0'

That way an upstream npm publish can't change what your gate flags or silently bump severity. Reproducible audits are the only audits worth gating on.

What's next

The CircleCI Pin Bar - same methodology as the GitHub Actions one (59% pinned to SHA), applied to the top 30 OSS repos that publish their .circleci/config.yml.
An end-to-end scan of .circleci/config.yml files across the 100-repo leaderboard.
A "how much will my repo cost on each CI?" tool that takes a single set of workflows and prices them on GHA, GitLab, Bitbucket, Azure, and CircleCI side by side.

Subscribe at /newsletter.html if you want issue #3 in your inbox Sunday.

I scanned 5 popular OSS repos in 5 minutes. Here's what I found.

depmedicdev-byte — Tue, 28 Apr 2026 03:06:33 +0000

Earlier today I shipped scan.html: a one-page in-browser tool that takes any public GitHub repo URL, fetches its .github/workflows/*.yml, and returns a per-workflow report using ci-doctor (14 rules) and gha-budget (per-job pricing). Runs entirely client-side via the GitHub public API. No signup, nothing uploaded.

To make sure it actually works on real-world repos and not just on the canned examples I built it against, I picked 5 well-known npm-ecosystem repos that I had not specifically optimized for, and ran them through. All 5 are maintained by experienced engineers. None of these are random small repos; they all matter.

The 5 repos

Repo	Workflows	Per-run $	Modeled $/mo*	Findings (err / warn / info)
axios/axios	8	$2.62	$2,362	40 (12 / 27 / 1)
eslint/eslint	8	$1.54	$1,382	46 (0 / 40 / 6)
vitejs/vite	12	$1.09	$979	26 (0 / 25 / 1)
prettier/prettier	17	$1.02	$922	32 (6 / 23 / 3)
sveltejs/svelte	5	$0.70	$634	14 (0 / 10 / 4)
Total	50	$6.97	$6,279	158 (18 / 125 / 15)

*Modeled at 30 runs/day, 8 min/job, on standard ubuntu-latest GitHub-hosted runner pricing. Real spend depends on actual run frequency, runner choice, and OSS rate-limit credits. The point of the column is comparison, not accusation.

The same 3 rules show up in all 5 repos

This is the part I find genuinely interesting. These repos have nothing in common architecturally - vite is a bundler, axios is an HTTP client, eslint is a static analyzer, etc. - but the top-3 ci-doctor findings are nearly identical across all of them:

missing-timeout (76 hits across 5 repos). No timeout-minutes: on jobs, so a hung step bills until GitHub's 6-hour default cap. Every repo has this.
missing-concurrency (20 hits). Push 3 commits to a PR in 30 seconds, you get 3 stacked CI runs and GitHub bills all 3. concurrency: with cancel-in-progress: true kills the first 2 in milliseconds. Free 30-50% CI savings on PR-heavy repos.
missing-cache (16 hits, mostly in eslint). actions/setup-node without cache: 'npm' / 'pnpm' / 'yarn' means every job re-downloads node_modules. Slow and expensive.

The interesting outlier is axios/axios with 12 error-severity findings. All 12 are deprecated-action: workflows still pinned to actions/checkout@v3, actions/setup-node@v3, and actions/upload-artifact@v3. v3 of upload-artifact was deprecated in late 2024 and the v3 endpoint is being shut off. These are not "save 3% of your CI bill" findings; these are "your CI will silently start failing" findings.

Why these specific 3 are everywhere

My theory: GitHub Actions doesn't push you to add any of them. The workflow files YAML-validates fine without a timeout, without concurrency, without a cache. The CI passes. The PR ships. There is no linter built in to nudge anyone toward better defaults. So the same 3 smells survive in every repo I scan, including in mine before I built ci-doctor.

This is a tooling problem, not a competence problem. The maintainers of all 5 of these repos are excellent engineers. The smells are just invisible until something points at them.

What to do about it (5-minute fixes)

For each of the top 3 rules, here's the smallest possible change:

1. Add a job-level timeout

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15   # <-- add this
    steps: ...

2. Add concurrency at workflow scope

# top of every workflow that runs on PRs
concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.ref }}
  cancel-in-progress: true

3. Tell setup-node what package manager you use

- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'      # or 'pnpm' or 'yarn'

Or just run npx ci-doctor --fix and let it patch missing-concurrency, missing-timeout, wide-trigger, and artifact-no-retention in place. The other 10 rules need a human to look at them, but those 4 are mechanical.

Run this scan on your own repo

Free, browser-only, no signup: https://depmedicdev-byte.github.io/scan.html

Paste any public GitHub repo URL. Get the same per-workflow report above for your own code in about 10 seconds. Shareable result URL. Nothing uploaded.

Methodology

All 5 repos were pulled via the GitHub public API, no auth.
Each .github/workflows/*.yml was passed through ci-doctor 0.4.1 (14 rules) and gha-budget for per-job pricing.
Cost = sum of all jobs at GitHub-hosted standard ubuntu-latest rates, assuming 8 min/job.
Monthly = per-run * 30 runs/day * 30 days. Self-hosted and large-runner jobs are unpriced.
This is the same engine that runs in the browser at /scan.html. The 20-repo version of this analysis lives at /benchmarks.html with per-repo deep dives.

What this is NOT

This isn't an attack on any of these projects. They all ship excellent software, and "modeled $/mo" is not the same as "actual $/mo" - large OSS projects get free GitHub Actions credits, run things conditionally, and use self-hosted runners for the heavy lifting. The point is that the same three workflow-YAML patterns show up in every repo I scan, including mine before I started building ci-doctor.

Free CLIs: ci-doctor, gha-budget, pin-actions. All MIT.

If the in-browser report flags 5 things in your workflow and you'd rather just copy a known-good template than fix one rule at a time, the Cut Your CI Bill cookbook ships 30 production patterns: monorepo dispatch, OIDC publish, security gates, matrix trims, the works. $19 one-time, MIT-licensed templates. https://depmedicdev-byte.github.io

GitHub Actions linters compared - actionlint, ci-doctor, sherif, octoscan

depmedicdev-byte — Mon, 27 Apr 2026 23:41:03 +0000

Disclosure: I maintain ci-doctor. The comparison below describes each tool by what it documents and ships, not by my opinion of its authors. Run all four on the same workflow to see for yourself.

GitHub Actions YAML is small enough that one tool could in theory validate everything: syntax, secret hygiene, runner cost, supply-chain pinning, deprecated actions, untrusted inputs. In practice, the open-source landscape splits this work across four projects. They overlap in some areas and miss each other in others.

The short version

Concern	actionlint	ci-doctor	sherif	octoscan
YAML / shell syntax	yes	no	no	no
Untrusted input injection	partial	no	no	yes
Action ref pinned to SHA	no	yes	no	yes
Top-level `permissions`	no	yes	no	yes
Concurrency / cancel-in-progress	no	yes	no	no
Job `timeout-minutes`	no	yes	no	no
Cache hint on setup-* actions	no	yes	no	no
Artifact retention-days	no	yes	no	no
Matrix combinatorial explosion	no	yes	no	no
Cost projection in dollars	no	via `gha-budget`	no	no
Auto-fix in place	no	yes	no	no
Auto-pin actions to SHA	no	via `pin-actions`	no	no
SARIF output for Code Scanning	via wrappers	yes	no	yes
Monorepo / multi-repo focus	no	no	yes	no

actionlint

The reference syntax checker. Written in Go, fast, no dependencies. Catches expression syntax errors, unknown event names, unknown contexts, malformed shell scripts in run: blocks (it invokes shellcheck), and a small number of security patterns like ${{ github.event.pull_request.title }} in a shell context.

What it doesn't do: enforce policy. actionlint tells you whether your YAML parses and runs; it does not tell you whether your workflow is cheap, secure-by-default, or maintainable.

Use it for: pre-merge syntax validation. Catching shell quoting bugs.

ci-doctor

Policy and cost focus. Eleven rules grouped into cost, security, and maintenance. Includes --fix mode that auto-applies safe fixes (permissions, concurrency, timeouts, artifact retention) and --sarif for GitHub Code Scanning. Pairs with pin-actions for SHA pinning and gha-budget for dollar cost projection.

What it doesn't do: validate YAML or shell syntax (use actionlint), detect injection vulnerabilities at the expression level (use octoscan), or compare workflows across repos (use sherif).

Use it for: cost discipline. Default-secure policy. PR comments. Code Scanning ingestion. Auto-fixing the four common issues that have a single safe answer.

sherif

Cross-repo / monorepo lens. Sherif's value is comparing workflows across many repos under one org and surfacing inconsistency: same job, different timeout; same matrix, different runner; same checkout step, different version.

What it doesn't do: ship policy rules of its own. It tells you which workflows disagree; it does not say which one is right.

Use it for: standardising CI across an org once you've decided on a baseline.

octoscan

Security-first. Looks for untrusted-input injection patterns specifically (the ${{ github.event.* }} in shell context class), unpinned actions, missing top-level permissions, and similar hardening misses. Emits SARIF.

What it doesn't do: cost analysis, auto-fix, cache hints, retention policy, matrix sanity.

Use it for: security audit before a release. Quick check that your actions/checkout@... isn't shipping someone else's code.

How to combine them

None of these tools is a superset of the others. The cheapest composition that covers all four lenses is:

# syntax
actionlint

# cost + maintenance + auto-fix
npx ci-doctor --fix
npx ci-doctor --sarif > ci-doctor.sarif

# supply chain
npx pin-actions --check

# expression-level injection scanning
octoscan run

# cross-repo consistency, if you run an org
sherif --workspace .

Total runtime on a normal repo: under five seconds.

What I'd actually run in CI

In order, fail fast:

actionlint - syntax must be valid before policy makes sense.
npx pin-actions --check - cheap, supply chain.
npx ci-doctor --sarif > ci-doctor.sarif + codeql-action/upload-sarif - findings as PR annotations.
octoscan if your workflow accepts external input.

The first three are non-negotiable for any repo with public CI. The fourth is non-negotiable for any workflow that runs against PRs from forks.

Try without installing

If you want to see what ci-doctor would say about your workflow without installing anything, paste it at https://depmedicdev-byte.github.io/audit.html. Same engine, runs entirely in your browser, share the result by URL.

I priced the GitHub Actions workflows of 20 famous OSS projects. The results were ugly.

depmedicdev-byte — Mon, 27 Apr 2026 23:25:53 +0000

There is a class of "best practices for GitHub Actions" article that just lists the same five tips - cancel concurrent runs, set a timeout, cache your dependencies, pin actions to a SHA, narrow your matrix. Every one of those articles is correct, and almost none of them tell you how often even the best open source projects miss those exact things.

So I pulled the live workflow YAML out of .github/workflows for 20 well-known repositories, priced every job at GitHub's published per-minute rates, and ran a linter against the whole set. The data and the tools are public.

Headline numbers, all from public workflow YAML on main:

20 repos
229 workflows scanned
388 priced jobs (159 more were jobs running on self-hosted or unknown runners and excluded from cost math)
902 CI findings flagged by ci-doctor
About $51,000 of combined monthly spend assuming each job runs 30 times per day at 8 minutes per run

The interactive table is at https://depmedicdev-byte.github.io/benchmarks.html. A few of the per-repo numbers from the dataset:

Repo	$/run	Monthly @ 30/day	Findings
denoland/deno	$18.30	$16,473.60	84
facebook/react	$16.19	$14,572.80	87
vercel/next.js	(varies, see table)	(varies)	(varies)

(The full table has all 20 repos, sorted by monthly spend.)

What every project gets wrong

Across 902 findings, the distribution is heavy on a small number of issues:

Rule	Count
missing-timeout	364
missing-cache	113
pinned-action-sha	91
missing-permissions	80
artifact-no-retention	73
matrix-overcommit	52
missing-concurrency	52
deprecated-action	39
fetch-depth-zero	22
expensive-runner	12
wide-trigger	4

missing-timeout is the single biggest one. Out of 388 priced jobs, 364 of them are running without a timeout-minutes. A stuck job in CI does not exit on its own. It runs until GitHub kills it at 360 minutes, which is six hours of paid runner time, on top of whatever the job was actually trying to do.

missing-cache is the second. Most projects have one cached language tool (npm, or pip, or whatever) and then forget to cache the rest. Every pnpm install or bundle install or cargo build that runs without a cache costs you 1-3 paid minutes per job, every run.

missing-concurrency only shows up 52 times but it is the highest-leverage one to fix. Without a concurrency: block, a developer who pushes three quick fixes in a row triggers three full CI runs back to back. With a concurrency: block, the first two cancel and only the third runs. On an active PR this can cut your monthly spend in half.

How the data was generated

Three small open-source tools, all on npm:

# Audit a workflow:
npx ci-doctor .github/workflows/ci.yml

# Estimate the cost of a workflow:
npx gha-budget .github/workflows/ci.yml --runs-per-day 30 --minutes 8

# Pin every action in a workflow to a SHA:
npx pin-actions

The benchmark fetched workflow YAML for each repo via the GitHub REST API, then ran ci-doctor and gha-budget against every file. Each priced job was multiplied by 30 runs/day and 30 days/month. Self-hosted runners and runs-on values not in the GitHub price sheet were excluded from cost math but still scanned for findings. Code is in https://github.com/depmedicdev-byte if you want to reproduce it.

What you can do today

If you have a workflow you suspect is expensive, the fastest check is to paste the YAML into one of these:

https://depmedicdev-byte.github.io/audit.html - paste, get findings, no install
https://depmedicdev-byte.github.io/budget.html - paste, get $/run and monthly projection

Both run entirely in your browser. They share findings and totals via URL hash so you can send a teammate a link.

What I'd actually do

If I had to fix one thing per repo for maximum dollar impact, the order would be:

Add concurrency: { group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: true } to every PR-triggered workflow.
Add timeout-minutes: 15 (or whatever your real p99 is) to every job.
Cache whatever your install step is downloading. actions/cache for ad-hoc dirs, the official setup actions for language tools.
Pin every uses: to a full commit SHA. This is a security move more than a cost move, but the same pin-actions CLI handles it.

Those four changes alone, applied across the 20 projects in the dataset, would cut the combined monthly spend roughly in half. The longer set of patterns (60+) is in the Cut Your CI Bill cookbook but you do not need it to fix the top three.

Re-runs and updates

The dataset will be re-run monthly. If you want a specific repo added, open an issue on any of the tool repos and I will include it.

Forem: depmedicdev-byte

ci-doctor vs octoscan: when to use which

tl;dr

Where octoscan wins

Where ci-doctor wins

Run them side by side

Why I bother writing these

ci-doctor vs actionlint: when to use which

tl;dr

Where actionlint wins

Where ci-doctor wins

Run them side by side

Honest comparison styled

Why I bother writing these

ci-doctor vs zizmor: when to use which (honest take from one of the maintainers)

Where zizmor wins

Where ci-doctor wins

Rule overlap, side by side

Run them side by side

What about actionlint, super-linter, MegaLinter, woodpecker?

Why I wrote this

I shipped 4 things this week: a GitHub Action, an Azure Pipelines auditor, a CircleCI auditor, and a comparison page nobody asked for

1. ci-doctor-action - the easiest way to put ci-doctor on a PR

2. azure-pipelines-ci-doctor - the fourth sister CLI

3. circleci-ci-doctor - the fifth sister CLI

4. ci-doctor vs zizmor - an honest comparison nobody asked for

Pattern of the week: pin the action AND its CLI

What's next

I scanned 5 popular OSS repos in 5 minutes. Here's what I found.

The 5 repos

The same 3 rules show up in all 5 repos

Why these specific 3 are everywhere

What to do about it (5-minute fixes)

1. Add a job-level timeout

2. Add concurrency at workflow scope

3. Tell setup-node what package manager you use

Run this scan on your own repo

Methodology

What this is NOT

GitHub Actions linters compared - actionlint, ci-doctor, sherif, octoscan

The short version

actionlint

ci-doctor

sherif

octoscan

How to combine them

What I'd actually run in CI

Try without installing

See also

I priced the GitHub Actions workflows of 20 famous OSS projects. The results were ugly.

What every project gets wrong

How the data was generated

What you can do today

What I'd actually do

Re-runs and updates