RPA marketplace supply chain risk: what you're installing on the bot host

Why the marketplace is a supply chain, not a feature store

Most RPA security writeups stop at the bot's identity and the orchestrator's RBAC: who runs the bot, what creds it holds, what queues it can pull from. That is the right scope for the control plane. It is the wrong scope for the question this page asks, which is: whose code is actually running on the bot host when the workflow executes.

When a developer drags an activity from the UiPath Marketplace into a process, what lands on the bot host is a packaged .nupkg with one or more .dll assemblies inside, plus a transitive closure of NuGet dependencies resolved at build time. The activity may publish telemetry, talk to a vendor endpoint, read clipboard or screen state, write temp files, or call native code. None of that is inherently bad. All of it is third-party code that a security review of your workflow probably did not read line by line.

The UiPath Marketplace crossed 1,000 reusable components by mid 2020 and has grown since, spanning UiPath-published, partner-published, and community-published listings. Automation Anywhere's Bot Store and Microsoft AppSource's Power Automate connector catalog have similar shapes. The trust model is “the marketplace curates”; the technical model is “the package runs as you on a Windows host that touches your SAP, your EHR, your banking core”.

What the dependency graph looks like, concretely

A typical enterprise UiPath process imports a handful of activity packs. Each pack brings its own NuGet tree, and every leaf in that tree runs with the bot user's privileges. This is the shape of the boundary you are accepting:

Each input on the left is a separate publisher with its own update cadence. Each output on the right is something the bot host now does on your behalf, often without an explicit log line attributing it to the originating package.

The six specific risks

1. Publisher compromise. A partner's build or publish credentials get phished or their GitHub Actions runner gets popped. The next version of an activity pack you already trust ships malicious code. This is exactly what happened to tj-actions/changed-files in March 2025 (CVE-2025-30066); your RPA marketplace ecosystem is one such incident away.
2. Transitive dependency drift. The activity pack pins to a major version, but inside it the NuGet resolver pulls a newer patch of a library on the next CI run. The behavior of your bot changes for reasons no one on your team typed into a workflow.
3. Selectors against vendor UIs. Many marketplace activity packs are wrappers that fire pre-baked selectors against a specific version of SAP, Oracle, or a banking core. The vendor ships a support pack, the selector rots, the activity pack does not get a fix because the publisher moved on. Your workflow now needs a third-party package the publisher does not maintain.
4. Excess privilege by default. An activity pack that needs to read one SAP field gets the full screen, clipboard, file system, and outbound HTTP because no Windows-RPA stack has a per-activity sandbox. Compromise of any one pack equals compromise of the bot user.
5. Publisher disappearance. The maintainer of a community-published bot stops responding, the listing gets delisted, or the partner exits the marketplace program. Your internal feed still resolves the cached version, but no one is going to ship the next fix. The workflow rots quietly.
6. Silent telemetry and outbound calls. Some activity packs phone home to the publisher's telemetry endpoint, license server, or update channel. Without an outbound-network allowlist on the bot host you do not see this, and a security review that only read the developer-facing docs would not catch it either.

Side by side: marketplace-driven stack vs. one-publisher accessibility-API stack

The comparison that matters when you write the controls document. Same workflow on SAP GUI, two different runtime architectures, two very different supply chains.

What concrete mitigations work if you stay on a marketplace-driven stack

Five things, in rough order of leverage. None of them are marketplace-specific; they are the same controls a mature npm or PyPI consumer applies. The point is that most enterprise RPA programs are running the npm playbook from 2014, not the one from 2026.

• Mirror, do not pull. Run a private NuGet or activity feed inside your perimeter and only mirror in vetted, version-pinned packages. Block direct pulls from public marketplaces on bot hosts. This converts “the publisher republished” from a silent event into one your security team chooses to accept.
• Demand a real publisher and an SBOM. Require a verified publisher identity and a software bill of materials for every component you onboard. Anonymous community packages are untrusted by default. Vendor-published activity packs from a verified partner are a different risk class than a forum post.
• Sandbox the bot host. Each bot host runs in a VM or container with no inbound and an outbound allowlist. Segment by workflow risk class: a customer-facing claims bot does not share a host with a back office reconciliation bot. Compromise of one activity does not become compromise of the network.
• Scan and pin every ingest. Run the same scanning tooling you use for npm and PyPI against ingested .nupkg files: known-CVE checks, malicious package signatures, dep-tree audits. Pin transitive deps via lock files. Review every version bump like a code change.
• Log outbound network on bot hosts. Every outbound call from a bot host should be logged and attributed. Activity packs that phone home to the publisher's telemetry or update endpoint should be reviewed and either explicitly allowed or blocked. The allowlist is the audit.

The structural alternative: collapse the boundary to one publisher

Every mitigation above is a way to make a marketplace-driven supply chain safer. None of them remove it. There is a different shape available, which is to not have a marketplace of community-contributed bots in the stack at all.

Mediar's runtime is one Rust crate in one public repo (crates/executor in github.com/mediar-ai/terminator), 1,606 lines, under one publisher. There are no partner-published activity packs to install on the bot host. The workflow is a TypeScript file that your operator's recording generates into your own repo; the executor reads it and replays the steps via Windows accessibility APIs. The fallback cascade for finding a control (automation_id, then window plus bounds, then visible text) is in the executor, not in a per-vendor selector pack.

From a supply chain review point of view, the boundary collapses:

• One publisher to vet (mediar-ai on GitHub), one release cadence, one Cargo.lock to audit.
• Zero partner activity packs running on the bot host.
• Zero NuGet transitive dependency tree per workflow; only the Rust runtime's own dependency closure, fixed across workflows.
• The workflow itself is your code in your repo, not a third-party package. It reads exactly like a TypeScript script and goes through your normal code review.

This is not a claim that Mediar is incidentally more secure; it is the structural consequence of replacing a marketplace with a recording-plus-executor architecture. The trade-off is real: you do not get hundreds of pre-built connector packs. For Windows desktop legacy work (SAP GUI, Oracle EBS, Jack Henry, Fiserv, FIS, Epic, Cerner, mainframe terminals) that is fine, because the accessibility tree gives the agent enough structure to do without per-app activity packs in the first place.

FAQ