Source code
Code quality
Releases
Security & compliance
Stability
Dependency supply chain
What actually installs when your build runs.
Overview
The dependency tree you ship is decided by your lockfile, your version ranges, and any install scripts along the way. This check reads all three and reports where the build could resolve to something other than what you tested.
What it looks for
- No lockfile committed, or a lockfile out of sync with the manifest
- Floating and unpinned version ranges
- postinstall scripts in dependencies you did not vet
- Abandoned, deprecated, or known-risky packages
- Two package managers in one repo, and native-build dependencies targeting serverless
Why it matters
A missing or drifted lockfile means production installs a tree nobody has run. Floating versions turn any upstream release into an unreviewed deploy, and a postinstall script in a transitive dependency executes with your CI credentials.
Rules in this check
| What it reports | Fix path |
|---|---|
| No lockfile committed — installs are non-deterministic | Pull request |
| Lockfile out of sync with manifest | Pull request |
| Unpinned / floating version in deps | Pull request |
| Known-risky / deprecated package | Guide |
| postinstall script in unknown dep | Guide |
| Abandoned package in dependencies | Guide |
| Mixed package managers | Pull request |
| Native-build dep in serverless target | Guide |
How the fixes arrive
Pull requestLow-risk changes arrive as a pull request on a lumioguard branch, with a breakage analysis attached. You review and merge it.
GuideChanges only you can make safely arrive as a step-by-step guide you can follow yourself or hand to your coding agent.
Run them all on your app
Connect your repo and your live services with read-only scopes. The first scan is free, and nothing changes without your approval.