{"meta":{"title":"リポジトリセキュリティアドバイザリを作成するためのベストプラクティス","intro":"セキュリティアドバイザリを作成または編集すると、標準形式を使用してエコシステム、パッケージ名、影響を受けるバージョンを指定する際に、あなたが提供する情報を他のユーザーが容易に理解できるようにすることができます。","product":"セキュリティとコードの品質","breadcrumbs":[{"href":"/ja/code-security","title":"セキュリティとコードの品質"},{"href":"/ja/code-security/tutorials","title":"Tutorials"},{"href":"/ja/code-security/tutorials/fix-reported-vulnerabilities","title":"報告された脆弱性を修正する"},{"href":"/ja/code-security/tutorials/fix-reported-vulnerabilities/write-security-advisories","title":"セキュリティアドバイザリを記述する"}],"documentType":"article"},"body":"# リポジトリセキュリティアドバイザリを作成するためのベストプラクティス\n\nセキュリティアドバイザリを作成または編集すると、標準形式を使用してエコシステム、パッケージ名、影響を受けるバージョンを指定する際に、あなたが提供する情報を他のユーザーが容易に理解できるようにすることができます。\n\n> \\[!NOTE]\n> セキュリティ研究者の場合は、保守担当者に直接連絡して、自分が管理していないリポジトリで自分に代わってセキュリティアドバイザリを作成または CVE を発行するように依頼する必要があります。しかし、リポジトリに対してプライベート脆弱性レポートが有効になっている場合は、脆弱性を自分で\\_個人的に\\_報告できます。詳しくは、「[セキュリティの脆弱性を非公開で報告する](/ja/code-security/how-tos/report-and-fix-vulnerabilities/report-privately)」をご覧ください。\n\n## リポジトリのセキュリティアドバイザリについて\n\nリポジトリセキュリティアドバイザリを使用すると、パブリックリポジトリのメンテナーは、プロジェクト内のセキュリティの脆弱性について非公開で話し合い、修正することができます。共同で修正を行った後、リポジトリ保守担当者はセキュリティアドバイザリを公開して、セキュリティの脆弱性をプロジェクトのコミュニティに開示することができます。セキュリティアドバイザリを公開することにより、リポジトリ保守担当者は、コミュニティがいっそう簡単にパッケージの依存関係を更新したり、セキュリティの脆弱性の影響を調べたりできるようにします。詳細については、 [AUTOTITLE を](/ja/code-security/concepts/vulnerability-reporting-and-management/repository-security-advisories)参照してください。\n\nリポジトリのセキュリティアドバイザリを記述する場合、またはグローバルセキュリティアドバイザリにコミュニティで貢献する場合は、 GitHub Advisory Databaseで使用される構文 (特にバージョンの書式設定) を使用することをお勧めします。\n\nGitHub Advisory Database の構文に従う場合、特に影響を受けるバージョンを定義する際は:\n\n* リポジトリアドバイザリを発行すると、詳細情報を要求することなく、\"GitHub Advisory Databaseレビュー済み\" アドバイザリとしてGitHubにアドバイザリを追加できます。\n* Dependabot には、影響を受けるリポジトリを正確に識別し、 Dependabot alerts 送信して通知するための情報が含まれます。\n* コミュニティメンバーは、不足している情報や不正確な情報を修正するためのアドバイザリに対する編集を提案することが少なくなる可能性があります。\n\n*\\[下書きセキュリティアドバイザリ]* フォームを使用して、リポジトリアドバイザリを追加または編集します。詳しくは、「[リポジトリセキュリティアドバイザリの作成](/ja/code-security/how-tos/report-and-fix-vulnerabilities/fix-reported-vulnerabilities/create-repository-advisory)」をご覧ください。\n\n*\\[セキュリティアドバイザリの改善]* フォームを使用して、既存のグローバルアドバイザリの改善を提案します。詳しくは、「[GitHub Advisory Database でのセキュリティアドバイザリの編集](/ja/code-security/how-tos/report-and-fix-vulnerabilities/fix-reported-vulnerabilities/edit-advisory-database)」をご覧ください。\n\n## エコシステム\n\n**\\[エコシステム]** フィールドを使用して、サポートされているエコシステムのいずれかにアドバイザリを割り当てる必要があります。サポートされているエコシステムについて詳しくは、「[GitHub Advisory Database でのセキュリティアドバイザリの参照](/ja/code-security/how-tos/report-and-fix-vulnerabilities/fix-reported-vulnerabilities/browse-advisory-database)」をご覧ください。\n\n![セキュリティアドバイザリフォームの \\[影響を受ける製品\\] 領域のスクリーンショット。 \\[エコシステム\\] フィールドが、濃いオレンジ色の枠線で強調されています。](/assets/images/help/security/security-advisory-ecosystem.png)\n\n## パッケージ名\n\n\\*\\*\n\\*\\*の \"GitHubレビュー\" アドバイザリにはパッケージ情報が必要であるため、\\[パッケージGitHub Advisory Database] フィールドを使用して、影響を受けるパッケージを指定することをお勧めします。パッケージ情報はリポジトリレベルのセキュリティアドバイザリでは省略可能ですが、この情報を早期に含めると、セキュリティアドバイザリを発行するときにレビュープロセスが簡略化されます。\n\n## 影響を受けるバージョン\n\n影響を**受けるバージョン**フィールドを使用して、影響を受けるバージョンを指定することをお勧めします。この情報は、GitHubの \"GitHub Advisory Databaseレビュー\" アドバイザリに必要であるためです。バージョン情報はリポジトリレベルのセキュリティアドバイザリでは省略可能ですが、この情報を早期に含めると、セキュリティアドバイザリを発行するときにレビュープロセスが簡略化されます。\n\nGitHub Advisory Databaseの詳細については、「」を参照してください。\n\n### 用語集\n\n* **脆弱なバージョン範囲 (VVR)**: 特定のソフトウェアバグに対して脆弱なバージョンの範囲。\n* **演算子**: 脆弱なバージョン範囲の境界を示す記号。\n* \\*\\*オープンソース脆弱性形式 (OSV):\\*\\*GitHub Advisory Database データが互換性を持つよう努める形式。\n\n### バージョンの構文\n\n* 数値が小さいほど古いバージョンで、数値が大きいほど新しいバージョンです。たとえば、`1.0.0` は `2.0.0` よりも低いバージョンです。\n* アルファベットの並び順が先の文字ほど古いバージョンで、後の文字ほど新しいバージョンです。たとえば、`2.0.0-a` は `2.0.0-b` よりも古いバージョンです。\n* 数字の後に文字が付くとプレリリースの一部と見なされるため、数字の後に文字が付いているバージョンは、数字だけで文字のないバージョン番号よりも古いバージョンです。たとえば、`2.0.0-alpha`、`2.0.0-beta`、`2.0.0-rc` は `2.0.0` よりも古いバージョンです。\n* 最終版は、VVR の最大数より小さくすることはできません。たとえば、脆弱なバージョンがリリースされ、保守担当者がダウングレードを推奨したとします。保守管理者は、`Fixed` フィールドでその下位バージョンを固定バージョンまたはパッチ適用バージョンとしてラベル付けすることはできません。これは、その下位バージョンが脆弱なバージョンよりも小さいためです。\n\n### サポートされている演算子\n\n* ```\n \"このバージョン以上\"、`>=`。\n ```\n\n* ```\n \"このバージョンより大きい\" 場合、`>`。\n ```\n\n > \\[!WARNING]\n > GitHubは`>`演算子の使用をサポートしていますが、OSV 形式ではサポートされていないため、この演算子の使用はお勧めしません。\n\n* ```\n \"このバージョンと等しい\" 場合、`=`。\n ```\n\n* ```\n \"このバージョン以下\"、`<=`。\n ```\n\n* ```\n \"このバージョンより小さい\" 場合、`<`。\n ```\n\n### 影響を受けるバージョンを指定する GitHub\n\nアドバイザリでは、影響を受けるバージョンを明確に定義することが重要です。\nGitHub には、 **影響を受けるバージョン** の範囲を指定するためのいくつかのオプションが \\[影響を受けるバージョン] フィールドに用意されています。\n\n影響を受けるバージョンが一部の既存のアドバイザリでどのように定義されているかを示す例については、「[例](#examples)」を参照してください。\n\n* 影響を受ける有効なバージョン文字列は、次のいずれかで構成されます。\n * 下限演算子シーケンス。\n\n * 上限演算子シーケンス。\n\n * 上限と下限の両方の演算子シーケンス。最初に下限を指定し、その後に 1 つのコンマと 1 つのスペースを続け、次に上限を指定する必要があります。\n\n * 等値 (`=`) 演算子を使用した特定のバージョンシーケンス。\n\n * 各演算子シーケンスは、演算子、1 つのスペース、そしてバージョンとして指定する必要があります。有効な演算子の詳細については、上記の「[サポートされている演算子](#supported-operators)」を参照してください。\n\n * バージョンは数字で始めて、その後に任意の数の数字、文字、ドット、ダッシュ、またはアンダースコア (スペースまたはコンマ以外のもの) を続ける必要があります。バージョンの書式設定の詳細については、上記の「[バージョンの構文](#version-syntax)」を参照してください。\n > \\[!NOTE]\n > 影響を受けるバージョン文字列には、先頭または末尾にスペースを含めることはできません。\n\n* 上限演算子は、包括的とすることも排他的とすることもできます (つまり、`<=` または `<`)。\n\n* 下限演算子は、包括的とすることも排他的とすることもできます (つまり、`>=` または `>`)。ただし、リポジトリアドバイザリを公開し、リポジトリアドバイザリをグローバルアドバイザリに格上げする場合は、別のルールが適用されます。下限文字列は、包括的 (つまり、`>=`) とすることしかできません。排他的な下限演算子 (`>`) は、バージョンが `0`にのみ許可されます (たとえば、`> 0`)。\n\n* スペースの適切な使用\n * 演算子とバージョン番号の間にスペースを使用します。\n\n * `>=` や `<=` でスペースを使用しないでください。\n\n * `>= lower bound, <= upper bound` では、数値とコンマの間にスペースを使用しないでください。\n\n * コンマと上限演算子の間にスペースを使用します。\n > \\[!NOTE]\n > 下限の制限は、次のとおりです。\n >\n > * OSV スキーマとの互換性がないために発生します。\n > *\n\nGitHub Advisory Databaseの既存のアドバイザリに対して提案を行う場合にのみ適用されます。\n\n* `> 2.0, < 2.3, > 3.0, < 3.2` など、同じフィールドに、複数の影響を受けるバージョン範囲を指定することはできません。複数の範囲を指定するには、 **\\[+ 影響を受ける製品を追加]** ボタンをクリックして、各範囲に新しい **\\[影響を受ける製品]** セクションを作成する必要があります。\n\n ![セキュリティアドバイザリフォームの \\[影響を受ける製品\\] 領域のスクリーンショット。 \"影響を受ける別の製品を追加\" リンクが濃いオレンジ色の枠線で囲まれています。](/assets/images/help/security/security-advisory-add-another-affected-product.png)\n* 影響を受けるバージョン範囲に 1 つの上限または下限のみが含まれる場合:\n * 下限が明示的に指定されていない場合、暗黙的な値は常に `> 0` です。\n * 上限が明示的に指定されていない場合、暗黙的な値は常に無限大になります。\n\n### VVR で上限のみを設定する\n\n* 上限のみを設定する場合は、`<=` または `<` を使用します。\n* GitHub Advisory Databaseは、PyPA データベースをデータソースの 1 つとして使用します。ただし、 GitHub は PyPA VVR 形式と完全には一致しません (PyPa セキュリティアドバイザリでは、多くの場合、 `>= 0, <= n` または `>= 0, < n` を使用して、上限のみを持つバージョン範囲を参照します)。\n* 上限のみを持つ範囲に `>= 0` を含める必要はありません。\n\n### VVR で下限のみを設定する\n\n* アドバイザリキュレーションチームは、マルウェア以外のアドバイザリに下限のみを設定することはお勧めしません。\n これは、固定バージョンがリリースされた場合、アドバイザリが手動で更新されるまで、固定バージョンのユーザーは不要な Dependabot alerts を受け取り続けるからです。\n* すべてのバージョンの場合は、`>= 0` を使用します\n* `> 0` は一般に使用されません。\n\n### 影響を受けるバージョンを 1 つだけ指定する\n\n* ```\n 影響を受ける 1 つのバージョンの場合、`= n`。\n ```\n* `=` には、指定されたバージョン\\_のみ\\_が含まれ、公開用またはプライベートプレビューは自動的には含まれないことに注意してください。\n\n### 一般的なエラー\n\n* `< n` という脆弱なバージョン範囲を使用した後で、`n+1` にパッチを適用するというのは避けてください。\n * `< n` は、`n` が脆弱でない場合にしか使用できません。\n * この場合、VVR を `<= n` または `< n+1` にする必要があります。\n\n* 正式なバージョン番号に文字が含まれる最終版を記述する場合は、数字のみを使用しないでください。ソフトウェアに `linux` と `windows` の 2 つのブランチがあるとします。\n `2.0.0-linux` と `2.0.0-windows` をリリースする際に、脆弱なバージョンとして `< 2.0.0` を使用すると、バージョンロジックによって `2.0.0-linux` と `2.0.0-windows` がプレリリースと解釈されるため、`-linux` と `-windows` は脆弱とマークされます。\n `2.0.0-linux` や `2.0.0-linux` が脆弱であると見なされないように、最初のパッチバージョンとして、アルファベット順で最も早いブランチである `2.0.0-windows` をマークする必要があります。\n\n### 例示\n\n#### 複数の VVR と複数の演算子を使用したアドバイザリ\n\n「[Etcd Gateway TLS 認証は、DNS SRV レコードで検出されたエンドポイントにのみ適用されます (GHSA-wr2v-9rpq-c35q)](https://github.com/advisories/GHSA-wr2v-9rpq-c35q)」には、次の 2 つの脆弱なバージョン範囲があります。\n\n* `< 3.3.23`。下限がなく上限があり、`<` 演算子を使用します。\n* `>= 3.4.0-rc.0, <= 3.4.9`。上限と下限があり、`>=` 演算子と `<=` 演算子を使用します。\n\n#### プレリリースと通常リリースの関係を示すアドバイザリ\n\n「[XWiki Platform では、文字列プロパティの XClass 名を使用して XSS を使用できます (GHSA-wcg9-pgqv-xm5v)](https://github.com/advisories/GHSA-wcg9-pgqv-xm5v)」には、次の 4 つの脆弱なバージョン範囲があります。\n\n* `>= 1.1.2, < 14.10.21`\n* `>= 15.0-rc-1, < 15.5.5`\n* `>= 15.6-rc-1, < 15.10.6`\n* `= 16.0.0-rc-1`\n\nこれらの VVR のうち 3 つには、脆弱なバージョン範囲のプレリリースが含まれています。最後の VVR (`= 16.0.0-rc-1`) では、`16.0.0-rc-1` のみが脆弱であるのに対し、その後の通常のリリース (`16.0.0`) は脆弱ではないことを示しています。このロジックでは、`16.0.0-rc-1` と `16.0.0` は別のバージョンで、`16.0.0-rc-1` は `16.0.0` よりも前のリリースと見なされます。\n\nこの脆弱性へのパッチは、バージョン 16.0.0 に対して 2024 年 1 月 24 日に公開されました。詳細については、[](https://github.com/xwiki/xwiki-platform/commit/27eca8423fc1ad177518077a733076821268509c) リポジトリの `xwiki/xwiki-platform ` を参照してください。 MVN リポジトリサイトの [XWiki Platform Old Core](https://mvnrepository.com/artifact/org.xwiki.platform/xwiki-platform-oldcore) ページには、修正プログラムが XWiki に追加される前の 2024 年 1 月 22 日に `16.0.0-rc-1` が公開され、修正プログラムがコミットされた後、`16.0.0` が 2024 年 1 月 29 日に公開されたことが示されています。\n\n#### バージョン番号にブランチ名を含むアドバイザリ\n\n[Google Guava](https://mvnrepository.com/artifact/com.google.guava/guava) のバージョンリリースには、`android` と `jre` の 2 つのブランチがあります。「[Guava は、一時ディレクトリのセキュリティで保護されていない使用に対して脆弱です (GHSA-7g45-4rm6-3mm3)](https://github.com/advisories/GHSA-7g45-4rm6-3mm3)」および「[Guava の情報漏えい (GHSA-5mg8-w23w-74h3)](https://github.com/advisories/GHSA-5mg8-w23w-74h3)」は、Guava に影響を与える脆弱性に関するアドバイザリです。どちらのアドバイザリでもパッチ適用バージョンとして `32.0.0-android` が設定されています。\n\n* バージョン範囲ロジックは `32.0.0` の後の文字をプレリリースとして解釈するため、パッチ適用バージョンを `32.0.0` に設定すると、`32.0.0-android` と `32.0.0-jre` の両方が誤って脆弱とマークされます。\n* バージョン範囲ロジックはアルファベットの後の文字をアルファベットの前の文字よりも新しいバージョンとして解釈するため、パッチ適用バージョンを `32.0.0-jre` に設定すると、`32.0.0-android` は誤って脆弱とマークされます。\n\n`32.0.0-android` と `32.0.0-jre` の両方にパッチが適用されていることを示す最善の方法は、パッチ適用バージョンとして `32.0.0-android` を使用することです。そうすると、ロジックは、アルファベットの `32.0.0-android` より後のものはすべてパッチ適用済みと解釈します。"}