What is a dependency?

A piece of software from someone else that your application uses, such as a package from npm or PyPI. Such a component has components of its own: those are the indirect dependencies.

Do you produce an SBOM?

No. We show which components have a known vulnerability or are known to be malicious. We don't deliver a full bill of materials.

Do you update the components too?

No. We fix nothing and change nothing in your repository. You decide what to update.

Doesn't our pipeline already do this?

Maybe, and that's good. We run the scanner at a fixed version, set the result next to your tests, your documentation and your architecture, and show it for every role.

Which languages and package managers?

Python, JavaScript and TypeScript. Other languages don't fit the pilot yet.

Check your code for vulnerable dependencies

Find vulnerable dependencies in your Python and JavaScript code

Your software runs on many components from other people, and any of them can have a known vulnerability. We read your lockfiles and set every component against the public lists of known vulnerabilities. For every finding you see which component, which version and where it sits in your repository.

Updated 18 October 2026

What we check

A well-known open-source scanner at a fixed version, without AI, on the lockfiles in your repository. A lockfile records which versions you use, including the components of components.

Components with a known vulnerability, direct and indirect
Packages known to be malicious
Whether there are lockfiles: without one, nobody knows exactly which version runs live
Runtimes and frameworks that no longer get security updates

Supply chain: what we do and don't deliver

We show which components have a known problem. We don't produce a software bill of materials (SBOM) and we don't update components for you.

You decide which update to apply and when. We show what is there, with proof, so you know where to start.

What you get back

For every finding: the component, the version, the entry in the public list and the lockfile it sits in. In your workspace you see it in layers: a traffic light for the board, and for developers exactly where it is.

Why a check on every new version

A component that looks safe today can get an advisory tomorrow. And with AI, new components arrive faster. That's why, with continuous checks, we look at your lockfiles again and again.

The pilot is by invitation. Sign up, we check whether your application fits and email you. You connect your repository with read access only, the first check starts by itself, you see what is checked and what is proven, and then we ask what it is worth to you. Have a question first? Ask it in the message below.

Our team

Reads every sign-up and every question

Our team reads what you send and answers by email. A conversation only happens if you ask for one: with the people who do the work, not a salesperson.