Stop the bad package before it enters
Detection after the fact is too late. SBOMVault turns the malicious-package, typosquat, abandonware, and license signals it already computes into an allow / warn / block decision — as an inventory view and a CI gate that fails the build.
Block the unambiguous, warn on the rest
A secure-but-non-disruptive default: hard-block what is unambiguously bad, warn on the judgment calls so a policy you haven't opted into doesn't break your build, and let you override with allow/deny lists.
Always block
The unambiguously bad — hard-blocked by default.
Warn by default
Judgment calls surfaced as warnings — escalate to a block in policy when you are ready.
Allow / deny lists
Your overrides. Allowlist a vetted internal package; denylist one you never want — matched by name or purl.
Two ways to enforce it
01
Inventory firewall
Evaluate your existing dependency inventory against the policy and see exactly which packages would be blocked or warned — reusing the malicious, typosquat, health, and license signals SBOMVault already computes.
02
CI gate (fail the build)
A documented endpoint your pipeline calls with a list of packages. It returns an allow / warn / block verdict per package and responds HTTP 422 when anything is blocked, so a CI step fails the build on status alone.
03
Configurable policy
Keep the hard blocks, escalate abandoned or license risk to a block, and maintain allow/deny lists — owner/admin controlled, applied across both the inventory view and the CI gate.
What it is — and what it isn't
The firewall enforces in two places: an inventory view that reports what your existing dependencies would trip, and a CI-callable gate that returns a per-package verdict and fails the build (HTTP 422) when a package is blocked.
It is not — yet — an install-time registry proxy that blocks the package at npm install. Enforcement is at the inventory and CI-gate layer, which is where most teams want a hard stop before code merges. A registry-proxy mode is on the roadmap.
Gate risky packages out of your build
Start free and see what your inventory would trip — then wire the CI gate into your pipeline to fail the build on a malicious or typosquatted package.
Frequently asked questions
- What is a package firewall?
- A curation gate that blocks risky packages before they enter your software, rather than reporting them after a scan. SBOMVault blocks known-malicious packages, typosquats, CISA-KEV and critical CVEs by default; warns on abandoned packages, high CVEs, and license risk; and supports allow/deny lists.
- How does it fail a CI build?
- A documented endpoint takes a list of packages and returns an allow / warn / block verdict for each, plus an overall result. It responds with HTTP 422 when any package is blocked, so a pipeline step can fail the build on the status code alone. It authenticates with a scoped API key.
- Is the policy configurable?
- Yes. The malicious / typosquat / KEV / critical-CVE blocks are always on; owners and admins can additionally escalate abandoned packages and license risk to a block, and maintain allow/deny lists (matched by package name or purl). The policy applies to both the inventory view and the CI gate.
- Does it block at install time?
- Not yet. Enforcement is at the inventory and CI-gate layer — which is where most teams want a hard stop before code merges. An install-time registry-proxy mode is on the roadmap.