dependency-audit

Provides dependency management and supply chain security practices for auditing vulnerabilities, checking licenses, assessing dependency health, and managing upgrades safely. Use when auditing packages, reviewing security, managing dependencies, or when user mentions 'audit', 'vulnerability', 'dependency', 'supply chain', 'npm audit', 'license', 'bundle size'.

Jump to install

Repository: Tibsfox/gsd-skill-creator
Last source activity: April 14, 2026 at 07:57
Detected SKILL.md language: English
Stars: 69
Forks: 9

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Back to search Back to installation

name	dependency-audit
description	Provides dependency management and supply chain security practices for auditing vulnerabilities, checking licenses, assessing dependency health, and managing upgrades safely. Use when auditing packages, reviewing security, managing dependencies, or when user mentions 'audit', 'vulnerability', 'dependency', 'supply chain', 'npm audit', 'license', 'bundle size'.
type	skill
category	patterns
status	stable
origin	tibsfox
modified	false
first_seen	"2026-02-07T00:00:00.000Z"
first_path	examples/dependency-audit/SKILL.md
superseded_by	null

Dependency Audit

Read-only analysis patterns for dependency security, license compliance, and health assessment. This skill does NOT auto-upgrade packages -- it helps you understand your dependency landscape and make informed decisions.

Security-First Principles

Principle	Practice
Audit before merge	Run security checks in CI on every PR
Understand before upgrading	Read changelogs, check breaking changes
Never blindly force-fix	`npm audit fix --force` can introduce breaking changes
Pin production dependencies	Use exact versions or lock files
Verify publisher identity	Check package ownership, download counts, repo activity

Security Audit Workflow

Step 1: Run the Audit

# npm (built-in)
npm audit

# npm -- JSON output for parsing
npm audit --json

# Yarn
yarn audit

# pnpm
pnpm audit

Step 2: Read the Report

# Example npm audit output
┌───────────────┬──────────────────────────────────────────────┐
│ Severity      │ high                                         │
├───────────────┼──────────────────────────────────────────────┤
│ Package       │ lodash                                       │
│ Dependency of │ my-library                                   │
│ Path          │ my-library > lodash                          │
│ More info     │ https://github.com/advisories/GHSA-xxxx-xxxx │
└───────────────┴──────────────────────────────────────────────┘

Step 3: Assess Each Vulnerability

Severity	CVSS Score	Action
Critical	9.0-10.0	Fix immediately, block deployment
High	7.0-8.9	Fix within 24 hours
Moderate	4.0-6.9	Fix within 1 week, assess exploitability
Low	0.1-3.9	Track, fix in next maintenance window
Info	0	Informational, no action required

Step 4: Determine Fix Strategy

# SAFE: See what non-breaking fixes are available
npm audit fix --dry-run

# SAFE: Apply only semver-compatible fixes
npm audit fix

# DANGEROUS: Never run without understanding consequences
# npm audit fix --force    <-- CAN INTRODUCE BREAKING CHANGES

# INVESTIGATE: When audit fix doesn't resolve
npm ls <vulnerable-package>          # See dependency tree
npm explain <vulnerable-package>     # See why it's installed

# Check if the vulnerable code path is actually used
# Read the advisory -- is it relevant to your usage?

# Option A: Override the transitive dependency (npm)
# In package.json:
{
  "overrides": {
    "vulnerable-package": ">=fixed-version"
  }
}

# Option B: Override the transitive dependency (yarn)
# In package.json:
{
  "resolutions": {
    "vulnerable-package": ">=fixed-version"
  }
}

# Option C: Exclude from audit (document why)
# Create .nsprc or use npm audit --omit=dev for dev-only deps

Tool	Type	Best For
`npm audit`	Built-in	Quick check, CI integration
Snyk	SaaS + CLI	Deep analysis, fix PRs, monitoring
Socket.dev	SaaS + CLI	Supply chain attack detection
Dependabot	GitHub native	Automated update PRs
Renovate	Self-hosted/SaaS	Highly configurable update PRs
OSV-Scanner	CLI	Google's vulnerability database

# Install
npm install -g snyk

# Authenticate
snyk auth

# Test for vulnerabilities (read-only)
snyk test

# Monitor project (sends to dashboard)
snyk monitor

# Test a specific package before installing
snyk test <package-name>

# Install
go install github.com/google/osv-scanner/cmd/osv-scanner@latest

# Scan lock file
osv-scanner --lockfile=package-lock.json

# Scan entire directory
osv-scanner -r .

License	Type	Can Use In Commercial	Must Open Source Your Code	Must Include License
MIT	Permissive	Yes	No	Yes
Apache-2.0	Permissive	Yes	No	Yes (+ NOTICE file)
BSD-2-Clause	Permissive	Yes	No	Yes
BSD-3-Clause	Permissive	Yes	No	Yes
ISC	Permissive	Yes	No	Yes
GPL-2.0	Copyleft	Yes	Yes (if distributed)	Yes
GPL-3.0	Copyleft	Yes	Yes (if distributed)	Yes
LGPL-2.1	Weak Copyleft	Yes	Only modifications to LGPL code	Yes
AGPL-3.0	Strong Copyleft	Yes	Yes (even for network use)	Yes
MPL-2.0	Weak Copyleft	Yes	Only modified MPL files	Yes
Unlicense	Public Domain	Yes	No	No
SSPL	Source Available	Check terms	Yes (broad scope)	Yes
BSL	Source Available	After change date	Before change date, restricted	Yes

# List all dependency licenses
npx license-checker --summary

# Check for problematic licenses
npx license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

# Export full report
npx license-checker --csv --out licenses.csv

# Production only (skip devDependencies)
npx license-checker --production --summary

# GitHub Actions step
- name: Check licenses
  run: |
    npx license-checker --production \
      --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0" \
      --excludePackages "known-exception@1.0.0"

Indicator	Risk	Check
No updates in 2+ years	Unmaintained, unpatched vulns	`npm view <pkg> time`
Single maintainer	Bus factor of 1	Check GitHub contributors
No tests or CI	Quality unknown	Check repo for test config
Frequent ownership changes	Possible supply chain risk	Check npm ownership history
Typosquat name	Malicious package	Verify exact package name
Post-install scripts	Can execute arbitrary code	Check `scripts.postinstall`
Excessive permissions	Over-scoped access	Review package contents
Many open security issues	Known vulnerabilities	Check GitHub issues/advisories

# View package metadata
npm view <package-name>

# Check when last published
npm view <package-name> time --json | jq 'to_entries | sort_by(.value) | last'

# See who maintains it
npm view <package-name> maintainers

# Check download counts (popularity signal)
npm view <package-name> --json | jq '.dist-tags, .versions | length'

# List all postinstall scripts in dependencies
npm ls --json | jq '.. | .scripts?.postinstall? // empty'

# Check package size before installing
npx package-phobia <package-name>

# See what's outdated (read-only)
npm outdated

# More detail
npm outdated --long

# Output:
# Package    Current  Wanted  Latest  Location
# express    4.18.2   4.18.3  5.0.0   my-app
# lodash     4.17.20  4.17.21 4.17.21 my-app

# Check the changelog before upgrading
npm view <package-name> repository.url
# Then visit the repo and read CHANGELOG.md or Releases

# Upgrade one package at a time
npm install <package-name>@<version>

# Run tests immediately
npm test

# Check for type errors (TypeScript)
npx tsc --noEmit

# Check for lint issues
npm run lint

# Verify the lock file changed as expected
git diff package-lock.json | head -50

# Commit the single upgrade
git add package.json package-lock.json
git commit -m "chore(deps): upgrade <package> to <version>"

Concern	Without Lock File	With Lock File
Reproducibility	Different versions on each install	Exact same versions every time
Security	Can get compromised newer version	Pinned to known-good versions
CI reliability	"Works on my machine"	Same everywhere
Audit accuracy	Audit results vary	Consistent audit results

Rule	Rationale
Always commit lock files	Ensures reproducible builds
Use `npm ci` in CI, not `npm install`	`ci` respects lock file exactly
Review lock file diffs in PRs	Catch unexpected transitive changes
Regenerate periodically	Clear accumulated cruft
Never manually edit lock files	Use npm/yarn commands instead

# CORRECT: Clean install from lock file (CI)
npm ci

# CORRECT: Install and update lock file (development)
npm install

# WRONG: Deleting lock file to "fix" issues
# rm package-lock.json && npm install   <-- loses pinned versions

# Check bundle size of a package (before installing)
npx bundlephobia <package-name>

# Analyze your bundle
npx webpack-bundle-analyzer dist/stats.json

# Check what's in node_modules
npx cost-of-modules

# Compare alternatives
npx bundlephobia lodash vs ramda vs lodash-es

Strategy	Example
Import specific functions	`import debounce from 'lodash/debounce'` not `import { debounce } from 'lodash'`
Use tree-shakeable packages	`lodash-es` instead of `lodash`
Check for smaller alternatives	`date-fns` vs `moment` (tree-shakeable)
Lazy load heavy dependencies	`const lib = await import('heavy-lib')`
Avoid duplicate packages	Check `npm ls <pkg>` for multiple versions

name: Dependency Audit
on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'
  schedule:
    # Run weekly audit on Monday mornings
    - cron: '0 8 * * 1'

jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci

      - name: Security audit
        run: npm audit --audit-level=high

      - name: License check
        run: npx license-checker --production --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

      - name: Check for outdated (informational)
        run: npm outdated || true

Anti-Pattern	Problem	Fix
`npm audit fix --force`	Introduces breaking major version bumps	Use `npm audit fix` (safe) and handle majors manually
Ignoring audit warnings	Vulnerabilities accumulate	Triage every audit finding, document accepted risks
`"*"` or `""` version ranges	Installs any version, including malicious	Use exact versions or `^` ranges with lock file
Not committing lock file	Non-reproducible builds	Always commit `package-lock.json` / `yarn.lock`
Deleting lock file to fix issues	Loses all version pins	Diagnose the actual issue, regenerate carefully
Installing without reviewing	Supply chain attack vector	Check package health before `npm install`
Bulk upgrading all at once	Hard to diagnose breakage	Upgrade one package at a time, test between each
Running `npx` with unknown packages	Executes unreviewed code	Verify package before first `npx` usage
Ignoring post-install scripts	Arbitrary code execution	Review scripts, use `--ignore-scripts` when cautious
No CI audit step	Vulnerabilities ship to production	Add `npm audit` to CI pipeline
Using deprecated packages	No security patches	Find maintained alternatives
`devDependencies` in production	Larger attack surface, bigger image	Use `npm ci --omit=dev` for production builds

npm audit reports vulnerability
  |
  +--> Is it in a devDependency only?
  |      YES --> Lower priority (not in production)
  |      NO  --> Continue
  |
  +--> Is there a patch/minor fix available?
  |      YES --> npm audit fix (safe)
  |      NO  --> Continue
  |
  +--> Is the vulnerable code path used in your app?
  |      NO  --> Document accepted risk, revisit monthly
  |      YES --> Continue
  |
  +--> Is there a major version fix?
  |      YES --> Read changelog, test upgrade in branch
  |      NO  --> Continue
  |
  +--> Can you use overrides/resolutions?
  |      YES --> Pin transitive dep to fixed version
  |      NO  --> Continue
  |
  +--> Find alternative package or implement inline