警告！サプライチェーン攻撃は『少ないほど安全』で防げ！まさかの落とし穴に注意！
引用元：https://news.ycombinator.com/item?id=45307242
Obsidianのプラグインはvault内の全ファイルに無制限アクセスできるって。これってひどいセキュリティモデルだよね。Obsidianは「サードパーティの依存が少ない」って言うけど、コミュニティ任せで攻撃面を広げてるだけ。ブラウザ拡張みたいに、プラグインにパーミッションを宣言させるべきだよ。
Obsidianプラグインのヤバさは、vault内だけじゃなくて、マシン上の全ファイルに無制限アクセスできるってこと。もっとひどい話だよ。Discordで昔指摘したんだけど、スルーされちゃったんだよね。
Little Snitchを使って、Obsidianからの通信を全部ブロックしたらどうなると思う？
ほとんどのプラグインモデルって、Obsidianと同じようなものじゃない？VSCodeとかVim、Emacsなんかも内容を隔離したりしてる？プラグインの権限が制限されてるのって、ゲームくらいじゃないのかな。
Arch LinuxのAUR（Arch User Repository）の話を思い出したよ。エンジニアでさえセキュリティ管理が難しいのに、一般ユーザーにそれを期待するのは無理があるってことだよね。
昔はゲームデザインからソフトウェアに良いアイデアが流れてたのに、今は聞かないね。World of Warcraftのプラグインシステムがどう発展したか、そのノウハウが本になったら、ソフトウェア界にめちゃくちゃ貢献すると思うよ。多くのプラグインシステムが、本当にずさんすぎるんだから。
firejailとかQubesOSで仮想環境を使う選択肢はあるけど、やっぱりObsidian自体にもっと堅牢なセキュリティモデルがあったら嬉しいよね。
僕はObsidianとかDiscord、それにブラウザなんかでfirejailを使ってるよ。みんなにもマジでオススメするね。
firejailを勧める理由を教えてよ！選択肢が多すぎて、どれを選べばいいか分からなくなる（analysis paralysis）んだよね。
flatpakを使ってるなら話は別だよ。アクセスはかなり制限されるし、ユーザーの/homeへのアクセスも明示的に許可しないとダメだからね。
このアプリ、すごく大事な個人情報を扱うのに、堂々とElectronアプリなんだよね。これだけでかなり危険な兆候に見えるよ。
もっと良い代替案が出るまではElectronで我慢するしかないよね。Obsidianに匹敵するものなんてないんだから。
HNでのコメントを記録しとくべきだな。firejailについて長文コメントを何度も書いた気がする。もうやってられないよ :D
ユーザー空間だとbubblewrapとfirejailが一般的だね。bubblewrapは使ったことないからコメントできないけど、firejailはすごいよ。前回のコメントはfirejailでX11かWaylandへのクリップボードアクセスを簡単に制限できるって話だった。他にもFirejailではたくさんのことができるんだ。詳しくはここを見てね。
https://wiki.archlinux.org/title/Firejail
https://man.archlinux.org/man/firejail.1
Little Snitchってopen(2)をブロックできるの？
ブラウザ拡張機能って、わりとしっかりした権限ベースのシステムを持ってるよね。もし本気を出せば、Electronやnode-webkitみたいなブラウザっぽいローカルアプリも、拡張機能の権限をもっと細かく制限する方法を考えられるんじゃないかな。
vimやemacsは30年以上前のアーキテクチャだから、コードが信頼されていた時代のものなんだよね。現代のソフトウェアがそのセキュリティ姿勢を真似しちゃダメだと思う。VSCodeには言い訳の余地がないよ。ブラウザがベースなんだから、拡張機能を制限する機能は持ってるはずだろ。彼らの大きな見落としで、もっと批判されるべき点だと俺は思うね。
「エンジニアが自分のセキュリティも管理できないのに、なぜユーザーに期待するのか？」って話だけど、今回の攻撃はCrowdstrikeも食らったよね。Huntressに侵入されてたとしたら、彼らが与えられたアクセスをどれだけ悪用できたか想像してみて。セキュリティ担当者や企業は自分たちが重要だと思ってるけど、C suiteはトラブルが起きたときのスケープゴートと見てるし、ほとんどのエンドユーザーも空港で靴を脱ぐのと同じくらい無意味だと思ってる。大体間違ってないんだよ。
エンジニアが自分のセキュリティを管理できないわけじゃない。まるでタコと戦うように複雑にしちゃったからで、シームレスで当たり前になるべきなんだ。それに、セキュリティとプライバシーは密接に関係してる。ユーザーにそれを教えるのは、俺たちの業界の大部分の利益にはならないってこと。
https://news.ycombinator.com/item?id=45183589
「エンジニアは自分のセキュリティを管理できないわけじゃない」って言われたけど、どうかな。俺のPCには少なくとも1つハードウェアバックドアがあるけど、同等のエクスプロイトがないハードウェアなんて手に入らない。OSもコード修正を極力困難にするツールで作られてるし、アプリの分離も最低限。それに、一生かけても読み切れないほど巨大だよ。それでも一番使えるOSで、これよりセキュアなものだと使い物にならない。
ブラウザはOSのほぼ新しいレイヤーみたいなもんで、さらに10倍も大きい。有名だけど、修正不可能なくらい複雑に書かれてる。
みんなが今注目してるのはアプリケーションだけど、これらをセキュアにしても、上記のすべてを解決しない限り、ほとんど意味ないってことだね。
Obsidianの機能を「賢く、重要に感じさせるため」に必要だと思い込んでるだけだよ。もっと良い選択肢はあるんだから。結局、お前はただメモを取ってるだけだろ。日記を書くならObsidianみたいなのに入れちゃダメだよ。セキュリティやプライバシーの点では、Apple Notesの方がまだマシだね。
彼らは、開くことはできるけど、データをどこにも送れないって言ってるんだと思うよ。ちょっとやりすぎな気もするけど、まあ現状はこれだよね。
ゲーム開発も80/29ルール（80/20ルールの遊びか？）を効果的に適用すれば報われるけど、商用ソフトウェアではあまり見かけないよね。各ゲーム世代で、次世代ハードなら簡単なのに現世代ではめちゃくちゃ難しいゲームがあるんだ。結局は賢さやごまかしで動かしてるんだよ。
そう思ったんだけど、もう何年も経ってるのに、僕が知る限りVSCode拡張機能の分離はまだないんだよね。Microsoftはお金をたくさん持ってるのに気にしないなら、小規模なアプリケーションが細部を詰めるのは期待できないよ。
僕はObsidianプラグインを商業で開発してるんだけど、特定のグレードのプラグインにはもっと高いレベルの審査があればいいのにと思ってるよ。個人的にはArch LinuxのAURみたいに、コミュニティ管理のプラグインリポジトリと、もっと審査が厳しいものを併用すべきだね。そうすればプラグインのレビュー時間も短縮できるだろうし。
この批判はフェアじゃないと思うよ。ほとんどの一般的なパッケージはArch Linuxが管理してるコアとエクストラリポジトリでカバーされてるし、AURはユーザーのビルドスクリプトの集まりなんだ。使うにはある程度のスキルが必要だし、ほとんどのユーザーはセキュリティの危険性を明確に知ってるはずだよ。ArchがAURを管理・監視するのは役割外だし、投票やコメント機能でユーザー自身が管理できるツールを提供してるんだ。人気のあるAURパッケージは有名なメンテナーが管理してるよ。
ソフトウェアがプログラム内部でも境界を強制する、強力な機能ベースモデルを採用してほしいね。最小権限の原則（POLA）で、呼び出すコードには必要な機能（例えばファイルを開くとか、ネットワークソケットとか）だけを渡して、現在のプロセスが持つ全てにアクセスさせないようにね。Thomas Leonardのブログ記事（https://roscidus.com/blog/blog/2023/04/26/lambda-capabilitie…）が詳しく解説してるし、OCamlのEioエフェクトシステムもこの側面を持つだろうね。Emily言語（OCamlのロックダウンされたサブセット）も、コントロールを回避できるエスケープハッチを取り除くために標準ライブラリの一部を積極的に削除していて面白かったよ。
お前は間違ってるよ。ObsidianはVSCodeと比べても悪くないさ。確かに権限はあるけど、拡張機能がプロセスを起動してそのプロセスが何でもできるのは、VSCodeでもすごくよくあることなんだからさ。
お前は間違ってるね。ObsidianのFlatpak版はデフォルトで/homeへのアクセス権を持って出荷されてるんだよ。ほら、ここを見てみろよ：https://github.com/flathub/md.obsidian.Obsidian/blob/5e594a4…
サプライチェーン攻撃って、まだ一般的じゃないし攻撃対象も大きくないから、開発者がそこまで時間かけないんじゃないかな。でも、悪意のあるブラウザ拡張機能でサンドボックスを破れば、何十万〜何百万ものユーザーを攻撃できるよね。VSCodeやIDEの拡張機能だと、ターゲットは数百〜数千人の開発者とか中小企業くらいだけど、情報セキュリティのブログには載るかもね。
もしOS上のどんなファイルでも開いたり書き込んだりできるなら、もう終わりだよ。ネットワークやソケットにアクセスできなくても、データはいくらでも漏洩させられるからね。
そう、ユーザーに提供するコードは全部、自分の責任だよ。依存関係を固定（Pinning dependencies）しないなんて、トラブルを招いてるようなもんさ。まさに「インターネットから適当なコードをダウンロードして、後は運任せ！」ってことだよね。
もっとコメントを表示（1）
依存関係を固定しちゃうと、固定したバージョンより後に出たセキュリティ修正が適用されなくなるってことでもあるんだ。それも問題だから、修正に気づいて、それをバックポートするか、修正済みのバージョンにアップグレードする仕組みが必要になるよ。
DependabotやRenovateみたいなツールを使えば、セキュリティアップデートがいつ利用可能になったかを教えてくれるから、依存関係を固定しつつも最新のセキュリティ修正を適用できる、まさに一石二鳥だよ。
「修正に気づいて、それをバックポートするか、修正済みのバージョンにアップグレードする仕組みが必要」って話だけど、RSS Feedじゃダメなの？
どんなコードも、根本的に決して安全じゃないんだよ。
「どんなコードも安全じゃない」ってのは、「コーヒーだって薬物だよね」って言うような、無意味な屁理屈だよ。
既知の脆弱性があるコードは、未知の脆弱性があるコードより桁違いに危険さ。
システム管理者に「どうせ脆弱性はあるんだから、セキュリティパッチなんて当てるな」って言うようなもんでしょ。そしたらランサムウェア攻撃でN-day脆弱性を突かれて支払いさせられるのがオチだよ。
最近、何か重要そうなアプリケーションのセキュリティパッチをレビューしたことある？ 90%は価値なし、本当に使える10%は簡単に見分けられるよ。みんなが思ってるほど大したことないんだよね。
依存関係を固定しても、結局はその依存関係がまた別のコードを持ってくるから、結局何が来るか分からないコードをダウンロードしてるのと同じだよね。Electronなんか特にそう、どれだけのコードがついてくるんだって話。
結局、できる限り依存関係（と、そのまた依存関係）を最小限にするのが一番だよ。意外と少ない数で済むこともあるし、長い目で見れば、たくさん抱え込むよりもずっと楽になるかもね。
そうそう、サーバアプリ出す時はDebianとかUbuntuにデプロイして、ディストリの依存関係だけを使うようにしてるんだ。そうすると、ディストリのセキュリティチームがパッチ当ててくれるし、OSバージョンアップまで新しいバージョンに強制されないから、長期的に運用しやすいよ。ライフサイクルコストも抑えられて、DevOpsのQoLも上がるしいい感じ。
（好きなディストリをここに入れてね、長期的に安定版にセキュリティ修正をバックポートしてくれるやつ）
「ランダムなコードをダウンロードして祈る」だけが選択肢じゃないよ。公開npmjsレジストリがひどくても、pnpmとプライベートレジストリを使えば、依存関係の全体像がわかるロックファイルを使って、脆弱性のない再現性のあるビルドができるんだ。もちろん、CVEsがない状態を維持するのは大変だけど、不可能じゃないよ。
確かに、これは部分的な改善に過ぎないね。もっと良くするには、各プラットフォーム向けにネイティブで作り直したり、プラグインをしっかりサンドボックス化したり、承認された権限がないとファイルやネットワーク操作ができないようにJavaScriptのサポート範囲を厳しく制限したりすることだろうね。
「postinstallスクリプトを実行しない」ってのはわかるけど、あんまり意味ないと思うな。もしパッケージがもう乗っ取られてたら、postinstallを止めても残りのコードが安全になるわけじゃないし。乗っ取られてないなら、正当なインストール手順を壊すリスクがあるだけだろ。セキュリティ的には変な妥協だよね。サプライチェーン攻撃より、通常のアップデートで修正される脆弱性の方が圧倒的に多いだろうし、アップデートを遅らせたり止めたりすると、逆に危険が増す気がする。
同意するけど、ちょっと複雑だよね。今どき、スキャンって普通はインストール後に行われるのが現状だから、インストール中に何か実行されるのを防ぐのは望ましいことなんだ。インストールの一環としてスキャンや制限ができる機能がもっと普及してほしいな。一部の専用ツールはすでにやってるけど、まだ一般的じゃないんだよね。
そうだね。例えば数日前、npmでcryptoマルウェアが大騒ぎになった時、たまたまパッケージを更新してたんだ。監査で数十個もの重大な問題が見つかったんだけど、それは全部インストールされた後だったよ。幸い、俺はインストールスクリプトを無効にしてたから、コードを実行せずに元に戻せたんだ。助かったよ。
とはいえ、ビルドマシンは保護されるよ。手軽にできる、良いセキュリティ対策だと思うね。適当なウェブアプリをちょっといじりたい時とかに、何億もの依存関係から勝手にスクリプトが実行されるのを心配しなくて済むのは大きい。
Obsidian以外のノートアプリを使ってるから、この記事は参考になるね。でも、ObsidianってElectronアプリだよね？Electronっていつもリソースを食うしネイティブじゃない感じがするし、JavaScriptも「安全」って印象がないんだけど、俺って時代遅れかな？
JavaScriptはめっちゃ安全な言語だよ。ブラウザがグローバル規模で安全なJavaScriptを動かしてるのが大成功の証拠だね。使ってるウェブサイト全部がJavaScriptを動かしてるけど、他のサイトのデータは読めないでしょ？Electronも同じで、v8を使ってJavaScriptをサンドボックス化してるよ。
ユーザーからの入力をサンドボックス内で実行しない限り（多くのプログラミング言語が許してるけどね）、すごく安全なんだ。サプライチェーン攻撃の問題はnpmに特有で、JavaScript自体とは関係ないよ。npmって組織が、最近の攻撃にもっと責任を持って、依存関係を公開するときにもっと厳しいセキュリティ管理をみんなに強制すべきなんだ。
これって、ブラウザのサンドボックスが安全ってことで、JavaScriptが安全ってことじゃないんじゃないの？
それとも、僕が知らないJavaScriptの特定の側面を言ってるのかな？（JavaScriptのこと、あんまり知らないんだけど）
ほとんどのJavaScriptはサンドボックスで動くから、まあ同じようなものって言えるのかもしれないけど、厳密には違うんじゃないかな。Electronが安全って言う方が正確なんじゃない？
このコメント、すごく気になるんだけど。プログラミング言語が安全って、どういう意味なんだろう？
チューリング完全なプログラミング言語なら、どれも同じくらい安全じゃないの？
セキュリティって、コンパイルしたり解釈したりするものからしか来ないんじゃないかな？JavaScriptは紙の上でも実行できるでしょ。
チューリング完全性は関係ないよ、それは計算能力の話だからね。セキュリティはシステムアクセスに関わるんだ。Brainfuckはチューリング完全だけど、単一の入力ストリームから読んで単一の出力ストリームに書く以外のプリミティブがないでしょ？
もし誰かがそのストリームを重要なファイルに繋がなければ、システムを攻撃には使えないよね。
言語設計はセキュリティにすごく影響するんだ。システムとやり取りするプリミティブが何を提供してるかで決まるからね。勝手なsyscallプリミティブがあるなら、その言語は安全なソフトウェアを書くのに役立たない。もしシステムとやり取りする唯一の能力が、外部から提供されてアクセスを許可されるCapabilityオブジェクトを経由するだけなら、きっとセキュリティをすごく考えて設計された言語を使ってるってことだよ。
ASLRみたいなオペレーティングシステムのセキュリティ機能って、低レベル言語が自分で作ってないメモリを読み書きできるから存在するんだよね。
逆に、ランタイムやコンパイラにバグがない限り、高レベル言語はそういう変なことはできないようになってるよ。
たとえば、Heartbleedバグを見てみて。OpenSSLは、適切に不正なリクエストが与えられたときに、自分が所有していないメモリを読んでしまったんだ。
JavaScriptって、ディスクからファイルを読み込むAPIなんて持ってないし、ましてや勝手なバイナリを実行するAPIもないんだよ。（NodeJSみたいなランタイムから来るものは別としてね）。
他のJavaScriptプロセス内のメモリにもアクセスできないし…だから何がJavaScriptを安全じゃないって言うの？
公平に言うと、メインアプリと同じJavaScriptコンテキストでプラグインが全部やり取りするようなJavaScriptベースのプラグインシステムは、大きなリスクがあるのは確かだよ。どんなプラグインでも、いくらかの制限はあるけど、グローバルスコープ内の定義や変数を変更できちゃうからね。でも、信用できないコードを信用できるコードと同じコンテキストやメモリなんかで実行する言語なら、何だってリスクはあるよ。唯一の解決策は、プラグインをサンドボックス化することだね。
これら全てがJavaScript言語自体を安全にしているわけでも、その結果でもないんだよね。セキュリティは、それがどう使われるかに圧倒的に依存していて、言語自体の特性じゃないんだ。
「安全性」は助けになるけど、Rustみたいな「安全な」言語でも、CやJavaScript、Pythonなんかと同じように、簡単に安全じゃない、セキュアじゃないコードを書いてパッケージ化できちゃうからね。
JavaScriptはたぶん、数え方にもよるけど、地球上で最も使われてる言語の一つだよね。
ほとんどのコンピューターと基本的に全ての電話で動いてるんだから、そういう事実ゆえに、たくさんのセキュリティ問題が発見されるのは当然だよ。「ネイティブ」アプリがもっと安全だっていう根拠は何なの？
「Earth」は僕らが住んでる惑星の固有名詞で、「earth」は土のことだよ。
Electronはそんな好きじゃないけど（Tauriありがとう！）、Obsidianはマジ最高なアプリだから、Electronだからって避けるのはもったいないよ。MCPと繋げば、個人の知識ベースとしても超便利に使えるんだ。
Tauri最高って言うけどさ、セキュリティの観点から見ると、最初に目についたのがこれだったんだよね。sh ＜(curl https://create.tauri.app/sh)
そうだね。でも、どうやって取得して検証するか知ってるでしょ？だから、適当なものをシェルにパイプするのはダメってのは同感。Tauriは（緩い意味で）信用できるし、シェルへのパイプはよくあるお決まりのパスだよ。これは低い価値の「臭いテスト」ってだけ。僕はgit cloneしてからDockerで立ち上げる方が好きだな。その方が少しサンドボックス化される気がするんだ。
僕は公式のパッケージマネージャー対応（Debian、Macportsみたいな非公式リポジトリでもいいから）があったらいいなって思うな。昔はソフトウェアってtarballにまとめられてたのに、今はデベロッパーがシェルへのパイプを推奨する時代になっちゃったね。
もっとコメントを表示（2）
いや、Electronはそんな問題じゃないよ。GitHubとかVS Code、Slack、Discord、PostmanもElectronアプリだし。それに、Markdownのノートアプリでパフォーマンスがそんなに気になることって何してるの？もしかしてThinkPad 701CでLynx使って読んでるとか？
Markdownのノートアプリでパフォーマンスがそんなに気になることって何してるの？って言うけど、起動した時に早く立ち上がってほしいだけだよ。
それがNotionから離れた理由なんだ。起動がとんでもなく遅いんだよね（もしかしたら頻繁にアップデートしてるから？）。
結局MarkdownがHTMLになるなら、Webブラウザを使ってもいいんじゃない？
JavaScriptはメモリ管理言語だから、C++よりずっと安全だよ。
バッファオーバーフローって実際のセキュリティインシデントの0.001％しか占めないんだよ。C++のハッカーがマシンを乗っ取ることを心配する前に、秘密鍵の漏洩とかサプライチェーンの問題を先に解決しようぜ。
メモリ管理の脆弱性はバグの70％を占めると見積もられてるんだ。信頼境界でのコードがメモリ安全じゃない言語で書かれなくなれば、0.001%まで減るだろうね！
脆弱性ってのはセキュリティインシデントとは違うからな。
最近、新しいパッチがリリースされても依存関係を更新すべきじゃないっていうアドバイスがあるんだけど、理解に苦しんでるんだ。更新しないとマルウェアを誤ってインストールするリスクが減るのはわかるけど、パッチって普通セキュリティ向上のためにリリースされるものじゃないの？新しいパッチをインストールしないのは一般的に賢明じゃないと思うんだけど。
この問題に欠けてるのは、なぜ更新するのか、パッチの内容が何かを知ることだね。ソースコードは読めないけど、リリースノートの要約ツールは多いよ。Npm Auditとかね。僕は必要じゃない限り更新しない戦略をとってる。更新は攻撃ベクトルだし、バグの原因にもなるからね。でも、どんな脆弱性に僕が弱いかは常に把握してるよ。セキュリティってのは、組織のリスク許容度に合わせて調整する能動的で継続的なプロセスなんだ。「決して更新しない」とか「常に更新する」っていう一括した考え方じゃなくて、もっと情報が必要だよ。
まったくその通り。セキュリティ目的のパッチ以外は適用しないようにすれば、サプライチェーン攻撃のリスクはかなり減らせる。SemVerだけじゃセキュリティ関連パッチかどうかわからないし、リリースノート確認も手間がかかるから、スケールしないのが問題だね。SAST（Semgrep、Snykとか）やサプライチェーンスキャンが役に立つけど、これらは高価なんだ。オープンソースツールもたくさんあるけど、セキュリティベースラインを作るためにツールの数が増えるとオーバーヘッドも増える。結局、時間がない企業は高いクローズドソース製品を使うことになるんだよね。
ReDoSの件だけど、現在のCVSS評価システムは不十分だと感じてるんだ。可用性は重要だけど、セキュアコーディング原則（フェイルクローズド）に従うなら、整合性や機密性が侵害されるよりもシステムがダウンする方がいい。可用性の問題が、整合性や機密性の問題と同じ（高い）評価を受けることが多いのはフラストレーションがたまるね。
新しいパッチが出ても、すぐに適用を避けるんじゃなく、少し待つのがいいと思うよ。最近は侵害が数時間で見つかるからね。npmパッケージのリリースを監視してる会社もたくさんあるし。pnpmには、パッケージが最低X分経過してからインストールする設定があるんだ。安全のために最低24時間は待つといいかもね。https://pnpm.io/settings#minimumreleaseage
俺のパッケージを襲った攻撃はパッチリリースだったんだけど、まさにこういう前提を悪用してたんだ。Post-Install scriptでもなかったしね。
自動スキャンが進化した今じゃ、脆弱性はすぐわかるし、アラームも明確に鳴るから、正直そんなに問題じゃない。
サプライチェーン攻撃を気にするなら、バージョン範囲指定はマジで最悪だってずっと言ってるよ。
アップデートで良くなるか悪くなるかの綱引きはリアルだしどこにでもあるけど、npmエコシステムのアプリ（Obsidianとか）は特にひどいよ。
npmは狙われやすいし、人手を介さないとパッケージの削除や使用ブロックができないんだ。
だから悪意のあるパッケージの削除が遅い。自分のアップデートを遅らせるのが、この対策に少しはなるね。
「サプライチェーン攻撃は、多くのアプリで使われるオープンソースコードに忍び込む悪意のあるアップデートだ。」違う！
正しくは、「サプライチェーン攻撃は、多くのアプリで使われるソースコードに忍び込む悪意のあるアップデートだ。」だよ。
FOSSを責めるのはやめろよ。FOSSソフトウェアは安全じゃないって思ってる人が多すぎるんだ。
＞アプリを構成するパッケージはElectron、CodeMirror、moment.jsなどごくわずかだ。
これって、今まで書かれた中で最も複雑なソフトウェアの一つであるWebView、テキスト編集用のコードエディタ全体、そして新しいAPIで代替できる非推奨の時間ライブラリを肥大化したパッケージとして提供してるってこと？正直、全然すごいと思えないね。
Obsidianがやってることは、どんなソフトウェアでもパッケージ管理として最低限のことであって、真剣なセキュリティポリシーの証拠じゃない。セキュリティ監査はしてるけど、それは良い習慣だと思う。
Obsidianは大好きだけど、プラグインがないとまともに使えないアプリなのに、プラグインのセキュリティモデルがひどすぎて、整合性の保証もほとんどないってどうなの？
もしかしたら、サプライチェーンのリスクを減らすことについて、偉そうにアドバイスしない方がいいんじゃないかな。
でも、VSCodeはどうなんだ？
VSCodeチームがサプライチェーンセキュリティについて話してるの聞いたことある？
Obsidianはユーザーとして大好きだけど、開発者としてこの記事はナンセンスで予測可能だね [1]。Obsidianのクレジットページには20個の依存関係があるけど、Electronを例に取ると、その依存関係の依存関係…と、深層まで追うと膨大な数になるんだ。
Obsidianチームはこれら全てをレビューしてるのか？誰が所有してるのか？チェーンの各層が問題を検知すると信じてるのか？これらの依存関係のどれか一つでも侵害されたら、無数の重要なユーザーデータにアクセスされる。これがサプライチェーン攻撃の意味だよ。
[1] https://drewdevault.com/2025/09/17/2025-09-17-An-impossible-…
偶然だけど、昨日俺もそれやったよ。Mermaidは137個もの依存関係を抱え込んでるんだ。
ObsidianもObsidianの人たちも好きだけど、結局サンドボックス化することにしたよ。
公平に言えば、Electronプロジェクトはその規模から、自身の依存関係のレビューにそれなりのリソースを投資してるだろうね。
でも、これは良い演習だよ。ソースから製品全体を完全に理解することを優先するYoctoみたいなシステムがもっと必要だと思う。
