A zero-dep CLI that scans your GitHub Actions for the mistakes that actually get repos compromised

Your CI workflow is the softest target in your repo. It runs automatically, it
has a GITHUB_TOKEN that can push commits, and it can read your secrets. The
supply-chain attacks of 2025 — reviewdog, tj-actions/changed-files — all came
in through the same unlocked door: a workflow that trusted a mutable action
tag, so when the upstream tag got repointed at malicious code, every consumer
ran it with full privileges.

The uncomfortable stat: 71% of repositories never pin their actions to a commit
SHA. @v4 is not a version — it's a
moving pointer someone else controls.

I wanted a five-second check for this and the other top footguns, with nothing to
install and nothing to configure. So I built actionsec.

npx actionsec

.github/workflows/ci.yml
  ✗ critical  L12   pull-request-target-checkout  pull_request_target checks out PR head code — untrusted code runs with a write token
  ✗ critical  L16   script-injection              untrusted github.event.pull_request.title in a run step
  ✗ high      L5    broad-permissions             permissions: write-all gives the token full read/write
  ✗ high      L13   unpinned-action               some-marketplace/deploy-action@main is a mutable branch — pin to a SHA
  ✗ medium    L10   unpinned-action               actions/checkout@v4 is a mutable tag — pin to a SHA

✗ 5 issue(s) in 1 of 1 file(s) — 2 critical, 2 high, 1 medium

The five checks

The interesting constraint: zero dependencies on YAML

Workflows are YAML, and here's the thing — neither Node nor Python ships a YAML
parser in the standard library. Pulling one in would mean the tool itself has a
dependency tree (the exact thing a security tool shouldn't have).

So actionsec doesn't parse YAML into a tree at all. It scans line by line with
light block-awareness. That sounds crude, but it turns out every one of these
checks is textually distinctive — a uses: line, a ${{ }} expression inside
a run: block — so a careful line scanner catches them without ever needing to
understand the document structure. The payoff: it installs in one step, depends
on nothing, and runs in milliseconds. (It even distinguishes a third-party action
on a tag, high, from a GitHub-owned actions/* on a tag, medium.)

It is not trying to replace actionlint
(YAML/syntax validation) or zizmor (deep
dataflow analysis). It's the fast, zero-config first pass that fits in a pre-commit
hook or a one-line CI gate.

In CI

# fail the build on the serious stuff
- run: npx actionsec --min-severity high

Exit 0 clean, 1 issues found, 2 error. --format json for tooling.

Install

npx actionsec          # Node — zero deps
pip install actionsec  # Python — pure stdlib, works on any repo

Both produce byte-for-byte identical output.

Try it on your own repos

• Node: https://github.com/jjdoor/actionsec
• Python: https://github.com/jjdoor/actionsec-py

Point it at a repo you maintain — npx actionsec path/to/repo — and tell me what
it finds. I'm especially curious how many @v4s are hiding in workflows people
think of as "official and therefore safe."

When you write a workflow, do you pin actions to a SHA, or is @v4 good enough for
your threat model?