商用オフザシェルフ (COTS) ソフトウェア

不特定多数の市場向けに販売されていて、買い手の要求に合わせて作られたのではない既製ソフトウェア。「作らずに買う」という調達判断であると同時に、「内部を知らず、進化を制御できない部品に依存する」という設計判断でもある。SOUP が安全規格の側から見た同じ対象で、COTS は調達の側から見た呼び名。

定義 — 境界線は「無改変」

米連邦調達規則 (FAR 2.101) の COTS item は3条件を満たすもの:

1. 商用製品であること
2. 商用市場で相当量販売されていること
3. 無改変で、市場で売られているのと同じ形で提供されること

一行でも顧客のために手を入れた瞬間、それは COTS ではなくなる (MOTS)。この線引きが厳しいのは形式主義ではなく、「他の全顧客と同じ物を使っているから、市場の使用実績を自分の論拠にできる」という一点を守るため。改変すれば、その実績は自分の版には及ばない。安全臨界での運用実績クレジット(後述)も同じ論理に乗っている。

なお FAR の COTS item は「any item of supply (including construction material)」であって、ソフトウェア専用の語ではない。民生 FPGA・ラックマウントサーバ・Ethernet スイッチのような物品も COTS で、そもそも1994年の政策転換(後述)が主に狙っていたのは MIL-SPEC 部品の民生品への置き換えだった。ソフトの文脈で使われることが多いだけで、語の射程はもっと広い(ばら積み貨物 — 農産物・石油等 — は明示的に除外)。

*OTS 族

上位概念は NDI (Non-Developmental Item) — 新規開発を要さない、あるいは最小限の改変で済む調達物。

GOTS が政府調達で好まれるのは、全側面を自分で制御できるから。COTS の安さは制御権の放棄と引き換えになっている。

実物 — 業務で触るものはほぼ COTS

「COTS = 特殊な業務パッケージ」と捉えると射程を見誤る。実際には自社で書いた分以外のほぼ全部が COTS で、だからこそ仮説1(命令の99%超)が成り立つ。

自社開発システムに埋まった OSS(Log4j, OpenSSL, SQLite)も、FAR の定義からは外れるが実務上の扱いは同じ。

shadow IT との切り分け — 軸が違う

射程が広いので shadow IT と混同されやすいが、両者は直交する別の軸を測っている。

• COTS = 「どこで作られたか」(出自の軸) — 自社開発か、市販の既製品か
• shadow IT = 「誰の承認で入ったか」(統制の軸) — IT 部門が把握・承認しているか、現場が勝手に導入したか

右下が効く。shadow IT には COTS でないものが普通に含まれる(野良マクロ、勝手に書いたスクリプト)。逆に左上は shadow IT ではないが、まぎれもなく COTS。包含関係はどちらの向きにも成り立たない。

混同が起きるのは実務上の重なりが大きいから。現場が勝手に導入するものは今どきほぼ SaaS なので、shadow IT の大半がたまたま COTS になる。ただしそれは重なりであって同一ではなく、困りごとの性質も対処も違う。

決定的な反例が Log4Shell(後述の④) — 在庫が分からなかったのは shadow IT ではなく、契約書も資産台帳もある正規調達の COTS 製品群だった。つまり shadow IT を完全にゼロにしても COTS の在庫問題は丸ごと残り、だから SBOM という別の道具が要る。同一視すると「shadow IT を潰せば安全になる」という誤った結論に着地する。

なぜ「買う」に振れたか — 1994年の政策転換

米国防総省の COTS 化は2つの文書で始まった。

• Perry memo (1994-06-29, “Specifications and Standards — A New Way of Doing Business”) — 3万件超あった MIL-STD / MIL-SPEC をデフォルトから外し、軍固有仕様は最後の手段、使うなら Milestone Decision Authority の waiver が要る、とした。
• FASA (Federal Acquisition Streamlining Act of 1994, 1994-10-13 署名) — Title VIII “Commercial Items” が商用品調達の優先を法制化。

動機は2つ。コスト(軍仕様というだけで価格が跳ね上がる)と、速度。1980年代までは軍が技術の先端にいたが、90年代に PC・ネットワーク・DBMS で商用側が追い越した。COTS 化は「先端が組織の外に移った」という事実への適応であって、単なる節約策ではない。

買っても開発は消えない — 実証データ

Boehm & Abts “COTS Integration: Plug and Pray?” (IEEE Computer, 1999) を起点に、COCOTS プロジェクト(20件の COTS ベースシステム)が工数を定量化した。Basili & Boehm “COTS-Based Systems Top 10 List” (IEEE Computer, 2001-05) がその骨子。

工数の内訳 — COTS に起因する活動の平均比率:

標準偏差が平均と同程度に大きい。つまり万能の配分は存在せず、案件ごとに支配的な費目が入れ替わる。

主要な仮説(著者らが「仮説」として提示したもの。数字は桁の感覚として読む):

読み方はひとつ。「買う」は開発を消すのではなく、統合・追従・調達管理へ付け替える。しかも付け替え先の単価は高い(1行あたり3倍)。COTS が効くのは総量が減るときであって、名目上の自作コード行数が減るときではない。

安全臨界での COTS — 「使うな」ではなく「正当化せよ」

規制領域では、COTS を使った瞬間に正当化義務が発生する。各基準の呼び名は違うが構図は同じ。

エビデンスの作り方は3経路あり、実務では組み合わせる。

flowchart TD
    C["COTS 部品<br/>(内部が見えない・記録がない)"] --> A["① 追加検証<br/>自分でテスト/解析を積む"]
    C --> B["② 運用実績<br/>product service history"]
    C --> D["③ アーキテクチャ隔離<br/>ラッピング/独立モニタ/冗長化"]
    A --> E["認証エビデンス"]
    B --> E
    D --> E
    B -.->|"落とし穴"| F["他社の使い方の実績であって<br/>自分の使い方の実績ではない"]
    D -.->|"効き方"| G["COTS の誤りが<br/>安全影響に至らない構造にする<br/>= 要求される厳格度自体を下げる"]

③ が本質的に強い。個々の部品の信頼度を上げるのではなく、部品が誤っても安全に至らない構造を作れば、その部品に要求される厳格度そのものが下がる(安全はアーキテクチャで作るの適用)。

ベンダ側が先回りする道もある。SQLite は avionics メーカーからの関心を受けて TH3 テストハーネスを DO-178B の要求に合わせて設計し、2009-07-25 にコアに対する 100% MC/DC を達成した。結果として Airbus A350 の搭載系で使われている。Ferrocene が rustc に対してやっていることの DB 版で、COTS を SOUP でなくすのはベンダの仕事にもできることを示す例。

ここは「認証エビデンス込みで売る」という市場になっている。

現代の COTS — OSS と SaaS

FAR の定義は「売られている」ことを前提にするが、実務上の困難は価格ではなく自分が作っていない部品への依存にある。無償の OSS は従属先が「ベンダ」から「メンテナ」に変わるだけで、構図はそのまま残る。むしろ悪化している面がある。

• 仮説1(99%)は OSS 時代にさらに極端になった
• 仮説3(追従サイクル)は OSS のほうが速い。しかも支援打ち切りの通告が来るとは限らない
• 「相当量が売られている(広く使われている)」は品質の保証ではなく、攻撃価値の証明でもある。xz-utils バックドア (CVE-2024-3094, 2024-03) は「みんなが使っている」ことが侵入動機そのものだった

だから SBOM と継続的な CVE トリアージに行き着く。IEC 62304 が2006年に SOUP のアノマリリスト評価として制度化していたものが、いまサプライチェーン管理として一般化した形になる。

SaaS はさらに一歩進む。バージョンの選択権すら手放すため、仮説3の追従サイクルが自分の意思ではなく強制になる。

実際に何が起きたか — 失敗の6つの型

COTS 固有の失敗は「脆弱性があった」ではなく「自分の手が届かない」に由来する。型ごとに代表例を1件ずつ。

① 自分では直せない — MOVEit Transfer (2023)

ファイル転送製品の SQL インジェクション 0-day (CVE-2023-34362)。2023-05-27 から Cl0p が悪用し、LEMURLOOT という web shell を設置してデータを窃取。CISA 推計で米国3,000超・全世界8,000超の組織が影響を受けた(BBC、British Airways、ノバスコシア州政府など)。

本質は、利用側の誰一人このバグを直せなかったこと。ソースが無いので Progress 社のパッチを待つ以外にできることは、止めるか隔離するかだけ。さらに British Airways などは自社で MOVEit を使っていたのではなく、給与計算を委託した Zellis 社が使っていて刺さった。COTS の依存は自社の境界で止まらない。

② EOL が被害そのものになる — Accellion FTA (2021)

20年ものの旧世代ファイル転送製品。2020-12〜2021-01 に 0-day が波状的に悪用され、ニュージーランド準備銀行・豪 ASIC・Singtel などが被害。

肝は、Accellion が3年前から「FTA をやめて Kiteworks へ移れ」と言い続けていたこと。事件後に EOL を 2021-04-30 へ前倒しして打ち切った。仮説3(支援は直近3版のみ)の極限形で、版が新しいかではなく、製品そのものが終わりかけていたかが生死を分けた。台帳に持つべき最重要フィールドがバージョンでなく EOL 日である理由がこれ。

③ パッチが無い期間、残る手は隔離だけ — Ivanti Connect Secure (2024)

VPN 装置の認証バイパス (CVE-2023-46805 ほか)。CISA は 2024-01-19 に緊急指令 ED 24-01 を発出、補足指示で連邦機関に「2024-02-02 23:59 までに全インスタンスをネットワークから切り離せ」と命じた。パッチを当てろ、ではない。

ベンダが直すまでの間に利用側へ残る手が構造側(遮断・分離)しかないことを、規制当局の指令という形で示した例。上の経路③(アーキテクチャ隔離)がセキュリティ運用でも同じく最後の砦になる。

④ どの COTS に入っているか誰も知らない — Log4Shell (2021)

CVE-2021-44228。「直せない」以前に、自社が使う COTS 製品のどれに Log4j が含まれるのか特定できなかった。CISA が cisagov/log4j-affected-db をコミュニティソースで立ち上げ、ベンダ製品ごとの影響有無を集約する事態になった(初期で500製品超)。

深刻なのは、ベンダ自身が自社製品への同梱を把握していないケースが多発したこと。SBOM が一気に本気の議題になったのはここが起点。インベントリは「面倒だがやればできる作業」ではなく、やらないと事故時に手が打てない前提条件だと確定した。

⑤ COTS の中の COTS — URGENT/11 (2019)

Armis が VxWorks の TCP/IP スタック IPnet に11件の 0-day(うち6件が critical)を発見。2億台超の機器が影響下と推計。

構造が重要で、IPnet は Wind River が 2006年に Interpeak 社を買収して取得したもので、脆弱性の一部は買収前から存在していた。Interpeak は同じスタックを他社にもライセンスしていたため、Green Hills INTEGRITY(DO-178B Level A 認証取得の安全臨界 RTOS)、ThreadX、Nucleus、OSE、ITRON、ZebOS まで横断的に波及した。

認証を取った製品の内部に、認証と無関係な出自の COTS 部品が埋まっていた。soup の「責任範囲は依存物まで及ぶ」が事故として顕在化した形で、SOUP の同定義務が名称・製造元・版まで求める理由がここにある。

⑥ パッチ経路そのものが攻撃経路になる — SolarWinds Orion (2020)

ベンダのビルドシステムが侵害され、正規署名された更新に SUNBURST バックドアが混入。約18,000顧客が汚染された更新を受け取った。

唯一、「更新を適用せよ」という COTS 管理の基本動作が攻撃面になった型。ゆえに現在は更新適用だけでなくベンダ側のビルド完全性(署名検証、SLSA、再現ビルド)までが評価対象に入る。

運用の型 — 何を台帳に持ち、どこまで洗うか

上の6例が要求するものを運用に落とすと、こうなる。全数を同じ深さで見ようとすると破綻するので、深さのほうを変える。

発見は人に聞かず、既存のログから引く(棚卸しの最大のコストは発見であって記録ではない):

深さは3層に分ける:

Tier 1 は通常どの組織でも数十本に収まる。全数調査に見える作業の大半は Tier 2/3 で、そこは自動監視に流して終わり。

一度きりにする — 調達ゲート(新規購入時の台帳登録を必須化)を先に作れば洗い直しは既存分の一回で済む。ゲートが無いまま棚卸しすると毎年同じ作業が再発する。クラウド移行やリプレースのような「何を移すか決める」強制イベントに相乗りするのが最も安い。

買うか作るか — 判断軸

押さえどころ

• COTS → 商用市場で相当量売られ、無改変で同じ形で提供される既製品。改変すれば MOTS
• 無改変にこだわる理由 → 市場の使用実績を自分の論拠にできるのは、他の全員と同じ物を使っている場合だけ
• 語の射程 → ソフト専用ではない。FAR では物品全般(民生 FPGA・サーバ・スイッチ等)を含む
• shadow IT との違い → COTS は出自の軸、shadow IT は統制の軸で直交する。実務上重なるだけで、包含関係はない。Log4Shell の在庫不明は正規調達の COTS で起きた
• COTS 化の起点 → 1994年の Perry memo と FASA。動機はコストと、「技術の先端が組織の外に移った」という逆転
• グルーコード → 総工数の半分未満だが1行あたり約3倍。買っても開発は消えず、統合へ移るだけ
• 部品数 → 統合工数は n(n−1)/2 の界面に引きずられ二乗に近づく。「4個でも多すぎることがある」
• 安全臨界での扱い → 禁止ではなく正当化義務。追加検証 / 運用実績 / アーキテクチャ隔離の3経路
• 現代形 → OSS と SaaS。構図は同じで、追従サイクルの速さと攻撃対象性が強まった
• COTS 固有の失敗 → 「脆弱性があった」ではなく「自分の手が届かない」。MOVEit=直せない / Accellion=EOL / Ivanti=隔離しか残らない / Log4Shell=在庫が不明 / URGENT/11=COTS の中の COTS / SolarWinds=更新経路が攻撃経路
• 台帳の最重要フィールド → バージョンではなく EOL 日。切れた瞬間にパッチ経路そのものが消える
• 棚卸しのコツ → 全数を同じ深さで見ない。発見は既存ログ(調達DB・SSO・経費精算・EDR)から引き、深さを Tier で変え、調達ゲートで一度きりにする

制限

• Top 10 List の数字は2001年時点の、著者自身が「仮説」と明記したもの。母数20件の COCOTS データベースに基づき標準偏差も大きい。厳密な予測値ではなく桁の感覚と論点の所在として使う
• 事故事例の被害規模(MOVEit の 8,000組織、URGENT/11 の2億台、SolarWinds の18,000顧客)はいずれも当局・調査会社の推計であり、確定値ではない。型の理解に使い、数字の精度には寄りかからない
• FAR の定義は米連邦調達の文脈のもの。日本の調達実務や一般的な業界用法では「COTS = 市販パッケージ」程度に緩く使われることが多く、無改変要件まで含意しないことがある

Links

• FAR 2.101 Definitions (Acquisition.GOV)
• Basili & Boehm, “COTS-Based Systems Top 10 List”, IEEE Computer, May 2001 (PDF)
• Boehm & Abts, “COTS integration: plug and pray?”, IEEE Computer 32(1), 1999
• Garlan et al., “Architectural Mismatch: Why Reuse Is So Hard”, IEEE Software, Nov 1995
• “Specifications & Standards — A New Way of Doing Business” (Perry memo, 1994-06-29)
• SQLite TH3 — 100% MC/DC と DO-178B
• CISA AA23-158A — Cl0p による MOVEit (CVE-2023-34362) 悪用
• Accellion、旧 FTA 製品の EOL を発表 (2021-04-30)
• CISA ED 24-01 補足指示 — Ivanti 製品の切断命令
• cisagov/log4j-affected-db — 影響製品のコミュニティ集約リスト
• Armis URGENT/11 — VxWorks IPnet の11件の 0-day

関連

• soup — 同じ対象を医療規格の側から見た呼び名。COTS は調達側、SOUP は安全側の語彙
• do-178c — §12 が COTS / PDS の扱いを規定。運用実績による認証クレジットの出所
• iec-62304 — SOUP のアノマリリスト評価。現代の SBOM/CVE トリアージの先取り
• iso-26262 — qualification / SEooC。汎用部品を後から文脈に適合させる作り方
• safety-critical-certification — 「ランタイム未認証」= 実行系を COTS として正当化する負担
• accepted-safety-in-systems — 責任範囲は依存物まで及ぶ / 安全はアーキテクチャで作る
• ferrocene — ベンダ側が正当化エビデンスを先回りして作る実例(rustc)
• lock-in — 出口コスト。COTS 採用の見積りから抜け落ちやすい費目
• wasmtime — 実務上の典型的な COTS/SOUP。使う側に正当化義務が残る