Use case · Engineering and security
Check what you ship, not just what you wrote.
Vulkro checks every package against vulnerability data on your machine, tells you which ones your code actually reaches, and finds keys that should never have been committed.
01The problem
Most of your release is someone else’s code.
Hijacked maintainers, packages that publish themselves and names an AI assistant made up are all common ways in.
- Too many advisoriesA long list of vulnerable packages, with no way to tell which ones your code calls.
- Packages that were never safeMalicious versions, scripts that run on install and look-alike names.
- Keys in the historyA key deleted from the code is still in git for anyone who clones it.
02How Vulkro helps
The package your code calls comes first.
Every vulnerable package says whether your code reaches it, so the list starts with the ones that matter. Malicious versions and leaked keys sit in the same view.
vulkro · orders-api · packages and keysExample project
An example project. Package names and versions are real advisories; the files that reach them are illustrative.
03Why it holds up
Precise, and checkable.
- 01111 key formatsLeaked keys are recognised by the shape each provider gives them, in your files and, with Pro, in git history.Provider key formats recognised in every scan
- 02Data that travelsVulnerability data lives on your machine and updates from a checksummed file, so even an air-gapped machine stays current.Eight manifest formats are parsed. The default published bundle currently ships npm and PyPI; the wider signed bundle covers the other six.
- 03Checked before it runsInspect a new package or a cloned repository for malicious shapes and invented names before you run it.Malicious-package checks run in every scan