ソフトウェアサプライチェーンに対する攻撃は増加する一方です。攻撃者は斬新かつ高度な手法でマルウェアを仕込んでおり、生成 AI などの新たなテクノロジーまで動員されています。そのうえ事態を複雑にしているのは、組織が開発し使用しているソフトウェアが、オープンソースやサードパーティのコンポーネントなど多様な構成要素が混ざり合って構成されていることです。

「Digital Trust in Software Supply Chains & AI Models（ソフトウェアサプライチェーンと AI モデルにおけるデジタルトラスト）&」と題してデジサートが最近開催したウェビナーでは、ソフトウェアサプライチェーン攻撃を防ぐ際の課題を取り上げました。デジサートの CEO である Amit Sinha が主催した同ウェビナーには、この分野で業界的に著名な 3 人の専門家が参加しました。

• Mario Vuksan 氏: ReversingLabs 社 CEO
• Saša Zdjelar 氏: Crosspoint Capital 社オペレーティングパートナー、Salesforce 元セキュリティ保証担当シニアバイスプレジデント
• Hugh Thompson 博士: Crosspoint Capital 社マネージングパートナー、RSA Conference プログラム委員長

以上 3 人の専門家が、組織の直面している課題のいくつかを明らかにしたうえで、組織がこれから採用すべきベストプラクティスを提示しました。

オープンソースソフトウェアのコードに関する課題

「Open Source Security and Risk Analysis Report（オープンソースのセキュリティとリスク分析に関するレポート）」によると、調査対象としてスキャンされたコードベースの 96% にオープンソースが含まれています。この状況は全体に対するリスクにつながります。オープンソースのコードは組織の管理下になく、攻撃者が悪用できる攻撃対象を拡大するからです。ソフトウェアサプライチェーンの問題は常に存在してきましたが、ソフトウェアの規模と複雑性がこのように拡大したため、攻撃が増大しています。ReversingLabs による 2023 年のレポートによると、昨年だけでも 90% の企業がソフトウェアサプライチェーンのリスクを検出しており、現在のアプリケーションセキュリティソリューションがこの種の攻撃に対して必要な防御を実現できていないという回答も 70% 以上に達しました。

Vuksan 氏は次のように説明しています。

「サードパーティ作成のコンポーネントが、検出の回避や横展開を目的に［攻撃者によって］使われることが増えており、大規模で重大な侵害では特にその傾向が強くなっています。ソフトウェアサプライチェーン攻撃は、オープンソースやサードパーティの侵害を通じて発生することもあり、SolarWinds 社への攻撃のように、ビルドシステムの悪用によって起こる可能性もあります。

生成 AI によってソフトウェアサプライチェーンへの脅威が増幅

ソフトウェア開発者にとっては、生成 AI が新たなセキュリティリスクとなっています。生成 AI は、マルウェアをさまざまな形態に変形させることができ、セキュリティの制御をすり抜けたり、内部で使用される AI モデルを改ざんしたりできるからです。攻撃者が AI を活用してサイバーセキュリティ攻撃を自動化することもできます。

Thompson 氏が、この問題についてさらに詳しく説明しています。

バックエンドで機械学習や AI によって自動化されたと考えられる、高速な攻撃の例がすでに確認されています。限りのある人間や企業ではとても太刀打ちできません。この分野で早急な対策に動いている人もいますが、現在広く使われている AI モデルにも多くの問題が潜んでいる可能性を忘れるべきではありません。たとえば、AI モデル自体にもマルウェアが含まれている可能性があるため、急いで先に進む前に慎重な評価が必要です。

ソフトウェアに対する信頼に必要なベストプラクティス

ウェビナーでは、業界を代表する 3 人が、ソフトウェアサプライチェーンを保護する際に組織が採用すべきベストプラクティスについて、次のようなインサイトを共有しました。

• 脅威を検出するディープスキャンを実行する
• 安全なコード署名を活用する
• ソフトウェア透明性を実現する

脅威を検出するディープスキャンを実行する

ウェビナーの中で Vuksan 氏は、ソフトウェアサプライチェーン攻撃と聞くと、SUNBURST 攻撃のような好評されている攻撃を思い浮かべる人が多いと指摘しました。SolarWinds 社の事件で広く知られており、たった 1 回の攻撃でもその一度だけで数万という企業に影響を与えかねないという事実を劇的な形で示した攻撃です。「将来的に大規模な攻撃に耐えられるように、レジリエンスをまったく新しい次元にまで高めることに多くの労力が費やされています」と Vuksan 氏は述べています。

それと同時に、SUNBURST だけでなく Codecov や Kaseya といった公表済みの攻撃に焦点が当たったことで、その可能性があるにもかかわらず自分たちはソフトウェアサプライチェーン攻撃を受けていないと誤解する組織も現れています。しかし、ソフトウェアサプライチェーン攻撃のリスクには、誰もがさらされているのです。

今日使われているほとんどのソフトウェアが複雑であることに関係している、と Thompson 氏は述べています。

「［ソフトウェアは］内部的に記述されたコードだけでなく、システムのコンパイル時に動的に取り込まれるサードパーティのライブラリやコンポーネントなどもともに構成されています。そのため、たとえ攻撃が明確に企業を標的としていない場合でも、攻撃者は多用されるライブラリを操作することができます。これは、私たちがたった今取り組んでいる最大の課題のひとつだと考えます」

このような攻撃を防ぐために、組織は脅威と脆弱性の検出に関して詳細な分析を施さなければなりません。コードのスキャンに加え、マルウェア、機密漏えい、ソフトウェア改ざん、その他の CVE（Common Vulnerabilities and Exposures）といった脅威および脆弱性パターンの検索も必要です。

安全なコード署名を活用する

ここ数年、コードサイニング鍵のセキュリティが適切に確保されていない場合に何が起こるか、その実例をいくつか見てきました。巧妙になった攻撃者は、サプライチェーンの中でセキュリティの一番の脆弱ポイントが暗号周辺に存在することを発見したと Thompson 氏は指摘しています。たとえば、ASUS のコード署名侵害は、開発者が安全でないウェブサーバーにコードサイニング鍵を保存しており、そのサーバーにハッカーが侵入してマルウェアに感染させたことが原因でした。そして、ダークウェブを簡単にスキャンしただけで、盗まれたコード署名の認証情報だけでなく、技術を持たない購入者が保護されていない鍵を悪用するときに使えるマルウェアキットも見つかります。

この問題に対処するため、CA/B フォーラムは現在（2023 年 6 月 1 日時点）、コードサイニング秘密鍵を FIPS 140-2 または Common Criteria Level EAL4+ 準拠のデバイスに保存することを義務づけています。しかし、Amit Sinha が指摘したように、組織にはロールベースの管理、誰がコードに署名しているか、どこで実行されているのかを示す監査ログなど、ポリシーベースの管理も必要です。さらに、強固な認証も欠かせません。「署名権限を求める組織は徹底的な調査な必要です」と Sinha は話しています。

Thompson 氏も同意します。

「コードサイニングのインフラストラクチャには利点があります。あるソフトウェアが自社の製造したものであるということをソフトウェアメーカーが証明できるからです。ただし、それはいくつかの条件に依存しています。まず、攻撃者が秘密鍵を流出させ、本来のユーザーになりすましてソフトウェアに署名したりできないように、秘密鍵は安全な方法で保管しているという条件です。もうひとつは、それを中心としたシステムが、署名インフラを通じてソフトウェアを自動的にプッシュすることになっていて、侵害されていないこと［を確認すること］です。侵害が発生した場合、攻撃者はソフトウェアの修正版も含めたソフトウェアを、気づかれないうちに署名インフラを通じてプッシュできるからです。しかも、それが正規として見られてしまいます」

ソフトウェア構成表（SBOM）を利用してソフトウェアの透明性を実現する

ソフトウェア構成表（SBOM）とは、「署名の対象であるソフトウェアにバグやマルウェアなどの脆弱性がないこと、改ざんされていないこと、その内部でどのようなコンポーネントが使われているかをソフトウェアチームが正確に把握していること」を証明するものです、とデジサートのシニアマーケティングマネージャーである Eddie Glenn は、6 月のデジサートブログ記事で説明しています。

SBOM の重要性が高くなっているのは、最近の政府による規制や業界標準も一因だと Zdjelar 氏は説明しています。米国連邦政府の大統領令 #14028 や、EU のサイバーレジリエンス法案などです。氏は、SBOM を食品の栄養表示にたとえています。

Zdjelar 氏はこう述べています。

「数十年前、私たちが体に何を取り込んでいるかを知るのは良いことだという考え方が広く受け入れられるようになりました。そこで食品医薬品局（FDA）は、何が入っているかを確認できる栄養表示を発表しました。今では、買い物をするときに栄養表示を見て、たとえば血糖値に問題がある人なら、「糖分の少ないものがいい」と口にするのが完全に常識になっています。

これと同じように、私たちの企業システムに何が入っているかを知りたいというニーズも高まっています。たとえば、ある種のライブラリやライセンスは、法的な責任を問われる可能性を考慮して意図的に避けることがあるかもしれません。もし、後になって何か問題が起こった場合に、Log4j がどこにあるのか、Infragistics はどこで使われているかなど、自分の環境で何がどうなっているかを速やかに確認できるようにしたいわけです。

したがって、正当性と安全性を証明しようとしているソフトウェアを構成する要素すべてをスキャンすることが不可欠です。

Thompson 氏は、こう付け加えています。

「オープンソースのコードだけでなく、自分で書いたコードだけでもなく、そこにあるかもしれないモデルであり、バイナリも重要です。多くの人はバイナリを見るだけで実際にはスキャンしません。バイナリが存在することを確認するだけですが、実際にはそのバイナリから重大なリスクが発生する可能性があります」

ソフトウェアに対する信頼を取り込むことがデジタルトラスト実現の鍵

デジタルトラストとは、それを可能にする技術だけの問題ではありません。組織がデジタルトラストの第一人者になるには、それを可能にする構造、プロセス、活動を理解したうえで積極的に実装する必要があります。そこに伴うのが、業界標準の変更への対応、地域ごとの規制要件遵守の維持、デジタルトラスト技術のライフサイクル管理、デジタルエコシステムへの信頼の拡大などです。

ソフトウェアに対する信頼は、デジタルトラスト実現の基盤です。ソフトウェアに対する信頼を実現するために、組織は自社のソフトウェアについて以下の点を保証する必要があります。

• マルウェア、脆弱性、その他の脅威が存在しないこと（脅威の検出）
• 自社から正規に提供されたものであり、第三者によって改変されていないこと（安全なコード署名）
• すべて説明済みのコンポーネントで構成されていること（SBOM）
  

ウェビナーの最後に、Sinha はこう述べました。「ソフトウェアサプライチェーンにおいて、また特に最近の AI モデルにおいて、デジタルトラストの重要性はかつてないほど高まっています」。そのうえで Sinha は、デジサートと ReversingLabs の新たなパートナーシップによって、ソフトウェアに対する信頼が大きく進化すると発表しました。デジサートは、ReversingLabs の高度なバイナリ分析機能と脅威検出を DigiCert^® Software Trust Manager のワークフローに統合。組織が一元管理できる単一の環境で、ソフトウェアにマルウェア、改ざん、その他の CVE がないことを確認できるようになります。この統合によって、包括的な SBOM も生成されます。

DigiCert Software Trust Manager は、成熟したソフトウェア信頼ソリューションに必要とされる制御と標準すべてとともに、秘密鍵の完全な保護を実現します。Sinha は、この共同ソリューションを要約する言葉として「検査、署名、出荷」という 3 つの単語をあげています。

ソフトウェアサプライチェーン全体でデジタルトラストをどう実現するか、詳細をご希望ですか。ウェビナーは https://www.digicert.com/about/webinars/the-ai-model-impact-on-the-software-supply-chain からご覧ください。

DigiCert Software Trust Manager の詳細は、https://www.digicert.com/jp/software-trust-manager でご確認ください。