DEV Community

ShipWithAI
ShipWithAI

Posted on • Originally published at shipwithai.io

Hardening Your npm CI in 5 Concrete Layers

#claudecode #ai #npm #githubactions

Intro

Your CI pipeline installs dependencies far more often than any developer’s laptop. That frequency makes it the biggest npm attack surface. I recently saw the Bitwarden breach where a hijacked GitHub Action pulled a malicious CLI for 90 minutes and harvested every credential on the runner. Below is the exact 5‑layer playbook we dog‑fooded at ShipWithAI to stop that.

The Problem

Most CI configs still look like this:

- uses: actions/checkout@v4   # mutable tag
- uses: actions/setup-node@v4 # mutable tag
- run: npm install           # silent version bumps
- run: npm publish           # uses stored NPM_TOKEN
Enter fullscreen mode Exit fullscreen mode

The red flags are obvious: mutable tags, npm install, long‑lived tokens, no lockfile validation, and no dependency review. Each one is a foothold for an attacker.

Solution Walkthrough

Layer 1 – Enforce npm ci

npm ci installs only from the lockfile and fails on any mismatch. It also wipes node_modules first, guaranteeing a clean slate. Replace every npm install with:

- name: Install deps
  run: npm ci --ignore-scripts
Enter fullscreen mode Exit fullscreen mode

Commit a project‑level .npmrc with ignore-scripts=true, save-exact=true, and audit-level=moderate so every runner inherits the same defaults.

Layer 2 – Validate lockfile integrity

Add lockfile-lint to the workflow:

- name: Lint lockfile
  run: npx lockfile-lint --allowed-hosts npmjs.com --validate-https
Enter fullscreen mode Exit fullscreen mode

This blocks PRs that tamper with the lockfile source URLs.

Layer 3 – Dependency review action

GitHub’s dependency-review-action flags new or changed dependencies before merge:

- name: Dependency review
  uses: github/dependency-review-action@v2
  with:
    allow-scope: runtime,development
Enter fullscreen mode Exit fullscreen mode

Layer 4 – Pin actions to SHA

Instead of actions/setup-node@v4, use the exact SHA of the release you’ve vetted:

- uses: actions/setup-node@d3b0c5f...
Enter fullscreen mode Exit fullscreen mode

If a tag gets hijacked, your workflow stays on the trusted commit.

Layer 5 – OIDC trusted publishing

Replace static NPM_TOKEN secrets with OIDC tokens:

- name: Publish
  uses: npm/publish-action@v2
  with:
    token-type: oidc
Enter fullscreen mode Exit fullscreen mode

GitHub issues a short‑lived token that expires with the job, eliminating long‑lived credential leakage.

Results

Switching to npm ci alone caught three silent version bumps in the first week. Adding the full stack stopped a malicious lockfile PR from ever reaching merge and removed the need to store a permanent NPM token.

Key Takeaways

  • Deterministic installs (npm ci) are non‑negotiable for CI.
  • Validate lockfiles before they touch the runner.
  • Review deps on every PR.
  • Pin actions to immutable SHAs.
  • Publish with OIDC to avoid static secrets.

Conclusion & CTA

These five layers are easy to copy‑paste into any repo and give you a solid defense against the kind of supply‑chain hijack that hit Bitwarden. Follow me for more concrete SDLC hardening tips and feel free to drop your CI questions in the comments.

Originally published at https://shipwithai.io/blog/npm-ci-security-team-playbook/

Top comments (0)