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

開発者は、疑わしいコードを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 を要求したり、放棄された依存関係を削除したり、ロックファイルの変更を監視したり、不要なインストール スクリプトを制限したり、重要なサードパーティ プロジェクトでの突然の所有権変更を調査したりすることもできます。

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

最も早い有用な時点でパッケージを止める

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

パッケージ チェックをインストールの近くに移すことで、後からのスキャンの必要性を排除することなく、その時間枠を短縮できます。Windows ベースのチームにとって、ワークステーションの保護が重要であるのは、開発マシンがソース コード、資格情報、クラウド ツール、内部システムの近くにあることが多いためです。

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