cdxgenの内蔵Node.js問題：SBOMを作る道具の配布物を照合する

01

部品表を作る道具にも、部品がある

SBOMはSoftware Bill of Materialsの略で、ソフトウェアに含まれる部品とその関係を記す部品表である。CycloneDXは、ライブラリの名称、版、依存関係などを機械で読める形にする。その記録を脆弱性管理や調達へ結び付けるには、何を対象に、いつ作った部品表なのかが必要になる。 [S9]

今回の焦点は、調査対象のソフトウェアではなく、その部品表を生成するcdxgen自身にある。同じ名称の道具でも、ソースやパッケージを手元のランタイムで動かす形と、ランタイムごと受け取る形では、更新する場所が異なる。安全性を調べる工程に置いた道具だからといって、その道具の実行環境まで自動的に安全になるわけではない。

これは、部品表の価値を否定する話ではない。製品の外箱と内容の対応を問い直す材料になる。アプリケーションの版だけを見る表では、その内側のランタイムが隠れる。一方、ランタイムだけを見る表では、それを含む配布物やビルドを特定できない。両者を一行で結べるかが、今回の比較の出発点である。

企業にとっては、開発者が使う補助ツールの問題でも、納品や審査に影響する可能性がある。顧客へ提出する部品表を作る工程が止まれば、製品そのものに欠陥がなくても、説明資料がそろわない。その可能性を、実際の停止件数や被害額が判明したかのように読むべきではない。影響は各社の工程と代替手段に依存する。

02

まず配布形態を一つ選ぶ

図1では、公式勧告の配布区分を、利用者が探す資料へ対応させた。製品名が同じでも、導入方法が異なる行を一つにまとめると、ある担当者の回答が別の利用を説明するように見えてしまう。まず自分の行を選び、その行へ資料を集めると比較しやすい。

手元の資料に「cdxgen更新済み」とだけあれば、まず配布元、形式、識別子の欄を補う。単体実行ファイルなら、そのファイルに対応する配布版を選ぶ。コンテナなら、稼働に使ったイメージの識別子を記す。npm版なら、それを起動したNode.jsの記録を探す。これは製品名で一括回答する質問を、答えられる単位へ小さくする作業である。

コンテナ内にNode.jsがある場合、管理者の端末で表示したNode.jsの版は、そのイメージの説明にならない。逆に、npm版の実行環境を調べる際に、別の単体バイナリの部品表を添えても対応は結べない。資料が正しくても、対象がずれていれば判断は進まない。図1の各行は、同じ組織の中にも併存し得る。

共有の開発基盤を使う会社では、一つのチームの回答を全社へ広げる前に、残る配布形態を尋ねるとよい。個人端末の道具、継続的インテグレーションのジョブ、外部委託先のサービスは別々に残り得る。ただし、存在を推測して全件を危険扱いする必要はない。実際の利用記録から行を増やす方が、対応範囲を説明しやすい。

03

12.8.8では、何が食い違ったのか

図3は、原典が示す版の対応を読む場所である。冒頭の訂正理由と合わせると、ビルドのどこへ目を向けるかが分かる。

この具体例から読み取れるのは、設定ファイルを変更した数では、出来上がる内容を判断できないという点である。どの設定をどのビルドが使うかという関係が決め手になる。複数のファイルに正しい値が書かれていても、その実行経路が別の値を読めば、配布物へ届くのは後者である。

図3の訂正後の行は、公式に公開されたリリース資料へつながる。ただし、ビルドの成功、配布物の存在、利用側の選択は別々の出来事である。ある形式の成果物が存在することから、同じ番号の別形式も同じように配布されたと推測しない方がよい。

ここで必要な問いは、不備を起こした人の推測ではなく、回答する資料の選び方である。変更提案は意図を、ビルド記録は処理を、配布物の部品表は記録された内容を示す。それぞれの資料が同じ成果物へつながると、修正説明を使う理由が具体的になる。別の成果物の成功を示す記録を混ぜると、その関係が失われる。

04

検査対象のファイルが、外部の応答へつながる

図2の各行は、手元の構成に対応するかを選ぶために使える。設定資料と入力元の説明を合わせ、該当する行と、使わない行を区別しておく。どちらかが不明なら、その理由をメモに残す。

リポジトリは、ファイルを置く場所というだけでなく、道具が次にどこへ接続するかを記述する入力にもなり得る。外向きの通信であれば相手を信頼できるという考え方では、この関係を捉えにくい。接続を始めた側と、返される内容を決める側は同じではないからだ。

通常の業務に置き換えると、資料に書かれた参照先を確認する工程に近い。ただし、ファイル名がロックファイルであることから、通信内容まで固定されているとは推定できない。比較するべきなのは、ファイルの名前の安心感ではなく、参照先と応答を制御する相手、そして受け取ったデータを処理する部品である。

図2を使う際には、一行ずつ資料を対応させる。矢印に沿って入力元と処理を読めれば、必要な欄が欠けている場所も見つけられる。ある行を使わないという回答を別の行へ流用せず、それぞれに根拠を添えると、後から構成が変わった時にも読み直しやすい。

05

Brotliの欠陥を、実際の処理条件へ戻す

Brotliは圧縮形式とその実装に関わる名前である。Googleの1.2.1リリースはCVE-2026-111497の境界外アクセスを修正したと記す。Node.jsは、この欠陥が細工された入力によるメモリ破損を起こし、停止、情報開示、条件によってはコード実行につながり得ると説明する。 [S5] [S4]

圧縮された本文を受け取ること自体は、ウェブ通信で珍しい特別操作ではない。そのため、利用者が直接Brotliという機能を選んだ記憶がないことは、判断材料として弱い。高水準の通信機能の内側で展開される場合には、アプリケーション側の名前だけを調べても、処理する部品まで届かない。

一方、欠陥のある部品が入っているという記録だけで、任意の攻撃が成功するわけでもない。未信頼データがそこへ届くか、どの処理が有効か、実行する権限や環境は何かによって結果が変わる。影響の説明には、部品の存在と、入力の到達と、起き得る結果という異なる材料が含まれる。

企業の対応範囲を決める人には、これらを一つの危険点数にまとめるより、未回答の欄を見つける方が有用だ。部品の版が分かるのに利用経路が不明なら、経路を担当者へ尋ねる。入力経路が明らかなのに配布物が特定できないなら、実行物の識別を先に補う。調べる順番を変えることで、広すぎる一斉調査を避けられる場合がある。

06

ホスト更新で答えられる範囲

Node.jsの10月21日付セキュリティリリースは、22、24、26の系列に修正版を用意し、22.23.4、24.22.1、26.12.1を示している。これらはNode.jsの版番号であり、cdxgenの版番号ではない。同じ「24」という数字を、配布物の名前へそのまま移してはいけない。 [S4]

npm版のようにホストのランタイムを使う場合、アプリケーションの導入履歴と、起動時に選ばれたランタイムの記録を結ぶと質問が絞れる。開発者が普段使う既定値と、ジョブが指定した値が異なる運用も考えられる。実際の起動設定を説明できる記録があるかを確かめることが、単なる端末の版一覧より役に立つ。

同じホスト上に複数の版が存在する場合、最新の一つがあることだけでは、すべての利用がそれを選んだことにならない。逆に、古い版が保存されているだけなら、直ちに実行中とも言えない。保管されているもの、参照されるもの、実際に起動したものを、同じ欄へ詰めない方が説明は短くなる。

Webアプリケーションが別の実行環境を使う問題は、PHPの修正版とWeb実行環境の対応を確かめるでも扱った。今回の表では、その一般論をさらに広げず、cdxgenがどの配布形態で動くかに適用する。ホストの回答で足りる行と、成果物の内側を問う行を最初に分ければ、担当者へ必要以上の証明を求めずに済む。

07

単体実行ファイルでは、外側と内側を並べる

単体実行ファイルの便利さは、利用者が別にランタイムを整える負担を減らせる点にある。その代わり、ランタイムの選択は配布物を作る側へ移る。利用者は、ホストでNode.jsを更新したという説明だけで、その実行ファイルの内部が変わったと判断できない。便利な包装が、確認する資料の場所も変えるのである。

図3では、外側の版と内側の版を二つの列にした。上下の順序はリリースの関係を示し、版番号の差を数量として比べるグラフではない。アプリケーション番号とランタイム番号が同じ歩幅で増えるという前提を捨てると、食い違いを読み取りやすくなる。

手元の部品表を読む際には、それが検査対象の製品を説明するのか、道具自身を説明するのかを先に確かめる。似た形式のファイルが二つあっても、対象は異なり得る。

この照合で一行が埋まったとしても、保管庫にある別の実行ファイルまで自動的に説明できるわけではない。利用のあるコピーを単位にする。ただし、使っていない過去の配布物をすべて同じ緊急度で扱うことも、業務上の優先順位を曖昧にする。どこで選択されるコピーかという問いを添えると、保管と利用の違いを保てる。

08

コンテナでは、タグと稼働物の間に空欄を残さない

コンテナの比較には、イメージを指定した記録と、実際の配備を説明する記録が必要になる。タグの文字列だけを手元に残すと、その文字列がどの時点の内容を指したかが曖昧になる場合がある。既存の配備記録にイメージの識別子があれば、それを図1の該当行へ移すと、提供側の説明との対応が取りやすい。

この行を作る目的は、供給元の説明を一律に疑うことではない。提供側が新しいイメージを用意したことと、利用側がそれを選んだことは、別の工程だからである。どちらも必要だが、同じ担当者が答えるとは限らない。提供された版、選んだイメージ、実際の配備という範囲を明記した質問なら、回答を結びやすい。

図3の公開リリースの説明は、提供側の比較に使える。しかし、それを引用した回答だけでは、個々の企業の稼働イメージや、派生イメージの内容まで分からない。利用者が自分のコピーを選ぶ資料があって初めて、その説明を自社の行へ結び付けられる。

独自の基底イメージや追加の部品を使う会社では、上流のリリース説明と自社の成果物の間にもう一段の関係が加わる。そこで何が変更されたかは、自社のビルド記録の役割になる。上流の説明を転記して行を閉じるより、その間を結ぶ資料があるかを問う方が、次の更新でも同じ表を使いやすい。

09

Bunの実行ファイルが示す、別の包装の問題

Bunの公式勧告は、1.4.4を修正版とし、compileで作られた実行ファイルにはランタイムが含まれるため、古い実行ファイルには再ビルドが必要と説明する。また、Bunに対する攻撃の成立は試験していないと明記している。可能な影響と、製品上で実証した結果を混ぜない読み方が要る。 [S6]

これは、cdxgenの修正番号をすべての環境へ当てはめられない理由にもなる。ランタイムを含むという共通点があっても、ビルド方法、配布物の名前、管理する主体は異なる。Node.jsの修正番号、Bunの修正番号、アプリケーションの修正番号を、同じ版の欄に並べると比較の軸が崩れる。

利用者が自社のアプリケーションを単体ファイルとして配る場合には、道具を更新した日と、出力物を作った日を分けて記すとよい。新しいビルド環境を用意しただけで、以前に作ったファイルの内部が変化するわけではない。成果物ごとの記録があれば、まだ作り直していないものを具体的に尋ねられる。

一方、ここからすべての単体ファイルが影響を受けると一般化してはいけない。どのランタイムを含むか、どの版で作られたか、問題の処理を使うかが必要である。Bunの例は、形式の違いを説明する比較対象であり、cdxgen以外の全ソフトウェアを一つの対象群にまとめるための材料ではない。

10

同じ欠陥でも、製品ごとに確認条件が違う

Envoyの公式勧告は、Brotli decompressorを設定した配備を条件に挙げる。PyPAの記録では、Python向けBrotliパッケージの修正版を1.2.1とする。同じ共有実装の欠陥を扱っていても、プロキシの設定、言語のパッケージ、埋め込まれたランタイムは同じ単位ではない。 [S7] [S8]

図4は、部品から上へたどる際に、途中で何を取り違えやすいかを示す。ライブラリの修正版を見つけても、その番号がランタイム全体の番号と一致する必要はない。言語のパッケージが修正されても、それを含むすべてのイメージが自動的に再構築されるわけではない。別々の名前を残した表の方が、むしろ読み間違いを減らせる。

この違いは、複数の供給元へ同じ質問票を送る企業に関係する。共通して尋ねるべきなのは、対象物、含まれる部品、入力条件、根拠資料である。その中の製品固有の欄まで同じ番号や同じ操作名で埋める必要はない。回答の書式をそろえることと、技術的な対処を一律にすることは別である。

DNSを扱うBINDの処理経路と業務依存を照合するのように、特定のプロトコルや機能が前提になる問題もある。今回の比較では、圧縮データがどの実装へ渡るかという点を固定する。製品名を増やすほど網羅的に見えるが、対象と条件の対応が薄れれば、読者の確認作業はかえって難しくなる。

11

部品表の対象を、冒頭に書く

SBOMを受け取る側は、ファイルがあることより先に、その対象を読む必要がある。顧客向け製品、製品を作る工程、部品表を作る道具は、関連していても同一ではない。今回の問題では、最後の道具の内容が問いになる。製品の立派な部品表だけで、その生成環境まで説明できるとは限らない。

図5の照合表では、資料名の隣に「何を説明するか」を置いた。実行ファイルの配布物を示す資料、入力条件を示す設定、実行に選ばれたコピーを示す記録を、役割ごとに対応させる。ある資料で分からないことを別の資料へ引き継ぐための表であり、一つの欄が埋まれば安全を認定する採点表ではない。

この配置は、部品表の数を増やすことを目的にしていない。同じ対象について二つの記録が食い違った場合に、その違いを説明しやすくする。版の記載が異なるなら対象時点を、対象が異なるなら成果物名を、範囲が異なるなら含まれない部品を尋ねる。資料を追加する前に、既存資料の意味をそろえられる場合もある。

道具が生成した記録にも、対象を読み取る仕事が残る。ファイル名だけでは対応が分からなければ、作成時点や範囲を記した欄を読むとよい。自動化で集まる資料が増えるほど、この短い対応付けが、同じ名前の別の対象を混ぜない助けになる。

12

圧縮形式の指定と、通信の暗号化は別の層

HTTPのContent-Encodingは、本文に施した符号化と、それを元の内容へ戻す処理を示す。Accept-Encodingは、受け手が受け入れる形式を伝える側の指定である。Node.jsの文書も、要求と応答の圧縮を説明する際に、この二つの役割を分けている。名前が似ていても、相手へ希望を伝えることと、届いた本文を処理することは同じではない。 [S11] [S12]

そのため、通信先の一覧だけを見ても、展開処理に入る内容までは分からない。通信を始める前の設定と、応答を受けた後の処理の間に、もう一つの判断がある。自社の既存設計を読む人は、送信ヘッダーの欄だけで終わらず、応答の処理を説明する欄を探すと、この空白を見つけやすい。

HTTPSによる通信の保護と、受け取った圧縮データを正しく処理できることも、役割が異なる。接続先との通信が保護されても、その接続先が返す内容に対する処理の欠陥まで消えるわけではない。暗号化の利用を答える資料は有用だが、圧縮展開の修正版を示す資料の代わりにはならない。

Node.jsの同じ更新資料には、証明書に関する変更も含まれる。信頼関係の移行はeMudhraの証明書移行を接続ごとに確認するで読むことができるが、今回のBrotliの問いは、圧縮された内容を処理する実装に向く。証明書の有効性を点検した回答を、そのまま圧縮処理の更新済みという回答へ移さないことが、同じ文書の読み違いを防ぐ。

13

認証前の処理は、画面のログインだけでは分からない

要求を受けてから利用者を認めるまでに、サービスは何らかの処理を行う。認証の後に業務機能を動かす設計でも、本文を読む処理がその前に置かれていれば、その部分は別に考える必要がある。今回の勧告が挙げる順序の問題は、ログイン機能の有無という質問だけでは捉えられない。

これは、認証を無意味とする話ではない。誰にどの機能を使わせるかという制御と、その判断に届くまでにどのデータを処理するかは、別の設計上の問いである。既存の構成図で本文展開の場所が分かれば、認証の境界との位置関係を確認できる。場所が描かれていなければ、そこを質問として残せる。

前段にプロキシやゲートウェイがある場合も、その名称だけでは順序は決まらない。圧縮された本文がどこまでそのまま届くか、前段と後段でどの処理を行うかという構成が必要になる。図6の条件分岐は、この関係を既存資料から分類するためのものだ。実際のサービスへ試験要求を送る手順ではない。

外部へ公開していないサービスでも、利用者や接続経路が限定されていることを資料で示せば、その範囲を評価に使える。ただし、限定された相手から来る入力をすべて同じ信頼度に置くかは、利用形態による。自動ジョブや別チームの処理が接続するなら、その入力元を具体名で記す方が、社内という一語より情報が多い。

14

既存資料を使う、小さな照合例

架空の会社が、開発端末ではnpm版、定期ジョブではコンテナ、社内の補助作業では単体ファイルを使うとする。この例は実在企業の構成や被害を示さない。まず三行を作り、同じ「cdxgen」という欄を、導入方法ごとに分ける。それぞれの入力元も、社内だけ、外部も含む、不明という既存の説明から選ぶ。

次に、端末の行には起動時のNode.js記録、コンテナの行には配備イメージとその部品表、単体ファイルの行には対応するリリース資料を置く。三つの行へ一つのNode.js更新通知をコピーして埋めない。ホストと成果物内部のどちらを説明した通知なのかを、行ごとに記せばよい。

例えば、コンテナの部品表が保管されていても、どのジョブがそれを使うかが不明なら、その行は対応付けが未完になる。逆にジョブの識別子があっても、内部のランタイムが分からなければ、内容の欄が空く。異なる空欄を一つの未対応という言葉へまとめずに残すと、担当者が答える質問が具体化する。

ここで得られる成果は、危険の自動判定ではなく、利用する配布物と不足資料の一覧である。入力値をSG Groupへ送る必要はなく、表を手元の記録へ転記して使える。新しい部品表の生成、プログラムの実行、修正作業そのものをこの表が代行するわけではない。実際の更新は、各組織が許可した手順に従う。

15

真正な配布物でも、内容の問いは残る

配布物が正規の供給元から来たかという問いと、その中に必要な修正が含まれるかという問いは、どちらも大切だが同一ではない。図3は後者を考える材料になる。由来を調べる資料と内容を示す資料を並べると、一方の回答をもう一方へ移す誤読を減らせる。

配布済みソフトウェアの来歴はGitLabの配布物の来歴と説明資料を読むで整理した。今回の比較表は、その確認が済んだ後にも使える。正しい供給元と正しい名前のファイルがあるとして、その中に記録されたランタイムを問う。一方の資料を集めれば他方の問いまで自動的に閉じるという構成にはしていない。

この区別は、供給元が誤りを開示した際の読み方にも関係する。訂正の説明が具体的なら、利用者は影響する配布物を絞り、どの資料を読み直すかを決められる。曖昧な安心表現を増やすより、食い違った設定と成果物を示す方が、受け手にとって作業可能な情報になる。

ただし、訂正が詳しいこと自体から、他のすべての版や機能に問題がないとも言えない。この例を、供給元全体の品質ランキングへ飛躍させる根拠はない。利用者が得られるのは、この欠陥、この配布形態、この修正版についての比較であり、製品の将来を一括採点する結果ではない。

16

開発工程へ届く費用を、製品売上と混ぜない

SG Groupの見方では、今回の経済上の接点は、部品表を提出する工程が製品の供給と結び付いている点にある。道具の交換だけで済む会社と、固定したイメージから再ビルドし、出力の差を確かめる会社では、必要な作業が異なる。会社の規模より、どの形で道具を工程へ組み込んだかが先に効く。

作業負担を見積もる場合は、配布物を取り換える作業、ビルドをやり直す作業、部品表の内容の差を読む作業を分けられる。これは新たな市場規模の推計ではない。自社が既に持つ作業記録へ、今回の変更で必要になった部分を対応させる考え方である。作業が既存の定期更新へ収まれば、追加負担は小さくなり得る。

反対に、利用する形式が多く、担当者が別々なら、同じニュースでも影響が広がる可能性がある。ここから特定のセキュリティ企業の売上増を直ちに推定することはできない。社内作業で吸収するのか、既存契約の範囲か、新たな外部支出が生じるのかという条件が、企業間で異なるからである。

世界のソフトウェア供給網では、同じ公開部品が複数の製品へ入る。この共有は開発の重複を減らす一方、修正の問いが複数の包装へ同時に届く要因になる。今回の資料は、その伝わり方の具体例である。広い株式指数や当日の相場変動の原因を、この一件だけで説明する材料ではない。

17

出力の差を読むときは、内容と機能を分ける

道具の更新後に部品表が変わったとしても、その差がすべて新たな脆弱性の発見を意味するわけではない。収集する情報、部品の表し方、対象とする範囲が変われば、出力も変わる。更新前後の部品表を比べる際には、同じ対象を同じ条件で処理したかという前提が要る。

13.5.0のリリース説明は、ランタイムの更新に加え、複数の収集・記録機能の変更も含む。したがって、版を上げた後のファイルの差を、そのまま検査対象のソフトウェアが変化した証拠にしてはいけない。道具の機能変更と対象物の変更を対応させると、差分の意味を読みやすくなる。 [S3]

例えば、以前の出力にはなかった項目が現れた場合、対象物へ新しく入ったのか、以前は記録していなかったのかを尋ねる。部品の名前が変わった場合も、実際の交換か、表現方法の変更かを確かめる。こうした質問は、出力を大きくした方が優れているという単純な評価を避ける助けになる。

修正の確認と出力品質の比較は関係するが、片方だけで十分とは限らない。必要な修正を含む配布物を選ぶ作業と、顧客が必要とする情報を引き続き出せるかを確かめる作業を、同じビルドへ結び付ける。特定の版への移行を、どの企業にも同じ手順で勧めるための比較ではない。

18

評価を変える三つの条件

第一の条件は、使う配布形態が明らかになり、その内蔵または起動時のランタイムが対応する資料で説明されることである。これがそろえば、製品名しか分からない状態から一歩進む。資料の対象が違うと判明した場合には、結論を変えるより先に、照合する行を直す必要がある。

第二の条件は、未信頼入力が問題の処理へ届くかという構成である。既存の設定や設計から特定の経路が使われないと示せれば、その経路の懸念は狭められる。別の経路が残るなら、それは別に評価する。経路の一つを閉じることを、共有部品の修正そのものと同じ結果にしない。

第三の条件は、修正を含む成果物が実際に選択され、必要な出力を引き続き得られることである。供給元の公開だけで利用側の状態まで変わらない一方、利用側が対象のコピーと記録を示せれば、一般的な懸念をいつまでも広げる理由も弱まる。追加の情報は、判断を強める方向だけでなく、範囲を狭める方向にも使える。

これらの条件を見ても、攻撃の発生率や企業損失の期待値は計算できない。分母となる利用数や個々の入力条件がそろっていないからである。図6は、何が分かれば次の欄へ進むかを示す分岐であり、危険を数値化する装置ではない。読者は自社の資料にある条件だけを選び、残る問いを具体名で残せる。

19

何を追加で待つべきか

公開資料を読む限り、今回の欠陥から、特定企業で侵入が起きたという結論は導けない。Bunのように製品上の攻撃試験の限界を明示した資料もある。今後、実際の被害や特定の実行条件に関する一次資料が出れば、可能な影響の説明と照合する材料になる。単に関連する記事が増えることとは違う。

決まった日程の追加公表や、被害統計の発表はここで予定されているわけではない。次に判断を変えるものは、内蔵部品の訂正、入力経路の説明、実際の配備との対応、製品固有の攻撃成立に関する証拠である。これらのどれが変わったかを記録すれば、見出しの新しさに引きずられにくくなる。

20

部品表を扱う企業への、限定した意味

この問題を受けて、SBOMの利用自体を止めれば安全になるという結論は短絡的である。部品情報を失えば、別の欠陥への対応が難しくなる可能性がある。一方で、道具の名前を信頼するだけで工程を無条件に続ける理由にもならない。配布形態と入力条件を把握すると、選べる対応の範囲を具体化できる。

個々のチームには、顧客から受け取ったリポジトリと、自社だけで管理するリポジトリの違いを、既存の運用へ反映する余地がある。これは外部のコードをすべて拒むという提案ではない。何を入力として扱い、どの通信を伴うかが見えると、許可された環境と手順を選ぶ判断がしやすくなる。

業務の継続を考えると、部品表の作成頻度、使う形式、提出先が求める範囲が重要になる。頻繁な生成を自動化している会社は、共有イメージの選択が複数のジョブへ影響し得る。手作業中心の会社は、担当者がどの実行ファイルを使うかが先に問われる。規模の大小で同じ手順を割り当てるより、包装の違いから始める方が実態に近い。

21

SG Groupの見方：版の列を二つにする価値

SG Groupは、この具体例を、道具自身の配布形態と入力条件を結ぶ問題として見る。部品表を作る工程が何を受け取り、どの実装で処理するかを合わせると、一般的な製品名の一覧より、確認する対象が小さくなる。

読者が持ち帰れる作業は、配布物の版とランタイムの版を別の列にし、資料がどちらを説明するかを対応させることである。本文の表は、その対象を絞るために使える。外側が新しいという回答と、内側の記録がそろう回答の違いを、具体的な成果物の行で確かめられる。