これは、 一連の記事 最も一般的なソフトウェアサプライチェーン攻撃の種類について: 公開レジストリを悪用する攻撃 オープンソースの ソフトウェアコンポーネント。前回のエピソードで分析した後、「悪意のあるパッケージの構造：その傾向とは？「悪意のある行為者が新規または既存の公開済みコンポーネントに悪意のある動作を注入する方法がわかったら、私たちは消防士のジャケットを着て、このように配信される悪意のあるソフトウェアを効果的にブロックする方法、あるいは、間違ったアプローチを取ったために潜在的に深刻なサイバーインシデントに対処する方法を検討する準備ができています。」
セキュリティに意識の高い専門家のほとんどは、この脅威への対処方法について考えを持っています。セキュリティマネージャーがためらうことなくこう言っているのを耳にしました。 SCA ツールは既にパッケージのバージョンがマルウェアであるかどうかを教えてくれます。あるいは、マルウェアがすぐに検出され削除されるような、よく知られた、評価の高いソフトウェアコンポーネントに依存していることも教えてくれます。脆弱性修正を自動的に取得するためにオープンなマイナー/パッチバージョンを使用しており、これはオープンソースの依存関係のリスクを低減するための適切な推奨方法です。早期にパッチを適用し、頻繁にパッチを適用する」の原則。
今回のエピソードでは、これらの考え方がなぜ間違っているのか、そしてこうした誤解がどのようにしてこの攻撃手法の普及と、組織が直面する圧倒的なリスクにつながっているのかを検証します。最後に、実際に効果のある対策と、それに必要な労力とリソースについて解説します。
よくある誤解
ソフトウェアセキュリティに関する取り組みの中で、私たちは攻撃手法の進化と、セキュリティ意識の高い人々による多種多様なアイデアを目の当たりにしてきました。組織は、この脅威に対して何が有効なのかを誤解していることが多いため、まずは何が効果的でないのかを検証します。以下に、よくある誤解をまとめたリストを示します（ただし、これは網羅的なリストではありません）。
誤解 #1: SCA ツールは既に悪意のあるコンポーネントを報告している
確かに！ しかし事後的に…おそらく、その要素がソフトウェアビルドで使用されていた場合、悪意のある攻撃者がすでに開発者や CI/CD ホスト。機密情報が流出したり、追加のマルウェアがダウンロードおよびインストールされたり、攻撃者が横方向に移動して既に他の場所にアクセスしている可能性もある。
ソフトウェア構成分析（SCA従来のツールは、既知の潜在的な脆弱性を特定するために設計されました。最新のツールは、信号対雑音比を高めることで、脆弱性が実際に到達可能か悪用可能かを判断するという点で優れた性能を発揮します。しかし、新しいマルウェアに対しては役に立ちません。悪意のあるコンポーネントをゼロデイ脆弱性と考えてみてください。悪意のある動作が検出された場合にのみ、コンポーネントはレジストリに報告され、セキュリティチームによるレビューの後、悪意のあるものとして確認され、レジストリから削除されます。 【1].
その時点で、世界（ SCAs) コンポーネント（または既存のコンポーネントのいくつかのバージョン）をインストールまたは使用することは良くないことだと認識している。しかし、これはコンポーネントがレジストリから入手できない場合の話である。サードパーティ製コンポーネントに脆弱性があること、あるいはレジストリによって悪意のあるものとして分類されたコンポーネントがあることを知ることは良いことですが、残念ながら SCA あるいは、一般的な監査ツールはこの状況では役に立たない。 を除いて SCA/監査ツールは、コンポーネントが組織内で使用される前に、それが悪意のあるものであるかどうかを事前に正確に把握することができます。.
悪意のあるオープンソースコンポーネントに対する対策は、それらを検出する必要があることを覚えておいてください。 急いでコンポーネントがレジストリに公開されてから、そのコンポーネント（バージョン）が組織で初めて使用されるまでの期間。これには推移的なコンポーネントも含まれます。
誤解その2：ビルド時にインストールスクリプトを制御することで、オープンソースコンポーネントによる悪意のある動作を防ぐことができる。
さまざまなパッケージマネージャは、スクリプトを実行する機能を提供します（コンポーネントのtarballに含まれています）。 【2]), 正当な理由、例えば異なるプラットフォームで必要な項目をコンパイルしたり、コードを生成したり、テストを実行したりするために使用されることがありますが、tarball に悪意のあるスクリプトが含まれていたり、攻撃者が正当なスクリプトの代わりに悪意のあるスクリプトを実行させたりできる場合、悪意のある者によって悪用される可能性があることを私たちは皆知っておくべきです。
このことを知っていれば、パッケージマネージャーがスクリプトを無視するように設定できます。たとえば、NPM では –無視-スクリプト フラグ（または構成プロパティ） .npmrc ファイル) はインストール中にスクリプトをスキップします。多くのエコシステムではスクリプトの実行が一般的であるため、これはいくつかの問題を引き起こす可能性があります。一部のパッケージマネージャでは、スクリプトの実行を無効にすることさえ許可されていません (ヒント: プロンプト「どのパッケージマネージャーでは、インストールスクリプトの実行を無効にすることができませんか？（お気に入りのAIで）。しかし、これは一般的に保護するものではありません（スキップ無効化設定がどこにでも存在するように強制する必要があります）。
また、悪意のある動作がインストールスクリプトではなく、実行時に実行されるソフトウェアにある場合、このオプションだけでは保護になりません。
誤解その3：バージョン固定によって悪意のあるコンポーネントのインストールが防止される
早期かつ頻繁なパッチ適用にはトレードオフがある。 オープンバージョン （セキュリティ修正プログラムが利用可能になった際にパッケージマネージャーが自動的に新しいアップデートをインストールするようにする） バージョン固定 （固定バージョンのソフトウェアのすべての直接的および推移的依存関係を持つこと）。セキュリティ原則は頑固で、時には矛盾することもあります。「早期にパッチを適用し、頻繁にパッチを適用する」と 「アップグレードは軽視すべきではない」パッケージマネージャーによっては、サーバー範囲を指定して自動更新を行うことが推奨されています。悪意のある更新も受け取りたい場合は、これは素晴らしい方法です。確かに、脆弱性をできるだけ早く解消するセキュリティ修正プログラムを受け取るためには、コンポーネントを更新する必要がありますが、パッケージマネージャーにこれを自動的に行わせてはいけません。
誤解その4：信頼できるコンポーネントを使用すれば安全である。悪意のあるバージョンは速やかに発見され、開示され、削除される。
コンポーネントが信頼される理由は？おそらく、非常に人気が高く、多くの人が脆弱性を探し、メンテナンスに貢献する人が多数おり、すべてのコードを熱心にレビューするコアメンテナーが複数いるからでしょう。 pull requests現実は全く異なります。重要なコンポーネントのいくつかは、無償の開発者1人によって維持されています。広く使用されているフレームワークは 定期的に寄稿してくれる数名急速に減少している commitメンテナー1人あたりs（人気のあるプロジェクトには、ドライブバイを行う貢献者が多数いる） commit そして二度と戻ってこない）。また、メンテナーが1人しかいない人気プロジェクトは数多く存在する。
自分がこう言っているところを想像してみてください 「ああ、私たちはSpring Boot、Angular、React、PyTorch、そして公式のベースDockerイメージを使用しているので、あなたが言っているようなリスクはかなり低いですよ。」 おそらくそれは本当でしょう。私たちセキュリティベンダーは常に恐怖を煽り、議論の余地のあるリスクを軽減するために開発チームに干渉するのはナンセンスです。次のセクションのリスク受容の段落に飛んで、それで終わりにしたくなるかもしれません。残念ながら、最も人気のあるコンポーネントは悪意のある攻撃者の標的になり、たとえば、人気のある PyTorchライブラリが攻撃を受けた 過去インチ
「速やかに発見、開示、および除去された」。 新たな悪意のあるコンポーネントが公開レジストリから削除されるまでには数日かかります。レジストリは、コンポーネントのバージョンを削除することに慎重です。これは、セキュリティ上の理由によるものです。弊社の経験では、弊社側から報告されてからレジストリが該当バージョンを削除するまでの平均時間は39時間、つまり1日半以上かかります。中には、弊社が最初に報告してから1週間経ってからようやく削除される悪意のあるコンポーネントもあります。また、場合によっては、被害者やインシデント対応会社がそのコンポーネントに関連するインシデントを報告した後に初めてコンポーネントが削除されることもあります。
悪意のあるコンポーネントに対して効果がないものは何か
漠然としたアプローチでは必ず失敗に終わるでしょう。これは確実です。この脅威に伴うリスクに対して、効果的な対策を講じていないのですから。
クラシックハット SCA これらのツールは既知のマルウェアについて教えてくれますが、リスクにさらされる期間が長くなります。悪意のあるコンポーネントを強制的にブロックするなど、マルウェア検出を積極的に実行しない限り、この脅威に対しては効果がありません。
インストールスクリプトを無効にすることは有効な手段となり得るが、コンポーネントのインストールが必要なすべての箇所で強制的に適用する必要がある。バージョン固定についても同様で、安全な初期状態からバージョンを永久に固定することはできない。
人気のある部品は十分な注目を集めているため、サプライチェーン攻撃で意図しない動作を注入されても、ほぼ瞬時に検知されて被害を防ぐことができると考えるのは、ナイーブで危険です。そんな危険な状況は避けたいですよね？
ここで止めると、 リスク受容 できるのはこれだけです: これはcis脅威モデル/リスク評価に文書化する必要のあるイオン。リスクを受け入れる根拠と潜在的な影響を含めて記述します。経営陣やその他の関係者に伝えることで意識を高めます。 不測の事態 悪意のあるコンポーネントがソフトウェアにインストールまたは組み込まれた際に計画することは可能ですが、攻撃者がたどる経路が多数あるため困難です。悪意のあるコンポーネントの使用に基づくサプライチェーン攻撃の詳細は、組織の規制枠組みの下でおそらく義務付けられているインシデントの公開方法を大きく変えるでしょう。また、以下の点にも対処する必要があります。 補償制御 or 移転リスク 例えば、保険の場合。
しかし、リスク許容度に満足できない場合は、脅威に対処するための対策を検討すべきです。続きをお読みください。
悪意のあるコンポーネントを使用した攻撃に対しては何が効果的なのか
ソリッドバージョン処理
脆弱性を排除しつつマルウェアに感染しないためには、制御された情報に基づいたバージョンアップによるバージョン固定が最善の方法です。しかし、誤解その3に注意してください。バージョン固定だけでは、新しいバージョンから悪意のあるコードが侵入するのを防ぐには不十分です。なぜなら、将来的に直接的または間接的に依存するバージョンを更新する必要が生じるからです。その際、変更されたすべてのバージョンにマルウェアが含まれていないという十分な証拠が必要になります。
早期警告
悪意のあるコンポーネントの問題に対するアプローチの 1 つは、早期警告システム (ここでは次のように呼ばれる) です。 マルウェア早期警告 またはMEW）では、新規または既存のコンポーネントの新しいバージョンが公開されると、検出エンジンによって分析され、十分な証拠が見つかった場合、新しいバージョンが潜在的に悪意のあるものとして分類される可能性があります。
現在の公開ペースではすべての新規コンポーネントを手動でレビューすることは不可能であるため、自動化が不可欠です。そのため、検出エンジンは、静的分析、動的分析、機能分析、ユーザーの評判、コンポーネントのメタデータとtarballの内容、またはtarballとコンポーネントの出所とされるソースリポジトリとの間の不一致から得られる証拠など、さまざまな手法を組み合わせる必要があります。
あり ダークゾーン 公開時刻からエンジンがコンポーネントの内容を分析するまでの時間ですが、数分を超えないようにしてください。この仕組みは変更可能で、例えば、新しいコンポーネントが分析されるまで待ってから、ソフトウェアビルドにインストールして使用できるようにするなどです。 pipeline必要に応じて、またはオンデマンドで分析します。特定のバージョンのコンポーネントは不変です。 【3]そのため、分析は一度だけで済みます。
完全な自動化は不可能であり、潜在的に悪意のあるコンポーネントに関するセキュリティレビューが必要である。 デジタル万能薬の提唱者には注意せよAIと機械学習は、疑わしいコンポーネントにマルウェアが含まれているかどうかを最終的に判断できるほど十分に発達していません。確かに、機械学習は検出エンジンにおいて、取得した生データから入力コンポーネントを分類する上で重要な役割を果たしますが、コンポーネントが「隔離」された後は、悪意のあるコンポーネントに関する経験を持つセキュリティチームによる手動レビューが最終的な判断を下します。これにより、潜在的なマルウェアの有無が確認されるか、安全であると再分類されます。そして、この作業には数時間かかります。
レジストリは悪意のあるバージョン/コンポーネントを報告し、その後、レジストリはレビューを実行して確認し、公開してレジストリから削除します。一部のレジストリはセキュリティ保持パッケージを保持しています。ここでの時間範囲は、公開からの日数または週数です。滞留時間'または'露出ウィンドウほとんどの悪意のあるコンポーネントに対して。
コンポーネントのバージョンが悪意のあるものかどうかを知ることは可能ですか？
早期警戒のためには、次の質問に満足のいく回答を与える必要があります。ライブラリやパッケージが悪意のあるものかどうかをどのように判断すればよいのでしょうか？悪意のある動作の十分な証拠をどのように収集すればよいのでしょうか？攻撃者は検出を回避するために多くの工夫を凝らすため、可能ではありますが困難です。さまざまなアプローチがあり、それぞれに長所と短所があります。
静的解析 すべての実行パスを調べて、コンポーネントを実行せずに攻撃者が使用する手法をチェックし、難読化解除や解読などの前処理タスクを実行できます。攻撃者は悪事を隠そうとするため、難読化の試みは確かにマルウェアの証拠となります（ただし、正当なコンポーネントは知的財産を保護するためにコードを難読化するため、「オープンソース」。高度な難読化を伴う高度な攻撃のごく一部のみがサンドボックス化を必要としますが、そのような高度な難読化は悪意の明らかな兆候です。従来の SAST これらのツールは、意図しない脆弱性に対応するために設計されたものであり、バックドアのような悪意のある目的のために設計されたものではありません。
動的解析 コンポーネントを実行し、ランタイムを計測することで応答を調べます。通常はサンドボックス環境を提供することで計測します。特定の条件下でトリガーされる悪意のある動作は検出されない可能性があります。マルウェアは次のような回避技術を使用する可能性があることに注意してください。 仮想化/サンドボックス回避 監視されていない時のみ作動し、また、あらゆる静的解析エンジンにとって悪意のある活動の明らかな兆候でもある。
能力分析 コンポーネントの動作、つまり接続先、アクセスするファイル、実行されるコマンドやプログラム、実行される端末またはデバイスのI/O、呼び出されるシステムコールなどを考慮します。この動作のフィンガープリンティングは、（既存のコンポーネントについて）バージョン間で比較できるため、予期しない動作が検出された場合、その証拠は新しいバージョンに悪意のある活動が注入された可能性を疑わせることになります。このアプローチは、セキュリティアナリストが潜在的なマルウェアに直面した際に従うトリアージ手順、つまり検査と ストリング または同様のツール。この手法は、トリガー条件に関係なく悪意のある動作を検出し、ソースコードが入手できない場合でも機能します。
コンテキスト分析 コンポーネントがどのように公開されたか、誰によって公開されたかに関する情報を収集します。悪意のある攻撃者は、厳格な審査プロセスを受けていない新しいユーザーアカウントを使用することがよくあります。過去の活動を追跡することで、潜在的な侵害を示唆する可能性のある異常など、基となるユーザーに関する洞察が得られる場合があります。評判は得るのが非常に難しく、失うのは非常に簡単です。過去の活動がないユーザーは中立ですが、悪意のある者には必ず報いがあります。ハクティビスト、または公開資格を盗まれた一般ユーザーは、注意深く追跡する必要があります。
もう一つのコンテキスト情報は、コンポーネントのtarballを作成するために使用されたとされるソースリポジトリとtarball自体の内容との間の不一致です。また、公開レジストリで公開されているコンポーネントのバージョンと一致するタグやリリースをソースリポジトリに作成するなど、ベストプラクティスに従うことも重要です。特定のソースリポジトリの場合 commit リリースがタグ付けされているのに、突然あるバージョンがそれに従わなくなった場合、それだけでコンポーネントが汚染されている可能性が高いという強力な証拠になります。悪意のある攻撃者がコンポーネントの公開に使用されたアカウントを侵害した可能性がありますが、ソースコードリポジトリへの書き込み権限はありません。多くの攻撃は、これらのルールを使用して日常的に検出されます。たとえば、 台帳攻撃 こうした観点から容易に検出できる。したがって、コンテキスト分析は、出版プロセスにおけるこうした異常を特定するのに役立つ。
依存関係ファイアウォール
別のアプローチとしては、ソフトウェアで使用されるすべての依存関係グラフのコンポーネントの包括的なホワイトリストを用意し、ビルド時に pipeline 組織内で実行する場合、承認されたコンポーネント バージョンのみをインストールして使用できます。ファイアウォール」は、許可されたコンポーネントバージョンのtarballが配信（キャッシュまたはプロキシ経由）される内部レジストリを使用して適用されます。新しいバージョンを合理的に安全と分類してホワイトリストに追加できる技術がない限り、ホワイトリストは機能しないことにご注意ください。
早期警告（新バージョン公開後できるだけ早く迅速に検出すること）は、その情報を積極的に利用してビルドに影響を与えるコンポーネントをブロックする方法と組み合わせる必要があることにご注意ください。 pipeline開発者のマシン 【4]私たちはこれを「依存関係ファイアウォール: 自動ビルドを悪意のあるパッケージから保護するための隔離メカニズム。内部パッケージやイメージレジストリは、組織を外部の悪意から隔離するのに役立ちますが、隔離を効果的に行うには十分な証拠が必要です。
ランタイムサンドボックス
公開時の検出における代替アプローチとして、実行時の動作分析が挙げられます。これは、ソフトウェアの想定される動作を捉え、検出された異常を検出（またはブロック）するという考え方です。このアプローチには、監視やブロックのために実行時を計測する必要があるという課題がありますが、悪意のあるコンポーネントの侵入を防ぐための防御メカニズムとして有望なアイデアです。
包括的な戦略の策定
推奨される戦略では、ソフトウェア開発プロセスにおいて様々な手法を組み合わせ、バージョン更新を制御して悪意のあるコンポーネントの侵入を阻止する必要があります。重要な脆弱性に対する修正プログラムを入手するためにバージョンを更新する際、自動的に感染しないようにバージョン固定に対応しなければなりません。また、バージョン更新中に直接的および間接的な依存関係を迅速かつ効率的に評価し、マルウェアに感染していないことを十分に証明する必要があります。既知の悪意のあるコンポーネントに依存するソフトウェアのビルドはブロックしなければなりません。そして、これらすべてを徹底的に実施する必要があります。
可能な限りバージョン固定を使用してください。そうすることでビルドの再現性が向上します。 管理された手動承認によるバージョンアップによるバージョン固定, ヘルパー技術による支援アップデートによってマルウェアが持ち込まれたり、ソフトウェアが破損したりしないかを評価し、脆弱性を修正するためのアップデートとマルウェア感染の回避を両立させる必要があります。ツールは、(1) 実際に重要な脆弱性 (到達可能で悪用可能であり、攻撃者に狙われるリスクが高いもの) の優先順位付け、(2) 現在のコンポーネントの使用状況と互換性があり、ソフトウェアを破損させないターゲット バージョンの選択、(3) 悪意のある動作を含まないターゲット バージョンの選択、(4) マニフェスト ファイルの変更を提案し、迅速に承認できるようにすることで、直接的および間接的な依存関係のバージョン更新を容易にします。ステップ (3) では、悪意のあるコンポーネントに関する具体的な情報を、できるだけ公開直後に入手する必要があります。
依存関係を更新するこのプロセスは 施行された (NAIST) と 認証済 あらゆる場所で。プロセスは文書化されなければならず、開発とソフトウェアの構築/展開は外部委託されることが多いため、関係者全員がトレーニングを受ける必要があります。 CI/CD pipelines はそれに応じて修正されるべきであり、自動化によって悪意のある間接的な依存関係がビルドに紛れ込むことがないようにする必要があります。 guardrails 依存関係に潜在的なマルウェアが存在する十分な証拠がある場合は、ビルドをブロックすることが推奨される方法です。
組織内に、許可されたコンポーネントのバージョンを保持するためのセキュリティプロキシとして機能する内部レジストリがある場合、要求されたコンポーネントを許可リストに追加する前に、（他の基準に加えて）悪意のあるコンポーネントに関する情報を入手して、そのコンポーネントを審査する必要があります。
オープンソースソフトウェアを安全に利用することは容易ではなく、マルウェア対策を十分に考慮するとともに、脆弱性対策にも同様の努力を払う必要がある。
最後の注意点： 情報源の出所コンポーネントのビルド時に生成されるソフトウェア証明書の形式は、成果物（コンポーネントのtarball）を、それを生成したソースとビルドプロセスと追跡する取り組みにおけるもう1つの重要な要素です。ソースのスナップショットとビルド環境、および関連するソフトウェア成果物（信頼できるビルドシステムによって署名されたもの）との間のこのリンクは、コンポーネントに悪意のある動作が含まれていないことをそれ自体で防ぐものではありませんが、悪意のある者がマルウェアを注入することをより困難にします。また、オープンソースコンポーネントを利用する際の一般的な要件として出所検証を行うには長い時間がかかり、 最近NPMに追加されました信頼できるビルドおよびデプロイシステムを改ざん防止仕様にしたり、ビルドにおけるあらゆる改ざんを検出できるようにしたりすることは、また別の話であり、この記事の範囲外です。
参考文献
次のエピソード オープンソースの悪意のあるパッケージ：Xygeniのアプローチ Xygeniが採用している戦略をご紹介します。 マルウェア早期警告 （MEW）システム。公開パッケージおよびイメージレジストリの新しいパッケージバージョンをスキャンし、静的解析、動的解析、機能解析、コンテキスト解析を組み合わせて証拠を取得します。この証拠は、ユーザーの評判やソースコードリポジトリの変更履歴と組み合わせることで、コンポーネントを高リスクまたは悪意のある可能性のあるカテゴリに完全に自動的に分類します。システムは、パッケージから収集された過去の証拠から学習し、誤検出を最小限に抑えます。
登録済みの組織は、悪意のあるバージョンが分類された場合、直接的または間接的に使用しているコンポーネントに関する警告通知を受け取ります。その後、当社のアナリストが手動分析を行い、分類を承認または却下します。マルウェアが確認された場合は、公開レジストリに通知され、レジストリが独自の分析を実行し、通常は悪意のあるバージョンを削除するか、該当するユーザーアカウントのブロックや削除などの追加措置を講じます。
本稿では、NPM、PyPI、GitHubをはじめとするオープンソースエコシステムの主要なインフラストラクチャが、新たに公開された悪意のあるコンポーネントがマルウェアと確認されレジストリから削除されるまでの滞留時間を短縮できるよう、当社がどのように支援しているかを説明します。また、組織がMEWシステムを活用することで、オープンソースコンポーネントが関与するソフトウェアサプライチェーン攻撃に対する保護を大幅に強化できる方法についても解説します。
- 【1] いずれにせよ、コンポーネントのユーザーは、コンポーネントのtarballがどこか（例えば内部レジストリなど）にキャッシュまたは登録されているかどうかを確認する必要があり、そうすることでこの問題は解消されます。
- 【2] パッケージ化されたコンポーネントには、パッケージング形式に従って、通常は圧縮された形式で、その内容とメタデータを宣言するマニフェスト、ソースコードまたはコンパイル済みコード、インストールスクリプト、およびテストスイートなどの追加項目が含まれます。これは「コンポーネントtarball」と呼ばれます。
- 【3] たとえ悪意のある攻撃者がレジストリ自体の侵害によって公開済みのコンポーネントを改変できたとしても、解析後には、ごく一般的な暗号化ダイジェストによってtarball内の変更を検出できる。
- 【4] 悪意のあるコンポーネントの中にはインストール時に実行されるものもあるため、悪意のあるコンポーネントXを含む「npm install X」を意図せず実行した開発者ノードに影響を与える可能性があることに注意してください。
