Warden — Software Supply-Chain Security Platform

A single pip install runs third-party code with the developer's or the CI runner's privileges. Attackers exploit that with malicious publishes, typosquats, dependency confusion, and account takeovers of packages that were fine yesterday.

A vulnerability scanner cannot see any of this: there is no CVE for a package nobody has reported yet. Warden asks a different question — what does this package do, and who really published it? — and keeps vulnerability intelligence as a separate dimension, because malicious and vulnerable are different questions with different responses.

A FastAPI backend runs the package pipeline. For a name and version, Warden resolves the release on PyPI, downloads the artifact under a size cap, verifies the digest the registry published against the bytes received, and extracts it under hostile-archive guards; nothing analyzed is ever executed. Fourteen analyzers then run in parallel, each with its own timeout: metadata, typosquatting, AST behavior, install scripts, other install vectors (.pth start-up hooks, in-tree build backends, console scripts that shadow common commands such as pip, python or git), obfuscation, known indicators (IOC), file inventory, secrets, dependency confusion, provenance, YARA and Semgrep (optional tools that report themselves unavailable when not installed), and vulnerability intelligence from OSV, CISA KEV and FIRST EPSS.

Every analyzer emits the same Finding: a severity and a separate confidence, the file and line where known, CWE and MITRE ATT&CK mappings, and remediation. A correlation engine combines findings into named attack chains — credential theft followed by exfiltration, install-time droppers, obfuscated loaders — and a risk engine scores separate dimensions, behavioral and vulnerability risk among them, keeping the 0–100 risk score as a derived value. A policy-as-code engine maps the result to allow, warn or block.

Around the package pipeline sit project scans that parse manifests and lock files for dependency-hygiene and dependency-confusion checks, a dependency graph and CycloneDX 1.6 or SPDX 2.3 SBOMs; release-to-release behavioral diffs; offline analysis of container image archives; and a monitoring worker that watches packages for new releases. The REST API serves verdicts, a CLI gate fails a build on a chosen decision, and a React + TypeScript security console shows the results; a GitHub Action runs a project scan in a workflow, uploading SARIF before it fails on a chosen finding severity. Results persist to PostgreSQL, with Redis for caching and events.

The detection numbers come from a synthetic benchmark, and the repo labels it as one. Twenty-two hand-written, inert packages — 14 malicious, 4 of them written to evade simple pattern matching, and 8 harmless look-alikes — go through the real pipeline offline under the default policy, each carrying an established package's registry facts. A malicious sample counts as detected when it draws a warn or a block: 13 of 14 malicious samples are detected, all 4 evasive ones among them, and 1 of 8 harmless look-alikes is flagged with a warning, and none of the 8 is blocked. The recorded run had YARA available; the same totals were measured with YARA and Semgrep both unavailable, which is how CI runs it. The miss is an SSH private key read and sent over a socket from a runtime module, allowed at risk 33: correlation will not turn that into an attack chain without corroboration, because legitimate SSH, deployment and upload tools do exactly this. The false positive is a compiler call in setup.py, surfaced for review rather than blocked or ignored. The repo's benchmark notes say the corpus was written by the same people who wrote the analyzers, so it shares their blind spots, and the README calls these numbers a regression baseline, not a real-world detection rate. Building the benchmark exposed and fixed five detection gaps and an ML over-escalation.

The engineering around the verdict: in the CI run on main at commit 942e3e9 (2026-09-18), 2,908 backend tests passed with 7 skipped, and every other job passed too — ruff lint, bandit and pip-audit security audits, a PostgreSQL migration round-trip with an app start-up smoke test, the frontend's lint, type-check, tests, build and npm audit, and container builds that fail on fixable critical or high Trivy findings. CI runs on every push to main and every pull request, and the benchmark itself is a CI regression gate. Docker Compose is the documented way to bring up the full stack; CI builds and scans the images but does not start that stack. Warden's own posture, as configured: refresh-token rotation, five-role RBAC, a hash-chained audit log with a verification endpoint, secrets redacted before anything is logged, stored or returned, and containers set to run as non-root on digest-pinned base images with a read-only root filesystem. Among the honest limitations the README lists: Warden reduces risk but does not eliminate it, and is no substitute for reviewing what you depend on; static analysis is evadable by sufficiently novel obfuscation; the ML model's metrics are synthetic hold-out numbers; provenance checks stop short of cryptographic signature verification; vulnerability intelligence is only as current as its sources; and the bundled indicator and popularity lists are point-in-time snapshots.