UiPath Marketplace und offene Packages: Pro, Contra und was Enterprise-Teams wissen müssen

UiPath baut auf NuGet — und das ist erstmal gut

Jede UiPath Activity — ob von UiPath selbst, von Partnern oder von Community-Mitgliedern — wird als NuGet-Package verteilt. Der UiPath Marketplace ist im Kern ein kuratierter NuGet-Feed mit einer Web-Oberfläche.

Fünf Feeds kennt UiPath Studio:

Das Prinzip ist richtig: Offenheit erlaubt Innovation. npm, PyPI und NuGet haben bewiesen, dass ein offenes Ökosystem die Plattform stärkt. UiPath’s Package Manager erlaubt es jedem Entwickler, Custom Activities zu bauen und zu teilen.

Das Problem liegt in der Praxis.

Was für offene Package-Systeme spricht

Innovation durch die Community

Die besten Ideen kommen oft nicht vom Plattform-Hersteller. Enterprise-Kunden brauchen SAP-Konnektoren, Banking-Interfaces, branchenspezifische Adapter. UiPath kann nicht alles selbst bauen. Der Marketplace ermöglicht es Partnern, ihre Speziallösungen anzubieten.

Wiederverwendbarkeit und Standardisierung

Ein gutes Error-Handling-Framework, ein Logging-Helper, ein Credential-Manager — einmal als NuGet-Package gebaut, in 50 Projekten genutzt. NuGet als Basis bedeutet bekanntes Tooling, bekannte Versionierung (SemVer), bekannte Deployment-Mechanismen.

Wo es für Anwender kritisch wird

1. Abandonware im Marketplace

UiPath’s eigene Dokumentation sagt es klar:

“UiPath has no control over the unlisting of packages created by partners or the Marketplace community.”

Was passiert wenn ein Community-Entwickler sein Package nicht mehr pflegt?

Typisches Szenario:

  2022: Entwickler A baut "SmartRetry.Activities" (net461)
  2023: 500 Downloads, 4.5 Sterne — sieht vertrauenswürdig aus
  2024: UiPath wechselt auf .NET 6 als Standard
  2025: Entwickler A hat den Job gewechselt, kein Update
  2026: Enterprise-Kunde upgraded auf Studio 2024.10
        → SmartRetry.Activities funktioniert nicht mehr
        → 30 Workflows die darauf aufbauen sind broken
        → Kein Maintainer erreichbar

Das ist kein hypothetisches Szenario — es ist der Normalfall in jedem offenen Package-Ökosystem. npm hat 2,1 Millionen Packages, davon sind geschätzt 30-40% unmaintained.

2. .NET-Version-Chaos

UiPath hat in den letzten Jahren massiv die .NET-Basis gewechselt:

Bis 2021:    .NET Framework 4.6.1 (Windows-Legacy)
Ab 2021.10:  .NET 5/6 (Windows + Cross-Platform)
Ab 2024.10:  .NET 6/8 als Standard

Jedes Community-Package muss diese Migration mitmachen. Viele tun es nicht.

UiPath garantiert Rückwärtskompatibilität nur zwischen zwei aufeinanderfolgenden Versionen. Für Community-Packages gibt es keine solche Garantie. Ein PeerSpot-Review beschreibt das Problem:

“When deciding to update to the newest version, it is often the case that it breaks previously developed automations and code.”

3. Supply-Chain-Sicherheit: NuGet als Angriffsvektor

NuGet-Supply-Chain-Angriffe sind real und werden sophistizierter:

Nethereum-Typosquat (Oktober 2025): Ein Angreifer erstellte ein NuGet-Package mit einem Unicode-Lookalike-Namen des populären Nethereum-Packages. Das Fake-Package erreichte über 11,6 Millionen Downloads und stahl Krypto-Wallet-Schlüssel.

Logic-Bomb-Kampagne (2023-2024): Neun NuGet-Packages mit Zeitverzögerungs-Payloads zielten auf Industrie-PLCs. 9.488 Downloads bevor sie entdeckt wurden.

Für UiPath-Kunden bedeutet das:

UiPath-Bot installiert Community-Package
  → Package hat transitive NuGet-Dependency auf nuget.org
  → Bot läuft mit Service-Account auf dem Server
  → Service-Account hat Zugriff auf SAP/Banking-System
  → Kompromittiertes Package hat Zugriff auf ALLES
    was der Bot-Service-Account kann

UiPath’s Security Certification prüft den Code bei Erstveröffentlichung — aber nicht bei jedem Update der transitiven Dependencies.

4. “Verified” bedeutet nicht “gut”

Was die Marketplace-Zertifizierung prüft — und was nicht:

“Verified” heißt “nicht offensichtlich bösartig”. Es heißt nicht “production-ready”.

5. Dependency-Hölle in der Praxis

UiPath-Forum-Threads zeigen das Problem regelmäßig:

"NU1102: Unable to find package System.Configuration.ConfigurationManager
 with version (>= 8.0.0)"
"The feed lists package but multiple attempts to download the nupkg
 have failed"
"Failure to Install Project Dependencies: Feed is invalid or packages
 were removed"

In der klassischen Software-Entwicklung gibt es dafür Lock-Files. UiPath’s project.json hat rudimentäres Version-Pinning, aber keine Lock-Datei die transitive Dependencies fixiert.

Was Enterprise-Teams tun sollten

6 Governance-Regeln für Package-Management

1. Package-Whitelist führen — Nur geprüfte Packages in der Orchestrator-Governance erlauben. Workflow-Analyzer-Regel ST-USG-014 (Package Restrictions) aktivieren.

2. Transitive Dependencies prüfen — dotnet list package --vulnerable --include-transitive regelmäßig ausführen, nicht nur bei Installation.

3. Keine Direct-nuget.org-Dependency in Produktion — Community-Packages über einen internen Feed spiegeln und dort prüfen.

4. Package-Pinning — Exakte Versionen in project.json, keine Ranges. Bei jedem Update: bewusste Entscheidung.

5. Abandonware-Check — Letzte Package-Version älter als 12 Monate? Risiko bewerten. Maintainer nicht mehr aktiv? Alternative suchen oder forken.

6. SBOM führen — Software Bill of Materials für jeden Bot: Welche Packages, welche Versionen, welche Lizenzen. NIS2 fordert das zunehmend.

Die Governance-Lücke ist das eigentliche Problem

Offene Package-Systeme sind die richtige Architektur-Entscheidung. Das Problem ist nicht die Offenheit, sondern die fehlende Governance-Schicht darüber:

Was fehlt:                              Wer sollte es liefern:
──────────────────────────────────────  ─────────────────────────
Dependency-Health-Monitoring             → Automatisierte Tools
Abandonware-Erkennung                    → Automatisierte Tools
Transitive-Vulnerability-Scan            → Automatisierte Tools
Kompatibilitäts-Vorhersage bei Updates   → Dependency Analyzer
Package-SBOM-Generierung                 → Automatisierte Tools
Qualitäts-Check jenseits von "nicht      → Code Quality Tools
  bösartig"

Die Antwort auf “Warum braucht man zusätzliche Tools wenn es den Workflow Analyzer gibt?” hat eine zweite Ebene: Weil der Workflow Analyzer nicht prüft ob Ihre Community-Dependencies sicher, aktuell und kompatibel sind.

Das tut aktuell niemand automatisch.

Dieser Artikel basiert auf einer Analyse des UiPath Marketplace-Ökosystems, öffentlichen NuGet-Security-Incidents und UiPath-Forum-Threads. Alle genannten Sicherheitsvorfälle sind öffentlich dokumentiert.