DEV Community: Cody Pack

I Publish npm Packages With No Tokens Stored Anywhere — Here's the Setup

Cody Pack — Sat, 17 Oct 2026 22:31:01 +0000

Last week I shipped version 0.3.0 of SolAudit, a static analyzer for Solana programs. The publish step involved zero secrets. No npm token in GitHub Actions secrets. No token on my laptop. No token anywhere. And anyone can cryptographically verify that the tarball on npm came from a specific commit in my repo, built by a specific workflow run.

This is npm's trusted publishing (OIDC) plus Sigstore provenance, and it took me about 30 minutes to set up. This post is the full walkthrough, including the two gotchas that cost me a failed run each.

The problem with npm tokens

The classic way to publish from CI is:

npm token create on your machine
Paste it into GitHub repo secrets as NPM_TOKEN
Reference it in a workflow

That token is a long-lived credential with full publish rights to your package. If it leaks — a compromised dependency, a malicious Action, a rogue postinstall script in your CI environment — someone else publishes as you, and every npm install your-package pulls their code.

This isn't hypothetical. Token theft and malicious version bumps are how several real npm supply-chain incidents have worked. The ecosystem's answer is to eliminate the standing credential entirely.

What trusted publishing actually does

Instead of a stored token, the GitHub Actions runner proves its identity to npm at publish time using OpenID Connect (OIDC):

Your workflow runs. GitHub mints a short-lived OIDC token that says: "I am workflow publish.yml in repo you/your-package, running on ref main."
npm publish exchanges that token with the registry.
npm checks: does this package have a configured trust relationship matching that exact repo, workflow file, and (optionally) environment?
If yes, npm issues a temporary, publish-scoped credential that expires almost immediately.

There's nothing to steal because there's nothing stored. An attacker who compromises your CI mid-run gets a credential that's scoped to one publish and dead within minutes.

What provenance adds on top

Trusted publishing controls who can publish. Provenance lets everyone else verify what was published.

When you publish from a trusted-publishing workflow, npm automatically generates a Sigstore attestation: a signed, publicly verifiable statement binding the package version to the source repository, the commit SHA, and the workflow run that built it. It shows up as the green "Provenance" badge on the package's npm page, and anyone can verify it locally:

npm audit signatures

That command checks the Sigstore signature on every installed package against the public transparency log. If someone tampered with the tarball or published it from anywhere other than your declared workflow, verification fails.

The setup, step by step

1. Link the package on npm

On npmjs.com, go to your package → Settings → Publishing access → Trusted publishing. Add:

Repository owner: your GitHub username or org
Repository name: your repo
Workflow filename: the exact filename, e.g. publish.yml
Environment name: leave blank unless you use GitHub environments

Two things to know:

The workflow filename must match exactly, including extension. publish.yml ≠ publish.yaml.
For a brand-new package that doesn't exist on npm yet, you do one initial manual publish first (npm publish from your machine with 2FA), then configure trusted publishing for all future releases.

2. The workflow

Here's the actual workflow SolAudit uses (.github/workflows/publish.yml):

name: Publish to npm

on:
  workflow_dispatch:

permissions:
  id-token: write   # required for npm trusted publishing (OIDC)
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24
          registry-url: https://registry.npmjs.org

      - uses: oven-sh/setup-bun@v2

      - name: Install dependencies
        run: bun install

      - name: Build self-contained CLI bundle
        run: bun run build:cli

      - name: Ensure npm supports trusted publishing
        run: npm install -g npm@latest

      - name: Publish solaudit to npm
        working-directory: cli
        run: npm publish

Three details matter:

permissions: id-token: write — without this, the runner can't mint the OIDC token and the exchange fails.
No NODE_AUTH_TOKEN, no secrets block at all. The registry-url on setup-node is just for registry config, not auth.
npm install -g npm@latest — this is the gotcha that cost me a run. Trusted publishing requires a recent npm CLI (11.5.1+). The runner image ships an older one. Upgrade in the workflow or the OIDC exchange silently falls back to looking for a token you don't have.

3. Release

Bump the version, merge to main, then trigger the workflow manually from the Actions tab (that's what workflow_dispatch gives you — a big green "Run workflow" button). I keep publishing manual on purpose: merging code and shipping a public package are two different decisions, and I want a deliberate click between them.

4. Verify

After the run goes green:

npm view solaudit@0.3.0
npm audit signatures   # in any project that installs it

And the package page on npmjs.com shows the provenance badge, linking to the public Sigstore transparency log entry with the source repo and commit.

What this looks like in practice

SolAudit 0.3.0 shipped this way this week. The full chain is inspectable:

The commit that bumped the version
The Actions run that published it
The npm page with the provenance badge

If I ever lose my laptop, get phished, or a dependency in my CI turns malicious, the blast radius for "publish as me" is: nothing. There is no credential to take.

The honest limitations

npm only, for now. Trusted publishing exists on PyPI and RubyGems too, but each registry implements it separately.
Your workflow file name is part of the trust config. Rename publish.yml and publishing breaks until you update npm's side.
It protects the publish step, not your code. If a malicious dependency lands in your actual build, provenance will faithfully attest to compromised code. You still need lockfile hygiene and dependency review.

But as a 30-minute change that deletes an entire credential class from your threat model, it's the best security-per-minute trade I've made on this project.

SolAudit is a free, open-source static analyzer for Anchor/Solana programs — 94% precision on its public benchmark, with documented limits. GitHub · npm

PlainSight — a local-first security checkup tool I'd actually sell to small businesses

Cody Pack — Thu, 15 Oct 2026 19:25:15 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

PlainSight is a command-line tool that runs a passive security checkup on a small business's website and produces a plain-English report written entirely by a local open-weight model. No cloud APIs. No client data leaves the machine.

bun plainsight.ts checkup example-business.com

Who would pay for it? CPAs, law firms, dentists, contractors, realtors — the small businesses that handle sensitive client data all day and have no IT department. They can't afford a penetration test ($5k+), but they can afford a one-page "here's what's wrong with your website, in English" report for $49–129. That's the side hustle: run the tool, deliver the report, offer a quarterly recheck.

The tool checks the things that actually matter at that scale:

TLS certificate health and expiry
Security headers (CSP, HSTS, X-Frame-Options, and friends)
Email spoofing protections (SPF/DMARC) — the #1 way small businesses get impersonated
Accidentally exposed files (.git, .env, config backups)
HTTP→HTTPS redirects, mixed content, cookie flags
Whether a security.txt exists so researchers can report problems responsibly

Every check is passive — the same requests any browser makes. There's an explicit ethics section in the README: you only scan sites you own or have written permission to test.

The scan produces structured findings, and then the interesting part happens: a local model writes the report. Not a template — an actual readable document, prioritized into "Fix these first," "Worth fixing soon," and "Good to know," in language a dentist's office manager understands.

Demo

Real run against my own other project's demo site (more on that below):

The full artifacts from that run:

Code

blueeyez425-art / plainsight

Local-first security checkup tool for small businesses — passive scan + local open-weight AI writes a plain-English report. No client data ever leaves the machine.

PlainSight

Local-first security checkups for small business websites. Passive checks in, plain-English report out — written by an open-weight model running entirely on your machine.

What it does

bun plainsight.ts checkup example.com

Scans the domain passively — the same requests any visitor's browser makes: TLS certificate, HTTP security headers, HTTP→HTTPS redirect, mixed content, cookie flags, email authentication (SPF/DMARC), and a handful of commonly exposed sensitive files (.git, .env, config backups).
Hands the raw findings to a local open-weight model (via Ollama) that writes a calm, jargon-free report a business owner can actually read: what each issue is, why it matters to their business, and one concrete fix.
Saves a Markdown report you can send as-is or render to PDF with pandoc.

Why local AI matters here

A security report is a map of a client's weaknesses. Sending that through a closed third-party API is…

View on GitHub

The whole thing is one TypeScript file (~250 lines) running on Bun, with zero npm dependencies. Deliberately boring: the scanner is deterministic code, the model only does the writing.

How I Built It

Two halves, each doing what it's good at:

The scanner is code, not AI. All checks are plain TypeScript: fetch the page, inspect headers and TLS, probe a short list of well-known sensitive paths, query DNS TXT records for SPF/DMARC. Deterministic, auditable, no hallucination risk in the findings. A security tool that invents vulnerabilities is worse than useless.

The report writer is an open-weight model via Ollama. The scanner hands the model the structured findings JSON plus a prompt that demands plain English, calm tone, and no alarmism. Default model is llama3.1:8b; I also ran it on gemma3 — any Ollama model works via one env var:

OLLAMA_MODEL=gemma3:1b bun plainsight.ts checkup example.com

The model never sees anything except the findings list — no cookies, no page bodies, nothing sensitive beyond "this header is missing." The report ends with a footer stating exactly which model wrote it and that no data left the machine. Transparency is the product.

Why Does Open Innovation Matter?

This project only works because the model is open and runs locally. Three reasons, in order of how much they'd kill the business:

1. Confidentiality is the whole job. A security report is, by definition, a list of a client's weaknesses. If I generate that report by shipping the findings to a closed third-party API, I've just taken a small business's vulnerability inventory and handed it to infrastructure neither of us controls. As the person selling security, that's the one thing I can't do. A local open-weight model makes the ethically correct architecture also the easiest one to build.

2. Marginal cost is zero, so the price point works. At $49–129 per report, a per-token API bill is survivable but annoying — and it scales the wrong way. With a local model, the hundredth report costs exactly what the first one did: nothing. That changes what the business can be — free "first checkup" lead magnets, quarterly rechecks, batch runs across a whole book of clients, all without watching a meter.

3. No lock-in, no deprecation roulette. A closed provider can change pricing, deprecate a model, or decide my use case violates a policy revision. When the model is a file on my machine, the tool I sell today still works in two years, and I can swap llama3.1 for gemma3 for whatever comes next by changing one environment variable. The open ecosystem — Ollama, the open weights themselves, Bun — is the supply chain, and none of it can be taken away.

My First User

Me — and it caught real problems.

I maintain another open-source project, SolAudit (a security scanner for Solana programs, because apparently I only build one kind of thing), with a demo site at solaudit-web.vercel.app. PlainSight's first real scan was against it, and the report flagged missing Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers — on the demo site of a security tool. Embarrassing? A little. Exactly the kind of finding a small business needs? Absolutely.

I fixed the headers in vercel.json, redeployed, and re-ran the checkup:

	Critical	High	Medium	Low	Info
Before	0	0	1	3	2
After	0	0	0	0	1

The only remaining finding is "no security.txt file" — fair enough, that's next. The before/after artifacts are in the repo's examples/ folder.

Did they pay? I invoiced myself $0 and left a tip jar full of lessons. But it validated the core promise: the tool finds real, fixable issues and explains them in language you'd actually act on. The first external user is the next step — the report format is the deliverable for a freelance checkup service I'm piloting with local small businesses.

Prize Categories

Best Use of Gemma — Gemma 3 is a tested report-writer backend (OLLAMA_MODEL=gemma3:1b, verified end-to-end against the sample scan — Gemma wrote a complete plain-English report from the findings JSON), alongside Llama as the default. Open weights all the way down.

Built during the challenge window (October 14–15, 2026). Scanner: TypeScript + Bun, zero dependencies. Reports: open-weight models via Ollama. MIT licensed — if you want to run this side hustle in your own town, the repo is yours.

I built a free static analyzer for Solana programs — here's what it catches and how it's built

Cody Pack — Wed, 14 Oct 2026 02:26:30 +0000

Solana exploits keep hitting the same bug classes: missing signer checks, arbitrary cross-program invocations, unchecked account deserialization, integer overflow. These aren't exotic — they're the same patterns that have drained hundreds of millions of dollars from on-chain programs, and they're detectable with static analysis before code ever gets deployed.

So I built SolAudit: a free, MIT-licensed static analyzer for Anchor/Solana Rust programs. 0.2.0 shipped this week.

Try it in 10 seconds: npx solaudit ./your-program

What it does

Point SolAudit at a directory of .rs files and it applies 11 security rules, then gives you a report grouped by severity — no RPC calls, no wallet, no build step:

Severity	Examples
CRITICAL	Missing signer checks on token transfers/mints
HIGH	Arbitrary CPI (caller-controlled program IDs), unchecked deserialization, type cosplay, insecure manual account closure, missing bump canonicalization
MEDIUM	Integer overflow on balance math, insecure account init, missing rent-exemption checks
LOW	Missing owner checks

Each finding includes the exact line and a concrete remediation hint. Exit code is 1 on any CRITICAL/HIGH finding, so it drops straight into CI as a gate.

Three ways to use it

CLI — npx solaudit ./program, or bun add -g solaudit. Outputs human-readable, --json, or --sarif.

Web app — solaudit-web.vercel.app. Paste a public GitHub repo URL or upload a single .rs file. No install.

GitHub Action — on the Marketplace. Ten lines of YAML and every push gets scanned, with findings uploaded to your repo's Security tab as code-scanning alerts:

- uses: actions/checkout@v4
- uses: blueeyez425-art/solaudit@main
  with:
    path: ./programs

On accuracy — honest numbers

On the committed labeled benchmark suite, the engine scores 93.8% precision, 100% recall, 96.8% F1 on rule-covered categories.

Those numbers describe that suite, not general effectiveness. One known gap remains: duplicate mutable accounts. I built a "distinctness" heuristic for it, it produced false positives on common legitimate patterns (e.g., a deposit instruction's user/vault token accounts of the same type), so I didn't ship it. A scanner that cries wolf gets uninstalled; I'd rather have a smaller rule set people trust.

Supply chain: verify the build yourself

A security tool that asks you to trust its binaries shouldn't exist. Every npm publish of SolAudit goes through GitHub Actions trusted publishing with signed Sigstore provenance — the package on npm is cryptographically bound to an exact commit and workflow run in the public repo. There's no "someone's laptop" in the loop. npm displays the provenance badge on the package page.

The dogfooding story

The repo's own CI runs SolAudit against its intentionally vulnerable example program on every push. Setting that up immediately caught a real bug — in my own Action: when a consuming repo had a local workspace package named solaudit, npx would resolve the local package instead of the pinned npm release, and the scan silently ran... nothing. The fix: install the pinned CLI into a temp dir and invoke it directly. Self-scanning found a distribution bug before any user did. That's the loop working as advertised.

What's next

Closing the duplicate-mutable-accounts gap with a smarter heuristic that survives the false-positive review
More rules from post-mortems of real exploits
Reentrancy-via-CPI-callback detection

Links

Repo: https://github.com/blueeyez425-art/solaudit (⭐ if useful)
npm: https://www.npmjs.com/package/solaudit
Action: https://github.com/marketplace/actions/solaudit-security-scanner
Demo: https://solaudit-web.vercel.app/

Feedback, false positives, and rule requests are all welcome as GitHub issues. SolAudit is free and will keep being built either way — development doesn't depend on tips. That said, if it saved you real time or caught a real bug, there's a tip link in the README, and it's genuinely appreciated.

Built by an independent security researcher. SolAudit is a first-pass scanner, not an audit — it doesn't replace manual review for anything holding real funds.