---
title: コミュニティインシデント対応ガイドライン
weight: 102
default_lang_commit: 1f686d5f7b6bbdfaa30dafdc6ca0214c6f2308db
---

セキュリティ上の脆弱性は、迅速に、そして場合によっては非公開で対応する必要があります。
このプロセスの主な目的は、既知の攻撃手法に対してユーザーが脆弱な状態にある総時間を減らすことです。

関連する OpenTelemetry リポジトリのメンテナーは、セキュリティ SIG および OpenTelemetry Technical Committee (TC) の支援のもと、内部コミュニケーションと外部への開示を含むインシデント対応に責任を負います。

## セキュリティモデル {#security-model}

<!--
    This section is mirrored from the authoritative source at:
    https://github.com/open-telemetry/sig-security/blob/main/security-response.md#security-model

    Any changes should be made there first, then synced back here.
-->

セキュリティ修正の緊急性と重要性を評価する際、すべての OpenTelemetry ソフトウェア成果物において、機密性と完全性が最も重要な関心事です。

一方で、OpenTelemetry ソフトウェア成果物のデフォルト設定が可用性攻撃に対して安全であるとはみなしていません。
実現可能な場合は、安全でないデフォルト設定を使用しないことを強く推奨します。
可用性を確保するために、ユーザーは[ウェブサイトのセキュリティセクション](/docs/security/)のガイダンスに従って、エンドポイント通信に認証を要求する必要があります。

さらに、OpenTelemetry プロジェクトは以下をセキュリティ上の脆弱性とはみなしません。

- 適切に認証されたクライアントによるサービス拒否攻撃
- 適切に認証されたクライアントによるエンドポイントへの可用性関連の攻撃

これらはバグとみなされる可能性があり、ユーザーはバグとして報告できます。
可用性関連の影響を評価する際、メンテナーはそれらのプロジェクトとの互換性を提供するコンポーネントに対する脆弱性を評価するにあたり、他のプロジェクト（例：Prometheus）のセキュリティポリシーや、攻撃が利用するリソース使用量の非対称性の度合いも考慮します。

## サポート対象バージョン {#supported-versions}

OTel プロジェクトは、最新のマイナーバージョンに対してのみコミュニティサポートを提供します。
バグ修正は、次のマイナーバージョンの一部、またはオンデマンドのパッチバージョンとしてリリースされます。
次のバージョンに関係なく、すべてのパッチバージョンは累積的であり、リリース時点の `main` ブランチの状態を反映します。
たとえば、最新バージョンが 0.10.0 の場合、バグ修正は 0.11.0 または 0.10.1 の一部としてリリースされます。

セキュリティ修正は優先的に扱われ、新しいバージョンがリリースされるきっかけとなる可能性があります。
各リポジトリは、独自の補完的なプロセスを確立する権利を有します。
不明な点があれば、セキュリティ SIG が TC と連携して助言を行います。

## 報告プロセス - 脆弱性報告者向け {#reporting-process-for-vulnerability-reporters}

### 報告方法 {#reporting-methods}

脆弱性報告をできるだけ早くメンテナーに届けるために、それぞれの GitHub リポジトリの `Security` タブにある `Report a vulnerability` ボタンの利用を推奨します。
これによって、報告者とメンテナーの間のプライベートな通信チャネルを作成します。

GitHub の報告ワークフローを利用できない、または利用しない強い理由がある場合は、[security@opentelemetry.io](mailto:security@opentelemetry.io) にご連絡ください。脆弱性の報告方法をご案内します。

報告は 3 営業日以内に確認される必要があります。

**GitHub の一般的な公開「Issue」として脆弱性を報告しないでください。**

GitHub の Issue は公開されるため、Issue として脆弱性を報告することは情報の公表にあたります。
誤ってそのように報告してしまった場合、またはそのような報告を見つけた場合は、直ちに `Report a vulnerability` で再報告し、その際に公表されてしまったことを記載してください。
GitHub に Issue の削除を依頼できますが、それだけでは十分な緩和策とはみなされず、脆弱性は公開されたものとして扱われます。

### 非公開の脆弱性 {#non-public-vulnerabilities}

脆弱性が公に知られていない、または未公開であると判断された場合、リポジトリのメンテナーが対応を開始します。
報告者は、修正がリリースされ、秩序ある方法で公開されるまで、脆弱性を非公開に保つ公開猶予（エンバーゴ）期間を遵守するよう求められます。
報告者がセキュリティカンファレンスまたはその他の義務のために、さらに情報を公開する必要がある場合は、修正担当のメンテナーと公開日を調整するよう求められます。
いかなる場合も、メンテナーは修正とリリースのプロセスを迅速に進めるために最善を尽くします。

### 公開されている脆弱性 {#publicly-known-vulnerabilities}

すでに公開されているか、既知の脆弱性で未報告のものを発見した場合は、上記の報告方法を使用して直ちにチームに通知し、チームがパッチ、リリース、およびコミュニケーションのプロセスを開始できるようにしてください。
可能であれば、スコアリングや優先順位付けのため、その脆弱性の現在公開されている悪用に関する情報も含めてください。

## 詳細情報 {#more-information}

詳細については、GitHub の [Security SIG documentation](https://github.com/open-telemetry/sig-security/blob/main/security-response.md) を参照してください。
