Supply-chain risk in the MSP's own tooling: the vendor you trust is also an attack surface

MSPs spend a lot of energy assessing supply-chain risk in their clients' environments — which vendors have access, which integrations hold credentials, what a compromise upstream of the client would mean. The same lens applied to the MSP's own tooling gets a lot less scrutiny, which is strange given that an RMM or PSA platform sits in a structurally more dangerous position than almost anything in a client's own stack: it has broad, often privileged access across every client the MSP serves, all at once. A compromise of the platform itself isn't a single-client incident. It's every client, simultaneously.

This isn't hypothetical as a category — supply-chain compromises of exactly this kind of centralized management tooling are why 'trust the vendor' has become an insufficient answer on its own, and why the right question isn't whether to trust a platform vendor, it's what specifically limits the damage if that trust turns out to be misplaced.

What actually reduces the blast radius of a platform-level compromise

• Tenant isolation that holds even against the platform's own code — if a bug or a compromised component in the platform tries to reach across client boundaries, a database-level enforcement layer independent of the application code is what stops it, not just well-intentioned query logic.
• A default-deny capability model for anything that can execute on a client's systems — a compromised platform that can only run the specific job classes explicitly enabled, rather than arbitrary code, has a meaningfully smaller blast radius even in a worst case.
• Signed, verified jobs — if every remote action has to be cryptographically signed by the platform and verified on the device before it runs, a compromised delivery path still can't originate a valid job without the signing key, which narrows what a supply-chain attacker who's gotten partway in can actually do.
• CI gates that run on every single change before it reaches production — dependency auditing, secret scanning, and a full test suite that has to pass, not as a manual step someone can skip under deadline pressure, but as a hard gate on the merge itself.

The uncomfortable truth is that no vendor, including us, can honestly claim zero supply-chain risk — that's not a real state any software reaches, and a vendor claiming it is telling you they haven't thought about it carefully enough. What a vendor can do is make its actual mitigations checkable rather than asserted. Nexus publishes its own test coverage as a number computed automatically from the codebase — not hand-typed into a README and left to go stale — specifically because 'we have a thorough test suite' is a claim that should be falsifiable, not taken on faith.

The other half of this is process, not architecture: dependency updates, third-party library exposure, and the CI pipeline itself are all part of the attack surface, and 'we run an audit occasionally' is a materially weaker claim than a gate that blocks a merge on a dependency vulnerability automatically. Where Nexus stands today — private beta, dogfooded on our own real MSP practice before anyone else runs on it — is itself a supply-chain risk-reduction decision as much as a product-maturity one: the platform runs against our own infrastructure and our own real client data first, which means we're the first ones exposed to any gap in these mitigations, not a design partner. That's not a substitute for the architecture above. It's why we're comfortable being specific about what that architecture actually is.