✓ Überlebt Platz 1 von 8 VorschlägenIndie Sicherheit 30. Okt. 2026

Integritätsüberwachung über mehrere Registries hinweg für IDE-Erweiterungen

Erstellt Snapshots von VS Code-, Cursor- und Open-VSX-Erweiterungsreleases, vergleicht sie registryübergreifend und alarmiert Security-Teams, sobald ein manipulierter oder abweichender Build ausgeliefert wird.

Diskussion öffnen ↗

Ein fertiges Briefing für Claude Code, Cursor oder jeden anderen Coding-Agenten (auf Englisch).

I want to build a small, bootstrappable product. Help me plan and start the MVP.

Product: Cross-registry integrity monitoring for IDE extensions
What it is: Snapshots VS Code/Cursor/Open VSX extension releases, diffs them across registries, and alerts security teams when a tampered or divergent build ships.
Who pays: Security engineering or platform leads at companies with 100+ developers using VS Code forks (Cursor, Windsurf); $500–2,000/mo from the software supply-chain security budget.
Closest alternatives: Socket, Snyk, Endor Labs, StepSecurity
The gap: Existing supply-chain tools watch package registries (npm, PyPI) and CI pipelines; nobody continuously monitors IDE extension marketplaces for tampered releases, publisher changes, or builds that diverge across registries.
Why now: Cursor and other VS Code forks now run their own extension marketplaces with separate, weaker publishing pipelines, and AI extension adoption exploded in the last year — this incident proves the attack path works.
Moat to build toward: Versioned historical snapshot database of extension bundles plus a growing dataset of benign-vs-malicious release diffs; switching costs from alert/MDM integrations.
Biggest risk: Marketplaces (Microsoft, Cursor, Open VSX) add mandatory signing and native anomaly detection, collapsing the gap before the customer base is built.

First three steps:
1. Build crawlers that snapshot the top ~500 extensions across the VS Code Marketplace, Open VSX, and Cursor marketplace, storing versioned bundle hashes and publisher metadata.
2. Build a diff engine flagging versions missing from other registries, publisher/signing-key changes, and new dangerous capabilities (child_process, writes to ~/.ssh, LaunchAgents).
3. Ship Slack/webhook alerting plus a dashboard where teams register the extensions their org uses.

Start by asking me up to five questions about constraints (stack, budget, timeline), then propose the smallest version a paying customer would use, and scaffold it.

Gesamt6.8/10

Schmerz7

Zahlungsbereitschaft6

Timing8

Marktlücke7

Burggraben5

Machbarkeit8

Dafür

Wer zahlt

Security Engineering oder Platform Leads bei Unternehmen mit 100+ Entwickler:innen, die VS-Code-Forks wie Cursor oder Windsurf nutzen; 500–2.000 $/Monat aus dem Budget für Software-Supply-Chain-Security.

Was die Leute sagten · 5

Eine manipulierte Claude-Code-Erweiterung war etwa 11 Stunden lang auf dem Cursor Marketplace verfügbar, bevor sie entfernt wurde, und hatte vollen Zugriff auf Quellcode und Entwicklungswerkzeuge. Aus dem Artikel ↗
Die kompromittierte Version erschien auf Open VSX bzw. Cursor, offenbar aber nie in der offiziellen Microsoft-Registry, was eine gefährliche Abweichung zwischen den Registries zeigt. Kommentar lesen ↗
Entwickler:innen erkennen, dass KI-Coding-Tools täglich ungeprüften Remote-Code ausführen und niemand prüft, was diese CLIs und Erweiterungen tatsächlich tun. Kommentar lesen ↗
Verzögerte Auto-Updates gelten nicht für „vertrauenswürdige Publisher“, und Nutzer:innen können nicht festlegen, welchen Publishern sie vertrauen. Bösartige Updates können sich dadurch sofort verbreiten. Kommentar lesen ↗
Es wird erwartet, dass staatliche Akteure zunehmend Entwicklertools und Open Source angreifen. Daher sollten alle eingehenden Artefakte als feindlich behandelt werden. Kommentar lesen ↗

Sinngemäß aus der Diskussion wiedergegeben. Die Links führen zu den Originalkommentaren.

Wettbewerber und Lücke

SocketSnykEndor LabsStepSecurity

Bestehende Supply-Chain-Tools überwachen Paket-Registries (npm, PyPI) und CI-Pipelines. Niemand überwacht IDE-Erweiterungsmarktplätze kontinuierlich auf manipulierte Releases, Publisher-Wechsel oder Builds, die sich zwischen den Registries unterscheiden.

Warum jetzt

Cursor und andere VS-Code-Forks betreiben inzwischen eigene Erweiterungsmarktplätze mit separaten, schwächeren Veröffentlichungspipelines, und die Verbreitung von KI-Erweiterungen ist im letzten Jahr stark gewachsen. Dieser Vorfall belegt, dass der Angriffsweg funktioniert.

Burggraben · 5/10

Versionierte historische Snapshot-Datenbank von Erweiterungsbundles plus wachsender Datensatz mit Diffs zwischen gutartigen und bösartigen Releases; Wechselkosten durch Alert- und MDM-Integrationen.

Dagegen

Red Team: Ein 11 Stunden lang live auf dem Cursor-Marktplatz verfügbares Backdoor beweist den Angriffsweg. Supply-Chain-Security-Budgets existieren, und Socket/Snyk decken zwar npm/PyPI ab, aber nicht IDE-Erweiterungsregistries mit Erkennung registryübergreifender Abweichungen.
Woran es scheitern würde: Marktplätze (Microsoft, Cursor, Open VSX) führen verpflichtende Signierung und native Anomalieerkennung ein und schließen die Lücke, bevor eine Kundenbasis aufgebaut ist.

Start

Die ersten drei Schritte: Crawler entwickeln, die die etwa 500 wichtigsten Erweiterungen aus dem VS-Code-Marketplace, Open VSX und dem Cursor-Marktplatz erfassen und versionierte Bundle-Hashes sowie Publisher-Metadaten speichern.
Diff-Engine bauen, die Versionen markiert, die in anderen Registries fehlen, sowie Publisher- oder Signaturschlüssel-Wechsel und neue gefährliche Fähigkeiten (child_process, Schreibzugriffe auf ~/.ssh, LaunchAgents) erkennt.
Slack-/Webhook-Benachrichtigungen und ein Dashboard ausliefern, in dem Teams die Erweiterungen hinterlegen, die in ihrer Organisation verwendet werden.
Ursprüngliche Diskussion: Backdoor in Claude Code for VS Code extension on the Cursor Marketplace ↗ 579 Punkte401 KommentareAus den KommentarenVerlinkter Artikel

Aus dem Englischen übersetzt. Original lesen

Dafür

Dagegen

Start

Mehr aus dieser Ausgabe