Dependency Security Check — Supply Chain Gate

Overview

Every pip install, npm install, and go get is a trust decision. This skill ensures that trust is verified before code enters your environment.

Supply chain attacks exploit implicit trust in package ecosystems. A single compromised package can exfiltrate credentials, inject backdoors, or pivot into production infrastructure. This skill acts as a gate — intercepting install commands and validating packages before they execute.

When This Skill Activates

• New dependency — any install command for a package not in the current lockfile
• Version change — updating an existing dependency to a new version
• Full audit — scanning all dependencies in a project for supply-chain risk
• PR review — when a PR modifies dependency files (go.mod, package.json, requirements.txt, etc.)

Pre-Install Checks

Before allowing any installation, run ALL of the following checks:

1. Package Identity Verification

For EVERY package, verify:
├── Does the package name match what the user intended? (typosquatting check)
│   ├── Compare against known popular packages (e.g., "requets" vs "requests")
│   └── Check for homoglyph attacks (e.g., "rnodule" vs "module")
├── Who maintains it?
│   ├── Number of maintainers (1 = higher risk)
│   ├── Maintainer account age
│   └── Maintainer history (other packages, reputation)
├── Package age and history
│   ├── First published date (< 30 days = flag)
│   ├── Version history (sudden ownership transfer = critical flag)
│   └── Download count trajectory (organic growth vs spike)
└── Source repository
    ├── Does the package link to a real repository?
    ├── Does the repository code match the published package?
    └── Is the repository actively maintained?

2. Vulnerability Database Check

Query these sources for known vulnerabilities:

3. Behavioral Analysis

Detect suspicious package behaviors:

4. Lockfile Integrity

Risk Scoring

Calculate a composite risk score (0-100):

risk_score = weighted_sum(
    typosquatting_similarity    * 25,   # High similarity to popular package
    maintainer_risk             * 20,   # Single/new/transferred maintainer
    package_age_risk            * 15,   # < 30 days old
    vulnerability_count         * 20,   # Known CVEs (weighted by severity)
    behavioral_flags            * 15,   # Install scripts, network access, etc.
    lockfile_integrity          * 5     # Hash missing or mismatch
)

Decision Matrix

Ecosystem-Specific Guidance

Python (pip)

# NEVER do this in a Lerian project:
pip install <package>

# ALWAYS do this:
pip install --require-hashes -r requirements.txt

# For new packages, add to requirements.txt first with hash:
# 1. Download in isolated env
# 2. Generate hash: pip hash <package>.whl
# 3. Add to requirements.txt: package==version --hash=sha256:abc123
# 4. Install from lockfile

Key risks: No native lockfile with hashes. setup.py executes arbitrary code during install. PyPI has no maintainer verification.

Node.js (npm)

# NEVER do this in CI:
npm install

# ALWAYS do this:
npm ci  # Uses package-lock.json, fails if it doesn't match

# For new packages:
# 1. Review on Socket.dev or npm inspect
# 2. Check for postinstall scripts: npm pack <package> && tar -tf <package>.tgz
# 3. npm install <package> (updates lockfile with integrity hash)
# 4. Commit updated package-lock.json

Key risks: postinstall scripts run with full user permissions. Dependency trees are deep (transitive deps). Name squatting is common.

Go

# Go has the best native supply chain security:
# - go.sum provides cryptographic hash verification
# - Go module proxy (proxy.golang.org) caches and serves verified modules
# - GONOSUMCHECK, GONOSUMDB should NEVER be set in Lerian projects

# Verify dependencies:
go mod verify

# Check for vulnerabilities:
govulncheck ./...

Key risks: Go is stronger by default, but replace directives in go.mod can bypass verification. CGo packages can include native code.

Audit Mode — Full Project Scan

When running in audit mode, scan the entire dependency tree:

For each dependency in the project:
├── Run all Pre-Install Checks (sections 1-4)
├── Flag transitive dependencies separately
├── Generate dependency tree visualization
├── Identify abandoned dependencies (no updates > 2 years)
├── Check for known malicious packages (cross-reference with incident databases)
└── Produce summary report with prioritized actions

PR Review Mode

When reviewing a PR that modifies dependency files:

1. Diff the lockfile — identify added, removed, and updated packages
2. Run Pre-Install Checks on all additions and updates
3. Flag lockfile hash changes for existing deps (potential supply chain attack)
4. Check if lockfile was regenerated vs surgically edited (surgical edits = suspicious)
5. Comment on PR with risk assessment for each changed dependency

Integration Points

• CI/CD Pipeline: Run audit mode on every PR that touches dependency files
• Pre-commit hook: Intercept install commands locally (optional, developer opt-in)
• Scheduled scan: Weekly full audit of all project dependencies
• Incident response: When a supply chain attack is disclosed, scan all projects for affected package

Response to Active Compromise

If a package is confirmed compromised:

1. Identify all projects using the package (audit mode across all repos)
2. Check if the compromised version was installed (lockfile + CI logs)
3. Rotate ALL credentials that were accessible to the compromised environment
4. Pin to last known-good version or find alternative
5. Report to security team with timeline and blast radius assessment

References

• Socket.dev — Supply Chain Security
• OSV.dev — Open Source Vulnerabilities
• OpenSSF Scorecard
• Sigstore — Package Signing
• SLSA Framework