How it works

One service between your package managers and the public registries. Every request is checked against your policy, the package’s age and its scan verdict, and served from Scrutyn’s own copy.

Request beta accessSee pricing

Follow one install

A developer runs npm install @sample/http-kit on mira-laptop. Version 4.1.0 was published two days ago; 4.0.2 has been out for six weeks. Example

  1. Scrutyn checks who is asking

    The request carries this device’s token. It identifies the device and its account, and the account’s policy applies: the Lazaretto window, the rules for riskier installs, and any exceptions an admin approved.

  2. Two independent checks decide which versions are listed

    Neither check waits for the other. A version can be old enough and still blocked, or scanned clean and still too new. It is listed when it is old enough and not held or blocked, and its file is served only with a clean verdict.

    Lazaretto Is it old enough?

    4.1.0
    Two days old; your window is 7 days. The wait ends on Oct 4.
    4.0.2
    Six weeks old. Passes.

    Lens What is the verdict?

    4.1.0
    On hold: a new maintainer plus a new install script.
    4.0.2
    Scanned, no findings. Passes.

    Scrutyn computes the version list and latest from what passes, so here latest is 4.0.2. When the wait for 4.1.0 ends on Oct 4, it still needs an acceptable verdict and your policy’s approval before it is listed.

  3. npm picks from the allowed list

    You runWhat happens
    npm install @sample/http-kitInstalls 4.0.2, the newest version that passes both checks.
    npm install @sample/http-kit@4.1.0Fails with “No matching version found”. scrutyn why gives the reason.
    npm ci with 4.1.0 in the lockfileFails with a 403 that gives the reason (here, held for security review) and the scrutyn why command.
    Any install when no version passes yetFails, with the reason in the error and in scrutyn why.

    Python works the same way at the index. When pip install sample-requests-lite or uv add sample-requests-lite asks Scrutyn’s Python index, files that are too new, held or blocked aren’t listed, and scrutyn why explains a missing version. Each client reports that in its own words.

  4. Depot delivers the stored copy

    Warm
    4.0.2 was scanned and stored before. Depot serves that copy, checks its hash on the way out, and never refetches it from npm.
    Cold
    Nobody has asked for a version yet. Lens scans it once and the verdict is shared across every account. The file is served only after a clean verdict. While it is still being analysed, the client is told so and asked to retry later.
    Scanning unavailable
    Versions that already have a verdict keep being served. Versions without one aren’t served until they are scanned. That is a pending scan, not a malicious verdict, and scrutyn why says so.

  5. Afterwards, Scrutyn keeps watching

    The download is in the activity log. Stored versions are re-evaluated as malware feeds and signals change. If 4.0.2 were later found malicious, it would be blocked and a recall would name mira-laptop and every other device that downloaded it.

Where protection stops

Scrutyn protects the installs that reach it with a device token. Installs that go straight to a public registry, git URLs and downloaded scripts don’t pass through it. A recall tells you what to clean up; it can’t remove files or undo code that already ran. Security model & limits