2024 年版 Red Hat 製品セキュリティリスクレポート：CVE、XZ バックドア、SSCA、AI

大きな甘い紅茶かコーヒーを片手に、 Red Hat 製品セキュリティの  2024 年版 Red Hat 製品セキュリティリスクレポートをお読みください。オープンソースのエコシステムとそのセキュリティの課題について常に最新情報を入手しようと努めている私にとって、今年のレポートは非常に長く詳細に書かれており、期待を裏切らないものでした。実際、今年のレポートへの注目すべき点は、 AI に関する議論が追加されていることです。 

数字のゲーム

まずは、数字から見ていきましょう。Red Hat Security Advisories (RHSA) は 2024 年に新たなピークを記録し、2,975 件となりました。ここ数年間は着実に増加しています。興味深いことに、 重要 (Important) かつ 中程度 (Moderate) のアドバイザリーが大幅に増加した一方、 重大 (Critical) レベルのアドバイザリーはわずかに減少し、よりプロアクティブなセキュリティ・プラクティスと迅速な検出への移行を示しています。

共通脆弱性識別子 (CVE) の数は 4,272 件に急増し、比較的安定していた数年から大幅に増加しました。原因は何でしょうか。本レポートでは、Linux Kernel Organization が 2024 年 2 月に CVE Numbering Authority (CNA) になったことが強調されています。この組織は、多数のカーネルの問題に CVE を割り当てましたが、その多くはこれまで割り当てられていなかった問題でした。これらの新しい kernel.org CVE を除外すると、Red Hat のポートフォリオの増加を反映していると思われるわずかな増加が見られますが、これは驚くべきことではありません。 

詳細を見ると、ほとんどの新しいカーネル関連の CVE は中程度 (Moderate) および低程度 (Low) であり、2024 年に kernel.org が割り当てた CVE のうち、現在の Red Hat Enterprise Linux (RHEL) カーネルに影響を与えたのはわずか 45% でした。今後も重大 (Critical) および 重要 (Important) の脆弱性に焦点を当てていく必要があります。このアプローチは、 重大 (Critical) の CVE の半数以上に対する Red Hat の迅速な対応によって実証されています。最初の修正は 7 日以内に提供され、3 件の修正については、0 日目に提供されています。

上記のような背景なしにこれらのメトリクスを見ると、Red Hat は何をしているのかと思うかもしれません。CVE の数値は大幅に増加しましたが、Red Hat 製品についての潜在的なリスクプロファイルはそれに伴って変化していません。これらの数字は、CVE の数によってすべてを判断することはできないことを示しています。重大度、悪用の可能性、関連性なども考慮する必要があります。Red Hat が重大 (Critical) および 重要 (Important) の問題のパッチの適用に注力していることは、データによって検証されており、実際のセキュリティ侵害が最も多く行われているのがこれらの脆弱性レベルにおいてであることを示しています。つまり、これはリスクベースのアプローチが最も理にかなっていることを証明するものとなっています。

XZ バックドア：扱いにくい問題

2024 年にセキュリティについて語る上で、XZ バックドアのインシデントを抜きにして語る人はいないでしょう。このインシデントは、考え抜かれたサプライチェーン攻撃であり、今もオープンソース・コミュニティにとって悪夢のような出来事でした。信頼されていた保守担当者が 2 年以上にわたってコミュニティとの信頼関係を構築していましたが、XZ ライブラリに高度なバックドアを導入しました。 Andres Freund 氏がこれに気づいていなかったら、数え切れないほど多くのシステムで Secure Shell (SSH) アクセスが侵害されていた可能性があります。

このレポートでは、Red Hat がオープンソースの対応を振り返りながら、本質的なリスクについて明確に説明し、オープンソース・モデルの強みを紹介しています。これについては、ソースコードや対応に関する情報が公開されていたため、共同作業による迅速な分析や情報の共有が可能でした。また、同レポートでは、Fedora テストや RHEL 品質エンジニアリングなどの、自社のパイプライン内の障壁についても取り上げています。このような障壁があると、脆弱性を検知できなくなる可能性がゼロではありません。  

XZ のバックドアのインシデントは重要な警鐘となりました。このインシデントは、オープンソースの信頼と貢献のプロセスに長期的な影響を与えるでしょう。サプライチェーン攻撃の数や巧妙さは増すばかりです。攻撃者は、開発者が日常的に使用する一般的なツールや共有コードを標的にする方法を模索しており、広範囲にわたる問題を引き起こすことを目指しています。これらの種類の攻撃は、ソフトウェアベンダーに複数の保護レイヤーが必要であることを示すものとなっています。つまり、使用する事前構築済みのコード部分の安全性を自動的に確認し、ソフトウェアを構築するための安全な組立ラインを用意し、新しい部分を追加する前に詳細に検査するプロセスが必要です。これに関連し、Red Hat にはいくつかのチェックを実施しており、 これらのチェックによって最近の XZ のセキュリティ問題を検知できる可能性が考えられます。これは、セキュリティの複数のレイヤーが実際に役立つことを示しており、セキュリティは、一度限りで終わる活動ではありません。

サプライチェーンの問題

ソフトウェア・サプライチェーン攻撃 (SSCA) の数が増加し、オープンソース・コンポーネントへの依存度が高まっていることは、ほとんど信じられないような状況ですが、統計的には事実です。 Black Duck の分析によると、商用コードベースの 97% がオープンソース・コンポーネントに依存しています。これはイノベーションと開発のスピードを向上させる一方で、悪意のある攻撃者にとって非常に魅力的な標的となり、攻撃者はあらゆる機会を狙っています。Red Hat は公開されている SSCA の動向を調べていますが、報告によると、2024 年には 89 件のインシデントが発生していることが明らかになりました。これは、前年比で 68% の大きな増加となっています。 Sonatype の報告でも、この不安定な傾向について言及しています。ソフトウェア・サプライチェーンはますます厳しい状況に置かれています。

XZ Utils のセキュリティ侵害や、複雑な雇用詐欺のスキームを使用して内部情報にアクセスする北朝鮮の攻撃者などは、悪意のある攻撃者が使用する、さらに高度になっている戦術の 2 つの例に過ぎません。これらに関する問題点は、これらの攻撃のほとんどについての動機が不明であることであり、巨額の資金が未請求のままであるという点です。攻撃者が誰で、攻撃の目的が何であるかを完全に理解していないと、効果的に防御することは難しくなります。一部の攻撃者は金銭を要求したり、スパイを試みますが、多くの攻撃についての目的は明らかになっていません。このため、サイバー脅威によって状況はさらに複雑になり、予測やモデル化するのが困難になります。攻撃者の視点からは、鍵を握っているとも言える開発者とそのアクセスポイントを標的にすることは効果的です。しかしこれは、デジタル世界の構築に必要な人間的要素こそが主要な標的になることを意味しています。

これらの SSCA は、熟練した匿名の攻撃者による重要なオープンソースの依存関係の悪用がエスカレートすることを示しています。とはいえ、先進的なソフトウェアを体現したオープンソースの使用を止める訳にはいきません。私たちは、根本的な転換を図る必要があります。すなわち、侵害への対応時だけでなく、開発ライフサイクル全体に組み込まれたプロアクティブなセキュリティ・プロトコルが必要です。これには、依存関係のより良い精査、開発者のための強固なセキュリティ対策、さらに XZ への対応で強調されているように、ベンダー、コミュニティ、ユーザーがエコシステムの保護に投資する共有責任モデルなどが含まれます。私たちの依存度の高まりと比例して、セキュリティへの投資も増やしていく必要があります。現時点では、攻撃者が明らかに数歩リードしている状態であり、さらなる追い上げが必要です。

AI への期待

参考までに、生成 AI (gen AI) は昨年、チャットボットからコーディングアシスタント、クリエイティブツールまで、爆発的に増加しました。その勢いはとどまることなく、生成 AI は 2030 年までに毎年 37% の割合で成長すると予測されており、この成長率は驚くべきものです。 

しかし、いずれの最新テクノロジーにも言えることですが、どれくらいの速度で動作するか、どれだけのことができるのか、また業務のあり方をどのように変えるかなど、最初は誰もがその機能に注目します。

しかし今は、真価が問われる段階です。とりわけ医療、金融、行政などの規制の厳しい業界では、ミスが重大な影響を及ぼす可能性があるため、より重大な点について検討する必要があります。より重要な点とは、AI の使用における安全性、セキュリティ保護および信頼性をどのように確保できるか、AI が混乱を生じさせたり、個人情報を漏洩しないと信頼できるようにするにはどうしたらよいか、といった点です。データの安全性の維持が AI についての今年の最大の懸念事項であると述べる意思決定者がいるのは当然なことです。個人情報が外部に流出したり、安全に構築されていない AI が誤った判断を下したりすることは避けなければなりません。また、前述のように、オープンソースには認知度の高いターゲットがいくつか存在します。

私たちは単に AI の時流に乗っているだけではなく、AI のセキュリティと安全性を確保する方法の見出そうとしています。しかし、これは簡単な作業ではありません。 

Red Hat が「Building Trust: Foundations of Security, Safety and Transparency in AI」で最初に指摘している点は、AI のセキュリティ上の脆弱性と AI の安全性に関する問題とを切り分ける必要性です。

• セキュリティの脆弱性：ハッカーが  AI システムに侵入する方法を見出そうとする。
• 安全性の問題：「ハッキング」されていなくても、AI 自体が不正確で、偏りのある、は有害な情報を提供する。

上記の 2 つの問題は別々に対処する必要があります。バグを修正することと、AI に対して有害や情報やでたらめな情報を提供しないようにと教えることと同じではないからです。これら 2 つの問題には、それぞれ異なるルールブックが必要になります。

Red Hat のような企業や、EU や米国などの政府機関、また各種の業界グループがこの問題の解決に取り組んでいるのを見れるのは心強いことです。これらの異なる AI リスクを追跡するためのガイドラインや、標準および方法の策定が進んでおり、テクノロジーの構築を責任を持ってゼロから取り組み、エンジニアをトレーニングし、安全な設計を作り上げようとしています。Red Hat について言えば、Red Hat は語るだけでなく、実際に構築を行っています。

これは何を意味するでしょうか。AI ブームはエキサイティングで、多くのことを変える可能性があります。しかし、最終的に重要になるのは、信頼できるかという点になります。どのような良好な関係についても、信頼関係がその基盤となります。AI のメリットを最大限に活用するためには、AI との関係も信頼に基づいて構築される必要があり、単なる派手なデモ以上のものが必要になります。信頼は、テクノロジーが確実に安全で、期待通りに動作するようにするための舞台裏での懸命な取り組みから生まれます。また、適切な人材がそれに注力しているかどうかも大切な点になります。大きな問題を後から解決しようとするのではなく、今のうちに注意を払ってガードレールを構築する必要があります。そのためには、AI を信頼して、こうした重要な取り組みに携わる人材が必要です。

SDLC の舞台裏

2024 年、Red Hat は、信頼性の高い製品の背後には、問題の見落としがないことを確認するための精力的な努力があることを実証しました。Red Hat のアプローチは、単にNIST のセキュリティ標準に従うだけのものではありません。Red Hat は、AI テクノロジーを含む、Red Hat が構築するすべてが最初から信頼できるものであることを検証する独自の方法を開発しています。

Red Hat Secure Software Development Lifecycle (RHSDLC) は、セキュリティに重点を置いたソフトウェアを構築するためのプランを提供するものですが、さらにスマートになり、現実にあるセキュリティの課題との関連性や整合性が強化されています。しかし、Red Hat は単に表面的なチェックを行っているのではなく、RHSDLC などの独自の基準を策定し、Security Operating Approvals (SOA) の手順を成熟させることでソフトウェア・サプライチェーンのセキュリティを強化するように全面的に取り組んでいます。これには、サードパーティツールの検証、チェックの自動化、問題が生じる前にリスクを報告することが含まれます。言ってみれば、これは、洪水を待つのではなく、まだ水滴が垂れているうちに水漏れに対応するようなアプローチです。Red Hat では、セキュリティの詳細を徹底的に検討し、信頼や透明性、およびレジリエンスに重点的に取り組むことで、お客様が Red Hat の製品を信頼していただけるよう努力しています。

Security Architecture Review (SAR) が RHSDLC で標準化されていることは非常に興味深いことです。このレビューでは、「絶対に必要な場合にだけアクセスを提供する」、「防御をレイヤー化する」などといった、実際にテスト済みの従来のセキュリティ原則をサポートしており、セキュリティが初日の製品の設計に組み込まれるようにしています。

最後は、RapiDAST について言及します。オープンソースやアプリケーション開発に携わっているなら、このツールは隠された宝のような存在になるでしょう。これは Red Hat の動的なアプリケーションのセキュリティのテストツールであり、2024 年重要なアップグレードが行われました。これにより、RapiDAST は、より強力になっただけでなく、使いやすくなりました。たとえば、Kubernetes Operator テストのサポートや、自動化の強化、インタフェースの単純化が可能になりました。今では Google Cloud Storage に結果を直接エクスポートできるようになったため、コラボレーションの効率が向上しました。

Red Hat はこれらすべてを、開発者が製品の構築とリリースに日常的に使用する CI/CDパイプラインに直接組み込んでいます。開発者であれ、IT プロフェッショナルやシステムの安全性の維持に取り組むエンドユーザーであれ、ツールを利用するすべての人々にとって、セキュリティに重点を置いた開発への取り組みは非常に重要です。サイバー脅威が絶え間なく起こる状況において、ソフトウェアベンダーが設計段階からテスト、コンポーネントの追跡に至るまで、セキュリティに集中的に取り組んでいることを知ることは安心につながります。Red Hat は、セキュリティに対して、単なる付け足しではなく、品質の中核部分として真剣に取り組んでいます。

2025 年版に向けて

今年のレポートは、セキュリティが常に変化することを改めて認識させるものです。CVE の報告方法の変化、サプライチェーン関連して継続して見られるリスク、AI の影響の増大、脆弱性の優先順位付けなど、ユーザーが考慮すべきことは多々あります。

このような状況下で、この透明性の高いレポートは非常に重要です。開発者から IT チーム、また私のような好奇心旺盛な読者まで、すべての人々が現状を理解し、課題やより情報に基づいた選択肢を理解するための助けとなります。私は、重要なのは問題を防ぐことだけではなく、それらにどのように対応するかも同様に重要であると考えています。XZ バックドアのようなインシデントの発生時にオープンソース・コミュニティは形成されました。これこそが、コラボレーションの実際の力と言えます。

2024 年 Red Hat 製品セキュリティリスク・リポートの全文をご覧ください。