Use case · Engineering and security
Check your dependencies and secrets
Most of the code in your release was written by someone else. Vulkro checks every package against vulnerability data on your machine, says whether your code reaches it, and finds the keys that should never have been committed.
Vulkro Core · Vulkro for Salesforce
01The problem
Many recent attacks came through dependencies
Hijacked maintainers, worms that publish themselves, and package names an AI assistant made up are all in recent headlines.
Too many advisories
A long list of vulnerable packages, with no way to tell which ones your code actually calls.
Packages that were never safe
Malicious versions, install scripts that run on install, and typosquats of popular names.
Keys in the history
A secret removed from the code is still in git, readable by anyone who clones the repository.
02How Vulkro handles it
What each part of Vulkro does
- Known vulnerabilities in your lockfiles, matched offline, with whether your code reaches each one and the actively exploited ones raised (Free)
- Leaked keys and passwords, recognised by 124 provider key formats (Free); keys committed and later removed, found in git history (Pro)
- Malicious versions, risky install scripts, typosquats and invented package names, and an inspection of source you have not run yet (Free)
- A bill of materials, matching an external one, packages inside built containers, and an answer to "is this advisory anywhere in our code?" in seconds (Pro)
- Managed packages and JavaScript in static resources checked against vulnerability and end-of-life data (Free)
- The same offline data bundle as Vulkro Core
03The workflow
Steps from first scan to fix
- 01Vulkro Core
Scan the lockfiles
Every scan reads your manifests and lockfiles and matches them against local vulnerability data.
- 02Vulkro Core
Rank by reach
A vulnerable package your code calls is ranked above one that only sits in the tree.
- 03Vulkro Core
Vet before you install
Check a new package or a cloned repository for malicious shapes and invented names before it runs.
- 04Vulkro Core
Sweep for keys
Find credentials in the working tree, and in the history behind it.
- 05Vulkro Core
Answer the next advisory fast
When a new advisory lands, ask whether that package is anywhere in your code.
04What you get
What you get
- Reach first
- Every vulnerable package says whether your code reaches it, so the fix list starts with the ones that matter.
- Before install
- Malicious versions, install scripts and invented names are flagged before they run.
- Secrets
- 124 provider key formats, in files and, on Pro, in history.
- Offline data
- Vulnerability data arrives as a checksummed bundle, so an air-gapped machine stays current.
- Evidence
- A bill of materials and the Cyber Resilience Act bundle when someone asks what you ship (Pro).
Questions
Common questions
- Which ecosystems are covered?
- Five manifest formats are parsed. The default published bundle currently ships npm and PyPI; the wider checksummed bundle covers Go modules, crates.io and Maven.
- Does it call out to a vulnerability service?
- No. Matching runs against data on your machine. You can refresh it online, or carry an update bundle into an air-gapped network.
- What is free?
- Dependency vulnerabilities with reachability, secrets in your files, malicious-package and invented-name checks, and source inspection are free. Secrets in git history, the bill of materials, container scanning and advisory response are Pro.