Check a package, walk its tree, review a lockfile

Check a package

Type a name and a version and see what the rules say, for everyone or for a particular application and environment. Show every version lists each published version as approved, blocked, quarantined, cooling or excluded, with the reasons.

Walk the tree

A package with 60 dependencies needs all 60 allowed, or the install still fails. The walk resolves the whole tree and says what every package is, worst first: blocked, known advisory, no rule approves it, or never seen here. For an image, the tree is its platforms, its layers and every package found inside them. The walk is for npm, PyPI and images only for now. Tick what you need and ask for it, or as an approver, allow it, in one go.

Review a file

Drop in a package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, a requirements.txt, poetry.lock, uv.lock, pylock.toml, Pipfile.lock, a composer.lock or composer.json, a CycloneDX or SPDX SBOM, a CSV or JSON inventory, a plain list, or a zip of any of them.

An SBOM is split by each component's package url (its purl, or a bom-ref that holds one), and an inventory by its purl or ecosystem column, so NuGet, Maven, RubyGems, CocoaPods, Swift, Composer, RPM and APT packages are each judged by their own type's rules. A type the box has no rules for, like Go modules or Cargo crates, is counted and left out, and the notes say how many. Every package comes back as blocked, whitelisted or needs review, with the distinctions that matter: whitelisted but vulnerable, at risk, and an unapproved version of a known package. Every pinned version is checked against the advisory feed too.

The upload is read in memory and never written to disk. A blocked row has no tick box at all, so a denied version can never be whitelisted by being in the same file as something somebody wants.