A verifying package registry
Point your package manager at one URL. Known-vulnerable and malicious packages are refused with an HTTP 403 in the download path itself — no CLI to wrap, no app to install, no cache that can bypass it.
One gate for every client your team already uses
The problem with scanning around the edges
Scanners ask for a plugin in the IDE, an app on the repo, a wrapper in CI, a flag on the command line. Each is one more surface, and each can be skipped by a laptop, a build script, or a cache that already holds the bad package.
Stout sits in the one place every one of those surfaces pulls from. If the registry will not serve a package, nothing downstream can install it.
How it works
Stout is a pull-through registry. Every artifact is checked before it is handed to a client, and the decision is made in exactly one place.
npm, pip, go, docker or any of the other protocols requests a package from Stout, exactly as it would from the public registry.
GET /npm/lodash/-/lodash-4.17.4.tgz
An isolated scan lane runs vulnerability, malware, behavioral and AI review checks on the exact bytes. The scanner pods hold no master credentials.
cve · malware · behavior · llm
A single serve decision turns the verdict into an answer. Anything unknown, errored or timed out is held, never published.
Download links in the response are rewritten back to Stout. If a link cannot be rewritten, the request errors instead of leaking an upstream URL.
tarball → registry.stout.io
A version still being verified holds the connection. If the budget runs out, the client gets a recoverable 503 with Retry-After — never the artifact. Hold times are sized from each client's real timeout, so npm, go and maven ride it out.
Fail-safe is structural. A check that cannot run is never a pass, and an ecosystem Stout can't fully verify is skipped as indeterminate, not green.
Tools that hook network fetches lose to a populated local cache. A registry that refuses to serve does not.
Transitive by construction
Because every download URL Stout emits points back at Stout, each dependency at any depth re-enters the same gate. Protection doesn't depend on someone remembering to scan the lockfile.
Holds while the client resolves through Stout. A lockfile pinned to a direct upstream URL fetches direct, and Stout never sees it.
Detection
Advisory feeds catch what is already known. Behavioral and AI review catch what a package does, with no feed required.
Blocks once an advisory or signature has been published, at the same latency as everyone who uses the same feeds.
MAL-* advisoriesFires on what the artifact does, so it can act before any advisory exists.
curl | sh in install scriptsevalAI that has to show its work
The review model only gets to block if it quotes the exact lines of code that are malicious. Stout then re-reads the real file and checks the quote is there. A finding the model can't cite is discarded before it reaches anyone.
The artifact under review is treated as hostile input: the prompt is nonce-fenced against injection from the package itself, and the model never holds a provider key.
// finding: malicious · confidence 0.97 file postinstall.js:41-43 snippet fetch(u).then(r => r.text()).then(eval) ✓ server re-read postinstall.js ✓ snippet found verbatim at 41-43 → finding may gate
Setup
No new CLI for developers to learn and no pipeline step to maintain. Change the registry URL once, in the config file each tool already reads.
Evidence, not just a verdict
When Stout says no, you can see exactly why, and decide whether to override it.
Each finding records the file, the line range and the verbatim snippet behind it.
CycloneDX and SPDX for every package Stout verifies.
Verified artifacts are signed, and the public key is served from the registry. Signatures are local, not transparency-logged.
Audit events are anchored on a schedule so changes to history can be detected.
Refusals and the approved exceptions to them are recorded side by side.
Reputation-weighted reviews from people sit next to the automated verdict.
Choose per ecosystem and per check whether a rule enforces, observes or stays off.
Pods that touch hostile packages hold no database password, storage master key or signing key.
In development
The next layer lets platform teams attach their own checks and transformations to package pulls. A pull waits until required work succeeds, and a failure serves zero bytes and explains itself.
# illustrative policy policy: require-internal-scan match: { ecosystem: npm, scope: "@acme/*" } require: - check: license-allowlist - check: internal-sast on_failure: refuse # 0 bytes served timeout: 90s
Honest status
Security tools lose trust by overclaiming. Ours are tagged by what runs in production, what is built but off, and what isn't done yet.
We don't publish a false-positive rate yet because we haven't measured one. When we do, it will be here.
Questions
A finding can only block if the model quotes the offending code and Stout's server confirms that exact snippet exists in the file. Hallucinated findings cannot produce a real quote, so they are dropped. We are deliberately not claiming a measured false-positive rate until we have one.
Warm pulls of already-verified packages are served directly. A package seen for the first time is verified before it is served, so that first pull can be slow by design. Stout holds the connection rather than serving unchecked bytes.
It never publishes it. After the hold budget, your client gets a recoverable 503 with a Retry-After header. Unknown, errored and timed-out all resolve to hold.
No. You change the registry URL in the config your tools already read. There is no wrapper, GitHub app or IDE extension.
The behavioral gates and AI review inspect what a package does, so they don't wait for a feed. Whether those layers block or only advise depends on the ecosystem, which is why the status table above matters.
Sixteen package types: npm, Go, Python, Docker, Maven, Rust, NuGet, Ruby, PHP, Helm, Swift, Dart, Conan, Terraform modules, Terraform providers and agent packages. Docker is advisory today, and a few ecosystems lack OSV coverage, so those checks report indeterminate rather than clean.
Stout is Apache 2.0 licensed. A self-hosted distribution is in development and hasn't been released yet.
The pull-through proxy for all 16 package types is never behind a plan. Point one client at Stout and watch what it refuses.