Start here
This page is the overview: how mShield is deployed, what it enforces, what it is configured with, and what it deliberately does not do — enough to judge the fit before a call.
Deployment and routing
SaaS: CloudKitty operates mShield. Point package managers at the hosted endpoint. On-prem: run mShield in your infrastructure, using client configuration or DNS mode.
Client configuration
Point each package manager at its mShield endpoint. Start with a test project or CI runner.
DNS mode
Route supported registry domains through mShield using internal DNS. Configure network access and HTTPS certificate trust.
Verify either route: test an allowed request and an intentional block, then confirm both decisions in the dashboard. Internal repository integration depends on your routing and access requirements.
Agree hosting, record storage, credentials, and rollback before provisioning. Compare the deployment models visually, or follow the npm and PyPI setup guides.
Supported ecosystems
An ecosystem is supported when mShield enforces policy on that ecosystem's real traffic — not merely passes it through.
| Ecosystem | Clients | Setup |
|---|---|---|
| npm | npm, Yarn, pnpm | Guide |
| PyPI | pip | Guide |
| NuGet | .NET CLI, Visual Studio | Provided on setup |
| Maven | Maven, Gradle | Provided on setup |
| Terraform | Providers and modules | Provided on setup |
Further ecosystems are in development. If one matters to your evaluation, ask — we will confirm its current availability and setup requirements.
Policies and enforcement
A policy is a named set of conditions, a scope, an action to take when a condition fails, and who gets notified. Your operators author them. Your team chooses the rules and enforcement actions.
What a policy can decide on
- Known vulnerabilities — with the severity threshold your organisation has agreed.
- Known-bad packages — releases already identified as malicious, checked against continuously updated intelligence.
- License compliance — allow and deny rules over what a package is licensed under.
- Your own rules — conditions your team writes, evaluated alongside everything else.
What happens on a failure
- Block — the request is refused with a reason naming the package and the rule. The blocked artifact is not served through mShield. This is the default.
- Allow and warn — the request goes through and the alert is raised anyway. To evaluate a new policy: run it in warning mode against real traffic, read what it would have stopped, then switch it to block.
Exclusions
When a block is wrong for a case your team has accepted, an operator grants an exclusion scoped to the package and time-boxed to an expiry, with an author and a reason. It is recorded like any other decision, and it expires on its own.
Operating the gate
Operators work from a dashboard: policy violations, request history, and what teams are pulling in — plus whether the gate itself is healthy, because a degraded gate is worth knowing about before it becomes a false allow. Access is authenticated, and every operator action on a policy or an exclusion is attributable.
One thing worth planning for: mShield is in the install path, which means its availability is your install path's availability. Start a pilot on a CI lane or a single project, agree the rollback in advance, and keep it reversible until the gate has earned the trust.
What mShield does not do
Being explicit here is more useful than a feature list.
- It is not a scanner of your existing code. mShield decides on requests. It does not walk a repository or tell you what is already installed. Keep an SCA tool for that — see how the two divide the work.
- It does not detect unknown malware by itself. It enforces what is known and what you have defined. A package nobody has reported yet, and that no rule of yours matches, will pass.
- It does not gate paths it is not in. A machine configured with a second source, a vendored dependency, or a laptop outside the covered network is outside the gate. Coverage is a deployment property, not a product claim.
- It does not rewrite your dependency tree. There is no automatic upgrade and no silent substitution of a patched version. A refusal comes with a reason; the fix stays a human decision.
Troubleshooting
Installs still go straight to the public registry
Something is overriding the configuration. Check scope precedence — a project-level setting beats a user-level one — check for a second source or fallback index, and check tools that keep their own configuration rather than reading the package manager's. The verification commands in the integration guides are written to prove which setting actually applied.
A refusal with no obvious cause
The response names the package and the rule that refused it. If your tool hides response bodies, the same decision is in the dashboard with the requesting client. If the request is not there at all, it never reached mShield — go back to the previous item.
A developer is blocked on something legitimate
That is what exclusions are for: package-scoped, time-boxed, recorded. If it keeps happening for the same class of package, the policy is the thing to change, not the exclusion list.