CNCFは2026年9月7日、主にセキュリティに注力していない小規模・中規模のオープンソースプロジェクトを対象とした、「脆弱性報告への対処」（Handling vulnerability reports: Recipe card）というガイドカードを公開した。資料を作成したのは、TAG Securityの共同議長であるEderaのMarina Mooreと、TAG SecurityのリーダーであるRed HatのSherine Khouryである。
このガイドの基本的な考え方は、管理者とユーザーの余分な作業を減らしつつ、修正の準備が整う前にセキュリティ報告が公開の議論へと発展するのを防ぐことにある。CNCFは、セキュリティ脆弱性とは、システムの機密性、完全性、可用性に影響を及ぼすために悪用され得る欠陥だと説明している。ただし、ソフトウェア上のすべての欠陥が悪用可能であったり、脆弱性に分類されたりするわけではない。
明確で非公開の報告窓口から始める
ガイドラインは、README.mdに見つけやすい明確なセキュリティセクションを設け、指示をファイル内に直接記載するか、リポジトリのルートにあるSECURITY.mdへ案内することを推奨している。目的は、誰でも読める公開issueで問題の詳細を公開するのではなく、研究者を非公開の経路へ誘導することにある。
報告手順では、脅威モデル、または報告を脆弱性とみなすために最低限必要な条件、送信先、報告の形式、レビューまでに予想される期間、開示までのおおよその期間など、複数の事項を明確にすべきである。GitHubの非公開脆弱性報告機能や、非公開のメーリングリストを利用できる。報奨金プログラムは、運用する能力がない場合、小規模・中規模プロジェクトにとって必須ではない。
脆弱性として扱う前に報告の性質を確認する
報告を受け取ったら、まず、それが実際に悪用可能な脆弱性を示しているのか、悪用不可能な欠陥なのか、想定される挙動についての誤解なのか、あるいはドキュメントの誤りなのかを判断すべきである。CNCFは、報告者やプロジェクト内の適切な専門家と報告について協議し、参加者の数を限定するとともに、報告が公開されるまで全員が秘密を守ることを提案している。
実務上、次のような質問を投げかけることができる。ユーザーが利用できる緩和策はあるか。その欠陥によって侵害、データ漏えい、その他の悪意ある活動が発生する可能性はあるか。問題はドキュメントだけにあるのか。報告が脆弱性ではないと判明した場合は、必要に応じて適切な公開手順を使ってユーザーに知らせつつ、報告者に公開issueの作成を案内できる。
不確かな場合、ガイドラインはTAG Security and ComplianceまたはCNCFのスタッフに助言を求めることを示している。ただし、報告の詳細は公開チャンネルに出してはならない。また、秘密保持期間中の参加者は慎重に選び、解決に本当に支援が必要な人だけを関与させるべきである。これにより、修正を提供する前に情報が攻撃者へ漏れるのを防ぐ。
公開せずに修正を開発・テストする
CNCFは、公開pull requestでパッチを公開したり議論したりすると、ユーザーが更新する機会を得る前に脆弱性の性質が明らかになる可能性があると警告している。GitHubの非公開報告機能を利用する場合は、報告を起点として非公開ブランチを作成できる。それ以外の場合は、非公開の経路で修正を開発・レビューできる。
通常の継続的インテグレーション環境が非公開ブランチで動作しない場合でも、修正をテストしなければならない。その場合は、管理者の判断と変更範囲に応じて、ローカルでテストを実施できる。修正が問題に対処しており、テストが十分であることを確認した後、ガイドラインは、速やかに統合し、その作成とテストに十分な数の管理者を参加させることを推奨している。一般公開する前に、コードを再度レビューし、脆弱性が実際に解消されたことを確認すべきである。
リリースをCVEの開示と調整する
修正が完了した後、CNCFは、報告を受け取ってから90日以内に開示することが一般的な慣行だとしている。プロジェクトに十分なリソースがあれば、非公開のユーザーリストへ事前に通知できる。しかし、更新された連絡先リストを維持することは負担となり、ほとんどの小規模プロジェクトには対応できない。
そのため、このカードはより簡単な方法を提案している。修正を含むリリースを利用可能にすると同時に脆弱性を発表し、問題が発表された時点でユーザーが修正を入手できるようにする。このためには、修正を取り込んだ直後に新しいリリースをビルドし、その後CVEを公開する必要がある。GitHubの非公開機能を利用している場合は、GitHubのインターフェースからこれを実行できる。
CVE番号はCNA、すなわちCVE採番機関から割り当てられなければならない。GitHubもそのような機関の一つであり、処理を実行できる。また、プロジェクトと研究者は、一覧に掲載されているCNAのいずれかへ直接連絡することもできる。CVEの深刻度は一連の質問を通じて決定され、プロジェクトは研究者と協力して回答の正確性を確認し、割り当てるスコアについて合意すべきである。
なぜこのガイドラインが重要なのか
実務上、このカードは脆弱性管理の責任を場当たり的な対応から、実行可能な手順へと移行させる。すなわち、非公開の窓口、限定的な確認、非公開の修正、そして調整されたリリースと開示である。CVEを公開した後、情報はOSVやその他の脆弱性データベースに現れ、ユーザー側のスキャンツールが更新の必要性を検出するのに役立つ。
ただし、このレシピの範囲は明確に限定されている。対象はセキュリティを専門としない小規模・中規模プロジェクトであり、高リスクまたはセキュリティ上センシティブなプロジェクト向けの、より複雑なプログラムの代替ではない。CNCFはまた、修正が利用可能になってから一定期間が経過した後に概念実証を公開することを検討するよう提案している。これによりユーザーに更新のための追加の機会を与えられるが、非公開の報告機能を利用している場合、その実施は難しくなる可能性がある。