security
Vulnerable Dependency Audit
Every Installed Package Against OSV — Critical CVEs And Malware Block The Deploy.
What you get
Checked Against OSV
Every package your lockfile actually installs is checked against OSV.dev — the open database that aggregates GitHub Security Advisories, npm, PyPI, RubyGems, crates.io and Go advisories, keyed to CVE IDs. Known-vulnerable and known-malicious packages are caught before they ship.
Critical And Malicious Block The Build
A critical CVE on a version your lockfile installs, or any package flagged as malware, stops the deploy before the build. High and medium findings are reported with the fixed version so you can plan the upgrade. An unreadable lockfile fails closed — it is never read as "no dependencies".
Transitive Dependencies Included
The audit walks the full dependency tree, not just the packages you named — most CVEs arrive through a dependency of a dependency. Each flagged package is reported with its CVE ID and severity so you can upgrade, pin, or accept it deliberately.
How The Audit Works
- 1
ZipLoom reads your lockfiles — npm, pnpm, Yarn, Cargo, Poetry, Pipenv, Bundler and Go modules — for the exact versions that install, transitive included.
- 2
Each package version is checked against the OSV vulnerability database.
- 3
Critical CVEs and malicious packages block the deploy; everything else is reported with its fixed version before the build ships.
What this check inspects
Every package in the dependency tree, not just the ones you named — most vulnerabilities arrive through a dependency of a dependency.
Each package version against the published CVE record, with the severity and the fixed version.
Whether a safe upgrade path exists, so you know if this is a version bump or a real migration.
Packages that are unmaintained or newly renamed — the supply-chain signals that precede a compromise. Deprecated packages are flagged from your lockfile today.
What it means when this fails
A known CVE in a shipped dependency is a published, documented way into your app: the exploit is often public before you hear about it. Unlike a subtle logic bug, attackers can scan for it at scale, which is why unpatched dependencies are such a common breach route.
Questions
- Do I have to fix every finding?
- No. Fix what's reachable and severe. A critical CVE in code paths your app actually runs matters far more than a moderate one in a build-time-only tool — the report tells you which is which.
- Why did a new CVE appear when my code didn't change?
- Vulnerabilities are disclosed continuously. A package that was clean last month can be flagged today, which is why the audit runs on every deploy rather than once.
- What if there's no fix available?
- The report says so, so you can decide deliberately — pin it, replace the package, or accept the risk and record why. Finding Memory keeps that decision attached to the finding.
What it replaces
Snyk Open Source
Dependency/CVE scanning, per contributing developer, 5-seat minimum.
GitHub Code Security
CodeQL scanning, Dependabot, dependency review. Billed per active committer; GitHub repos only.
Semgrep Team
SAST with a strong free OSS engine; rules and triage are yours to maintain.
ZipLoom Solo — every deploy check included
Deploy, security scan, and monitoring in one flat price. Guild $40/mo · Studio $70/mo · LoomWorks $149/mo · Business $299/mo.
Related features