marsai:dev-dep-security-check

Dependency Security Check — Supply Chain Gate

Overview

Every pip install and npm install 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 (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:

Source	Ecosystem	What It Covers
OSV.dev	All	Google's aggregated vulnerability database
GitHub Advisory Database	All	GHSA advisories linked to CVEs
Socket.dev	npm, pip	Supply chain specific — detects install scripts, network access, obfuscation
PyPI JSON API	pip	Package metadata, maintainers, release history
npm registry API	npm	Package metadata, maintainers, install scripts

3. Behavioral Analysis

Detect suspicious package behaviors:

Signal	Risk Level	Description
Install scripts	HIGH	postinstall (npm), setup.py with subprocess calls
Network access at import	CRITICAL	Package phones home on import
File system access outside project	HIGH	Reads ~/.ssh, ~/.aws, keychain, env vars
Obfuscated code	CRITICAL	Base64 encoded payloads, eval(), exec()
Native binary bundled	HIGH	Pre-compiled binaries without source
Excessive permissions	MEDIUM	Package requests more access than its stated purpose

4. Lockfile Integrity

Ecosystem	Lockfile	Hash Mechanism	Action
npm	package-lock.json	integrity field (SHA-512)	Verify integrity present for ALL deps
pip	requirements.txt	--require-hashes	Enforce — pip does NOT do this by default
Cargo	Cargo.lock	checksum field	Verify

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

Score	Result	Action
0-25	ALLOW	Install proceeds. Log the decision.
26-50	WARN	Install proceeds with warning. Developer must acknowledge.
51-75	BLOCK	Installation blocked. Developer can override with justification (logged).
76-100	BLOCK (HARD)	Installation blocked. No override — requires security team review.

Ecosystem-Specific Guidance

Python (pip)

# NEVER do this in a V4-Company 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.

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