OSSのセキュリティリスクと対策｜脆弱性・配布物の改ざん・SBOMによる管理

OSSのセキュリティリスクは、コードの欠陥が脆弱性として公表されるものと、配布物や開発者のアカウントが侵害され、正規の更新に不正なコードが入るものの二つだ。

どちらも、使っている部品とバージョン、いつどこから取得したかの記録があれば、影響する環境を絞り込める。ライセンス違反のリスクはこの記事では扱わない。

OSSのセキュリティリスク：既知の脆弱性と配布物の乗っ取り

OSSの既知の脆弱性は修正されたバージョンに上げれば解消するが、配布物の乗っ取りでは開発者以外の者が配布の経路に不正なコードを入れるので、最新バージョンに上げること自体が被害の入口になる。

OSSの既知脆弱性による影響

Log4jの脆弱性（CVE-2021-44228、2021年12月公表）について、Apacheは『Log4jのセキュリティ情報』で、ログに記録する文字列を攻撃者が操作できると、外部のLDAPサーバーから読み込んだコードを実行されると説明している。影響は部品とバージョンで分かれ、一部の修正済みバージョンは除かれる。

部品名だけでなく、どのファイルのどのバージョンが、どの設定で動いているかを照合して影響を決める。

Log4j 1はこの脆弱性の対象外だが、設定でJMSAppenderを使うと別の脆弱性（CVE-2021-4104）の影響を受け、保守が止まり修正も出ない。ApacheはLog4j 2への移行を求める。OWASPの『脆弱な依存関係の管理チートシート』は、修正が出ない部品には保守の続く代わりの部品の検討を勧める。

OSSのソフトウェアサプライチェーン攻撃と配布物の乗っ取り

ソフトウェアサプライチェーン攻撃は、OSSの開発や配布の経路から利用者に不正なコードを届ける攻撃だ。

2024年3月、圧縮ライブラリxzのバージョン5.6.0と5.6.1に不正なコードが見つかった（CVE-2024-3094）。発見者のAndres Freundによれば、不正なコードを組み込む仕掛けはGitのリポジトリになく、配布用のアーカイブにだけ入っていた。組み込まれるのは、x86-64のLinuxでDebianやRPMのパッケージとしてビルドする場合などだった。

Red Hatは、開発中のFedora 40とRawhideが該当し、systemdを経由してsshdの認証に干渉するとして、5.4系への切り戻しを求めた。悪用の事例は報告していない。

npmでは2025年9月、自己増殖するマルウェア「Shai-Hulud」が見つかった。米国CISAによれば、侵害した開発者のアカウントで別のパッケージにも自身を入れて公開し、500を超えるパッケージに広がった。GitHubのトークンやクラウドのAPIキーを盗み、公開リポジトリに上げていた。

どちらも、正規の配布元から通常の手順で取得した更新に不正なコードが入っていた。

OSSのセキュリティリスクを調べる直接・間接依存の一覧

OSSのセキュリティリスクを調べる最初の材料は、直接・間接の依存まで含めて何をどのバージョンで使っているかの一覧、ソフトウェア部品表（SBOM）だ。xzはsshdの利用者が自分で選んで入れる部品ではない。問題の部品が依存の先にあると、直接使う部品の一覧では見つからない。

直接・間接依存の一覧化

米国電気通信情報局（NTIA）は『SBOMの最小要素』（2021年）で、SBOMに載せる項目を部品名、バージョン、依存関係など7つとし、最上位の部品とその間接的な依存をすべて載せるべきだとした。列挙しきれない場合は、分かっていない部分（known unknowns）の明記を求めている。依存がない部品と、依存が分からない部品を区別するためだ。

Webアプリのロックファイルだけで一覧を作ると、xzのようなOSの部品が抜ける。

SBOMと実際の稼働構成の照合

NTIAは同じ文書で、新しくビルドするたびにSBOMを作り直すよう求めている。照合では、SBOMの作成日時と、サーバーやコンテナで動いているバージョンを突き合わせる。CISAはShai-Huludへの対応で、社内の保管庫に残るキャッシュも探すよう求めた。一覧の上で直っていても、保管庫やキャッシュに古いファイルが残っていれば、次のビルドで入る。

OSSのセキュリティリスクと利用履歴の照合：脆弱性情報・改ざん報告

OSSの脆弱性情報は部品・バージョン・設定で、改ざん報告は取得・実行した時期で、自社の利用履歴と照合する。

OSSの脆弱性管理に必要な脆弱性情報と利用条件

脆弱性情報とSBOMの照合は、SCA（ソフトウェア構成分析）と呼ばれるツールで自動にできる。照合の対象は部品とバージョンだ。

該当する部品・バージョン・設定がそろうサーバーを対応の対象にする。外部からの入力が届く場所から先に直す。照合の結果と対応の要否、その理由を、判断した担当者と日付とともに残す。

改ざん報告と取得・実行履歴

改ざんの報告には、不正なバージョンが出回った期間が載る。CISAは2025年3月、GitHub Actionsの部品tj-actions/changed-filesが侵害されたと注意喚起し、期間を3月12日0時から15日12時（協定世界時）とした。漏れた情報にはアクセスキーやトークン、RSAの秘密鍵が含まれ、その期間に動いたワークフローを特定して秘密情報を変更するよう求めた。

期間で照合するには、過去の取得と実行の記録が要る。

• いつ取得したか：CIの実行記録、ロックファイルの変更履歴
• どこから取得したか：公開の登録簿か、社内の保管庫か
• どこで実行したか：開発者のPC、CI、本番のサーバー
• その環境に何があったか：トークン、クラウドのキー、署名の鍵

不正なバージョンが動いた環境にあった秘密情報は、漏れたものとして変更する。CISAはShai-Huludでも、開発者の認証情報をすべて変更するよう求めている。

取得・インストール・実行の履歴を分けて調べる手順は、LiteLLMに認証情報を盗むコードが混入した事例の記事で整理している。

OSSのセキュリティリスクを抑えるバージョン固定と更新手順

OSSのセキュリティリスクを抑えるには、最新を自動で取り込む設定をやめてバージョンを固定し、更新を承認の要る変更として扱う。OWASPの『ソフトウェアサプライチェーンセキュリティ・チートシート』もロックファイルでの固定を勧めている。

1. ビルドではロックファイルどおりに入れる。npm ciはpackage.jsonとロックファイルが食い違うと止まり、ロックファイルを書き換えない。pipのハッシュ確認モードは、ハッシュのない依存があるとエラーにする。
2. CIで使う部品は、コミットのハッシュで指定する。GitHubは、部品のリポジトリが侵害されるとタグを移動・削除されうると説明している。
3. 公開から一定の時間がたたないバージョンは入れない。pnpmのminimumReleaseAgeの設定で、pnpmは悪意ある公開の多くが1時間以内に見つかり削除されるとしている。
4. 更新はプルリクエストで行い、間接依存を含むロックファイルの差分と、リリースノートと注意喚起を確かめる。承認は、更新を出した人と別の担当者が行う。新しく部品を加えるときも同じ承認に載せ、OpenSSFの『OSS評価の簡潔なガイド』にならい、直近12か月のリリース、保守者が複数いるか、正規の取得元かを確かめる。
5. 更新後にSBOMを作り直し、作成日時と承認者を残す。

サーバーのOSの部品は、配布元の注意喚起を受け取る担当者を決める。xzの切り戻し先も配布元が示した。

待ち時間は急ぎの修正も遅らせる。pnpmには指定した部品を待ち時間から外すminimumReleaseAgeExcludeもある。

問題の公表に備え、まずロックファイルとサーバーのパッケージ一覧からxzやlog4j-coreのような間接依存まで出せるか、CIの実行記録が何日分残るかを確かめておきたい。