【JavaScript】オープンソース開発者が悪に走る時…意図的なライブラリー改ざん騒動から考える [樽悶★]

【JavaScript】オープンソース開発者が悪に走る時…意図的なライブラリー改ざん騒動から考える [樽悶★] at NEWSPLUS

1:樽悶 ★
22/01/25 22:22:12.98 XW40fPFn9.net
　JavaScriptの開発者であるMarak Squires氏は、自ら開発したオープンソースライブラリーが収入を生み出さない点に不満を感じ、意図的にライブラリーを破損させた。これにより、他のプログラマーやエンドユーザーは使用していたプログラムが使えなくなってしまうという事態に陥ってしまった。
　あなたがJavaScriptを使うプログラマーでない限り、「colors.js」や「faker.js」というJavaScriptライブラリーの名前は、オープンソースでありながらも耳にしたことがないはずだ。前者は、一般的なJavaScriptランタイムであるNode.jsを使用する際に、コンソール上のテキストを着色するものであり、後者はテスト用のダミーデータを生成するものだ。faker.jsは2500本を超えるnpmプログラムで使用されており、1週間に240万回もダウンロードされている。また、colors.jsは1万9000本近くのnpmパッケージで使用されており、1週間に2300万回ダウンロードされている。つまり、あちらこちらで使われている。ところがSquires氏は、自らで生み出したこれらライブラリーを破損させ、数万本に及ぶJavaScriptプログラムを正常に動作しない状態に陥らせたのだ。
（中略）
　Squires氏はなぜこのような行動に出たのだろうか。本当のところは何も分かっていない。GitHubで公開されているfaker.jsのReadme.mdファイルには、「実際のところ、Aaron Swartz氏に何が起こったのだろうか？」と記されている。Aaron Swartz氏とは、マサチューセッツ工科大学（MIT）の学術誌の記事を公開しようとしたという疑いで刑事責任を問われ、2013年に自殺した人物だ。
　この件と今回の事件がどのように関連しているのか、筆者には判断できない。
　同氏が自らのライブラリーに無限ループを仕込んだ理由のうち、最もありそうなのは金銭的なものだったと考えられる。現在は削除されているがGitHubのIssuesには、「謹んで申し上げるが、私はもはやFortune 500企業（そして規模のより小さな他の企業）を自らの無償の仕事でサポートしようとは考えていない。それ以上に語ることはあまりない。この機会に、数十万ドル規模の年間契約を私と締結するか、プロジェクトをフォークして他の誰かに作業をしてもらってほしい」と記されていた。
　しかしこれはおかしな理屈だ。オープンソース開発者は自らの仕事に対して十分に報いられるべきだが、自らのコードを破壊するのは他の人から報酬を得るための手段になり得ないはずだ。
（中略）
　この問題には、あまりにも多くの開発者がコードを確認することなく、流れ作業のようにダウンロード／デプロイしてしまうという問題も潜んでいる。この種の「知っていながら知らないふりをする」という意識がトラブルを呼び込むのだ。
　ソフトウェアパッケージがオープンソースプログラマーによって開発されているという事実だけで、そのパッケージに欠陥がないことにはならない。オープンソース開発者は他のプログラマーと同様に、数多くの間違いをしでかしてしまうものなのだ。違いがあるとすれば、オープンソースの場合には問題の有無を確認する機会があるというだけだ。デプロイに先立ってチェックするという選択をしなかった場合、何が起こったとしてもその責任はデプロイした側にある。
　犯罪を画策する一部の開発者らは、人々の盲目的な信頼を悪用してプログラム内にマルウェアを潜ませている。例えば、DevOpsセキュリティ企業JFrogは最近、npmリポジトリー内に、意図的に攻撃を仕掛けてユーザーのDiscordトークンを盗み出そうとする、17本の悪意あるJavaScriptパッケージが登録されていることを発見した。盗み出されたトークンは、Discordの通信やデジタルディストリビューションプラットフォームで利用できる。
（中略）
　ソフトウェアサプライチェーンを手掛けるCodenotaryは同社ブログへの最近の投稿に「ソフトウェアが完璧になることはなく、その依存関係を有するコードベースは常に更新を重ねるドキュメントと言える。これはつまり、良いものが悪いものに変わる可能性があるという点を心にとめながら、品質を追跡する必要があるということを意味している」と記している。まったくもって、その通りだ！
　そして同社は「真の、そして唯一の解決策は、使用や配備で依存している対象を掌握しておくということだ。『ソフトウェアの部品表』（SBOM）はこの問題の解決策になり得るが、SBOMは改ざんができないようになっているとともに、迅速かつスケーラビリティーのあるかたちで照会でき、バージョン管理されている必要がある」と続けている。
1/25(火) 7:30配信
URLﾘﾝｸ(news.yahoo.co.jp)
URLﾘﾝｸ(newsatcl-pctr.c.yimg.jp)

レスを読む