OSS脆弱性レポート

顧客から納品物について脆弱性の影響確認を求められたら、ここでOSS脆弱性レポートを作成できます

CVE1、SBOM2、Dependabot3、SCA4ツールの結果について、顧客や取引先から「影響はありますか」「対応状況を教えてください」と聞かれたとき、すぐに最終判断まで出せないことがあります。

このページでは、依存関係ファイルやSBOMをブラウザで読み取り、ブラウザ内で匿名化加工することで、ソースコードを送らずに公開OSS名・versionなど必要最小限の情報だけを使った OSS脆弱性レポート を作成できます。

ソースコード非送信ソースコード全文は不要です。依存関係ファイルやSBOMから、必要な情報だけを抽出します。
送信前確認ありレポートを作成するために送信する情報と、送信しない情報を事前に確認できます。同意した場合だけ送信します。
PDFレポートで社内共有できる顧客回答前の社内確認に使えるPDFレポートを作成します。

OSS脆弱性レポートでは、次を整理します。

  • どの公開OSSとversionが確認されたか。
  • 既知脆弱性候補があるか。
  • 顧客回答前に何を追加確認すべきか。
  • 開発者へ何を確認依頼すべきか。
  • 現時点で断定できない事項は何か。
クイックチェックレポートを作成する準備するファイルを見る送信される情報を確認する

初動整理に役立つクイックチェックレポートを、このページからすぐ作成できます。作成するクイックチェックレポートは、顧客提出前の社内確認、開発者確認、監査準備に使う一次資料です。

クイックチェックレポートを作成して、顧客回答前の社内初動整理をすることができます

顧客からCVE影響確認やOSS脆弱性対応状況の説明を求められたときに必要なことは、アラート一覧を作成することではありません。まず必要なのは、確認済み事項・未確認事項・次に確認すべきことを分けた社内共有資料 です。

依存関係を整理lockfile、manifest、SBOMなどから、公開OSS名とversionを整理します。
公開脆弱性候補を確認加工済みデータを公開脆弱性情報と照合し、既知脆弱性候補を整理します。
確認事項を分離本番利用、該当機能利用、外部到達可能性、更新可否など、御社側で確認すべき事項を明確にします。
PDFで共有営業、開発、セキュリティ担当、責任者、監査担当が同じ資料を見て会話できます。

このクイックチェックレポートは、最終的な「影響なし」証明ではありません。顧客回答・開発者確認・監査準備を始めるための社内初動対応用一次調査資料です。

クイックチェックレポートに含まれる主な内容

初動整理サマリー入力された依存関係の規模、照合対象、脆弱性候補数、確認目安を整理します。
責任者向け初動判断メモ責任者が何を確認すべきかやその判断ポイントを整理します。
顧客向け一次回答案断定しすぎず、確認済み事項と未確認事項を分けた文面のたたき台を作ります。
開発者向け確認事項本番利用、該当機能利用、更新可否など、開発チームに確認すべき項目を整理します。
入力データ概要レポート作成にあたり何を材料にしたかを示します。
公開脆弱性照合結果サマリー公開脆弱性情報との照合で見えた候補と照合できなかった範囲を分けて確認します。
優先確認項目候補数、scope、relationshipをもとに、顧客回答前に確認すべき候補を自動で一次仕分けします。
監査・委託先審査向け記録いつ、何をもとに、どの範囲を確認したかの一次記録を残します。
レポート生成条件とデータ取扱いソースコード非送信、private package匿名化、自動生成レポートであることを明記します。
初動整理の次に詳細レポートで完成する内容詳細レポートで得られる項目がわかります。
クイックチェックレポートのサンプルを見る
クイックチェックレポートの章構成を確認する
  • 表紙
  • 確認目安の読み方
  • 全体サマリー
  • 責任者向け要約
  • 顧客向け一次回答案
  • 開発者向け確認事項
  • 入力データ概要
  • 公開脆弱性照合結果サマリー
  • 優先確認項目
  • 監査・委託先審査向けの記録
  • レポート生成条件とデータ取扱い
  • 免責・注意事項
  • 発行管理用情報

このクイックチェックレポートは、一次資料として自動生成するものです。CVSS詳細、EPSS、KEV、本番影響判断、到達可能性解析、顧客提出用の正式文面は「詳細レポート」、専門家による確認は「エキスパートレビュー」で取り扱います。

サンプルクイックチェックレポートを見る

実際に作成されるクイックチェックレポートの雰囲気を確認できるよう、サンプルを用意しています。レポートの章構成、確認目安、責任者向け要約、顧客向け一次回答案、開発者向け確認事項、監査・委託先審査向けの記録を確認できます。

このサンプルSBOMから、このようなクイックチェックレポートが作成されます。

これはサンプルクイックチェックレポート公開用に用意したCycloneDX形式のサンプルSBOMを入力して作成したものです。サンプルSBOMには、主にOSV_ID表示を確認できるよう、既知の脆弱性情報が多く返るように古い公開npm packageを含めています。実際のクイックチェックレポート作成時は、御社の対象システムから生成したSBOMまたは依存関係ファイルを使ってください。

サンプルSBOMを別タブで開く

このブラウザではPDFをページ内表示できません。 サンプルクイックチェックレポートを別タブで開いて確認してください。

サンプルクイックチェックレポートを別タブで開く サンプルSBOMを別タブで開く もしPDFをページ内表示できない環境でも別タブで確認できます。

クイックチェックレポートを作成するために手元に準備するファイル

クイックチェックレポートを作成するために必要なのはソースコード一式ではありません。対象システムの 依存関係が分かるファイル または SBOM を準備してください。

迷ったら、まずlockfileまたはSBOMを選んでください。

lockfileは、実際に使われるversionが分かりやすい形式です。SBOMは、複数言語・複数componentをまとめて渡しやすいため、脆弱性レポートの入力として扱いやすい形式です。

このうちのいずれかを準備してください
プロジェクト種別準備するファイルの例補足
Node.js / npmpackage-lock.json実際に解決されたpackageとversionを確認しやすい形式です。
Yarn / pnpmyarn.lock, pnpm-lock.yamlフロントエンドやNode.jsサービスの依存関係確認に使います。
Gogo.mod、必要に応じて go.summodule名とversionをもとに確認します。
Pythonrequirements.txt, poetry.lock, Pipfile.lockversionが固定されているlockfileの方が、確認精度が上がります。
Java / Mavenpom.xml直接依存を中心に確認します。推移的依存まで含めたい場合は、SBOMの利用も検討してください。
Rrenv.lock, DESCRIPTIONrenv.lock はversionを確認しやすく、DESCRIPTION は制約が残る場合があります。
SBOMCycloneDX, SPDX複数言語やコンテナ由来のcomponentをまとめたい場合に向いています。
DependabotやSCAツールのアラートが出ている場合

DependabotやSCAツールの画面キャプチャではなく、対象リポジトリのlockfile、manifest、またはSBOMを準備してください。アラート画面は「何が検出されたか」を見るには便利ですが、レポート作成では依存関係データとして扱えるファイルが必要です。

  • GitHubのDependabotアラートを見ている場合: 対象リポジトリの package-lock.jsonyarn.lockgo.modrequirements.txt などを準備します。
  • Snyk、Trivy、Grypeなどを使っている場合: 可能であれば、CycloneDXまたはSPDX形式のSBOMを出力して使います。
  • 複数リポジトリが関係する場合: まず、顧客から確認されたサービス、または本番影響が大きいサービス単位で1つずつ作成してください。
顧客からSBOM提出やCVE回答を求められている場合

顧客からSBOMやCVE回答を求められている場合は、顧客に提出予定のSBOMそのもの、または対象システムの依存関係ファイルを準備してください。

  • SBOMをすでに作成済みの場合: CycloneDX JSON/XML、SPDX JSON/tag-valueなどを使えます。
  • SBOMがまだない場合: 対象アプリケーションのlockfileやmanifestを使ってレポートを作成できます。
  • 顧客が特定CVEを指定している場合: そのCVEに関係しそうなサービスやリポジトリの依存関係ファイルを選んでください。
納品前・保守案件・委託先審査で使う場合

納品前や保守案件では、実際に納品・運用対象となるアプリケーションの依存関係ファイルを準備してください。開発用サンプルや古いbranchのファイルでは、顧客説明の材料として弱くなる場合があります。

  • Webアプリケーション: フロントエンドとバックエンドを分けて作成するか、SBOMでまとめます。
  • 受託開発案件: 納品対象のリポジトリ、または納品buildに対応するlockfileを使います。
  • 監査・委託先審査: いつの時点の依存関係かを、社内で説明できるファイルを選びます。
準備するファイルで迷う場合

次の順で選ぶと、判断しやすくなります。

  1. 本番で使うアプリケーションのlockfile。
  2. 対象サービスのSBOM。
  3. lockfileがない場合は、manifestや依存関係定義ファイル。
  4. 複数ある場合は、顧客から確認されたサービス単位で1つずつ。

versionが不明な形式や、推移的依存を完全に解決できない形式では、レポート内に「追加確認が必要」と表示される場合があります。

クイックチェックレポートを作ると、社内確認を進めやすくなります

OSS脆弱性対応で時間がかかるのは、OSS脆弱性情報を探すことだけではありません。それよりも顧客へ何を答えるか、開発者へ何を確認するか、監査向けに何を記録するかを整理することに時間がかかります。

このクイックチェックレポートは、最終判断ではなく、判断を始めるための共通資料です。

効果 具体的に進めやすくなること
顧客回答の初動が早くなる 何を確認済みで、何を追加確認中と説明すべきかを整理できます。
開発者への確認依頼が具体的になる 対象package、version、scope、relationship、確認事項を渡せます。
監査・委託先審査で説明しやすくなる 検知後にどのように一次整理したかを記録できます。
無責任な断定を避けられる 影響なしと断定できない理由と、次に確認すべき事項を分けられます。

ソースコードを送らずに試せます

依存関係ファイルやSBOMはそもそもソースコード本体ではなくアプリケーションを構成するものの一つですが、技術スタック、利用OSS、version、private package名、private registry URL5、git URL、社内ドメイン、認証情報候補を含む可能性があります。

クイックチェックレポート作成にはソースコード一式を送る必要はありません。依存関係ファイルやSBOMをブラウザで読み取り、クイックチェックレポート作成に必要な情報だけにブラウザ内で加工し、送信前にデータ内容をあなたの目で確認してから安心してクイックチェックレポート作成を指示できます。

クイックチェックレポートおよび作成用データの保存期間

クイックチェックレポートでは、レポート作成のためサーバーへ送信した加工済みSBOM/依存関係データ、公開脆弱性情報との照合結果、生成されたHTML/PDFを、作成から3日を目安に自動削除します。また前項で何度も申し上げているように元のSBOMファイル、lockfile本文、ソースコード全文を生のままで送信・保存する設計ではありません。

送信する情報public package名、version、ecosystem、scope、relationship、送信前確認結果など。
送信しない情報ソースコード、lockfile/SBOM本文、ファイル名、private package実名、URL、secret候補の実値など。
3日で自動削除レポート作成のためサーバーへ送信された加工済みデータ、照合結果、HTML/PDFは、作成から3日を目安に自動削除します。
Google AnalyticsCTAクリックやレポート作成完了などの行動のみを扱います。package名、version、CVE ID、JSON本文は送りません。
送信する情報・送信しない情報を詳しく見る
区分扱い
public package名公開脆弱性情報との照合に使います。
version既知脆弱性候補の照合に使います。version不明の場合は、制約として表示します。
ecosystemnpm、PyPI[^pypi]、Maven、Go、CRAN[^cran]などの分類として使います。
scope / relationshipRuntime / Dev、Direct / Transitiveなどの一次仕分けに使います。
ソースコード送信しません。
lockfile / SBOM本文そのままAPIへ送信しません。ブラウザ内で加工した依存関係データだけを送ります。
ファイル名APIにもGoogle Analyticsにも送りません。
private package名匿名化し、公開脆弱性DB[^db]の照合対象外として扱います。
private registry URL / git URL / VCS[^vcs] URL削除します。
認証情報候補検出時は送信へ進ませません。候補文字列そのものは送りません。
Google Analyticspackage名、version、CVE ID、JSON[^json]本文、private情報は送りません。
送信前加工を確認できるJavaScriptを見る

このページの説明だけを信じる必要はありません。このページにおける送信前加工、匿名化、secret検出、形式判定に関わるJavaScriptを公開しているのであなたの目で確認できます。

確認対象役割
oss-report-sanitize-payload.js送信してよい最小限のpayloadを組み立てる中心処理です。
oss-report-sanitize-redact.jsprivate package名、registry URL、git URL、local pathなどを匿名化または削除します。
oss-report-sanitize-secret-scan.jstokenや認証情報らしき文字列を検出した場合に、送信へ進ませないための処理です。
oss-report-detect-format.js選択されたファイル形式を判定します。
oss-report-format-detectors.js初期読み込みを軽くするため、形式だけを判定します。
oss-report-parser-errors.js形式別の失敗理由を共通化し、表示を分かりやすくします。

クイックチェックレポートを作成する

ここから、OSS脆弱性レポートを作成できます。初動整理用のクイックチェックレポートならすぐ作成できます。

このクイックチェックレポートは、次の目的で利用してください。

  • 顧客からのCVE確認に対する初動整理。
  • 開発者への確認依頼の準備。
  • DependabotやSBOMの脆弱性候補整理。
  • 納品前のOSS脆弱性確認。
  • ISMS6、SOC27、委託先審査に向けた証跡準備。
  • 詳細レポートやエキスパートレビューが必要かどうかの判断。
利用前に確認してください。
  • ソースコード全文送信は不要です。
  • 依存関係ファイルやSBOMは、ブラウザで読み取ってブラウザ内で加工してから送信します。
  • 送信前に、送信される情報と送信しない情報を確認できます。
  • 送信前加工の検証で認証情報らしき文字列が検出された場合は、送信へ進ませません。
  • このクイックチェックレポートは一次調査資料であり、最終的な影響判断ではありません。
  • サーバーへ送信された加工済みデータと生成されたクイックチェックレポートを、作成から3日を目安に自動削除します。
  • クイックチェックレポートにはストラテジアエキスパート担当者による個別確認を含みません。
誰がこのページでクイックチェックレポートを作成すればよいのか

顧客からSBOMやOSS脆弱性への対応状況を求められた営業担当者は、このページの存在と求められていることを開発担当者へ共有してください。このページでの実際のSBOMファイル選択や送信前確認は、対象システムの依存関係ファイルまたはSBOMを取り扱える開発担当者が行うのが安全です。

どのような場面でクイックチェックレポートを使えるか

代表的な利用シーンを見る

顧客からCVEの影響確認が届いた

対象OSSが依存関係上に含まれる可能性、既知脆弱性候補、追加確認事項、顧客向け一次回答案を整理できます。

DependabotやSCAツールのアラートが多い

候補数、依存種別、照合可否をもとに、開発チームへ確認依頼しやすい候補を整理できます。

SBOMを提出する前に脆弱性説明も整理したい

SBOMに含まれるcomponent情報を、顧客説明や社内確認に使いやすい脆弱性レポートへ変換します。

納品前・保守契約中にOSS脆弱性説明が必要になった

納品対象や保守対象の依存関係から、確認すべき論点を整理できます。

ISMS・SOC2・委託先審査の準備

検知後に何を確認し、どこが未確認かを説明する一次記録として使えます。

クイックチェックレポートで分かること・分からないこと

分かることを見る
項目内容
OSS名加工済みデータに含まれる公開OSS名。
version検出されたOSSのversion。
ecosystemnpm、PyPI、Maven、Go、CRANなどの分類。
依存種別Direct / Transitive、Runtime / Devなどの推定。
既知脆弱性候補公開脆弱性情報で返った候補IDと、先頭1件の参照リンク。
優先確認項目候補数、scope、relationshipにもとづく自動一次仕分け。
顧客向け一次回答案最終提出ではない、確認済み事項と未確認事項を分けるための文面。
クイックチェックレポートだけでは分からないことを見る
項目理由
本番環境で実際に使われているか。依存関係ファイルだけでは、実行時の構成を確認できないため。
外部から到達可能か。ネットワーク構成やアプリケーション経路の確認が必要なため。
脆弱な関数や機能を呼び出しているか。ソースコード解析や到達可能性解析が必要なため。
顧客通知義務があるか。契約条件、影響範囲、社内基準の確認が必要なため。
影響なしと最終判断できるか。実装、設定、運用、利用経路の確認が必要なため。

よくある不安

ソースコードを送る必要がありますか

ありません。このページでは、ソースコード全文を送信しません。依存関係ファイルやSBOMをブラウザ内で読み取り、必要最小限の加工済みデータだけを送信する設計です。

依存関係情報だけで意味がありますか

意味はあります。依存関係情報だけでも、公開OSSの名称、version、既知脆弱性候補、顧客回答前の追加確認事項は整理できます。ただし、本番利用有無や外部到達可能性などの最終判断には、追加確認が必要です。

顧客にそのまま提出できますか

このクイックチェックは、顧客提出前の一次調査資料です。顧客へ提出する場合は、御社の責任者が内容を確認し、御社の責任で提出してください。顧客提出向けに整えた文面が必要な場面には詳細レポート、専門家レビューが必要な場面にはエキスパートレビューを準備中です。

ストラテジアのエキスパート担当者がデータやレポートの中身を個別確認しますか

いいえ。現在のレポートでは、ストラテジアエキスパート担当者による個別確認は行いません。このページはオンラインで自動完結するOSS脆弱性レポート作成のためのページです。

Google Analyticsでファイルの中身を取られませんか

取りません。Google Analyticsで収集しているのは客観的なこのページ上の行動データです。ファイル名、package名、version、CVE ID、private package名、URL、社内ドメイン、JSON本文はGoogle Analyticsへ送りません。

よくある質問

このページは何のためのページですか

顧客、取引先、監査人、社内責任者からOSS脆弱性やCVEの影響確認を求められたとき、最初の回答材料を自動で整理するためのページです。依存関係ファイルやSBOMをブラウザ内で加工し、公開OSS名とversionなど必要最小限の情報だけを送信して、脆弱性レポートを作成します。

顧客への一次回答文は作られますか

クイックチェックレポートでは冒頭数行を作成します。最終回答向けではありません。追加確認が必要な事項を含めた、汎用的な一次回答を作成するためのたたき台です。顧客へ断定的に安心させる文面ではなく、確認済み事項と未確認事項を分けて、誠実に初動状況を伝えるための文面は詳細レポートやエキスパートレビューを利用することで入手できます。

DependabotやSnykやTrivyの代わりになりますか

代わりにはなりません。このページの成果物は、脆弱性検出ツールを置き換えるものではありません。Dependabot、Snyk、Trivy、Grype、OSV-Scannerなどで得られた情報やlockfileをもとに、顧客説明と初動整理に使える一次調査資料を作る位置づけです。

private packageはどう扱いますか

private package名は匿名化して扱います。private packageは公開脆弱性DBで照合できないため、レポートでは匿名化されたprivate packageとして件数を表示し、公開OSS照合の対象外であることを示します。

認証情報らしき文字列を検出した場合はどうなりますか

このページのクイックチェックレポート作成では認証情報らしき文字列が検出された場合は、送信へ進ませません。御社側で対象箇所を確認し、必要に応じて削除、修正、ローテーションを行ってから再度利用してください。

requirements.txtでversionを固定していない場合はどうなりますか

照合精度が限定されます。requests>=2.28 や django のように実際のversionが分からない場合は、既知脆弱性の該当有無を正確に判定できないことがあります。その場合は、レポートにversion不明または追加確認が必要であることを表示します。

RのDESCRIPTIONやrenv.lockには対応していますか

対応しています。DESCRIPTIONでは依存関係名と依存制約を取得できますが、実際にインストールされているversionとは限らないため、versionはunknownとして扱います。renv.lockでは固定されたpackage versionを取得できるため、CRAN package名とversionを一次照合に使います。

KEVやEPSSのような悪用状況も見ますか

このクイックチェックレポートでは、KEVやEPSSの値を自動で断定評価しません。悪用状況や悪用可能性まで整理する場合は、追加確認または詳細レポートやエキスパートレビューを利用すると得られます。

CVSSだけで優先度を決めますか

いいえ。このクイックチェックレポートでは、CVSSだけで優先度を断定しません。候補数、依存種別、照合可否をもとに自動で一次仕分けし、CVSS、修正版の有無、悪用状況は追加確認事項として扱います。

クイックチェックレポートはどれくらい保存されますか

クイックチェックレポートは作成のためにサーバーへ送信した加工済み依存関係データ、SBOMから抽出したcomponent情報、公開脆弱性情報との照合結果、生成したPDFは、作成から3日を目安に自動削除されます。保存期間終了後はレポートURLからの再表示や再ダウンロードができません。元のSBOMファイルやソースコード全文は送信されません。自動削除処理の都合により、物理削除には時間差が生じる場合があります。

このFAQで解決しない場合はどうすればよいですか

クイックチェックレポートの範囲で解決できない高度な判断、契約上の通知義務、顧客提出前レビュー、影響なし判断、専門家確認が必要な場合は、詳細レポートやエキスパートレビューの利用を検討してください。

クイックチェックレポートの上位に詳細レポートとエキスパートレビューを現在作成中

このページで作成できるクイックチェックは、顧客回答前の初動整理を目的としています。今後のリリース予定として顧客提出用に文面を整える"詳細レポート"、専門家レビューを付ける"エキスパートレビュー"、継続的に監視する場面向けメニューを現在作成しています。

準備中の"詳細レポート"、"エキスパートレビュー"で強化したい内容を見る

顧客提出用 詳細レポート

一次回答案をもとに、顧客に提出しやすい文面へ整え、確認済み事項、未確認事項、対応予定を分けて記載するサービスとして検討しています。

月次OSS脆弱性監視レポート

単発対応ではなく、継続的に顧客説明・監査証跡を残したい企業向けに検討しています。

Agencyプラン

受託開発会社、Web制作会社、セキュリティ診断会社、情報システム支援会社など、自社顧客向け成果物としてOSS脆弱性レポートを使いたい企業向けに検討しています。

エキスパートレビュー

自動レポートに専門家による確認を組み合わせるエキスパートレビューです。断定してよい表現、避けるべき表現、契約や監査で誤解されやすい表現を確認することを検討しています。

詳細レポートやエキスパートレビューを検討する稟議理由例を見る

顧客からのCVE影響確認に対応するため

顧客からOSS脆弱性およびCVE影響確認を求められており、回答文および社内確認資料の作成が必要です。
手作業での調査・文書作成には開発担当者およびセキュリティ担当者の工数が発生するため、OSS脆弱性レポートを利用し、確認済み事項・未確認事項・対応優先度など、顧客向け回答案の整理を効率化します。

監査・委託先審査の証跡を整備するため

脆弱性検知後の一次確認、未確認事項、対応方針、顧客回答準備の記録を残すことで、ISMS・SOC2・委託先審査等における脆弱性管理の説明資料として活用します。

注意事項

クイックチェックレポートは、このページで入力された加工済みデータおよび公開脆弱性情報に基づくOSS脆弱性の一次調査資料です。

本レポートは、脆弱性診断、侵入テスト、ソースコードレビュー、到達可能性解析、法的判断、契約上の通知義務判断を代替するものではありません。

本レポートは、入力データの完全性、依存関係解決の完全性、公開脆弱性情報の網羅性、実行環境における影響有無を保証するものではありません。

最終的な影響判断、顧客提出、リスク受容、修正方針の確定は、御社の責任で確認してください。

現在のクイックチェックレポートでは、ストラテジアエキスパート担当者による個別確認、専門家レビュー、顧客提出文書としての保証を含みません。

ストラテジアについて

ストラテジアは、中小企業の情報セキュリティ基盤の構築と運用を伴走支援しています。

OSS脆弱性レポートは、情報セキュリティ判断を属人的な作業にせず、企業が顧客・開発者・監査人に説明できる状態を作るための取り組みです。

必要なのは、単にアラートを増やすことではありません。必要なのは、企業が自社の状況を整理し、顧客に誠実に説明し、開発者に具体的に依頼し、監査で説明できる記録を残すことです。

クイックチェックレポートを作成する

  1. Common Vulnerabilities and Exposures の略。公開された既知脆弱性に付与される識別番号です。 ↩︎

  2. Software Bill of Materials の略。ソフトウェアに含まれる部品や依存関係を一覧化した情報です。 ↩︎

  3. GitHubが提供する依存関係更新・脆弱性通知の機能です。リポジトリ内の依存関係をもとに、更新候補や既知脆弱性を知らせます。 ↩︎

  4. Software Composition Analysis の略。OSSなどの依存関係を解析し、脆弱性やライセンス等を確認する手法・ツール群です。 ↩︎

  5. Uniform Resource Locator の略。Web上の場所やリソースを示す文字列です。 ↩︎

  6. Information Security Management System の略。情報セキュリティを継続的に管理する仕組みです。 ↩︎

  7. Service Organization Control 2 の略。主にクラウドサービス等の統制状況を評価する監査報告の枠組みです。 ↩︎