今年初め，人気の高いBowerパッケージマネージャのアーカイブ抽出機能に脆弱性が発見され，ユーザのディスクに攻撃者が任意のファイルを書き込めることが明らかになった。Node.jsのセキュリティWGメンバでSnyk開発アドボケートのLiran Tal氏が記したように，この攻撃で使用されているベクタアタックは，BBS初期の時代から知られているものだ。
セキュリティ研究者のskyn3t氏が2019年1月1日に報告した内容によれば，シンボリックリンク検証の不適切さを利用した悪意のあるzipアーカイブを作成することで，zip展開ディレクトリ外に任意のファイルを書き込むことが可能になる。Tal氏によると，Bowerでこのようなパスのトラバーサルが可能になった原因は，小さなNode.jsパッケージであるdecompress-zipにあるが，これが唯一のケースであるとは考えられない。事実，この種の脆弱性はJavaSctiptやRuby，.NET，Go，Javaを含むさまざまなエコシステムで見られており，数千のプロジェクトに影響するものと思われることから，ZipSlipと命名するにふさわしいものだ。さらに驚くのは，ZipSlipで使用されている攻撃方法の基本的な部分は，掲示板システム(BBS)時代からよく知られたものである上に，これまで何度も悪用されてきたという点だ。
InfoQはＴａｌ氏と話す機会を得て，ソフトウェアのセキュリティ，特にNode.jsのセキュリティについて学ぶことができた。
自己紹介と，Synkで何をしているのか，簡単に紹介して頂けますか？
ここしばらくはソフトウェア開発者をしています。最近では5年ほど，エンジニアリングマネージャとしてWeb開発チームの指揮を行っていました。Synkにはデベロッパアドボケートとして参加して，他の開発者がオープンソースを安全に使用できるように支援するとともに，セキュリティに関する作業の対象をNode.jsやJavaScriptエコシステムへと拡大しています。Synkでの仕事は素晴らしい経験です。ここにいるのは旧知の人たちですし，これまでに何年も，いくつかの現場でsynkを使ってきたからです。
世界的な統計によると，ソフトウェアの脆弱性はこの数年間で着実に増加しています。それが基本的なコンポーネント(CPU，OS，ネットワークスタックなど)から，ユーザが直面するアプリまでのソフトウェアシステムに影響して，これまでにない規模でユーザデータの盗用が行われています。これは私たちのシステムが以前より脆弱になったのでしょうか，それとも，複雑性の点で規模が大きくなり過ぎたのでしょうか，あるいは，セキュリティの重要性が広く認知されたことによって生じた前向きな効果なのでしょうか？
いま挙げられたすべてのものが影響していると思います。システムが複雑になっていることは間違いありませんし，20年前に比較すれば，抽象化されたものが多くなっています。これ自体は悪いことではありませんが，複雑さが増したことで，必要なスキルや専門知識も高くなっているのです。
システムが意図的に脆弱にされることはありませんが，すべての開発者が関係していることは間違いありません。コードを追加すれば追加するほど，バグやセキュリティ上の脆弱性のリスクは高くなります。ここ10年の間に，オープンソースの採用数は大幅に増えました。オープンソースソフトウェアのムーブメントに古くから関わっているものにとっては驚くべきことで，本当に心躍るものです。同時にこれは，私たちの開発するプロダクトが，潜在的に多くの開発者によって開発されたコンポーネントを使用している，という意味にもなります。言い換えれば，セキュリティ的なノウハウを持っているのか，コードベースに十分な監査を行っているのか，まったく分からない人たちの開発したものなのです。
このトピックについてお話できることを本当に嬉しく思っています。というのも，私はこの数週間，オープンソースのセキュリティの状況について，実際の数値を明らかにするレポートの作成に取り組んでいるからです。アプリケーションライブラリやシステムライブラリ，オープンソース開発者とメンテナの姿勢について調べています。彼らがセキュリティ上の脆弱性を発見する方法や，CIにどの程度の自動セキュリティテストを含めているかなど，開発コードベースのセキュリティ的な側面について興味深いことが分かりました。当社はこの報告書を昨年もリリースしていますが，新たな2019年版が数週間以内に公開される予定です。
全体的に見てE.S.Raymond氏は，十分に目を届かせることができれば，どのようなバグでも深刻ではないという，妥当な考えを持っていると思います。プラットフォームとしてのGitHubは，オープンソースコミュニティに参加するための敷居を非常に低いものにしてくれます。これはオープンソース採用への大きな貢献である，と私は思います。GitHubではコードベースのセキュリティ検査や，脆弱性とその修正に関してメンテナに協力することが比較的簡単にできます。一方で，昨年の報告書から収集した興味深い数値として，コードベースに混入した脆弱性の公開に要した期間が最大5.9年であった，というものがあります。ソースコードに潜んでいる脆弱性を誰かが見つけて発表するまでには，それほど長い時間を要する，ということです。いくつかの人気ライブラリを対象として私たちが調査した結果では，この期間の中央値は2.5年でした。
あなたの専門分野であるNode.JSについてお聞きします。先日あなたは、Bowerに関する脆弱性を発表しましたが、Bowerは現在も広く使用されています。さらに大きな不安があるのは、NodeJS/JavaScriptエコシステム最大のパッケージマネージャであるNPMの状況です。脆弱性を持ったソフトウェアを出荷するリスクを最小限にするために、開発者は何をすべきでしょうか？
問題が広範囲に及んでいるので，取り組みは大変なことになりそうです。 npmのセキュリティには，npmレジストリ自体のセキュリティと，開発者やメンテナのプラットフォームとしての2つの面があります。前者については，ビルドを支えるエコシステムとして，セキュアな基盤を提供するための適切な手段を備えているかという点で，これまでにも批判の対象となっていました。後者は，npmレジストリにホストされているJavaScriptソースコードのコレクションが備えている，セキュリティレベルの問題です。
可能な限り早い段階からセキュリティに取り組むというのは，セキュリティを重要視する上でよい出発点になります。Tanya Janca氏の言うように，まず最初に必要なのはセキュリティの考え方であり，セキュリティが全員の仕事であるという理解です。セキュリティの問題を設計とコードレビュープロセスの一部として受け入れて，それをサポートする優れたプロセスセットやツーリングを，毎日の開発ワークフローに継続的に取り入れるのです。
ビルドプロセスの一部として静的コード分析プラグインを採用する，あるいはプロジェクト内でオープンソース依存関係に関する脆弱性の可能性を見直す，といったことが考えられます。Synkの包括的な脆弱性データベースや，脆弱性を報告するだけでなく，依存関係のアップグレードに必要な最小限の変更をプルリクエストとして自動的にオープンするといった，プロアクティブなアプローチにも最適です。
CIインテグレーションで脆弱性をスキャンする だけでは，セキュリティの問題は解決しません。 Webアプリケーションを開発して，脆弱性を残さずに本番環境に展開し，次のプロジェクトに移る，という状況を考えてみてください。ソースがメンテナンスされなくても，最近のレポートや長年のセキュリティ経験で学んだように，脆弱性は後になって表面化します。どうすればそれが分かるでしょう？その間，プロジェクトの依存関係も監視していれば，セキュリティ上の問題が見つかった場合には，前のプロジェクトに立ち戻って修正を施すことができます。これがsyncに組み込まれている機能で，その全体的なアプローチは，ソフトウェア開発ライフサイクル全体に取り入れられるべきものです。
先程挙げられたBowerの脆弱性に関しては，synkセキュリティチームが昨年実施した調査と関連しているだけでなく，最初に取り上げられたのが20年程前のPhrackの記事である，という興味深い事実があります。この調査により，zipアーカイブ実装が不適切であることが原因で，任意ファイルの書き込みによってリモートコードが実行されるという脆弱性を抱えているプロジェクトが何千もあることが分かりました。これはまた，オープンソースソフトウェアを使うことの影響を示してもいます。ひとつのライブラリに脆弱性があれば，数千のプロジェクトやコードベースに現れる可能性があるのです。
想像に難くないように，npmやyarn，あるいはBowerのようなサプライチェーンサービスはすべてアーカイブに関与しなければなりません。Bowerでは特にそれが，Zip Slioの脆弱性として顕在化したということなのです。それがどのように影響するのかという概念実験に興味があるのでしたら，この問題のストーリと技術的な展開についての拙著をお読みください。
NodeJSエコシステムとして，より構造的なレベルで取り組むべき作業はありますか？
Node.jsの観点からは，セキュリティワークグループが，Node.jsの，そして関節的にはJavaScriptエコシステム全体のための，よりセキュアなエコシステムの実現を支援すべく，いくつかの責任領域でタスクを持っています。
私たちは現在，関連するNode.js APIやセキュアなコードレビュー，Node.jsコアのセキュリテイテストといったセキュリテイフォーカスのレビューと改善に，積極的に取り組んでいます。ワーキンググループはさらに，npmレジストリ上のサードパーティエコシステムモジュールとNode.jsコアの両方に対して，インシデント対応チームとしても活動しています。
コミュニティにセキュリティ知識や"Node.js Security Roadmap"のような洞察を提供する外部活動や，筆者が提供している"awesome-nodejs-security"リソースのような，外部での活動も存在する。より詳細な情報は，今後Security WGから提供されるものと思われる。