悪意のあるパッケージが本番環境に到達する前に阻止する

開発者は、不審なコードを1行も書かなくても、プロジェクトに悪意のあるコードを持ち込む可能性があります。パッケージのインストールだけで十分な場合があります。依存関係は一見正当で、よく知られた名前を持ちながら、インストール中に意図しないコードを実行することがあります。

そのため、パッケージのセキュリティはアプリケーションが本番環境に到達するずっと前から問題になります。最初の危険な操作は、開発者の Windows ワークステーション上、CI ランナー内、または自動ビルド中に発生する可能性があります。デプロイ直前だけに配置された管理策では、その経路の大部分が露出したままになります。

リスクは開発マシンで始まる

現代のプロジェクトは大規模な依存関係ツリーを取り込みます。開発者が意図的に10個のパッケージをインストールする一方で、パッケージ マネージャーはその背後で何百もの推移的依存関係を取得することがあります。その連鎖内のすべてのパッケージを検査する人はほとんどおらず、手動で行えば通常の開発が耐え難いほど遅くなります。

攻撃者はその信頼を悪用します。悪意のあるパッケージの中には、環境変数、資格情報、ブラウザー データ、認証トークンを盗もうとするものがあります。また、開発者がパッケージを開く前に、別のペイロードをダウンロードしたり、インストール スクリプトを通じてコードを実行したりするものもあります。

Windows では、影響を受ける環境には PowerShell セッション、パッケージ マネージャーの資格情報、SSH キー、クラウド ツール、現在のユーザー アカウントが利用できるファイルが含まれる可能性があります。WSL は同じマシンに別の開発環境を追加するだけで、基盤となるサプライ チェーン リスクを取り除くわけではありません。

悪質な依存関係は、必ずしも悪質に見えるとは限らない

パッケージ攻撃は、悪意のあるコンポーネントが開発者がすでに見慣れているものに似ている場合、発見がより困難になります。侵入口はさまざまです。

• タイポスクワッティング: 人気のある依存関係と1～2文字しか違わない名前をパッケージが使用する。
• 依存関係の混乱: 公開パッケージが内部依存関係と衝突し、自動ビルドによって選択される可能性がある。
• メンテナー アカウントの侵害: 攻撃者が公開アクセスを取得した後、信頼されていたパッケージに悪意のあるリリースが行われる。
• 悪意のあるアップデート: 以前は無害だったプロジェクトが、後のバージョンで動作を変える。
• 隠れた推移的依存関係: 開発者が選択したパッケージの数階層下に危険なコードが入り込む。

人気はセキュリティの保証ではありません。侵害されたプロジェクトは、過去のクリーンなリリースから何年もの評判を引き継ぐ可能性があり、新しい悪意のあるパッケージは、不審な動作が気づかれる前にダウンロード数を伸ばすことがあります。

後からのスキャンでは手遅れになり得る

多くのチームはすでに依存関係をスキャンしており、それらのチェックは依然として重要です。ソフトウェア構成分析は既知の脆弱性を特定できます。リポジトリ スキャナーは、露出したシークレットや危険なコードにフラグを付けることができます。CI セキュリティ チェックは、問題のあるビルドがデプロイされるのを防ぐことができます。

タイミングによって、それらの管理策で防げる内容は変わります。

開発者が Windows Terminal でインストール コマンドを実行し、要求されたパッケージに悪意のあるインストール スクリプトが含まれている場合、最初の本格的な CI チェックが行われる前に、コードがローカルで実行される可能性があります。本番環境がクリーンでも、ビルドが始まったマシンで資格情報が盗まれたことを取り消すことはできません。

既知の脆弱性のスキャンは、別の問いに答えるものです。既知のセキュリティ問題に関連付けられたバージョンの検出には強力ですが、新しく公開された悪意のあるパッケージには、まだ CVE や確立された脆弱性記録が存在しない可能性があります。

パッケージを通過させる前にチェックする

1つのアプローチは、開発者またはビルド システムとパッケージ レジストリの間に管理策を置くことです。要求されたすべてのパッケージを環境に直接許可するのではなく、管理策が最初にそれを評価し、疑わしい条件に該当するソフトウェアをブロックできます。

これが依存関係ファイアウォールの基本的な考え方です。

有用なのは、その判断がどこで行われるかです。パッケージは、環境にすでに入り込んだ後に問題として発見されるのではなく、インストール前に評価されます。シグナルには、不審な公開パターン、既存のパッケージを模倣した新規作成パッケージ、または追加の精査に値するその他の動作が含まれる場合があります。

だからといって、その管理策が絶対確実になるわけではありません。誤検知も重要です。新しくリリースされたパッケージは正当な場合もあり、通常とは異なる公開活動が自動的に悪意があるとは限りません。パッケージ チェックが正当な更新を頻繁に妨げると、開発者は回避策を探し始める可能性があります。

Windows 開発には独自の露出面がある

Windows 開発環境では、1台のワークステーションに Git、Node.js、Python、PowerShell、Visual Studio Code、Docker Desktop、WSL、クラウド CLI、ローカルに保存された資格情報が組み合わされることがよくあります。そのため、アカウントのアクセス許可とローカル セキュリティがパッケージのリスクに関係してきます。

いくつかの一般的な選択により、利用可能な攻撃面を減らせます。

• 可能な限り、日常的な開発は管理者以外のアカウントで行う。
• 未知のインストール コマンドを管理者特権の PowerShell で実行しない。
• 本番用の資格情報とローカルの開発用資格情報を分離する。
• 突然インストール スクリプトやインストール後スクリプトを導入したパッケージをレビューする。
• まだ信頼を得ていないソフトウェアには、隔離された環境を使用する。

Windows セキュリティ機能はオペレーティング システム層で役立ちますが、依存関係ツリー内のすべてのサードパーティ パッケージが特定のプロジェクトに属しているかどうかを判断することはできません。

ロックファイルは役立つが、何が安全かを判断することはできない

ロックファイルはパッケージのバージョンを予測しやすくし、インストール間の予期しない変更を減らします。しかし、ロックされたバージョン自体が悪意のあるものかどうかには答えません。

同じ制限は、他の管理策を単独で使用する場合にも当てはまります。バージョンの固定は一貫性をもたらします。コード レビューは、開発者が実際に確認できる変更を捉えます。脆弱性スキャンは既知の弱点を検出します。エンドポイント保護はマシン上のアクティビティを監視します。

チームはまた、内部パッケージの公開に MFA を要求したり、放棄された依存関係を削除したり、ロックファイルの変更を監視したり、不要なインストール スクリプトを制限したり、重要なサードパーティ プロジェクトでの突然の所有権変更を調査したりすることもできます。

より強力なアプローチは多層化です。パッケージ レジストリから開発マシン、ビルド システム、本番環境までの全経路を、単一の管理策でカバーすることはできません。

最も早い有効な時点でパッケージを阻止する

本番環境のセキュリティは本番環境に入る前から始まります。悪意のある依存関係がデプロイされたビルドに現れる頃には、すでに開発者のノート PC、パッケージ キャッシュ、ビルド システム、CI インフラストラクチャを通過している可能性があります。

パッケージ チェックをインストール直前の段階に移すことで、後のスキャンが必要なくなるわけではありませんが、その隙間を縮小できます。Windows ベースのチームにとって、開発マシンはソース コード、資格情報、クラウド ツール、内部システムの近くに位置することが多いため、ワークステーションの保護は重要です。

実際的な問題は、1つのツールがあらゆるパッケージの安全性を保証できるかどうかではありません。開発プロセスが、そもそも実行を許可すべきでなかったパッケージをどれだけ早く拒否できるかです。