66K
npm malware records
OpenSSF’s 2025 report lists 66,000 npm entries in its malicious-package data.
Software supply chain security
Control what enters your build.
mShield is a package firewall. It enforces security and license policy on package requests before dependencies reach developer machines and CI runners — blocking what your rules refuse, recording every decision, and telling developers exactly why a request was stopped.
npm · PyPI · NuGet · Maven · Terraform — enforced at the moment of install
Public package flowProtected build
Policy before downloadRisk contained
One decision point across your stack
npmPyPINuGetMavenTerraform
Signal, in the open
Public packages are a live attack path.
Independent research shows why policy belongs at the moment a dependency is requested.
69%
more malware advisories
GitHub published 7,197 malware advisories in 2025, up from 4,268 in 2024.
228K+
npm vulnerability records
OSV.dev’s public index lists more than 228,000 npm vulnerability records in a September 2026 snapshot.
15K+
open reports to learn from
OpenSSF’s public Malicious Packages repository publishes OSV records, hashes, and indicators for community use.
The problem
Every install is a trust decision.
Open source makes teams faster. It also gives attackers a path into developer machines and builds through packages that look ordinary at first glance.
01
Malicious packages
A dependency can carry hostile code, including install scripts that run before anyone imports it.
02
Compromised releases
A familiar package name does not guarantee that its next version is trustworthy.
03
Late discovery
Finding a risky package after a scan leaves teams to investigate what already reached their environment.
The mShield approach
A decision before the download.
mShield sits in the package request path. Your rules decide what is allowed, blocked, or recorded for review.
01 / SEE THE REQUEST
Know what was requested.
Identify the package, version, and ecosystem while the request is in flight.
02 / APPLY POLICY
Enforce your rules.
Evaluate each request against configured security and license policies.
03 / KEEP THE RECORD
Give teams an answer.
Show why a request was blocked and preserve the decision for investigation.
Built for the whole decision chain
One control. Three different questions.
Developers need a clear reason. AppSec needs a workable policy. Security leaders need confidence in the control.
01 / DEVELOPERS↗
Keep building.
Use familiar package tools. When a request is blocked, see which package and policy caused it.
Discuss a pilot↗
02 / HEAD OF APPSEC↗
Make policy real.
Turn security and license rules into decisions at the request path, with a record your team can investigate.
Discuss a pilot↗
03 / CISO↗
See the exposure.
Understand what teams attempted to bring in, what policy allowed, and what was stopped.
Discuss a pilot↗
Security should be present at the point of trust, not only at the point of review.
Why this matters
Package registries are part of the build path. Treating each download as a policy decision gives security teams a place to act while developers keep using the tools they know.
Straight answers
What mShield is, in plain terms.
Find setup details in the documentation, including what mShield does not do.
What is mShield?
mShield is a package firewall for software dependencies. It sits in the package request path between your developers and CI runners and the registries they install from, evaluates every request against your security and license policies, and blocks, allows, or records it. It supports npm, PyPI, NuGet, Maven, and Terraform.
Does mShield replace an SCA scanner?
No. SCA tools identify dependency risks in manifests, codebases, and build artifacts. mShield enforces policy on package requests routed through it. Use both to control downloads and review dependencies already in use.
What happens when a package is blocked?
mShield refuses the request and records the reason. The blocked artifact is not served through mShield. Where the package manager displays the response, developers can open the block details and request a scoped, time-limited exclusion for operator review.
Which package managers are supported?
npm (including Yarn and pnpm), pip and PyPI, NuGet, Maven and Gradle, and Terraform providers and modules. Further ecosystems are in development.
Do developers have to change how they work?
Developers keep their usual install commands. For SaaS or on-prem, configure package managers to use the mShield endpoint. DNS mode is available only on-prem and requires internal DNS, routing, and HTTPS certificate trust setup.
Where do the security decisions come from?
Your policies. mShield combines continuously updated intelligence on vulnerable and malicious releases with license rules and conditions your own team writes. Policies are yours; there is no fixed blocklist you have to accept as-is.
Can mShield run in our own infrastructure?
Yes. Choose SaaS, operated by KAPIDATA sp. z o.o., or on-prem in your own infrastructure. Client configuration works with both. DNS mode is on-prem only. Hosting location and decision-record storage are agreed before provisioning.
A focused first evaluation
Start with one team and one package ecosystem.
Discuss a scoped 30-day pilot with your Platform or AppSec team. Agree on the deployment route, selected policies, technical owners, and commercial terms before setup.
01 / SET UP
Choose the scope.
Select one supported ecosystem and a test project or isolated CI path. Review setup, support, and rollback together.
02 / EVALUATE
Check real decisions.
Run controlled allow and block checks, review decision records weekly, and measure operational impact.
03 / DECIDE
Leave with an answer.
Get a findings summary and agree whether to continue, change the scope, or stop.
Discuss a pilot
See whether package policy fits your build.
Tell us your team, ecosystem, and current dependency-policy challenge.
Opens your email app. You can also write to contact@cloudkitty.pl. Pilot scope and commercial terms are agreed before provisioning.