新しいWebプロジェクトのセットアップコマンドを実行し、ダウンロードされたパッケージの数を数えてみると、その数はたいてい1,000を超える。そのうちのいくつ分のコードを読んだことがあるだろうか？
よく見られる3つの攻撃パターン
- 著者のアカウントを乗っ取る――攻撃者が公開権限を奪い、マルウェアを仕込んだバージョンを公開する。ユーザーが通常通りアップデートを行い、感染してしまう
- パッケージ名の偽装 — 一般的なパッケージ名と似た名前を登録し、ユーザーが誤入力するのを待つ
- 長期的な信頼獲得 — 数ヶ月にわたり善意の貢献を行いメンテナンス権限を取得した後、巧妙なバックドアを仕込む
3つ目のタイプは、マルウェアが徐々に仕込まれ、読みやすいソースコード内ではなく、ビルドファイルやテストデータに隠されているため、最も危険です。
労力に応じた防御
手軽で今すぐ実行すべき対策：lockファイルで正確なバージョンをロックし、それをリポジトリにコミットする；脆弱性の自動スキャンを有効にする；パッケージのインストールスクリプトが勝手に実行されないようにする。
平均的な対策：インターネットから直接ダウンロードするのではなく、社内に中間キャッシュを保持する。新しいバージョンを取得するまでの遅延を数日に設定する。これは、マルウェアのパッチの大部分が最初の48時間以内に検出されるためである。
高価ですが、重要なシステムにはその価値があります：ソースコードからの再構築や照合、署名の検証が可能で、依存関係を大幅に削減できます。
ライブラリを追加する際に考えておくとよい質問：もしこのパッケージの作者が明日敵対的になった場合、私のシステムは何を失うことになるのか？
Thảo luận