Why we built this
We got tired of finding risky packages after they shipped. Scanners flagged dependencies already in production — xz-utils, event-stream, Shai-Hulud read as CVEs we couldn't undo. SBOMs got assembled the week before an audit. The install path is the one place left where a policy decision can still refuse a package before it lands. So that's where we built — and we close the loop in CI, on the endpoint, and at the network, with an enforcement audit trail a scanner can't produce.
Dependency policy only matters where it can still refuse a package — on the install path itself. Blocking inline isn't the moat; others do it too. The moat is closure: the same decision enforced in CI, on developer endpoints, and at the network, with an audit record that the refusal actually happened. That's the line between a report and a control.
Context
A published package reaches a build in minutes, and an install decision propagates across every repo and CI job just as fast. When the window between a malicious publish and a landed dependency is that short, the control that matters is the one that refuses on the install path — before the bytes land, not after the scan runs.
Most supply-chain tools look like older auditing categories: scan, alert, ticket, upgrade. That loop runs after risk has already entered the system. The install path is the last place you can refuse a package cheaply. So that's where we built.
Platform, security, and compliance teams who need dependency policy enforced the same way every time — not as a PDF in a wiki, not as a scanner report reviewed on Mondays, but as a decision made on every install request in every environment.
For product questions, deployment discussions, or enterprise requirements, contact sales@chain305.com.