このブログでは、ウェビナー「Supply Chain ：攻撃者が悪用する脆弱なリンク」の主なポイントを解説します。ウェビナーの全編はこちらからご覧ください。
Software チェーンリスクは、組織がオープンソースコンポーネント、外部パッケージ、自動化された開発パイプラインへの依存度を高めるにつれ、劇的に拡大してい。ます。かつては害のない小さな隙間も、依存関係が深まり検証が困難になるにつれ、今や現実的な影響をもたらすようになりました。
この変化を如実に示す事例が、最近のnpmShai-HuludワームおよびShai-Hulud 2.0である。これらは侵害されたパッケージを介して拡散し、わずか数時間で数千もの下流プロジェクトに影響を及ぼしました。このようなインシデントが明らかにするのは、サプライチェーンの脆弱性がもはや局所的な問題にとどまらず、エコシステム全体に波及するということです。
現代のソフトウェアの70～90％はオープンソースコンポーネントで構成されており、その大半は開発者が直接目にすることのないものです。そのため、小さな問題が急速に大きなリスクに発展する可能性があります。しかし、オープンソースリスクの管理方法に自信を持っている組織はわずか15％に過ぎません。2025年までに悪意のあるAI攻撃の70％がサプライチェーンを標的とすると予測される中、ソフトウェアサプライチェーンの脆弱な部分を特定することが今や不可欠となっています。
エンジニアリングおよびセキュリティチームにとっての利点は単純明快です：これらの脆弱性がどこにあるかを把握することで、予期せぬ事態が減り、対応時間が短縮され、次なるサプライチェーン関連のニュースの見出しに載る可能性が大幅に低減されるのです。
SBOMはもはや任意ではない
ソフトウェアのサプライチェーンリスクを管理し、脆弱性に対応するためには、組織は自社のソフトウェアスタックに何が含まれているかを明確に把握する必要があります。この可視性の基盤となるのがSBOM（ソフトウェア部品表）であり、コンポーネントのリスクを理解し、問題発生時に迅速に対応するために必要な透明性を実現します。
SBOM（ソフトウェア構成部品表）とは、アプリケーションで使用されるすべてのクローズドソースおよびオープンソースのコンポーネント、ライセンス、依存関係の詳細な目録として定義されます。この目録は、透明性、コンプライアンス、リスク管理に不可欠なデータを提供します。
今日脆弱性や悪意のないものも、明日には容易にそうなり得る。脆弱性は古いバージョンを含め継続的に発見されるため、継続的な監視とインベントリ管理が必要である。
ジョージ・プリチッチOPSWAT製品担当副社長
SBOM 対 SCA
重要な点の一つは、SBOM（Software ）とSCA（Software ）の区別です。SBOMは構成要素のインベントリ、つまり部品リストです。SCAはそれらの構成要素に脆弱性、陳腐化、リスクが存在するか否かを評価します。これらを組み合わせることで、組織は情報に基づいた意思決定を行い、セキュリティ問題に迅速に対応し、全体的なリスク管理を強化するために必要な洞察を得ることができます。
| カテゴリー | SBOM | SCA |
|---|---|---|
目的 | 部品在庫リスト |
コンポーネントの脆弱性を特定する
|
リスク対応 | コンプライアンスと可視性 | セキュリティリスク、CVE、実行時リスク |
タイミング | 事前配備／調達 | 継続的 / ビルドおよび実行時 |
SolarWindsのような攻撃に一部起因する世界的な動きにより、現在ではSBOMが必須となっています。CISA、NSA、NISTといった機関やEU、NATO加盟国からの規制推進により、SBOMの透明性はもはや任意の選択肢ではなく、あらゆるソフトウェアベンダーに対する基本的な要件となりました。
攻撃者が悪用する7つの重大な脆弱性
現代の開発スピードと、サードパーティ製およびオープンソースコードへの依存度の高さが相まって、深刻な脆弱性が生じています。脅威アクターは主に7つの弱点を悪用しています：
1. オープンソースと依存関係リスク
開発者がスピードを優先する場合、完全なコードレビューなしに大規模なオープンソースライブラリを使用することが多いです。単一のコンポーネントが追加の推移的依存関係を導入する可能性があります。トップレベルのみを監視すると、それらの隠れた推移的依存関係に注入された悪意のあるコードを見逃す恐れがあります。
このパターンはオープンソースエコシステム全体で継続的に見られる現象です。1つの侵害されたパッケージが依存関係チェーンを通じて連鎖的に拡散し、誰にも気付かれる前に数百万回のダウンロードに到達する可能性があります。暗号通貨マルウェアを伴う最近のnpmサプライチェーン攻撃は、これが実際にどのように発生するかを如実に示しています。
ベストプラクティス：
- すべてのオープンソースパッケージとその完全な依存関係チェーンをスキャンし、脆弱性、古いコンポーネント、または隠れたマルウェアがコードベースに到達する前に特定します。
- 依存関係を継続的に監視してください。安全なコンポーネントも、新たなCVEや悪意のある更新プログラムが出現すると危険になる可能性があるためです。
- 信頼できるレジストリを使用し、パッケージの完全性を検証して、ダウンロードしたパッケージが改ざんされていないことを確認してください。
- リスクの高いライセンスをフラグ付けまたはブロックするポリシーを適用し、互換性のないライセンスやウイルス的なライセンス条項がビルドに混入しないようにします。
- 新たに公開されたパッケージの使用は、審査が完了するまで遅らせてください。これにより、未審査または悪意のあるリリースが環境に導入されるリスクを低減できます。
2. ライセンスリスク
ライセンス問題は今や法務と同様にエンジニアリングにも影響を及ぼします。GPLのようなウイルス的ライセンスは、結果として生まれたアプリケーションを同じライセンスで公開することを強制し、自社知的財産（IP）の喪失を招く可能性があります。ライセンス条項は、過去に準拠していた古いバージョンであっても変更される可能性があるため、継続的な監視が不可欠です。
ベストプラクティス：
- 開発の初期段階で、自動化されたライセンス検出ツールを使用して、リスクの高いライセンスや互換性のないライセンスを早期に特定します。これが重要な理由についての詳細な説明はこちらに記載されています：オープンソースセキュリティにおけるライセンス検出の重要な役割。
- ライセンス変更を継続的に追跡し、コンプライアンスや知的財産リスクに影響を与える可能性のある変更を捕捉します。
- 制限的またはウイルス的なライセンスを持つコンポーネントがコードベースに入る前に、ブロックまたはレビューします。
- 使用中の全ライセンスの明確な在庫管理を維持し、監査とリスク評価を簡素化します。
3. SBOMデータの不備またはSBOMの欠落
規制によりSBOMの共有が義務付けられているものの、高レベルのリストだけでは不十分です。効果的な軽減策と予防策のためには、作成者、貢献者、リリース頻度、保守状況を含む詳細なデータポイントが必要です。
ベストプラクティス：
- コンポーネントの再スキャンによりSBOMレポートを強化し、更新されたライセンスデータ、脆弱性ステータス、その他の重要なメタデータで内容を充実させます。具体的な実施方法の詳細は、CycloneDX SBOMレポート検証および充実化の手順で説明されています。
- 自動化されたツールを使用してSBOMを検証および充実させ、情報が完全かつ正確で実用的なものであることを保証します。
- ベンダーに対し、推移的依存関係および関連するすべてのメタデータを含む完全なSBOMの深さを提供するよう要求します。
- コンポーネントが進化したり新たな脆弱性が発見されたりする場合、SBOMインベントリを継続的に更新・監視します。
4. サードパーティベンダー
依存するすべてのベンダーはサプライチェーンの一部となります。彼らが古い、あるいは改ざんされたコンポーネントを出荷した場合、そのリスクは貴社に引き継がれます。推移的依存関係を含む完全なSBOM（ソフトウェア構成部品表）があれば、インシデント発生時にベンダーを追跡する代わりに、迅速にリスクを把握することが可能になります。最近の投稿「Supply Chain依存関係脆弱性の管理」では、チームがこのプロセスを強化する方法について考察しています。
5. AISupply Chain
AIの急速な普及に伴い、チームは通常の制限を迂回することが多く、これが主要な攻撃経路となっています。攻撃者は機械学習モデル、PICOファイル、またはオープンソースライブラリに悪意のあるコードを注入しています。Pytorchのような環境ではタイポスクワッティングが頻発し、ユーザーが誤ったライブラリを取得することでマルウェアが配信され、エンジニアのマシン上で完全なリモートコード実行に至る可能性があります。
6.Container
コンテナのスキャンは、脆弱性のみに焦点を当てる段階から進化しなければなりません。現代のセキュリティ対策では、マルウェア、暗号通貨マイナー、公開コンテナイメージに組み込まれた即効性のある脅威もスキャン対象とすべきです。NVIDIAContainer CVE-2024-0132に関する最近の分析は、こうした問題がいかに簡単に見落とされうるかを示しています。
7. 秘密情報と認証情報の漏洩
チームが迅速に動く場合、テスト用にアクセスキーや認証情報をソースコードにハードコードすることがよくあります。後で上書きされても、これらの機密情報はGit履歴に残り、攻撃者がスキャンで容易に見つけられる状態になります。『隠れた脅威を暴く：コード内の機密情報の検出方法』では、こうした情報漏洩がどのように発生するか、そしてチームがそれを防ぐためにできることを解説します。
Secure Software Supply Chain網への道
これらの脅威に対抗するには、セキュリティは「シフトレフト」の考え方を取り入れる必要があります。つまり、リリース前に適用されるのと同じポリシーを開発サイクルの早い段階で適用すべきなのです。目標は、既存のCI/CDパイプラインの上にセキュリティをオーバーレイとして統合することです。この自動化されたアプローチにより、エンジニアリングの生産性に影響を与えずに、必要なタイミングで確実にポリシーを適用できます。
包括的なソリューションは以下を提供しなければなりません：
- パイプライン全体にわたる自動化されたサプライチェーンスキャン
- ソースコード、コンテナ、ベンダー提供ファイルの可視性
- CVEを超えた分析により、マルウェア、ライセンス問題、漏洩した機密情報を検出します
OPSWAT これらのギャップをOPSWAT 方法
- パイプラインの早い段階でマルウェアを検出Multiscanning
- GitHub、GitLab、TeamCity、Jenkins などの統合 CI/CD セキュリティゲート
- 自動化されたSBOM生成と脆弱性マッピング
- アーティファクト署名と完全性検証
- 秘密情報のスキャンと認証情報の衛生管理の徹底
当社の専門家にご相談いただき、お客様のシステム構成に合わせたソリューションを今すぐ見つけましょう。
