1. HOME
  2. ブログ
  3. サイバートラストの取り組みから考える! ソフトウェアサプライチェーンセキュリティ強化の動向 【JapanSecuritySummit 2024 サイバートラストセッションレポート】

サイバートラストの取り組みから考える! ソフトウェアサプライチェーンセキュリティ強化の動向 【JapanSecuritySummit 2024 サイバートラストセッションレポート】

最近ではOSS(Open Souce Software)の活用が進み、ひと昔と比べて利用範囲も拡大している。たとえば、スマートデバイスやIoT機器の普及により、高度な処理やセキュリティが求められるようになったことで、IoT機器ではLinuxが約43%も採用されている。そうなると心配されるのがセキュリティの問題だ。各国でセキュリティに関する規制が高まるなかで、サイバートラスト OSS事業本部の池田宗広氏が、ソフトウェアサプライチェーンセキュリティの強化と、同社のOSSセキュリティ活動の取り組みについて紹介した。

OSS界隈におけるソフトウェアサプライチェーンセキュリティの関連動向

近年、Linux OSのニーズが増加傾向にあることはご存じの通りだろう。実際にIoT機器ではLinuxが約43%も採用され、ダントツでトップを走っている状況だ(出典:Eclipse Foundation「IoT Developer Survey 2020」)。 そのような中で、IPAの「情報セキュリティ10大脅威 2024」では、相変わらずランサムウェアによる被害が一位、サプライチェーン攻撃も二位に定着している。修正プログラムの公開前を狙うゼロディ攻撃や、脆弱性対策情報を悪用するNディ脅威が急増しているのだ。このような動向を勘案し、欧米英など主要各国ではサイバーセキュリティ法規制が制定され、相互認証する形での共通規定になっている。

たとえばEUでは「サイバーレジリエンス法」(CRA)の最終ドラフトが出ており。日本では「セキュリティ要件適合評価及びラベリング制度」(JC-STAR)が制定され、いよいよ2025年3月から一部の申請受付が開始される。EUのCRAは要件を満たさないと市場に製品を出せない強制的な法規制になるが、日本のJC-STARは適合しなくても製品は出せる。ただし、調達基準になる予定なので、ビジネスを展開する際には事実上の強制力を持つようになるだろう。

OSS・ソフトウェアサプライチェーンの全体像と、OSSコミュニティの動き

ここからはIPAの情報セキュリティ10大脅威 2024のうち、第二位になったソフトウェアサプライチェーンセキュリティについて見ていこう。これは設計・開発から、実装、テスト、パッケージング、流通、インストール、実行までの一連のプロセスの関係と流れに対して「期待されたセキュリティの結果が得られているか?」ということだ。

つまり「期待する主体によって行われ」「期待する工程を経て」「期待する経路を通り」「期待する構成で」「期待する機能をもって」「実行場所(ユーザー)に届くこと」、それらが検証できることが求められる。この流れを全体像で示すと以下のようになる。

この中で特に重要な構成要素が「SBOM」(Software Bill of Materials)だ。SBOMはソフトウェアコンポーネントや、それらの依存関係を一覧化した構成リストだ。もう1つ重要な要素が「Provenance」(証跡)で、各工程で何が行われたのかを記録したメタデータとなるもの。これにより期待された工程を通ってきたのかを検証できる。両者を準備することで、ソフトウェアが最終的な実行場所で期待されるものになったのかを検証することができる。

さらに、ソフトウェアサプライチェーンの中でアクションを取り、もしも期待された構成でなく、何か脆弱性が潜んでいるような場合などに、警告したり実行を停止したりすることが可能だ。最終的に正しい状態に自動修正できるところまでくれば、ソフトウェアサプライチェーンセキュリティの現状における完全な姿としての理想像になるだろう。 ソフトウェアサプライチェーンにおける具体的なセキュリティ侵害例にはどのようなものがあるのだろうか? たとえば開発工程でマルウェアが混入したり、誰かが意図せざる工程を実施したり、テスト工程で本来行うべきものを迂回してしまったり、実行工程での「Typoスクワッティング」などが行われたりすることが挙げられる。Typoスクワッティングとは、もともとURLを少し変えて悪意あるサイトに誘導する場合に用いられる手法だが、ここではソフトェアのパッケージレポジトリに似た名前のパッケージを用意しておき、悪意あるコードを仕込んだものを誤って実行したユーザーに対して、攻撃を仕掛けるという手口だ。

OpenSSF(Open Souce Security Foundation)に代表される主要なOSSアクティビティ

ここまで紹介してきたように、ソフトウェアサプライチェーンのセキュリティ脅威が高まるなかで、OSSコミュニティでも対策を練る動きが出てきている。2020年代からの重大なセキュリティ事件を振り返ると、SolarWindsのネットワーク監視ツールにマルウェアが混入して全米で大規模な被害を受けたり、Javaのログライブラリ「log4shell」の深刻な脆弱性が問題になったり、最近では圧縮展開ツール「xz」にバックドアが仕込まれたりした事件も話題になった。

特にOSSコミュニティで問題になったのは、前出のXZ Utils(CVE-2024-3094)の話だろう。バックドア経由でroot権限が奪取され、リモートコードが実行されるという手口だが、幸いにもベータ版の配布段階で発覚したため、広い実害はなかった。ただし、この事件はOSSコミュティに大きな波紋を投げかけた。というのも攻撃者が正規のメンテナンス権限を持っていたからだ。もともと、その攻撃者はアタックの意図はあったようだが、コミュニティでの数年にわたる活動実績を経て、関係者の信頼を獲得しており、そのあとに攻撃コードを混入させたのだ。

ここで得られた大きな教訓は、xzのような重要なOSSでさえもメンテナンスが一人で奮闘しているケースが多いということで、今回のような事件を防止するために、メンテナンスの信頼をどう担保していくかということだ。しかし、これについての明確な答えはまだ出ていない。もう一度OSSを公共財として維持するための活動や、OSSプロジェクトの健全性を検証する仕組みが求められるだろう、また流通までにソフトウェアが経てきたプロセスを検証するためにも、あらためてサプライチェーンセキュリティの強化が必要になるということだ。

実はサイバートラストは、セキュリティ強化を目指すOSSコミュニティ「OpenSSF」(https://openxssf.org)に参加している。これはThe Linux Foundation傘下のプロジェクトで、現在120団体が業界横断的に加盟中だ。日本では当社のほかに4社(サイボウズ、ルネサスエレクトロニクス、日立製作所、スズキ)もメンバーになっている。

このOpenSSFに参加する意義は、「デジタル公共財であるOSSを守る」という意思表示になることだ。つまりOpenSSFは「共有地の悲劇」を起こさないために必要な仕組みと言える。共有地が自由でオープンであることは大切だが、誰もケアしなければ荒れ果ててしまう。そういった状態を回避するためにOpenSSFが重要になるわけだ。これまで啓蒙活動として、国内メンバーが不定期でMeetupを開いたり、各種イベントを開催したりしてきた。

OpenSSFは、さまざまな企業が集結してOSSの方向付けをしてきたが、具体的な開発を行うというよりは、組織全体としての活動を展開しているところだ。主要なOSSアクティビティとしては、まずOSSプロジェクトの健全性を評価・強化すべく、開発プロセスに関するベストプラクティスの基準を提供し、その基準に合致したものにバッジを与える「OpenSSF Best Practice Badge」や、OSSプロジェクトのセキュア度をスコアリングする自動スキャンツール「Scorecard」などの提供が挙げられるだろう。

またサプライチェーンセキュリティに関する活動としては、ソフトウェア開発プロセスを対象とする専用フレームワーク「SLSA」(Supply-chain Levels for Software Artifacts)がある。これは前述の工程証跡の概念であり、いわばサプライチェーンセキュリティのチェックリストのようなもので、要件を満たすとレベル3までが与えられる。またSLSAからは工程証跡のスキーマ「in-toto」も参照できる。一方で、OSS利用者が対象のフレームワーク「S2C2F」(Secure Supply Chiain Consumption Framework)もあり、こちらはレベル4まで用意されている。

サプライチェーンセキュリティの要素であるSBOMフォーマットは「SPDX」(Software Package Data eXchange)と「CycloneDX」がデファクトスタンダードになっている。SPDXはライセンス管理、CycloneDXは脆弱性管理の性格が強かったが、バージョンアップされて両者の違いもなくなってきた印象だ。ほかにも脆弱性情報フォーマットを標準化する「OpenVEX」(Open Vulnerability EXchange)、複雑になったSBOM情報などをグラフで可視化する「GUAC」、統一的なSBOMデータ構造を表現するプロトコルバッファ「Protobom」、開発者を明らかにするための署名・検証ツール「sigstore」などもある。開発者に関しては、具体的にどうセキュア開発を進めていくべきかという点が大事だ。そこでLinux Foundationでは「LF Training」や「OpenSSFガイド」(日本語訳)も用意している。

OpenSSF以外で日本の動きでは、経産省が「ソフトウェア管理に向けたSBOMの導入に関する手引きVer2.0」(https://www.meti.go.jp/press/2024/08/20240829001/20240829001-2.pdf)を公表したので、そちらも参照するとよいだろう。

OSSコミュニティの一員として貢献するサイバートラストの取り組み

最後にサイバートラストのサプライチェーンセキュリティに関する取り組みについても簡単に紹介しよう。以下、アクティビティ全般のマップを示す。このうち色付きのものが当社の製品やサービスを提供している分野だ。

脆弱性の発見や管理ができたら、その対応も必要だ。そこで開発ライフサイクル全般をセキュアな状態を継続的に担保できる組込み/IoT機器向けLinux開発環境(ディストリビュ-ション)の「EMLinux」をトータルサポート。また同社ではAlmaLinuxへ貢献しており、SPDXの対応なども積極的に進めている。

このようにサイバートラストは、さまざまなOSSのユーザーであると同時に、コントリビュータとしての立場から、OpenSFFへの参画などやコミュニティ活動を通じ、今後もセキュアなソフトウェアサプライチェーンを実現していく構えだ。

関連記事

サイバーセキュリティの課題をテーマ別に紹介中!!