LLVM セキュリティグループ

LLVM セキュリティグループは以下の目標を持っています。

  1. LLVM 貢献者とセキュリティ研究者が、LLVM プロジェクトに影響を与えるセキュリティ関連の問題を LLVM コミュニティのメンバーに開示できるようにします。

  2. 上記の問題に対する修正、コードレビュー、およびリリース管理を組織化します。

  3. 脆弱性または軽減策の欠陥の広範な普及の前に、ディストリビューターが問題を調査し、修正を展開する時間を確保します。

  4. LLVM ベースのツールチェーンとプロジェクトをパッケージ化および配布するベンダーへのタイムリーな通知とリリースを確保します。

  5. CVE プロセスを通じて、コンパイルされたコードがセキュリティに敏感なLLVM ベースのツールチェーンのユーザーにタイムリーに通知します。

  6. 問題を修正した後、追加のテスト、ファジング、強化を追加するなど、時間の経過とともにセキュリティを改善することに努めます。

注記：これらの目標は迅速な対応を保証し、問題が報告されたときの開示時期を提供し、ベンダー/パッケージャー/ユーザーの制約を尊重します。

LLVM セキュリティグループは非公開です。信頼できる LLVM 貢献者で構成されています。問題の調査中は、議論はセキュリティグループ（および問題報告者と主要な専門家）内にとどまります。問題が公開された後、その問題に関するグループの議論全体も公開されます。

セキュリティ問題の報告方法

いずれかの LLVM プロジェクトのセキュリティ問題を報告するには、github の llvm/llvm-security-repo リポジトリの「セキュリティ」タブにある 脆弱性の報告 機能を使用してください。

ご連絡いただいてから2営業日以内に、ご報告への確認をさせていただきます。その期限までに返信がない場合は、Discourse フォーラム に投稿して LLVM セキュリティグループの担当者と連絡を取るよう依頼することで、エスカレーションできます。**エスカレーションメーリングリストは公開されています**：投稿する際には、具体的な問題について議論したり言及したりしないでください。

グループ構成

セキュリティグループメンバー

グループのメンバーはコミュニティの幅広い層を表しており、以下の基準を満たしています。リストの形式は* ${フルネーム} (${所属}) [${githubユーザー名}]です。個人のgithubユーザー名がない場合、ブラケットは空になります。

  • Ahmed Bougacha (Apple) [@ahmedbougacha]

  • Andy Kaylor (Intel) [@andykaylor]

  • Artur Pilipenko (Azul Systems Inc) []

  • Boovaragavan Dasarathan (Nvidia) [@mrragava]

  • Dimitry Andric (個人; FreeBSD) [@DimitryAndric]

  • Ed Maste (個人; FreeBSD) [@emaste]

  • George Burgess IV (Google) [@gburgessiv]

  • Josh Stone (Red Hat; Rust) [@cuviper]

  • Kristof Beyls (ARM) [@kbeyls]

  • Matthew Riley (Google) [@mmdriley]

  • Matthew Voss (Sony) [@ormris]

  • Nikhil Gupta (Nvidia) []

  • Oliver Hunt (Apple) [@ojhunt]

  • Peter Smith (ARM) [@smithp35]

  • Pietro Albini (Ferrous Systems; Rust) [@pietroalbini]

  • Serge Guelton (Mozilla) [@serge-sans-paille]

  • Shayne Hiet-Block (Microsoft) [@GreatKeeper]

  • Tim Penge (Sony) [@tpenge]

  • Tulio Magno Quites Machado Filho (Red Hat) [@tuliom]

  • Will Huhn (Intel) [@wphuhn-intel]

  • Yvan Roux (ST) [@yroux]

基準

  • LLVM セキュリティグループのメンバーシップの候補者は、これらのグループのいずれかに該当する必要があります。

    • 個々の貢献者

      • コンパイラベースのセキュリティ関連の問題の修正を専門とするか、それらの調査と解決に頻繁に参加しています。

      • セキュリティの脆弱性を発見し、それらの脆弱性を責任を持って開示してきた実績があります。

      • 将来のセキュリティの脆弱性について知り、解決し、予防することに特に関心のあるコンパイラエキスパートです。

      • 昨年、LLVM プロジェクトに重要なコードを積極的に貢献しています。

    • 研究者

      • セキュリティの脆弱性を発見し、それらの脆弱性を責任を持って開示してきた実績があります。

      • 将来のセキュリティの脆弱性について知り、解決し、予防することに特に関心のあるコンパイラエキスパートです。

    • ベンダーコンタクト

      • 独自のLLVMのコピーを含む製品を出荷する組織または会社を表します。組織内での地位により、候補者はセキュリティ上の問題と開示の禁輸措置について知る必要があると考えられます。

  • さらに、LLVM セキュリティグループのメンバーシップには、以下の基準が不可欠ですが、十分ではありません。

    • LLVM セキュリティグループにすでに所属している場合は、昨年、1つのセキュリティ問題（もしあれば）に積極的に参加しています。

    • LLVM セキュリティグループにすでに所属している場合は、昨年、メンバーシップに関するほとんどの議論に積極的に参加しています。

    • LLVM セキュリティグループにすでに所属している場合は、昨年、透明性レポートの作成またはレビューに積極的に参加しています。

    • 企業またはその他の団体に雇用されている場合は、親団体はLLVM セキュリティグループにすでに3名以上のメンバーが所属していません。

    • ベンダーコンタクトとして指名された場合、そのベンダーでの地位は、最初に指名されたときと同じです。

    • 候補者は、既存のセキュリティグループのメンバーから、活動中の間もコミュニケーションの禁輸措置を遵守すると信頼されています。

指名プロセス

これらの基準を満たしていると感じる人は誰でも、自分自身を指名するか、既存のLLVM セキュリティグループのメンバーなどの第三者によって指名される場合があります。指名では、候補者が個人、研究者、またはベンダーコンタクトとして指名されているかどうかを明記する必要があります。指名のための根拠を明確に説明する必要があります。

現時点では、指名は通常、github プルリクエストを使用して提案、議論、および投票されます。指名の例はこちらにあります。プルリクエストの使用は、メンバーシップに関する議論を公開的で透明性があり、多くの方法でLLVM開発者にとってアクセスしやすいものにするのに役立ちます。何らかの理由で、完全に世界で読める指名が適切でないと思われる場合は、脆弱性の報告ルートを介してセキュリティグループに連絡を取り、個人が置かれている制約を考慮して、指名にアプローチする最良の方法について議論を行うことができます。

新規メンバーの選出

LLVM セキュリティグループのメンバーシップの指名が、既存のLLVM セキュリティグループのメンバーの過半数の支持を得た場合、セキュリティグループの既存のメンバーが異議を唱えない限り、5営業日以内に成立します。異議が申し立てられた場合、LLVM セキュリティグループのメンバーは問題について議論し、合意に達するよう努める必要があります。これにも失敗した場合、指名はLLVM セキュリティグループの3分の2以上の多数決によってのみ成功します。

メンバーシップの承認

新しいLLVM セキュリティグループのメンバーシップが確定する前に、成功した候補者はメンバーシップを受け入れ、このセキュリティポリシー、特に下記のLLVM セキュリティグループメンバーの権限と責任を遵守することに同意する必要があります。

メンバーシップの維持

  • LLVM セキュリティグループは少なくとも6ヶ月ごとに上記の基準を適用します。メンバーリストはそれに応じて整理されます。

  • セキュリティグループのメンバーは誰でも、今後5営業日以内に基準が適用されるよう要求できます。

  • LLVM セキュリティグループのメンバーがこのポリシーの文字と精神に従って行動しない場合、検討中の本人を除くメンバーの過半数の投票によって、LLVM セキュリティグループのメンバーシップを取り消すことができます。メンバーが取り消し投票を要求した後、投票は5営業日間にわたって行われます。

  • 緊急停止：LLVM セキュリティポリシーを公然と無視するLLVM セキュリティグループのメンバーは、2人のメンバーの要求により、メンバーシップを一時的に停止される場合があります。そのような場合、要求するメンバーは、違反の説明を添えてセキュリティグループに通知する必要があります。この時点で、メンバーシップは恒久的な取り消しに関する投票の結果を待つために、5営業日間にわたって一時的に停止されます。

  • LLVM 理事会は、LLVM セキュリティグループからメンバーを削除できます。

透明性レポート

LLVM セキュリティグループは毎年、透明性レポートを公開する必要があります。このレポートの目的は、過去1年間に公開された開示を要約することにより、コミュニティに情報を提供することです。公開されたすべての開示のリストと、問題を修正するまでの時間、禁輸期間の長さなどの統計が含まれます。

透明性レポートはLLVM セキュリティグループの透明性レポートで公開されています。

LLVM セキュリティグループメンバーの権限と責任

アクセス

LLVM セキュリティグループのメンバーは、非公開のディスカッションメディアに登録されます。これは、セキュリティ問題に関する技術的な議論と、開示のタイムラインやグループメンバーシップなどの問題に関するプロセスの議論に使用されます。メンバーはすべてのセキュリティ問題にアクセスできます。

機密性

LLVM セキュリティグループのメンバーは、公開されるまで、グループと共有されたLLVM セキュリティ問題の情報を機密として扱うことが期待されます。

  • メンバーは、両方のメンバーが同じLLVMベースの製品のベンダーに雇用されている場合を除き、メンバー以外にセキュリティ問題の情報を開示しないでください。その場合、情報は、その組織内で必要に応じて共有され、その組織内で通常行われているように機密情報として扱われます。

  • LLVM セキュリティグループが同意する場合、指定されたメンバーは、製品が同じ問題に苦しんでいる場合、非LLVMベースの製品のベンダーと問題を共有できます。非LLVMベンダーは、問題の禁輸日を尊重し、組織内の必要に応じて情報を開示しないように求められます。

  • LLVM セキュリティグループが同意する場合、特定の問題に対処するために、主要な専門家を招くことができます。主要な専門家は、問題の禁輸日を尊重し、情報を共有しないように求められます。

開示

以下のプロセスに従って、LLVM セキュリティグループは各セキュリティ問題の公開開示に関する禁輸日を決定します。修正版の出荷を計画しているすべてのベンダーが既にそうした場合、および報告者が異議を唱えない場合、合意された日よりも前に禁輸措置を解除できます。

共同作業

LLVMセキュリティグループのメンバーは、以下のことが求められます。

  • 認識したLLVMの脆弱性を速やかに共有する。

  • 問題解決に向けて積極的に取り組む。

  • 報告された問題の深刻度を評価する。

  • セキュリティ問題に対処するためのパッチの作成とレビューに協力する。

  • メンバーの推薦と削除のプロセスに参加する。

議論の媒体

LLVMセキュリティグループの議論に使用される媒体は、セキュリティに配慮したものである必要があります。そのため、当社のセキュリティ要件を満たすインフラ上で運用する必要があります。

セキュリティに関する議論を行うために、GitHubのセキュリティ脆弱性に関する秘密報告メカニズム を使用しています。

  • セキュリティ問題を報告する。

  • LLVMのセキュリティ強化について議論する。

LLVMセキュリティグループ自体の運営に関する事項についても、必要に応じて議論を行います。

  • 新規メンバーを推薦する。

  • メンバーの削除を提案する。

  • ポリシー変更を提案する。

これらの議論は、多くの場合、毎月の公開同期会議やDiscourseフォーラムで公開で行われます。内部または機密性の高い議論には、プライベートメーリングリストも使用します。

プロセス

報告された各問題については、以下のプロセスが議論媒体上で実行されます。

  • セキュリティ問題の報告者（必ずしもLLVMの貢献者である必要はありません）が問題を報告します。

  • 2営業日以内に、セキュリティグループのメンバーが問題の解決に責任者として選任されます。この責任者は、問題ごとに異なる必要はありません。本人は自ら立候補できます。

  • セキュリティグループのメンバーは、問題がセキュリティに関連する状況（もしあれば）について議論し、それがセキュリティ問題であるかどうかを判断します。

  • 公開開示のエンバーゴ期間を交渉します。デフォルトの最小期間は90日です。

  • セキュリティグループのメンバーは、特定の問題に関する議論に主要な専門家を参加させることを推奨できます。他のセキュリティグループメンバーから異議がない限り、主要な専門家は参加できます。

  • パッチの作成とレビューが行われます。

  • 最近のバージョンから古いバージョンへのセキュリティパッチのバックポートは、常に可能なわけではありません。そのようなバックポートを行うかどうか、そしてどの程度古いバージョンまで行うかは、セキュリティグループが決定します。

  • セキュリティグループは、LLVMプロジェクト自身のリリースと個々のベンダーのリリースをどのように調整して、問題を同時に修正できるかを検討します。

  • エンバーゴ期間は、セキュリティグループの裁量で延期または前倒しできます。

  • 責任者は、MITREからCVEエントリを取得します。

  • エンバーゴ期間が満了したら、LLVMの通常のコードレビュープロセスに従ってパッチが公開されます。

  • すべてのセキュリティ問題（および推薦/削除に関する議論）は、修正がLLVMリポジトリに反映されてから約14週間以内に公開されます。報告書に含まれる特に機密性の高いデータ（例：ユーザー名とパスワードの組み合わせ）の開示を避けるための予防措置を講じる必要があります。

ポリシーの変更

LLVMセキュリティポリシーは、LLVMセキュリティグループの過半数の投票によって変更できます。このような変更は、LLVMボードの承認も必要です。

セキュリティ問題とは何か？

LLVMプロジェクトには大量のコードがあり、そのすべてがセキュリティに配慮したものであるとは限りません。これは、LLVMが様々な状況で使用されているためです。脅威モデルは異なり、信頼できない入力は異なり、LLVMが実行される環境も様々です。そのため、LLVMプロジェクトがセキュリティ問題とみなすものは、メンバーが安全に維持することに同意したものです。

このセキュリティプロセスの成熟に伴い、LLVMコミュニティのメンバーは、コードベースの一部をセキュリティに配慮した（またはそれ以上セキュリティに配慮したものではない）ものとして指定することを提案できます。これには、根拠と、任意のRFCと同様にLLVMコミュニティからの同意が必要です。場合によっては、コードベースの一部はセキュリティに配慮したとして扱われる可能性がありますが、それを管理できる段階に達するには大幅な作業が必要です。LLVMコミュニティは、これらのコード部分をセキュアにすることに投資し、時間の経過とともにこれらのセキュリティ特性を維持するかどうかを決定する必要があります。いずれの場合も、LLVMセキュリティグループに相談する必要があります。なぜなら、彼らはこれらのコードベースに対して提出されたセキュリティ問題に対応するからです。

問題がこのセキュリティプロセスに該当するかどうかが不明な場合は、該当すると仮定してください。セキュリティグループは同意または不同意を示し、その根拠を報告書で説明し、上記のプロセスを通じてこの文書を更新します。

現在、LLVMプロジェクトでセキュリティに配慮したとみなされている部分は次のとおりです。このリストは時間の経過とともに変更される可能性があることに注意してください。

  • 現在定義されているものはありません。セキュリティに配慮が必要だと考える問題をセキュリティグループに報告することをためらわないでください。

現在、セキュリティに配慮していないと扱われているLLVMプロジェクトの部分は次のとおりです。このリストは時間の経過とともに変更される可能性があることに注意してください。

  • clangなどの言語フロントエンド。悪意のある入力ファイルによって望ましくない動作が発生する可能性があります。たとえば、悪意のあるCまたはRustソースファイルは、LLVMで任意のコードを実行する可能性があります。LLVMのこれらの部分は強化されておらず、信頼できないコードのコンパイルには通常、makeなどのユーティリティの実行も含まれ、悪意のある操作をより容易に行う可能性があります。