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.
A public package can introduce more than code. Put a policy decision between every dependency request and the machines that run it.
Designed for the moment of install
Public package flowProtected build
Policy before downloadRisk contained
One decision point across your stack
npmPyPIMavenNuGetOCI
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.
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.