What a pilot covers
One team, one package ecosystem, one clearly bounded path — a test project or an isolated CI lane. Small enough that the rollback is one config line, real enough that the traffic is your own.
- One ecosystem from the supported list: npm, PyPI, NuGet, Maven, or Terraform.
- One deployment approach, usually the simplest one — a single line of client configuration, nothing installed on any machine.
- A policy set you choose: vulnerability thresholds, known-bad packages, license rules, or a rule of your own you want tested.
- A named technical owner on your side and one on ours.
- Thirty days, with a written findings summary at the end.
What is deliberately not in scope: a company-wide rollout, network-wide coverage, or an ecosystem that is still in development. Those are conversations for after a pilot has answered the question it exists to answer.
What you need to bring
| Requirement | Why |
|---|---|
| A project or CI lane you can point at a different registry | Provides a controlled path for testing client configuration. |
| Someone who can change that client configuration | Typically Platform or whoever owns the build image. |
| An idea of what you would want blocked | Defines clear allow and block scenarios to evaluate. |
| Agreement on where decision records live | Choose SaaS or on-prem and agree record storage before provisioning. |
| A willingness to see a build fail on purpose | A gate that is never tested against a real refusal has not been evaluated. |
What you do not need: a network change, an agent on developer machines, or a migration off your existing internal repository.
Your pilot, step by step
- Week 0 · Agree the scope
Choose an ecosystem, SaaS or on-prem, policies, technical owners, success criteria, and commercial terms.
- Week 1 · Verify the setup
Configure the client. Test an allowed request and a deliberate block, then check the developer explanation and audit record.
- Weeks 2–3 · Evaluate real traffic
Trial new rules in warning mode. Review decisions, exclusions, and operational impact each week.
- Week 4 · Decide what comes next
Review a written findings summary. Agree whether to continue, adjust the scope, or stop.
What to judge it on
Suggested criteria — agree yours before you start, not after you have seen the results:
- Did ordinary work stay ordinary? Install times, failed builds unrelated to policy, developer interruptions.
- Was a refusal self-explanatory? Measured by whether developers asked someone what happened.
- How long did an exclusion take? From the blocked build to the unblocked one.
- Did the record answer a question you actually had? Pick a real one in week 1 and try to answer it from the dashboard in week 4.
- What did it catch that your current tooling did not? Possibly nothing, in thirty days on one project. That is also a result, and it belongs in the summary.
Commercial approach
Scope and commercial terms are agreed before anything is provisioned — including what happens at the end of the pilot, in either direction. No infrastructure is created on your behalf until that is settled in writing.
mShield is pre-general-availability. A pilot is a joint evaluation with direct access to the product team. Availability, support expectations, and next steps are agreed as part of the scope.
Starting the conversation
Email contact@cloudkitty.pl with four things and you will get a scoped answer rather than a discovery call:
- Your team and roughly how many developers and CI runners are in scope.
- The package ecosystem you care about most.
- The dependency-policy problem you are actually trying to solve.
- Whether records need to stay in your own infrastructure.
If mShield is not a fit for what you describe — wrong ecosystem, wrong control point, a problem a scanner already solves for you — we would rather tell you that in the reply.