- サプライチェーン攻撃は、オープンソースコードに悪意ある更新が紛れ込む形で発生し、Obsidianはこれを最小化するために外部依存そのものを減らす戦略を採用
- アプリ機能の大半を自前で実装し、必要な場合はフォークしたコードを自社コードベースに取り込んで管理
- 必須の大規模ライブラリ（pdf.js、Mermaid、MathJax など）はバージョン固定によって安全性を確保し、更新はセキュリティパッチがある場合にのみ慎重に実施
- すべての依存関係はlockfileで固定し、postinstall スクリプトを実行しないことで、インストール時の任意コード実行を防止
- このような慎重な更新手順と時間的遅延の戦略により、Obsidianは潜在的な脅威がコミュニティで検出される前提を活かして対応可能
サプライチェーン攻撃とは何か
- サプライチェーン攻撃とは、オープンソースのエコシステムにおいて悪意ある更新が配布コードに紛れ込む手法
- 多くのアプリがオープンソースコードを利用しているため、1つの悪意ある更新が連鎖的に多数のアプリへ影響を及ぼしうる
- Obsidianは依存関係を最小化する戦略によってこの攻撃面を減らし、アプリを安全に設計している
依存最小化戦略：Less is Safer
- Obsidianは同カテゴリの他アプリと比べて非常に少数の外部ライブラリにしか依存していない
- 主要機能（例：Bases、Canvas）は外部ライブラリを導入せず自前実装している
- これにより、実行されるコードを完全にコントロールできる
- 小規模なユーティリティ関数は、ほぼ常に開発チームが直接実装している
- 中規模モジュールは、ライセンスが許す場合にフォークしてコードベースへ組み込む
- **大規模ライブラリ（pdf.js、Mermaid、MathJax など）**は、検証済みのバージョンを固定して取り込み、重大なセキュリティ問題が見つかった場合にのみ最小限のアップグレードを行う
- すべての外部変更を詳細にレビューし、徹底したテスト手順を実施する
- この方法によりサブ依存関係の数も最小化され、悪意あるコードが流入する一次的なリスクそのものを下げる構造になっている
実際のアプリに含まれる要素
- 実際にユーザーが実行するアプリには、Electron、CodeMirror、moment.js などごく少数のパッケージしか含まれない
- それ以外の開発ツールはアプリのビルド工程でのみ使用され、最終ユーザーには配布されない
バージョン固定と lockfile 管理
- すべての外部依存関係は厳格なバージョン固定（pin）とlockfile のコミットによって管理される
- これによりインストールは常に再現可能となり、変更履歴の追跡も容易になる
- postinstall スクリプトを実行しない方針により、インストール中に任意のコードが実行される可能性を根本から遮断する
遅く慎重な更新手順
- 依存関係のアップグレードが必要な場合は、以下のような体系的なレビュー手順を行う
- 変更履歴（changelog）を1行ずつ細かく確認
- 新バージョンで追加された下位依存関係を確認
- 変更幅が大きい、またはリスク要因がある場合は upstream ソースとの diff を直接確認
- 主要な経路とプラットフォームについて自動／手動テストを実施
- 以上すべての段階を通過して初めて lockfile をコミット
- ほとんどの依存関係は頻繁な変更を必要としないため、更新頻度自体が低い
- 新たな外部コードの導入は、新規依存関係の採用と同等の水準でレビューし管理する
安定性のための「時間的余裕」：Time is a buffer
- 各種アップグレードは即時に配布せず、一定期間遅らせる
- この期間は、オープンソースコミュニティやセキュリティ研究者が悪意あるバージョンを検出できる先行対応の窓口として機能する
- 実際の配布時点ではすでに問題が確認されている可能性が高く、リスク最小化に有効である
結論
- 単一のセキュリティ対策だけでサプライチェーン攻撃のリスクを完全に排除することはできない
- しかし Obsidian は、依存関係の最小化、浅いグラフ、バージョン固定、postinstall 禁止、レビュー重視の遅い更新を組み合わせることでリスクを大幅に低減している
- こうした手順により、コードがユーザーに届く前にリスクを検出するための時間も大きく確保できる
1件のコメント
Hacker Newsの意見
多くのユーザーが、Obsidianでサードパーティのコミュニティプラグインを使っている点を見落としているという意見が多い。実際、Obsidianのプラグインのセキュリティモデルは非常に脆弱で、プラグインはボルト内のすべてのファイルにアクセスできる権限を持っている。Obsidianが自前でより多くの機能を内蔵する努力をしていれば、セキュリティリスクは減っていたはずであり、あるいはブラウザ拡張のように、プラグインが使用する権限を明示し、許可されていない権限アクセスを遮断する構造に改善することも可能だ。これらはいずれも「サードパーティ依存が少ない」という論理より、はるかに実際的なユーザー保護を提供する
昔のソフトウェア業界の何人かが、ビデオゲーム設計のアイデアが他の一般的なソフトウェアへ流入する事例について語っていたが、今ではほとんど聞かなくなった。Blizzardのような老舗ゲーム会社の中核人材が、World of Warcraftのプラグインシステムの初期10年間における仕組み、問題点、セキュリティ強化の過程を詳しくまとめた本を書けば、ソフトウェア全体のエコシステムに大きく役立つはずだ。多くのプロジェクトのプラグインシステムは、ずさんさと未熟さが入り混じっている
Obsidianプラグインはボルト内のファイルだけでなく、コンピュータ上のすべてのファイルにアクセスできる。以前Discordでこの点を指摘したが、無視された経験がある
Arch Linuxに似ていると考える。AURでソフトウェアを直接管理する際、エンジニアでさえセキュリティの扱いに苦労する。一般ユーザーにセキュリティ責任を負わせることを期待するのは無理がある
近いうちに、Obsidianプラグインの中からデータ流出事例が明らかになると思う。その時になればチームはセキュリティ機構を導入するだろう。少なくとも認証済みパブリッシャー制度の導入が必要だ
商用でObsidianプラグインを開発している。一定水準以上のプラグイン向けに、より高いレベルの審査プロセスがあればよいと思う。Arch LinuxのAURのようなコミュニティ管理リポジトリと、より厳格な審査リポジトリの2つを運用すれば、プラグイン審査速度の改善とセキュリティ向上に役立つはずだ
「サプライチェーン攻撃は、多くのアプリで使われるオープンソースコードに悪意ある更新が紛れ込むこと」という説明があるが、オープンソース（FOSS）でないソースコードであっても攻撃対象になり得る。FOSSが必ずより脆弱だという認識は問題だ
「インストール中にpostinstallスクリプトを実行しない」という方針は意図としてはよいが、パッケージがすでに侵害されているなら、postinstallを省略しても残りのコードが安全になるわけではない。パッケージが正常なら、postinstallは正当なインストールを助けることもある。実際の事故はサプライチェーン攻撃より一般的な脆弱性パッチで多く発生するので、更新を止めることはむしろリスクを高める可能性がある
今日ではセキュリティスキャンは通常インストール後（post install）に行われる。インストール中は何も実行されないように防ぐのがよい。今後はインストール段階でスキャンや制限を行う機能がもっと増えてほしい。一部の商用ツールでは対応していても、一般的ではない
それでもビルドマシンを守るうえでは意味がある。無数の依存関係から任意のスクリプトが実行されることを心配しなくて済む
ユーザーに配布するすべてのコードに対する責任は開発者にある。依存関係を固定しないのは、「インターネットから無作為なコードをダウンロードして運に任せるようなもの」だ
依存関係を固定すると、その後のセキュリティパッチを取り逃がす可能性がある。これもまた危険なので、新しいセキュリティパッチが出たときに気づける仕組みが必ず必要だ。そのパッチをバックポートするか、新しいバージョンへ更新しなければならない
固定された依存関係も、それ自体がさらに別の依存関係を含んでいるので、結局は常に「無作為なコードをダウンロードして希望的観測に頼る」構造だ。特にElectronベースのアプリには、本当に膨大な量のコードが付いてくる
最近よく見かける助言の中に、パッチリリースが出ても依存関係を更新するなという意見があるが、理解できない。更新しなければマルウェア導入リスクは減るかもしれないが、通常パッチはセキュリティ改善が目的だ。最新パッチを適用しないことが賢明な選択なのか疑問だ
パッチを適用する理由と変更内容を把握することが重要だ。すべてのソースコードを読む時間はないので、主要なツールやサービス（Npm Auditなど）を使って脆弱性の要約情報を確認している。私は本当に必要でない限り更新を遅らせる戦略を取る。更新は攻撃ベクトルであると同時に、バグの主要な原因でもあるからだ。しかし、どの脆弱性に晒されているかは必ず定期的に点検する。使っていない機能の脆弱性なら更新を見送ることもある。本当に重要な欠陥だけをすぐ更新する。セキュリティは能動的かつ継続的なプロセスであり、組織のリスク許容度に応じて対応は変わるべきだ。単純に「常に更新」または「絶対に更新しない」が答えではない
最近Z-WaveJS UIを更新するたびに依存関係更新が繰り返される。こうした不満の残るパターンのせいで、自分で確認するようにしている。今や誰もが依存関係に依存する時代で、「終わりはない」。自動更新を一度するだけでも危険だ
更新時には改善にも改悪にもなるリスクが常にあり、npmエコシステム（Obsidianも該当する）ではそのリスクがはるかに大きい。npmは悪意あるパッケージの削除に人手の介入が必要で、対処が遅い。更新をあえて遅らせることで、多少は防御できる
最近はパッチリリース直後に少し待ってからインストールする流れになっている。今は事故が数時間以内に検知されることも多い。多くの企業がnpmを監視しており、セキュリティビジネスも行っている。pnpmは、パッケージ公開後X分以上経過したものだけをインストールできるよう設定できる。私は最低でも24時間は待つ pnpm minimumreleaseage設定
2週間前に私のパッケージが受けた攻撃はパッチリリースを狙ったものだった。postinstallスクリプトではなかった。自動化されたスキャンで素早く検知されるので、この問題は今ではそれほど大きく取り上げられていない。パッケージの脆弱性が見つかると即座に通知が来て明確だ。version rangesの使用は、サプライチェーン攻撃対策としては最悪だ
Electron、CodeMirror、moment.jsだけを含むのでパッケージは大きくないという主張には同意しづらい。ElectronはWebViewベースで非常に大きな複雑性を持つソフトウェアであり、moment.jsにはすでにより良いAPIがある。Obsidianの依存関係管理レベルは、むしろ最低限の基準にすぎず、特別に優れたセキュリティ方針とは感じられない。それでも定期的にセキュリティ監査をしている点は前向きだ
Obsidian以外のアプリを使ってきたが、Obsidianにも関心を持ち始めている。Electronアプリである点がリソースを多く消費し、ネイティブではないのでJSにいつも不安を感じる。自分が古い感覚すぎるのか気になる
JavaScriptは非常に安全な言語だ。Webブラウザが世界規模でJavaScriptを安全に実行しているのが成功例であり、各Webサイトは互いのデータを読めない。ElectronもJavaScriptをv8エンジン上でサンドボックス化している。ユーザー入力コードの実行さえ避ければ、かなり安全だ。サプライチェーン攻撃の問題はnpm自体にあり、JS言語の問題ではない。npmには、パッケージ配布時により厳格なセキュリティ方針を適用する責任がある
JavaScriptは、どの基準で測っても世界で最も多く使われている言語の1つだ。ほぼすべてのコンピュータとスマートフォンで動作する。そのぶんセキュリティ問題もより頻繁に見つかる。ネイティブアプリだからといって、より安全だという根拠はない
Electronアプリが問題というわけではない。GitHub、VS Code、Slack、Discord、PostmanはいずれもElectronベースだ。よく聞きたくなるのは、Markdownノートアプリで本当に性能が問題になるような何をしているのかということだ。本当に古いノートPCでLynxブラウザを使い、テキスト専用で見ているのかと聞きたくなるほどだ
Electronはあまり好きではない（だからtauriが好きだ）。それでもObsidian自体は非常に優れているので、Electronであることを理由に敬遠する必要はない。MCPと連携して個人用ナレッジベースとして使うのにも向いているので勧めたい
Electronは確かに重い。PCでは大きな問題にならないが、モバイルではノートが数千件たまると、プラグインがなくてもアプリ起動が遅くなる。ユーザーは高速記録用プラグインやアプリで回避しているが、もっと軽いネイティブObsidianがあればと思う
ObsidianはElectronベースであり、その特性上、重さとセキュリティ脆弱性のリスクを伴う
EmacsとOrg-Roamを使い、ネットワーク接続のないVM（Qubes OSのQube）で運用している。Emacsで実行されるすべてのコードを自分でレビューできるわけではない
ネイティブアプリでサプライチェーンリスクをさらに下げたいなら、GTKベースで主要LinuxディストリビューションにパッケージされているZim Wikiが代替になる Zim Wikiはこちら