Je weniger Abhängigkeiten, desto sicherer: Obsidians Ansatz zur Verringerung des Risikos von Supply-Chain-Angriffen

 (obsidian.md)
11 Punkte von GN⁺ 2025-09-20 | 1 Kommentare | Auf WhatsApp teilen
  • Supply-Chain-Angriffe schleusen bösartige Updates in Open-Source-Code ein; Obsidian minimiert dieses Risiko mit einer Strategie zur Reduzierung externer Abhängigkeiten
  • Die meisten App-Funktionen werden direkt selbst implementiert; falls nötig, wird geforkter Code in die eigene Codebasis aufgenommen und dort verwaltet
  • Unverzichtbare große Bibliotheken (pdf.js, Mermaid, MathJax usw.) werden zur Sicherheit auf feste Versionen fixiert; Updates erfolgen nur vorsichtig, wenn es Sicherheits-Patches gibt
  • Alle Abhängigkeiten werden per lockfile fixiert, und postinstall-Skripte werden nicht ausgeführt, um die Ausführung beliebigen Codes bei der Installation zu verhindern
  • Durch dieses vorsichtige Update-Verfahren und eine Strategie der zeitlichen Verzögerung kann Obsidian auf potenzielle Bedrohungen reagieren, bevor sie in der Community entdeckt werden

Was ist ein Supply-Chain-Angriff?

  • Ein Supply-Chain-Angriff ist eine Methode, bei der im Open-Source-Ökosystem bösartige Updates in ausgelieferten Code eingeschleust werden
  • Da viele Apps Open-Source-Code verwenden, kann ein einziges bösartiges Update kaskadenartig zahlreiche Anwendungen betreffen
  • Obsidian reduziert diese Angriffsfläche durch eine Strategie der Minimierung von Abhängigkeiten und entwirft die App entsprechend sicher

Strategie zur Minimierung von Abhängigkeiten: Less is Safer

  • Im Vergleich zu anderen Apps derselben Kategorie ist Obsidian auf sehr wenige externe Bibliotheken angewiesen
  • Zentrale Funktionen (z. B. Bases, Canvas) werden selbst implementiert, statt externe Bibliotheken einzuführen
    • Dadurch ist eine vollständige Kontrolle über den ausgeführten Code möglich
  • Kleine Utility-Funktionen werden fast immer direkt vom Entwicklerteam selbst implementiert
  • Mittelgroße Module werden, sofern die Lizenz es erlaubt, geforkt und in die Codebasis aufgenommen
  • Große Bibliotheken (pdf.js, Mermaid, MathJax usw.) werden in geprüften, fest fixierten Versionen eingebunden und nur minimal aktualisiert, wenn kritische Sicherheitsprobleme entdeckt werden
  • Alle externen Änderungen werden detailliert geprüft, und es werden gründliche Testverfahren durchgeführt
  • Auf diese Weise wird auch die Anzahl transitive Abhängigkeiten minimiert, wodurch bereits das primäre Risiko des Einschleusens bösartigen Codes sinkt

Was tatsächlich in der App enthalten ist

  • In der App, die Nutzer tatsächlich ausführen, sind nur sehr wenige Pakete wie Electron, CodeMirror und moment.js enthalten
  • Andere Entwicklungswerkzeuge werden nur beim Build-Prozess verwendet und nicht an Endnutzer ausgeliefert

Versions-Fixierung und lockfile-Verwaltung

  • Alle externen Abhängigkeiten werden durch striktes Version-Pinning und committete lockfiles verwaltet
  • Dadurch bleibt die Installation stets reproduzierbar, und Änderungen lassen sich leicht nachverfolgen
  • Durch die Richtlinie, keine postinstall-Skripte auszuführen, wird die Möglichkeit der Ausführung beliebigen Codes während der Installation von Grund auf blockiert

Langsames und sorgfältiges Update-Verfahren

  • Wenn Upgrades von Abhängigkeiten notwendig sind, wird ein systematisches Prüfverfahren wie das folgende durchgeführt
    • Änderungsprotokolle (changelog) werden Zeile für Zeile sorgfältig geprüft
    • Neue transitive Abhängigkeiten in der neuen Version werden überprüft
    • Bei größeren Änderungen oder Risikofaktoren wird der Diff mit dem Upstream-Quellcode direkt geprüft
    • Für wichtige Pfade und Plattformen werden automatische und manuelle Tests durchgeführt
    • Erst wenn all diese Schritte bestanden sind, wird das lockfile committet
  • Da die meisten Abhängigkeiten nicht häufig geändert werden müssen, ist auch die Update-Frequenz insgesamt niedrig
  • Die Einführung neuen externen Codes wird auf dem Niveau der Einführung einer neuen bestehenden Abhängigkeit geprüft und verwaltet

„Zeitlicher Puffer“ für Stabilität: Time is a buffer

  • Verschiedene Upgrades werden nicht sofort ausgerollt, sondern bewusst um einen bestimmten Zeitraum verzögert
  • In dieser Zeit können Open-Source-Community und Sicherheitsforscher bösartige Versionen erkennen, was als vorgelagerte Reaktionsmöglichkeit dient
  • Zum tatsächlichen Auslieferungszeitpunkt ist die Wahrscheinlichkeit hoch, dass Probleme bereits identifiziert wurden, was die Risikominimierung wirksam unterstützt

Fazit

  • Mit einer einzelnen Sicherheitsmaßnahme lässt sich das Risiko von Supply-Chain-Angriffen nicht vollständig beseitigen
  • Obsidian senkt das Risiko jedoch erheblich, indem minimale Abhängigkeiten, ein flacher Dependency-Graph, Versions-Fixierung, ein Verbot von postinstall und langsame, prüfungsorientierte Updates kombiniert werden
  • Durch diese Verfahren wird auch deutlich mehr Zeit gewonnen, um Risiken zu erkennen, bevor der Code die Nutzer erreicht
  • Obsidians gesamter Sicherheitsansatz und frühere Sicherheits-Audits sind auf der offiziellen security page einsehbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-20
Hacker-News-Kommentare

  • Viele Kommentare übersehen, dass die meisten Nutzer in Obsidian Community-Plugins von Drittanbietern verwenden; tatsächlich ist Obsidians Sicherheitsmodell für Plugins sehr schwach, da Plugins Zugriff auf alle Dateien im Vault haben. Hätte Obsidian selbst mehr Funktionen direkt eingebaut, wäre das Sicherheitsrisiko geringer. Alternativ ließe sich die Struktur auch so verbessern, dass wie bei Browser-Erweiterungen die von Plugins verwendeten Berechtigungen explizit angegeben und nicht genehmigte Zugriffe blockiert werden. All das würde einen deutlich realeren Nutzerschutz bieten als die Logik „weniger Abhängigkeiten von Dritten“.

    • Früher erzählten einige Leute aus der Softwarebranche davon, wie Ideen aus dem Videospiel-Design in andere allgemeine Software einflossen, aber heute hört man das kaum noch. Es wäre für das gesamte Software-Ökosystem sehr hilfreich, wenn zentrale Leute aus alten Spielefirmen wie Blizzard ein Buch darüber schreiben würden, wie das Plugin-System von World of Warcraft in seinem ersten Jahrzehnt funktionierte, welche Probleme es gab und wie es sicherer gemacht wurde. Die Plugin-Systeme vieler Projekte sind eine Mischung aus Schlampigkeit und Unbeholfenheit.

    • Obsidian-Plugins können nicht nur auf Dateien im Vault, sondern auf alle Dateien des Computers zugreifen. Ich habe das früher einmal auf Discord angesprochen, wurde aber ignoriert.

    • Ich sehe das ähnlich wie bei Arch Linux: Schon wenn Ingenieure Software direkt aus dem AUR verwalten, ist Sicherheit schwierig; von normalen Nutzern zu erwarten, dass sie dafür verantwortlich sind, ist unrealistisch.

    • Ich denke, dass bei Obsidian-Plugins bald Fälle von Datenabfluss ans Licht kommen werden. Dann wird das Team Sicherheitsmechanismen einführen. Zumindest ein System für verifizierte Publisher ist nötig.

    • Ich entwickle kommerziell ein Obsidian-Plugin und würde mir für Plugins ab einem gewissen Niveau einen höherwertigen Prüfprozess wünschen. Wenn man wie bei Arch Linux zwei Repositories betreibt — ein Community-gepflegtes und eines mit strengerer Prüfung —, könnte das sowohl die Prüfungsgeschwindigkeit als auch die Sicherheit verbessern.

  • Es heißt hier, ein „Supply-Chain-Angriff sei, wenn sich ein bösartiges Update in Open-Source-Code einschleicht, den viele Apps verwenden“, aber jede Art von Quellcode kann Ziel solcher Angriffe werden, nicht nur FOSS. Die Wahrnehmung, FOSS sei zwangsläufig verwundbarer, ist problematisch.

  • Die Richtlinie „während der Installation keine postinstall-Skripte auszuführen“ ist gut gemeint, aber wenn ein Paket bereits kompromittiert ist, macht das Weglassen von postinstall den restlichen Code nicht sicher. Ist ein Paket in Ordnung, kann postinstall auch eine legitime Installation unterstützen. In der Praxis entstehen Vorfälle häufiger durch normale Vulnerability-Patches als durch Supply-Chain-Angriffe, sodass das Blockieren von Updates das Risiko sogar erhöhen kann.

    • Heutzutage findet Security-Scanning normalerweise nach der Installation (post install) statt. Es ist gut, wenn während der Installation nichts ausgeführt werden kann. Ich hoffe, dass es künftig mehr Funktionen für Scans oder Einschränkungen schon in der Installationsphase geben wird. Manche kommerziellen Tools unterstützen das zwar, verbreitet ist es aber nicht.

    • Trotzdem ist das sinnvoll, um Build-Maschinen zu schützen. Dann muss ich mir keine Sorgen machen, dass aus meinen zahllosen Abhängigkeiten beliebige Skripte ausgeführt werden.

  • Für allen Code, der an Nutzer ausgeliefert wird, ist der Entwickler verantwortlich. Wenn man Abhängigkeiten nicht pinnt, lädt man letztlich „zufälligen Code aus dem Internet herunter und hofft auf Glück“.

    • Wenn man Abhängigkeiten pinnt, kann man spätere Security-Patches verpassen. Auch das ist riskant, daher braucht man unbedingt ein System, das neue Sicherheitspatches sichtbar macht. Diese Patches müssen dann entweder backportet oder per Update auf eine neue Version übernommen werden.

    • Auch gepinnte Abhängigkeiten enthalten wiederum weitere Abhängigkeiten, sodass man am Ende doch immer „zufälligen Code herunterlädt und hofft“. Besonders bei Electron-basierten Apps kommt dabei wirklich eine enorme Menge Code mit.

  • In letzter Zeit begegnet mir oft der Rat, Abhängigkeiten selbst bei Patch-Releases nicht zu aktualisieren, und ich verstehe das nicht. Wenn man nicht aktualisiert, sinkt vielleicht das Risiko, sich Malware einzufangen, aber normalerweise dienen Patches gerade der Verbesserung der Sicherheit. Ist es wirklich klug, die neuesten Patches nicht einzuspielen?

    • Entscheidend ist, den Grund für einen Patch und seinen Inhalt zu verstehen. Niemand hat Zeit, den gesamten Quellcode zu lesen, daher nutze ich zentrale Tools und Dienste wie Npm Audit, um Zusammenfassungen zu Schwachstellen zu prüfen. Ich verfolge die Strategie, Updates aufzuschieben, sofern sie nicht unbedingt nötig sind, weil Updates sowohl ein Angriffsvektor als auch eine Hauptquelle für Bugs sind. Trotzdem prüfe ich regelmäßig, welchen Schwachstellen ich ausgesetzt bin. Handelt es sich um Schwachstellen in Funktionen, die ich nicht nutze, verschiebe ich Updates manchmal. Nur wirklich kritische Fehler behebe ich sofort. Sicherheit ist ein aktiver, fortlaufender Prozess, und die Reaktion sollte vom Risikotoleranzniveau der Organisation abhängen. Weder „immer updaten“ noch „nie updaten“ ist die einfache Antwort.

    • Zurzeit werden bei jedem Update von Z-WaveJS UI wieder Abhängigkeiten aktualisiert. Wegen dieses unbefriedigenden Musters prüfe ich inzwischen selbst nach. Heute hängen alle von Abhängigkeiten ab, es „nimmt kein Ende“, und schon ein einziges Auto-Update kann riskant sein.

    • Bei Updates besteht immer das Risiko einer Verbesserung oder einer Verschlechterung, und im npm-Ökosystem (zu dem Obsidian gehört) ist dieses Risiko deutlich größer. npm braucht menschliches Eingreifen, um schädliche Pakete zu entfernen, daher verläuft die Bereinigung langsam. Wenn man Updates absichtlich etwas verzögert, kann das wenigstens einen gewissen Schutz bieten.

    • In letzter Zeit ist es üblich geworden, nach einem Patch-Release noch etwas zu warten, bevor man installiert. Heutzutage werden Vorfälle oft innerhalb weniger Stunden entdeckt. Mehrere Unternehmen überwachen npm und betreiben darauf Security-Business. pnpm lässt sich so konfigurieren, dass nur Pakete installiert werden, deren Veröffentlichung mehr als X Minuten zurückliegt. Ich warte mindestens etwa 24 Stunden. pnpm minimumreleaseage-Einstellung

    • Der Angriff auf mein Paket vor zwei Wochen zielte auf ein Patch-Release, es war kein postinstall-Skript. Automatisiertes Scanning entdeckt so etwas schnell, deshalb steht dieses Problem heute nicht mehr so stark im Vordergrund. Wenn in einem Paket eine Schwachstelle gefunden wird, kommt die Warnung sofort und klar verständlich. Version Ranges zu verwenden ist für den Umgang mit Supply-Chain-Angriffen der schlechteste Ansatz.

  • Ich kann der Behauptung schwer zustimmen, das Paket sei nicht groß, weil es nur Electron, CodeMirror und moment.js enthalte. Electron ist webview-basiert und damit Software von enormer Komplexität, und für moment.js gibt es bereits bessere APIs. Das Abhängigkeitsmanagement von Obsidian wirkt eher wie ein Mindeststandard als wie eine besonders beeindruckende Sicherheitsrichtlinie. Positiv ist allerdings, dass regelmäßig Security-Audits durchgeführt werden.

  • Ich habe bisher andere Apps statt Obsidian verwendet, aber langsam interessiert es mich doch. Dass es eine Electron-App ist, verbraucht viele Ressourcen und fühlt sich nicht nativ an, und bei JS habe ich immer ein ungutes Gefühl. Bin ich da einfach altmodisch?

    • JavaScript ist eine sehr sichere Sprache. Webbrowser sind ein erfolgreiches Beispiel dafür, dass JavaScript weltweit sicher ausgeführt werden kann. Jede Website kann nicht einfach die Daten anderer Websites lesen. Auch Electron sandboxt JavaScript in der v8-Engine. Solange man die Ausführung von nutzereingegebenem Code vermeidet, ist das sehr sicher. Das Problem mit Supply-Chain-Angriffen liegt an npm selbst, nicht an der Sprache JS. npm hat die Verantwortung, bei der Paketverteilung strengere Sicherheitsrichtlinien durchzusetzen.

    • JavaScript gehört, nach praktisch jedem Maßstab, zu den meistgenutzten Sprachen der Welt. Es läuft auf fast jedem Computer und Smartphone. Gerade deshalb werden Sicherheitsprobleme dort häufiger entdeckt. Daraus folgt aber nicht, dass native Apps sicherer wären.

    • Electron-Apps sind nicht per se ein Problem. GitHub, VS Code, Slack, Discord und Postman basieren alle auf Electron. Ich frage mich oft: Welche Aufgabe in einer Markdown-Notiz-App sollte wirklich ein Performance-Problem sein? Man könnte fast denken, jemand nutze auf einem uralten Laptop einen Lynx-Browser im Nur-Text-Modus.

    • Ich mag Electron nicht besonders (deshalb mag ich Tauri), aber Obsidian selbst ist trotzdem hervorragend, sodass man es deswegen nicht links liegen lassen sollte. Ich nutze es auch mit MCP als persönliche Wissensdatenbank und kann es empfehlen.

    • Electron ist schon schwergewichtig. Auf dem PC ist das meist kein großes Problem, aber auf Mobilgeräten wird der App-Start langsam, wenn sich Tausende Notizen ansammeln, selbst ohne Plugins. Nutzer behelfen sich mit Plugins oder Apps für schnelles Erfassen, aber ich würde mir ein leichteres, natives Obsidian wünschen.

  • Obsidian basiert auf Electron, und das bringt naturgemäß sowohl Schwergewichtigkeit als auch ein Risiko für Sicherheitslücken mit sich.

    • Dafür unterstützt es auf allen Plattformen dieselbe UX und eine Zugänglichkeit auf nativem Niveau.

  • Ich verwende Emacs und Org-Roam und betreibe das Ganze in einer VM ohne Netzwerkverbindung (einem Qube unter Qubes OS). Auch ich kann nicht jeden Code prüfen, der in Emacs ausgeführt wird.

  • Wer statt Obsidian eine native App mit geringerem Supply-Chain-Risiko möchte, kann als Alternative das GTK-basierte Zim Wiki nutzen, das in den wichtigsten Linux-Distributionen paketiert ist. Zum Zim Wiki

    • Dem Zim Wiki fehlen allerdings eine native Mobile-App und eine Sync-Funktion, und genau deshalb zieht es mich zu Obsidian. Solange man nicht wahllos Plugins installiert, ist es aus Sicherheitssicht völlig in Ordnung.