ソフトウェア部品表（SBOM）とは？

サイバーセキュリティにおけるSBOM の役割

SBOMにソフトウェア依存関係の完全なリストを用意すれば、それらに存在する既知の脆弱性を記録し、DevSecOps のベストプラクティスに従ってそれらがパッチ適用されているか、またはそれらを標的とする攻撃に対してアプリケーションやインフラが強化されていることを確認できます。

SBOMを導入するメリット

SBOM は、その利点からソフトウェア開発における標準的な実践となっています。利点には以下が含まれます：

• セキュリティの透明性：各ソフトウェアプロジェクトの SBOM は、サイバー攻撃にさらされる領域の可視性を提供し、セキュリティリスクを評価し、脆弱性にパッチを適用したり緩和したりすることを可能にします。
• ソフトウェアライセンスのコンプライアンス：オープンソースソフトウェアライセンスには、コードの共有を含め、自身のプロジェクトで満たさなければならない要件がある場合がよくあります。SBOM には各コンポーネントのオープンソースまたはプロプライエタリライセンスを含める必要があり、ライセンス要件を満たすか、必要に応じて代替手段を見つけることができます。
• 規制遵守：ユーザープライバシーに関する規制フレームワークでは、機密データを保護するために可能な限りの措置を講じることが求められています。これには、ソフトウェアやインフラを潜在的な攻撃経路について評価し、発見されたリスクを軽減することが含まれます。

SBOMの標準化されたフォーマット

SBOM には 3 つの一般的な標準化フォーマットがあります：

• Software Package Data Exchange (SPDX)：Linux Foundation によって開発されたフォーマットで、パッケージのメタデータ、ライセンス、依存関係を記録するために使用されます。
• CycloneDX：OWASP Foundation によってサイバーセキュリティの目的で使用されるフォーマットです。
• Software Identification Tags (SWID)：ソフトウェアを一意にタグ付けし、管理およびコンプライアンス目的で利用する ISO フォーマットです。

SBOM導入における課題

SBOM は有益であると広く認識されていますが、ソフトウェア開発ライフサイクル（SDLC）に実装する際にはいくつかの課題が生じる可能性があります：

• 既存の開発ツールと統合できる、自動化された SBOM および脆弱性管理ソリューションを見つけることが理想です。
• 開発者やステークホルダーが新しいツールやプロセスに慣れるまで、実装段階で組織内に摩擦が生じる可能性があります。
• SBOM を他の関係者と共有する場合、特に運用上の理由や知的財産（IP）に関する懸念から保護したい社内コードなど、専有コンポーネントや機密コンポーネントをどのように記録するかを決定する必要があります。
• 元のソースコードやドキュメントを持たないレガシーソフトウェアを記録するのは難しい場合があります。
• 特に SBOM を初めて作成する段階では、多数の依存関係を一度にレビューしなければならないため、深くネストされた依存関係ツリーを記録する作業は、自動化がなければ時間がかかり複雑になる可能性があります。

SBOMの維持における課題

どの脆弱性管理ツールを採用し、どのように実装するかを決定した後でも、SDLC 全体で SBOM を作成・維持する際には継続的な課題があります：

• プロジェクトの規模や数が増えるにつれて、SBOM の複雑さと、それを維持するために必要なリソースも増加します。
• SBOM は最新の状態に保ち、注視してはじめて機能します。既存の依存関係と新しい依存関係の両方について、SBOM をレビューし新しい脆弱性を確認する必要があります。
• プライバシーとデータセキュリティに関する規制は、SBOM を作成・維持するために実装しているツールや標準、そしてそこに記録されるデータについて、定期的にレビューすることを求めています。

SBOMはどのように作成されるのか？

SBOM は、ソースコード、サポートソフトウェア（ホスト OS やランタイム環境など）、外部依存関係（API を含む）を調べ上げ、それらすべてを記録することで手動で作成できます。しかし、各項目について記録すべき情報は膨大であり、手間のかかる作業です。さらに、依存関係が別の依存関係を持つことも多く、複雑さが増します。

アプリケーションのソースコード（またはデプロイ前の Docker イメージ）をスキャンして SBOM の作成を自動化できるツールには、Snyk、CycloneDX、Syft、OWASP Dependency-Check などがあります。

SBOM を作成し脆弱性をスキャンすることは、クラウドセキュリティの一部にすぎません。Sysdig Secureを用いた脆弱性管理は、クラウドネイティブアプリケーションを脆弱性についてスキャンするだけでなく、本番環境においてランタイム保護を提供し、まだ発見されていないサプライチェーンの脅威やハッキングの試みを稼働中のアプリケーションで検出できるようにします。

サプライチェーンを保護することの重要性

現代のソフトウェア開発は、開発を迅速化し、専門家が開発したベストプラクティスや実績あるソリューションを実装するために、オープンソースやサードパーティのライブラリ、その他のソフトウェアコンポーネントを活用することに依存しています。たとえば、独自に認証ソリューションを書くよりも、サードパーティの認証ソリューションを統合する方が効率的であり、かつ安全です。

サプライチェーン攻撃の脅威はこれらの利点を上回るものではありませんが、依然として現実的な脅威となっています。Python 開発者が PyPi パッケージリポジトリにおけるタイポスクワッティング攻撃で、自分のプロジェクトに悪意のあるコードをインストールさせられたり、JavaScript アプリケーションが、週 200 万回以上ダウンロードされていた人気の event-stream ライブラリにおいて、新しい開発者がライブラリに悪意のある依存関係を追加したことで侵害されたりした事例があります。

クラウドネイティブアプリケーションとSBOM

クラウドネイティブアプリケーションは、常時オンラインである性質や水平スケーリングの可視性の低さから、サプライチェーン攻撃に特に脆弱です。サプライチェーン攻撃とランタイム侵入の両方の脅威を認識できるクラウドネイティブアプリケーション保護プラットフォーム（CNAPP）は、クラウドやハイブリッドクラウド環境で実行されるアプリケーションを保護するための鍵となります。

Docker のような技術を利用するコンテナ化アプリケーションに対して SBOM を作成・維持することも不可欠です。アプリケーションイメージは一度作成されると、その機能を果たしている限り放置されることが多く、依存関係に含まれた未特定の悪意あるコードを抱えたままになる可能性があります。自動化されたイメージスキャンと SBOM の作成は、Docker アプリケーションのコンポーネントのいずれかが安全でないとフラグ付けされた際に通知されるようにすることで、これを軽減します。

Sysdigの脆弱性管理は悪意のあるコードから保護します

Sysdig は、その CNAPP プラットフォームを通じて、クラウドネイティブアプリケーションにサプライチェーン保護を提供します。ランタイム保護、インシデント検出と対応、ポスチャ管理を統合したインターフェースに加えて、Sysdig は CI/CD パイプラインに統合され、デプロイするソフトウェアに既知の脆弱性や悪意のあるコードが含まれていないことを確実にするのに役立ちます。

クラウドネイティブセキュリティの現状についてさらに詳しく知るには、2024 Gartner Market Guide for Cloud Native Application Protection Platforms (CNAPP) をご覧ください。クラウドアプリケーションやワークロードを保護する場合は、無料のe-book 「クラウドの保護：効果的な脆弱性管理へのガイド」 をダウンロードしてください。

FAQs