セキュリティはもはやあなたの問題だけではありません — それはボードの問題です。アプリの97％がオープンソースを使用している中で、CSO は誤検知を排除し、SBOM について真摯に取り組む必要があります。
長年の間、サプライチェーンセキュリティは純粋に技術的な懸念事項と見なされていました。しかし、高いプロフィールの脆弱性と規制により、組織がレジリエンスを構築し、オペレーションを保護する方法を再考する必要があるボードレベルの問題になりました。
規制環境の変化は、C スイートの焦点を促進する重要なドライバーとなっており、欧州サイバーレジリエンス法（CRA）などの法律には、不遵守に対して世界売上高の最大2.5％の罰金が含まれています。さらに、オープンソースソフトウェアの拡大と複雑なグローバルサプライチェーンが相まって、CSO がサプライチェーンセキュリティにどのようにアプローチする必要があるかを変えるための完璧な嵐を生み出しています。
オープンソースソフトウェアの普及は、セキュリティの状況を根本的に変えてしまいました。Synopsys の 2025 年オープンソースセキュリティおよびリスク分析レポートによると、商用アプリケーションの97％がオープンソースソフトウェアを含んでおり、 86％が脆弱性を含み、 81％が高リスクまたは重大リスクに分類されています。5年前、このような統計は企業の役員会には無関係でしたが、今ではそれらが命令の背後にあるデータです。
2021 年の Log4Shell 脆弱性は問題を浮き彫りにしました。オープンソースの Apache Log4j 2 Java ライブラリの重大な欠陥により、攻撃者はリモートでコードを実行でき、サーバを含む数百万のアプリケーション、クラウドサービス、物理エンドポイントに影響を与えました。ハッカーはこの脆弱性を悪用して、データを盗んだり、ランサムウェアをインストールしたり、驚くべき速度でボットネットのためにデバイスをキャプチャしたりしました。これにより、オープンソースは安全であるという仮定が払拭され、状況はソフトウェアエコシステムの相互接続性と、単一の脆弱性の悪用がどれほど速く広がるかを強調しました。Log4Shell が発生したときに任意の製品に責任を持っていた私のような者は、私の痛みを感じることができます。それは事前の警告なしで Y2K に非常に似ていました。そして、他の誰が彼らが企業のウェブサイトをシャットダウンする必要があるかどうか突然疑問に思いましたか？
サプライチェーンセキュリティが C スイートの優先事項になった理由
立法上の変更により、セキュリティは技術的な問題からビジネス上の問題に昇格しました。CRA はソフトウェアセキュリティを製品安全の懸念事項と見なし、罰則はこの現実を反映しています。EO14028を含む連邦法では、機関が完全なソフトウェアおよびハードウェアインベントリを維持し、保証ポリシーを開発することが求められています。同様の規制は、インドや韓国を含む国で進行中または最終化されています。業界の規制焦点の一例は、FDA が医療機器にソフトウェア部品表（SBOM）を持つことを要求しており、ソフトウェアセキュリティが患者の安全に直接影響することを認識しています。FDA SBOM 要件の前に、FDA 認可の心臓モニターで脆弱性が発見されました。SBOM が提供され、脆弱性データベースと相互参照されていた場合、このデバイスは修復なしに市場に進出することはありませんでした。
CSO にとっての課題は、サプライチェーンセキュリティを管理することは従来のセキュリティとは根本的に異なることです。サプライヤーのコードがブリーチを引き起こした場合、補償条項は彼らが罰金を支払うことを意味するかもしれませんが、あなたは顧客への通知、評判へのダメージ、および対応の運用上の負担に責任を持ち続けます。契約に署名する前にサプライチェーンセキュリティ体勢についての詳細な質問を今求めているすべての顧客にわたってこれらのリスクを管理する必要があります。
SBOM はもはやソフトウェアライセンスの追跡のためだけに使用されていません。それらはエコシステム全体の脆弱性の特定と追跡を可能にするため、サプライチェーンセキュリティを管理するための鍵です。
問題を見つけることは始まりに過ぎません — その脆弱性があなたの実装に影響を与えるかどうかを判断する必要があります。たとえば、SSL ライブラリに 100 個の関数が含まれており、アプリケーションがそのうち 60 個を使用し、欠陥が未使用の 40 個の 1 つにある場合、リスクはありません。ただし、従来のスキャンツールはそれを重大として フラグを立てる可能性があり、チームは無関係の問題を調査するのに時間を浪費します。これを視点に入れるために、Cornell は、コード脆弱性ツールが97.5％の誤検知率を持つことを発見しました。サイバーセキュリティに時間を費やした誰もが、ファイアウォールアラートや EDR またはライブラリ脆弱性の相関を見ているかどうかにかかわらず、誤検知が私たちの存在の悩みであることを知っています。リスクがない場合でも、あなたが脆弱ではないことを検証したことを顧客が認識するように、その情報を公開する必要があることに注意することが重要です。
これは、開発者が誤検知のため週に 3.5 時間セキュリティスキャンの結果を手動で確認するため、かなりのリソースを使用します。これは新しい機能を遅延させ、市場投入を遅くします。セキュリティチームは信頼性を失い、開発者はアラートに無感覚になり、ノイズとしてアラートを却下し、実際の脅威が失われる可能性があります。アラート疲労は実在するものです。
関係する複雑さと異なる開発環境のため、サプライチェーンセキュリティ体勢を強化するための万能な解決策はありません。ソースコード分析は、コードとビルドプロセスにアクセスできるときはうまく機能しますが、サードパーティのバイナリまたはレガシーファームウェアをレビューできず、最終的なバイナリにコンパイルされるコードブランチを特定できないことがあります。ビルド時分析はコンパイル中に問題を特定しますが、後で追加されたコンポーネントでは機能しないことが多く、動的にリンクされたライブラリでしばしば躓きます。バイナリおよびファームウェア分析はこれらのギャップに対処しますが、コンパイルされたコードをリバースエンジニアリングするために洗練されたツールが必要です。
適切なソリューションはあなたの特定の環境に依存し、構築する製品のタイプ、開発パイプラインの動作方法、ソースコードまたはサードパーティコンポーネントをより使用しているかどうかを考慮する必要があります。万能なソリューションはありません。企業は、状況に適した適切なオプションを見つけるために、さまざまなツールを評価する必要があります。ワークフロー統合、サプライチェーンの複雑さ、リッチ OS とベアメタルのような展開プラットフォームはすべてツール適用性に影響を与えます。
少なくとも 3 つのソリューションでベークオフを実施することは、適切なオプションを見つけるために重要です。ベンダーのサンプルに頼るのではなく、コードに対して検証するために、精度をテストすることが不可欠です。目標は、各潜在的なオプションが環境でどのように実行されるかを理解することです。考慮する 1 つの側面は、ソフトウェアまたはファームウェアが実行される場所です — Windows、Linux、Android、または別のリッチ OS 上ですか？それともしばしば宇宙制約または産業環境で見られるベアメタルですか？後者では利用可能なファームウェア分析ツールは多くないため、これらの環境は、バイナリ分析ソリューションがリッチ OS ファームウェアでしばしばより良いにもかかわらず、ソース型またはビルドベースのツールに傾くかもしれません。
レビューするとき、脆弱性の特定の精度と誤検知率に焦点を当てます。ツールはすべての脆弱性をキャッチするかもしれませんが、多くのファントム問題にフラグを立てた場合、チームはワイルドグースチェイスに無数の時間を浪費します。逆に、重大な脆弱性を特定できない場合、組織は曝露されたままです。
さらに、製品は、Jira などの既存のチケット発行システムと統合する必要があります。自動化は、関係する複雑さとリスクを考慮すると、手動ダッシュボードチェックは実行可能ではないため、交渉の余地がありません。タスクは優先順位が付けられるべきであり、開発者は情報を探す必要がありません。脆弱性が見つかった場合、開発者の既存ワークフローで自動的にチケットを作成して、危険にさらされているもの、どこで使用されているか、実装で悪用可能かどうか、必要なアクションを概説する必要があります。目標は、サプライチェーン脆弱性への対応を、他のバグを修正するのと同じくらいシームレスにすることです。開発者が異なるツール間を切り替えたり、情報を手動で相関させたりする必要がある場合、応答時間は遅くなり、リスクが増加します。
サプライチェーン通信機能は、リスクを軽減し、規制要件を満たすための別の重要なコンポーネントです。ソリューションは、アップストリームサプライヤーからの自動更新を受け取り、ダウンストリーム顧客に迅速に通知することができなければなりません。アラートに加えて、通信には必要な軽減ステップを含める必要があります。ライブラリがパッチ適用されているか、脆弱性が到達不可能または悪用不可能であると判定されていることを迅速に確認する必要があります。
ドキュメントは別の重要な評価基準です。契約上および規制上の義務は、リアルタイムの情報共有を必要とします。ゼロデイ攻撃が発生した場合、文書化されたベストプラクティスは罰金から保護されます。顧客は、数日または数週間ではなく、彼らが自分たちを保護する必要がある必要な軽減ステップと共にすぐに知らされるべきです。脆弱性が発見された暗号化ライブラリを含む製品を出荷する試練を生き残ったために、顧客の問い合わせはあなたがそれらに答えることができるより速く来て、分単位で更に厳しくなることを約束できます。サプライチェーンセキュリティインフラストラクチャは、どの顧客が影響を受けているか、および彼らが自分たちを保護するために何をする必要があるかを特定することができなければなりません。
欠陥に対処するために取られたステップを示す徹底的な監査証跡は、懲罰的な罰金を回避するのに役立つかもしれません。CRA は、ソフトウェアを最新に保ち、展開ガイドラインに従い、ツールを評価し、環境に適した方法を選択し、迅速に対応したことを証明できるときはより許容します。目標は、責任あるソフトウェアセキュリティの管理を実証することです。最も厳しい規制当局でさえ、常にソフトウェアバグがあることを知っています。
前進への道
サプライチェーンセキュリティはさらに激化するだけです。FDA は 18 か月前に SBOM が何であるかを定義できませんでした。今それは医療機器承認の必須です。ソフトウェアサプライチェーンが製品セキュリティと安全性に重要であると認識されるにつれ、同様の規制が業界や管轄区域全体で出現しています。
CSO はこれをセキュリティのチェックボックスではなく、利益に影響を与える戦略的優先事項として扱う必要があります。リスクを認識し、それに応じて行動する経営幹部は、単なるコンプライアンスのためだけでなく、ますますセキュリティを意識した市場での競争上の優位性のために組織を位置付けます。遅延する者は、危機を管理し、規制罰金に直面し、顧客の信頼を失うことに気付くでしょう。問題はもはやサプライチェーンセキュリティを優先するかどうかではなく、それを上手く行うための機能をどれだけ速く構築できるかです。
