# pip-witness Policy Severity Guide

## Severity Levels and What They Mean

### CRITICAL — Confirmed malicious behavior
The package did something that only malware does. No legitimate package should trigger these.
- **Unknown network destination**: Connected to an IP not in PyPI/DNS/GitHub infrastructure
- **Credential file access**: Opened .ssh/id_rsa, .aws/credentials, .kube/config
- **TeamPCP IOC match**: C2 IP, session.key, tpcp.tar.gz
- **OpenClaw IOC match**: Browser profile/crypto wallet/keychain access

### HIGH — Strong anomaly requiring investigation
Something unusual happened that legitimate packages rarely do.
- **Shell spawned during install**: /bin/sh or /bin/bash invoked
- **Dangerous tool executed**: curl, wget, nc, ssh during install
- **Unknown .pth file**: Non-allowlisted .pth in site-packages (TeamPCP vector)
- **Encoded payload in setup.py**: base64/hex obfuscation
- **Pickle file downloaded**: .pkl fetched during install (not shipped in package)

### MEDIUM — Worth noting, investigate in context
Behavior that could be suspicious but has legitimate explanations.
- **Unknown program spawned**: Binary not in pip baseline
- **Unknown pickle in site-packages**: Shipped .pkl not in hash allowlist
- **Setup.py references sensitive paths**: References .ssh/.aws in build script
- **Custom build backend**: Non-standard pyproject.toml build-backend

### LOW — Informational finding
Expected behavior worth recording for audit trail.
- **Large dependency tree**: >30 packages installed
- **High file count**: >5000 files accessed

### INFO — Transparency only
Does not affect risk score. Recorded for completeness.
- **Package not signed (PEP 740)**: ~40% of packages don't have attestations yet
- **Signed package details**: Who signed, from which repo/workflow
- **Dependency count**: Total packages installed

## Current Ecosystem Reality (April 2026)
- ~60% of top-20 PyPI packages have PEP 740 attestations
- ~17% of all PyPI uploads include attestations
- Missing attestation = NOT suspicious (most packages don't have it yet)
- Having attestation = strong positive signal
- The signing policy is INFO-level, not a gate

## Policy Tiers

### critical (SLSA L1)
Only CRITICAL rules. Zero false positives. Safe for automated CI gates.

### standard (SLSA L2)
CRITICAL + HIGH + behavioral rules. May have occasional findings on
complex packages. Good default for security teams.

### strict (SLSA L3*)
Everything. Will flag most packages with large dependency trees.
Use for auditing, not gating.