tl;dr コントリビューター(貢献者)にセキュリティー問題の法的責任は生じません。また、OSS スチュワード(支援団体)についても同様です。

コントリビューターと OSS スチュワードの義務

コントリビューター

CRA は味方です。コントリビューターの皆さん、ご安心を。

個人のコントリビューターとして OSS プロジェクトに関わっている場合、プロジェクトの規模や市場シェアにかかわらず心配はいりません。コード内で脆弱性が発見されたとしても、その法的責任を問われることはありませんし、修正義務を負うこともありません。CRA の前文には、コントリビューターに義務を課さないことが明記されています。

この規則は、自らの責任の下にない、フリーかつオープンソースソフトウェアに該当するプロダクトに対し、ソースコードを寄贈する自然人または法人には適用されない。1

後ほど説明するように、OSS スチュワードは法人である必要があるため、個人がスチュワードと見なされることもありません。

OSS スチュワード

OSS スチュワードとは、簡単に言えば商業ベンダーとしてではなく、OSS プロジェクトに対して継続的なサポート、保守やインフラを提供する法人のことです2。具体例を挙げると、Linux であれば Linux Foundation、Drupal や TYPO3 といった CMS ではそれぞれの協会(Association)がスチュワードにあたります。

前述の通り、脆弱性を修正する責任は「製造者(メーカー)」に帰属するため、OSS スチュワードがその実務負担を負うことはありません。ただし、一定の責任が生じる可能性はあります。

2026 年 3 月現在、規制が実際にどのように運用されるかを定義する「CRA 運用ガイドライン (the guidance on the application of the CRA)」の最終版はまだ公開されていません 3。各 OSS スチュワードが負うべき義務は、プロジェクトへの関与の度合いによって変わる見込みですが、その具体的な基準は年内のガイドライン確定まで未定です。最終版が公開され次第、このポストを更新するか、続報を投稿する予定です。

以下は、OSS スチュワードが対応を求められる可能性がある義務の概要です。

  • 「安全なプロダクトの開発を促進するためのサイバーセキュリティーポリシー、および効果的な脆弱性対応体制の文書化」4
  • サイバーセキュリティー上のリスクを低減するための、市場監視当局への協力 5
  • 悪用されている脆弱性の ENISA(欧州連合サイバーセキュリティ機関)への速やかな報告、およびユーザーへのリスクと是正措置の通知 6
  • 「(任意の)セキュリティー認証プログラムの確立」7

OSS スチュワードは制裁金の対象外

製造者や販売者といった「経済事業者(economic operators)」とは異なり、スチュワードに管理上の制裁金(行政罰)は課されません。これは第 64 条 (10 b) に明記されています。もちろん当局への協力は求められますが、金銭的なペナルティーを科されることはありません。

非営利組織であり、イノベーションの源泉でもあるスチュワードを制裁の対象から外すことは、極めて妥当な判断と言えるでしょう。しかし、2022 年に公開された CRA の初期草案では、OSS スチュワードと製造者が明確に区別されていなかったという経緯があります。

この区別が明文化された背景には、CRA の初期草案に対して声を上げた多くのオープンソース推進者たちの粘り強い活動がありました。提案された規制がエコシステムに与えかねない打撃への懸念を訴える公開書簡が次々と送られ、度重なる協議の結果、現在の形へとソフトランディングしたのです。(この成果は OSS コミュニティー全体にとって極めて大きく、控えめに言って最高だと思います。この調整に関わった皆様に心からの敬意を表します。)

それで… 脆弱性が見つかったら誰が直すの?

製品内で脆弱性が特定された場合、その報告と解決の主たる責任を負うのは製造者(メーカー)です。スチュワードやメインテイナーの立場から見ると、これは主に 2 つの理由で非常に大きなメリットがあります 8

  • メインテイナーの負担が軽減される(ただし、修正内容の検証やセキュリティーアドバイザリーの作成、リリース作業への協力自体は引き続き期待される)
  • 献身的なボランティアに支えられている OSS エコシステムに対して、一部の製造者が「フリーライド(無賃乗車)」し続けることを効果的に防ぐことができる

関連リソース

Eclipse Foundation は、現時点での OSS スチュワードの義務に関する理解をまとめた包括的なホワイトペーパーを公開しています(英語のみ): https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/whitepapers/stewards-and-cra.md

筆者もいくつかの情報源を当たりましたが、現時点ではこのホワイトペーパーが最も網羅的です。

繰り返しになりますが、公式なガイドラインが確定するまでは、個々のスチュワードにどの義務が具体的に適用されるかは不透明であるという点に注意してください。

コントリビューター/スチュワードと、製造者の境界線

詳細は別のポストで説明しますが、CRA における「製造者(manufacturer)」とは、デジタル要素を備えたプロダクト(PDEs)を作る主体を指します。

したがって、単に OSS を保守するだけでなく、そのソフトウェアを利用してビジネスを展開している法人の場合は、製造者と見なされます。例えば以下のような例です。

  • 有償のサービス、サポート、または追加機能の提供
  • その OSS を組み込んだ製品の製造

実際の運用でこの規制がどのように適用されるかは非常に興味深い論点です。興味のある方は、ガイドラインのドラフト版にある複雑なシナリオをいくつか参照してみてください 9

結論

個人のコントリビューターであれば、心配無用です。何の責任も課されず、問われることもありません。

OSS スチュワードは、規制違反で罰せられることを心配する必要はありません。ただし、今後のガイドラインの動向を注視し、確定した際には必要な文書の作成や体制の整備などを進めていく必要があります。


  1. Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act) [2024] OJ L 2024/2847, recital 18 https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847 accessed 11 March 2026. ↩︎

  2. 同規則第 3 条。CRA では「オープンソースソフトウェア・スチュワード」を次のように定義している。「製造者以外の法人であって、その目的または目標として、商業活動を意図し、かつフリーかつオープンソースソフトウェアに該当する特定のデジタル要素を備えたプロダクトの開発に対して、持続的かつ体系的な支援を提供し、それらのプロダクトの実行可能性を確保すること」。 ↩︎

  3. European Commission, ‘Draft Commission guidance on the Cyber Resilience Act’ https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en accessed 19 March 2026. ↩︎

  4. CRA 第 24 条 (1) ↩︎

  5. 同 24 条 (2) ↩︎

  6. 同 24 条 (3) ↩︎

  7. 同 25 条 ↩︎

  8. これについては、以前のポスト『 CRA の施行で EU での IT 製品・サービス提供が面倒になる(けど総体的には色々良い)件について 』で詳しく説明しました。 ↩︎

  9. European Commission, ‘Draft Guidance’ (n 3) pt 3.5. ↩︎