TLDR (この記事が長すぎると思われる場合は、要約を読んでください)
オープンソース ソフトウェアを含むソフトウェアは世界中で規制されています。この長いブログ投稿では、オープンソース ソフトウェアに対する EU サイバー レジリエンス法の背景、強み、落とし穴、考えられる悪影響について説明します。さらに、人々がタイムラインと変化を推進する方法を理解できるように、EU のシステムを通じてこの法の複雑なプロセスを説明しています。
オープンソースを含むソフトウェアは世界中で規制されつつあります。この長いブログ投稿では、欧州連合におけるサイバー レジリエンス法の背景、何が良いのか、その欠点、そしてオープンソースに対する予想される悪影響について説明しています。また、スケジュールと変更の方法を理解するために、EU のシステム内を移動する難解なプロセスについても説明しています。
| 訳者注：EU「サイバーレジリエンス法」 https://www.european-cyber-resilience-act.com/
さらに口頭での説明が必要な場合は、Eclipse の Mike Milinkovich が、同様の内容を説明する非常に新鮮で明確なプレゼンテーションを提供します。短い行動喚起を希望する場合は、GitHub、CNLL (フランス語コンテンツ)、The Linux Foundation、またはより幅広い業界の対応を試してください。
より口頭での紹介をお探しの場合は、Eclipse の Mike Milinkovich が、同じ内容をカバーする非常に最新かつ明快なプレゼンテーションを行いました。短い行動喚起に興味がある場合は、GitHub、CNLL (フランス語)、Linux Foundation、またはより広範な業界のより包括的な対応を試してください。
| 翻訳者注:
非常に新しく明確なデモ欧州サイバーレジリエンス法の最新情報: https://www.youtube.com/watch?v=AmsM5_5QO5A行動喚起: GitHub、Linux Foundation
GitHub：https://github.blog/2023-07-12- no- cyber-resilience-without-open-source-sustainability/
Linux Foundation: https://linuxfoundation.eu/cyber-resilience-act
業界の対応: https://ccianet.org/library/joint-recommendations-for-a-feasible-cyber-resilience-act/
IT 業界は他の大規模な業界やセクターに比べればまだ小規模ですが、過去数十年で社会にとって重要な存在になっています。最近、ソフトウェアやIT業界における大きな出来事がニュースでよく見られます。さらに一般的なのは、ある種の災害、つまり設定ミス、脆弱性、または単純に簡単に「侵入」した犯罪や国家の行為によって引き起こされるストーリーです。IT の不正行為は現在、エネルギー輸送や製造から金融、民主的なプロセスや統治の行き届いた政府に至るまで、主要産業にも影響を及ぼしています。
IT 業界は他の大規模な業界やセクターに比べればまだ小規模ですが、過去数十年で社会にとって重要な存在になりました。ソフトウェアや IT 業界の大規模なイベントがニュースで取り上げられることが多くなりました。そして、多くの場合、それはある種の災害によって引き起こされる物語です。設定ミス、バグ、または明らかにあまりにも簡単に「侵入」した犯罪者や国家関係者です。IT の不適切な慣行は現在、エネルギー輸送から製造、金融、民主的プロセス、善良な政府に至るまで、主要産業にも影響を及ぼしています。
このため、社会やさまざまな規制当局もこのことに確実に気づき、世界中でさまざまなソフトウェア管理規制や法律が制定されています。
このため、社会やさまざまな統治機関が確実に注目し、その結果、世界中であらゆる種類のソフトウェア規制や法律が準備されています。
工学の歴史を例にとると、この種の規制は完全に正常な結果です。機械産業は、蒸気エンジンの発明のおかげで、19 世紀末に目覚ましい成長を遂げました。しかし、この産業の発展に伴い、蒸気ボイラーの爆発事故も増加しています。これらの事故はしばしば町の半分を破壊します。
エンジニアリングの歴史を例に挙げると、このような規制は完全に正常な結果です。1800 年代後半、蒸気エンジンの発明のおかげで、機械産業は驚異的な成長を遂げました。しかし、この業界が成長するにつれて、蒸気ボイラーの爆発事故の数も同様でした。多くの場合、特定の町の半分が平らになります。
1865年、蒸気船スルタナ号が爆発し、1,167人が死亡した。そこで、米国ボイラー製造業者協会（以下、ABMA）が設立され、業界の自主規制が始まりました。政府が介入政策を採用し始めるまでには、そのような爆発が何百回も発生し、特に1905年にボストンの靴工場で起きた爆発では多額の費用がかかった。
1865 年に蒸気船スルタナ号が爆発し、1,167 人が死亡した後、米国の業界に圧力がかかりました。その結果、米国ボイラー製造業者協会 (ABMA) が設立され、業界の自主規制が始まりました。このような爆発は数百回も必要でした。そして、1905年にボストンの靴工場で政府の政策介入のために作られた特に高価なものがあった。
興味深いことに、1905 年の災害に対応したのは ABMA ではなく、企業ではなく個人で構成される専門組織である米国機械学会の会員である 5 人のエンジニアのグループでした。これらの人々はボイラー規則の初版を書き、すぐにマサチューセッツ州議会によって承認されました。
興味深いことに、1905 年の災害に対応したのは ABMA ではなく、企業ではなく個人の専門組織である米国機械学会の会員である 5 人のエンジニアのグループでした。これらの人々がボイラー規約の最初のバージョンを作成し、その後すぐにマサチューセッツ州議会によって承認されました。
これらのエンジニア、これらの個人のボランティアは、多くの点で、問題解決に「自ら協力」しました。これは、今日私たちが ASF のオープンソースや IETF (インターネット エンジニアリング タスク フォース) でインターネット標準の開発を行っているのと同じです。問題を解決したのは専門家グループであり、雇用主、業界、米国ボイラー製造者協会ではありませんでした。
これらのエンジニアや個人のボランティアは、さまざまな意味で、問題を解決するために「かゆいところを掻いた」のです。これは、今日の ASF や、インターネット エンジニアリング タスク フォース (インターネットの標準を設定する) でオープンソースで行っていることとよく似ています。問題を解決したのは専門家コミュニティであり、雇用主、業界、ABMA ではありません。
現在、世界中のほぼどこでも多くの法律が制定されていますが、米国と EU はやや先を行っています (また、国家政策立案者間で多くの調整が行われています)。
現在、世界のほぼすべての地域で多くの法律が制定されています。米国と欧州連合がわずかに先行しています（そして各国の政策立案者間の十分な調整が必要です）。
このブログ投稿では、現時点ではそのうちの 1 つである EU の CRA (サイバー レジリエンス法)に焦点を当てます。これはタイムラインの観点からは「最初の動き」であるためです。
このブログ投稿では、時間軸の観点から「最初」である EU のサイバー レジリエンス法 (CRA) について、現時点では 1 つだけに焦点を当てます。
これは決して最も重要な法律ではありません。ASF では、欧州連合の製造物責任指令 (ソフトウェアに対する「厳格責任」規制を導入した)、米国の大統領令 14028「国家サイバーセキュリティの向上」および「オープンソース ソフトウェア 2023 年安全保障法」(米国) が適用される可能性があると考えています。さらに大きな影響を与えます。
それは決して最も重要な法律ではありません。ASF では、EU の製造物責任指令 (ソフトウェアに対する「厳格責任」の導入)、米国大統領令 14028、「国家のサイバーセキュリティの向上」、および「2023 年オープンソース ソフトウェアの保護法」(米国) の影響を評価しています。 、おそらくさらに大きな影響を与えると考えられます。
| 翻訳者注:
米国大統領令 14028、「国家サイバーセキュリティの改善:
https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
2023 年オープンソース ソフトウェア セキュリティ法」 (米国):
https://www.congress.gov/bill/118th-congress/senate-bill/917/text
米国の法律は国立標準技術研究所 (NIST) を通じて国の標準を設定することができ、NIST は EU よりも早く標準を設定することが多いため、これは特に当てはまります (したがって、世界標準である可能性が高くなります)。
これは、米国の法律が国立標準技術研究所 (NIST) を通じてその国の標準を設定する可能性があるため、特に当てはまります。これは通常、EU によって開発された標準よりも高速です (したがって、世界標準を設定する可能性も十分にあります)。
日常業務では、ソフトウェア開発者が規制の問題について考える必要はほとんどありません (医療、航空宇宙、金融、原子力などの特定の分野で働いている場合を除く)。オープンソース ライセンス (ダウンストリーム) とコミッター ライセンス契約 (アップストリーム) には、広範な免責条項が含まれる傾向があります。私たちはしばしば、コードを成文化された知識や音声と同一視します。
日常業務では、ソフトウェア開発者が規制を考慮する必要はほとんどありません (医療、航空宇宙、金融、原子力などの特定の分野で働いている場合を除く)。オープンソース ライセンス (ダウンストリームのアウトフロー) とコミッター ライセンス契約 (インストリーム) には、広範囲にわたる免責条項が含まれる傾向があります。そして私たちはしばしば、コードを成文化された知識や音声と同一視します。
しかし実際には、物事はそれほど単純ではありません。たとえば、ASF では、ダウンロード用に提供する暗号化コードの正確な場所を産業安全保障局 (BIS) に知らせるために、何年にもわたって文書の提出を求められてきました [https://infra.apache.org/crypto ] .html]。ASF によって公開されたコードは、特定の宛先または特定のリストに記載されている人物にエクスポート (または再エクスポート) することはできません。
しかし、実際には、物事はそれほど単純ではありません。たとえば、ここ ASF では、ダウンロード可能にしている暗号コードの正確な場所を米国産業安全保障局 (BIS) に知らせるために、書類を提出する必要が長年にわたってありました。 [https://infra.apache.org/crypto.html]。また、ASF によって配布されたコードは、特定の宛先または特定のリストに載っている人々にエクスポート (または再エクスポート) することはできません。
| 翻訳者注:特定のリストに記載されている特定の目的地または人物 - ASF 製品の輸出仕様: https://www.apache.org/licenses/exports/
EU では、CRA (サイバー レジリエンス法) が現在法的手続き中です (2023 年 7 月 19 日に重要投票が行われます)。この法案は、EU 内の幅広いソフトウェア (およびソフトウェアが組み込まれたハードウェア) に適用されます。この規制の目的は、ソフトウェアをより安全にするという良いものです (そしておそらく時代遅れとも言えます)。
EU では現在、サイバー レジリエンス法 (CRA) が法制定プロセスを進めています (2023 年 7 月 19 日に主要投票が予定されています)。この法律は、EU 内の幅広いソフトウェア (およびソフトウェアが組み込まれたハードウェア) に適用されます。この規制の目的は良いものです (そしておそらくずっと遅れているでしょう): ソフトウェアの安全性をさらに高めることです。
| 翻訳者注: EU の「サイバー レジリエンス法」 https://www.european-cyber-resilience-act.com/ は採決されましたが、多くの反対意見を引き起こしており、その後の展開は注目に値します。
この法案は、さまざまな方法でこの目標を達成しようとしています。最も重要なことは、CRA は、ソフトウェアの設計、構築、リリース、保守時にセキュリティに関する業界の優れた慣行を採用することを市場に要求することです。最も基本的なレベルでは、CRA は、バグを管理し、セキュリティの脆弱性を受け入れ、優先順位を付け、修正するという ASF の現在の基本ポリシーを形式化しました。これは、適切な場合に CVE (共通脆弱性およびエクスポージャ) を登録し、リリース ノートを作成し、適切なバージョン管理を行うなど、適切なガバナンスや慣行と組み合わせることでも達成されます (公平を期すために、これらのいくつかは正式化し、さらに改善する必要があります)。 。
この法律は、さまざまな方法でこれを実現しようとしています。最も重要なことは、CRA は、ソフトウェアの設計、構築、リリース、保守の際に業界の優れた慣例をセキュリティに適用することを市場に要求することです。最も基本的なレベルでは、CRA は、バグを管理し、セキュリティの脆弱性を受け入れ、優先順位を付け、修正するという、ASF で既にポリシーとして定められているものを形式化します。これは、これを優れたガバナンスや実践と組み合わせることで実現されます。必要に応じて CVE を登録したり、リリース ノートを作成したり、適切なバージョン管理を行ったりします (公平を期すために、それらのいくつかはさらに形式化して改善する必要があります)。
| 訳者注: ASF の現在の基本方針
https://www.apache.org/security/committers.html
CRA はまた、CE 適合宣言における非常に簡単な自己認証によって、欧州市場のすべてのソフトウェアが一定の最低限のセキュリティ レベルを満たしていることを確認しようとします。または、ファイアウォールや安全な暗号化キー エンクレーブなどのより重要なソフトウェアの場合は、外部の規制された指定機関による実際の「真の」認証と監査が行われます。CRA は、市場のコンプライアンスを監視するための一連のプロセスも定義します。
CRA はまた、欧州市場のあらゆるソフトウェアが、CE 適合宣言に文書化された非常に単純な自己認証によって、ある種の最低レベルのセキュリティを満たしていることを保証しようとします。または、ファイアウォールや安全な暗号キー エンクレーブなどのより重要なソフトウェアの場合は、外部の規制および通知を受けた機関による実際の「本物の」認証と監査が必要です。CRA はまた、市場のコンプライアンスを監視するための多数のプロセスも定義します。
| 翻訳者注:
「CE」マークは、製品の安全性認証マーク（つまり、一般的な品質要件ではなく、人間、動物、物品の安全を危険にさらさない製品の基本的な安全要件に限定されています）であると考えられています。メーカーが欧州市場を開拓し参入するためのパスポート。CEとはCONFORMITE EUROPEENNEの略です。
安全な暗号化キー エンクレーブ: ハードウェアのプロセッサおよびメモリの保護された部分を指します。
EU の政策立案者は、これらの「業界のベスト プラクティス」が明確に定義されていないことを認識しています (業界全体で、ASF のセキュリティ慣行はルールではなく例外です) - CRA の多くは国際標準に依存しています 組織は、人々が自分たちのプロジェクトを監査するために使用できる標準を設定しています (自己認証）、または外部監査人が使用できるもの。
EU の政策立案者は、これらの「業界のベスト プラクティス」がまだ十分に定義されていないことを認識しています (業界一般では、ASF は例外であり、規則ではありません)。そして CRA の多くは、可能な標準を作成するために国際標準化団体に依存しています。自分のプロジェクトを監査するために使用する (自己認証)、または外部監査人が使用できる。
さらに、重大な脆弱性は特別な扱いを受け、できるだけ早く報告されることが期待されています。それについては後で詳しく説明します。
また、重大な脆弱性が特別な扱いを受け、早期に報告されることも期待されています。それについては後で詳しく説明します
さまざまなブログや公開書簡をご覧になっている方ならわかると思いますが、オープンソース財団は、オープンソース ソフトウェアが「免除」されるように、つまり、コードが公開された場合に限り、CRA の既存の文言を修正する方法に焦点を当ててきました。オープン ソース パブリック ドメイン. コモンズ (公共リソースとも訳される) では、CRA が適用され、その後は商用サプライ チェーン全体に適用され続けます。同時に、何か (セキュリティ修正など) が再びパブリック ドメインになると、CRA (サイバー レジリエンス法) は適用されなくなります。
さまざまなブログやレターをご覧になっている方なら、オープンソース ソフトウェアを「免除」するために、CRA の現在の文言を改良することに、オープンソース財団が多くの焦点を当てていることがわかります。つまり、コードがオープンソースコモンズから離れる場合にのみ CRA を適用するようにします。その後、商業サプライチェーン全体に適用され続けます。また、セキュリティ修正などの何かが戻ってきて再びコモンズに入ったときに CRA が適用されないようにするためでもあります。
| 翻訳者注:
ブログ: https://blog.opensource.org/what-is-the-cyber-resilience-act-and-why-its- important-for-open-source/
公開書簡: https://blog.opensource.org/the-ultimate-list-of-reactions-to-the-cyber-resilience-act /
一般に、こうしたオープンソース財団やコミュニティの取り組みは成功していません。「CRA - Cyber Resilience Act」の文書バージョンは、これまでのバージョンで大幅に変更されましたが、前述のオープンソース財団やコミュニティの懸念といった特定の政策問題を中心に展開するものではありません。
概して、これらの取り組みは成功していません。文書のその後のバージョンは大幅に変更されましたが、この特定のポリシー問題に関するものではありませんでした。
その理由を理解するために、7 月 7 日に ASF の代表者が (OpenSSL とともに) EU と直接話し合い、これが初めて実際に議員と有意義な交流を持つことができました。
その理由を理解するために、7 月 7 日に ASF の代表者が (OpenSSL とともに) EU と直接話し合い、これが初めて実際に有意義な方法で議員と対話することができました。
この会話から、政策立案者たちはオープンソースが「生産」とイノベーションの両方において IT 業界にとって重要であることを明確に認識していることがわかりました。このため、彼らは卵を産むガチョウを殺すことを避けたいと考えています。
この会話から、政策立案者たちはオープンソースが「生産」とイノベーションの両方において IT 業界にとって重要であることをよく認識していることが分かりました。このため、彼らは金の卵を産むガチョウを殺すことを避けたいと考えています。
| 翻訳者注: 政策立案者はよく知っています
https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-impact-assessment
一方で、EU の立法者は、典型的な欧州の中小企業 (SME) が運用またはライセンス供与するソフトウェア スタックの 95% 以上をオープンソースが占めることが多いことも認識しています。中小企業はソフトウェアを市場に投入する側として、ソフトウェア スタック全体に責任を負います。
その一方で、EU の議員らは、典型的な欧州の中小企業 (SME) が運営またはライセンス供与されているソフトウェア スタックの 95% 以上がオープンソースであることが多いことも認識しています。そして、それを市場に出す当事者である中小企業が責任を負うのは、そのスタック全体です。
私たちは、政策立案者がこれらのプロセスの改善 (および (自己) 認証) にはコストがかかり、約 25% 多くの諸経費がかかると考えていることを理解しています。これは、ヘルスケア分野で最近導入された同様の規制と CRA 影響評価に基づいています (EU の法的提案は、予想される経済的影響を文書化する必要があります)。
私たちが理解しているところによると、政策立案者は、こうしたプロセスの改善 (および (自己) 認証) にはコストがかかると想定しています。コストのオーバーヘッドが 25% 増加します。これは、医療分野で最近導入された同様の規制と CRA の影響評価に基づいています (提案された EU 法は、経済的観点から考えられる影響を文書化する必要があります)。
したがって、SME スタック全体 (つまり、95% がオープンソース、5% がプライベート レシピ) を見ると、ほとんどのヨーロッパの SME にとって、コードの 100% 全てに対する追加の労力はエンジニアリングにかかる労力の数倍になるため、実現不可能です。EU の考え方は、オープンソース スタック上に構築されたコードの 5% または 10% を認証する方がはるかに簡単であるということです。
したがって、中小企業のスタック全体 (つまり、95% がオープンソース、5% が秘密のソース) を見ると、ほとんどのヨーロッパの中小企業にとって、この追加の労力は 100% を超えてエンジニアリングの労力の数倍になるため、実現不可能です。一方、EU では、オープンソース スタック上に構築されたコードの 5 ～ 10% を認証する方がはるかに達成可能であると考えています。
したがって、政策立案者(1)は、CRA をオープンソース財団に適用するつもりであることを ASF に明確にしました。現在、オープンソースの例外は、実生活では使用されない純粋な趣味のコードか、ミラーや NPM や Maven Central などのパッケージ リポジトリのようなものです。彼らのアプローチは、ソフトウェアが商業環境のどこかで使用されている場合、商業的意図があると推定することです。
このため、政策立案者は (1) オープンソース財団に CRA を適用させるつもりであることを ASF に対して明確にしました。オープンソースの現在の例外は、純粋な愛好家、実際には使用されないコード、またはミラーや NPM や Maven Central などのパッケージ リポジトリなどです。ソフトウェアが商業環境のどこかで使用される場合、彼らがこれを行う方法は商業的意図があると推定されます。
欧州連合における法案は通常、欧州委員会によって起草されます（欧州委員会は「影響調査」なども作成します）。その後、国会で審議される。議論は通常、より小規模な委員会で行われます。これらの委員会は報告書を作成し、最終的に法案は採決のために議会本会議に提出されます (2)。
EU の法案は通常、欧州委員会によって起草されます (影響調査などの準備も欧州委員会によって行われます)。その後、国会で審議される。これは通常、小規模な委員会で行われます。これらの委員会は報告書を作成し、最終的に法案は議会の本会議で採決されます(2)。
CRA の主要委員会は、LIBE、IMCO、ITRE です。
CRA の主な委員会は LIBE、IMCO、および ITRE です。
最初の委員会である自由・司法・内務委員会（LIBE）は「言論の自由」などの問題を議論する責任を負っていたが、同委員会は報告書の提出を拒否した。次に、域内市場・消費者保護委員会 (IMCO) は、消費者と域内市場にとって何が重要かを検討しました。委員会は報告書を作成し、産業・研究・エネルギー委員会（ITRE）に提出した。
1つ目は、「言論の自由」などが議論されるLIBE（自由・司法・内務委員会）は報告書の作成を拒否した。次にIMCO（内部市場と消費者保護に関する委員会）は、消費者と内部市場にとって何が重要かを検討した。報告書を作成し、ITRE に提供しました。
その後、産業・研究・エネルギー委員会 (ITRE) が合意文書を作成し、20230717 週中に公開で議論され、最終的に委員会によって承認される予定です (同意の場合、委員会は通常投票を行いません)。
ITRE（産業・研究・エネルギー委員会）はその後、20230717の週に公開で議論される予定の合意文書を作成し、最終的な委員会の承認を得た（同意がある場合、委員会は通常、物事について投票を行わない）。
| 翻訳者注: 20230717 今週のオープンディスカッション
https://www.europarl.europa.eu/committees/en/itre/home/highlights
この作業が完了すると、提案は投票のために欧州議会に提出されます。その時点での論争や合意のレベルに応じて、議論や自由投票が行われる場合もあれば、行われない場合もあります。
これが完了すると、提案は欧州議会を通過して投票されます。その時点でどの程度物議を醸しているか、または合意に達しているかに応じて、議論や自由投票が行われる場合もあれば、行われない場合もあります。
| 翻訳者注: 作業は完了しましたhttps://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-european-cyber-resilience-act
一方、EUの第三者機関である理事会も、独自の法案を準備している。主に各国の関係大臣がそれぞれの国としての観点から検討を行っております。その後、最終版が法律となる前に、3 つのバージョン (委員会、議会、評議会) が密室で「トライアローグ」で議論されます。
その間に、EU の第三者である理事会も、同法のバージョンを作成しています。これらは基本的に国家的な観点からそれを検討する各国の関係大臣です。その後、3 つのバージョン (EC、議会、評議会) が密室で審議され、法となる最終バージョンが得られます。
現在、立法過程のすべての当事者は一般的な合意に達していると言われており、2 つの当事者が ASF と論争はないという見解を共有している。さらに、さまざまな合意文書のコピーが漏洩しました。そのため、それらがそれほど大きく異なっていないことがわかり、同様に分析を開始できるようになりました。
現在、立法プロセスに参加しているすべての当事者は大まかな合意に達していると言われており、そのうちの2当事者は議論の余地はないという意見をASFと共有した。また、さまざまな合意文書のコピーが流出しました。したがって、それらがそれほど離れていないことがわかり、分析を開始することもできます。
現在の定義 (3) では、独占禁止法が ASF、その (ボランティア) すべての開発者、および当社のすべての成果物に適用されると規定されています。そして、ASFと政策立案者との会合によると、これは意図的なものであるという。
現在の定義(3) は、CRA が ASF、その (ボランティア) 開発者全員、および私たちのすべての成果物に適用されるものです。そして、ASFが政策立案者との会合から理解しているように、これは意図的なものでした。
CRA に関しては多くの懸念がありますが、ASF コミュニティにとって最も重要なのは次の問題と考えられます。
CRA にはかなりの懸念があります。しかし、以下はおそらく ASF コミュニティのトップでしょう。
パブリックドメインの概念は商業市場と何ら変わりはなく、オールインモデルである:第一の問題は、独占禁止法が全か無かの二分法を採用していることである。参加するか辞めるかのどちらかです。参加する場合、あなたに適用される内容は、基本的に、消費者に販売される商用製品の全スイートに適用する必要がある内容となります。
コモンズの概念は商業市場と区別できません。これはオールイン アプローチです。最初の問題は、CRA が二者択一の全か無かのアプローチを採用していることです。あなたは入っているか、出ているかのどちらかです。そして、あなたがその立場にいるとき、あなたに適用されるものは、本質的に、消費者に販売される本格的な商業製品に適用される必要があるものです。
オープンソースはこれに近いかもしれませんが (Apache Netbeans や Apache Zeppelin など、実際の商用製品は販売されていませんが)、オープンソースは一般に商用環境には属しません。代わりに、共有知識または共通リソースとして管理できます。学術論文や参考設計図のようなものです。CRA はこれを認識していません。したがって、CRA はオープン ソース ソフトウェアに完全に適用されます (適切な脆弱性処理、バージョン管理、「ソフトウェア部品表」など、この文脈で意味のある CRA の要素を適用するだけではなく) SBOM」 ）。
オープンソースはこれに近いものもありますが (販売されていませんが、Apache Netbeans や Apache Zeppelin など)、一般にオープンソースはそのような商業的環境の一部ではありません。代わりに、共有知識またはコモンズとして管理される場合があります。たとえば、学術論文や参考設計図などによく似ています。CRA はこれを認めず、したがって、CRA 自体を完全に適用します (たとえば、適切な脆弱性処理、バージョン管理、SBOM など、その文脈で意味のある CRA の要素のみを適用するのではなく)。
CRA は、「完全に分散化された開発モデル」を持たないオープンソース プロジェクトを規制します。ただし、「会社」の従業員がコミット権を持っているプロジェクトは免除されません (アップストリームのオープンソース コラボレーションが雇用主の商用製品と何らかの関係があるかどうかに関係なく)。由緒ある OpenSSL プロジェクトなど、一部のプロジェクトにはさらに複雑なパターンがあります。
CRAは、オープンソースプロジェクトが「完全に分散化された開発モデル」を持っていない限り、オープンソースプロジェクトを規制することになる。ただし、「企業」の従業員がコミット権を持っているプロジェクトは免除されません (上流のコラボレーションが雇用主の商品とほとんど、あるいはまったく関係がない可能性があるにもかかわらず)。また、由緒ある OpenSSL プロジェクトなど、一部のプロジェクトにはさらに複雑なモデルがあります。
| 翻訳者注: OpenSSL プロジェクトのモデルはさらに複雑です
https://www.openssl.org/blog/blog/2023/07/17/who-writes-openssl/
これはオープンソースのwin-win原則を覆すものです。企業メンテナが禁止されれば、企業は従業員にプロジェクトをメンテさせることをやめる可能性があり、その結果、オープンソース イノベーション エコシステムに悪影響が及び、皮肉なことに、その回復力と経済/成長への大きな後押しが損なわれることになります（EU の影響評価によれば、1 人あたり 90 億ユーロ）年）。
これにより、オープンソースの双方の利益が逆転します。企業のメンテナーが禁止されれば、企業は従業員にプロジェクトのメンテナンスを許可することから撤退する可能性があり、オープンソースのイノベーションエコシステムに悪影響を及ぼし、皮肉なことに、その回復力とその重要な経済/成長の原動力（EUの影響評価によると年間90億ユーロ）が損なわれる可能性があります。 。
また、ASF コミュニティの誰が、ASF に求められる可能性のある追加の (自己) 認証作業を行うのかを確認することも困難になります。
また、ASF コミュニティの誰が、ASF が行う必要がある追加の (自己) 認証作業を行うのかを確認することも非常に困難になります。
これによる最終的な影響は実際には非常に広範囲に及びます。「前文 (4)、10a」の例を見てみましょう (このような例はたくさんあります)。
これによる最終的な影響は実際には非常に広範囲に及びます。「Recitals(4), 10a」から例を挙げると (そのような例はたくさんあります):
同様に、無料のオープンソース プロジェクトへの主要な貢献者が営利団体に雇用されている開発者であり、それらの開発者または雇用主がコード ベースでどの変更を受け入れるかを制御できる場合、そのプロジェクトは一般に営利的であると見なされます。
同様に、無料のオープンソース プロジェクトの主な貢献者が営利団体に雇用されている開発者であり、そのような開発者または雇用主がコード ベースでどの変更を受け入れるかを制御できる場合、そのプロジェクトは一般に、商業的な性質。
ここで、これらの寄稿者と営利雇用主との間に取引上のつながりが欠如していることが問題となります。たとえば、開発者は民間航空会社 (つまり営利団体) に雇用されているパイロットであり、余暇にオープンソースに貢献することができます。ポリシーのこの部分では、そのような貢献は「商業的」なものとなります。さらに、ASF では、主要な貢献者 (コミッター) がコードベースに何を入れるかをある程度制御できることは確かです (5)。
ここでは、これらの寄稿者と営利雇用主との間に取引上のつながりがないことが問題となります。たとえば、開発者は民間航空会社 (つまり、営利団体) に雇用されている航空会社のパイロットである可能性があり、余暇にオープンソースに貢献します。ポリシーのこの部分では、その貢献が「商業的」になります。また、ASF では、主な貢献者 (コミッター) は、コードベースに何を入れるかをある程度のレベルで制御することができます(5)。
| 訳者注：これは、オープンソースとは何の関係もない航空会社もその影響を受け、監督の対象に含まれることを意味します。
さらに悪いことに、最も影響を受けるタイプのオープンソース組織は、現在、責任を持って脆弱性をトリアージ、修正、公開し、一致する CVE (共通脆弱性) とリスクを提供する非常に成熟したセキュリティ プロセスを備えている傾向にある組織でもあります。一般に、CRA は、製品を市場に出す企業の下流側で大幅な改善を推進することが求められます。しかし今はその逆が起きているかもしれない。
さらに事態を悪化させるのは、最も影響を受けるタイプのオープンソース組織が、今日、非常に成熟したセキュリティ プロセスを持つ傾向にある組織でもあり、CVE に合わせて脆弱性が優先順位付けされ、修正され、責任を持って開示されることです。一般的にはさらに下流にありますが、製品を市場に出す企業との間で、CRA は大幅な改善を推進する必要があると考えています。今ではその逆のことをする危険があります。
CRA は、完全にボランティア主導で推進されるプロジェクト (ASF など) に影響します。これらの独立した ASF プロジェクトでは、どの企業も製品の運用やリリースに影響を及ぼしません。CRA は、営利団体の従業員が貢献 (コミット) する権利があるプロジェクトに影響します。
CRA は、どの企業も製品の内容やリリースに影響力を持たない、完全にボランティア主導で行われるプロジェクト (ASF など) に影響します。営利団体の従業員がコミット権を持っているプロジェクトはすべて影響を受けます。
これは問題を引き起こします。営利企業であろうとオープンソース プロジェクトであろうと、どのコミッターがコードを変更できるか、どの許可が受け入れられるか、どのパッチが受け入れられるかについて、より注意する必要があります。
これは、営利企業とオープンソース プロジェクトの両方が、どのコミッターがコードに取り組むことができるか、どのような資金が必要か、どのようなパッチを受け入れることができるかについて、より慎重になる必要があるという問題につながります。
CRA 認証では、モジュールの (自己) 認証は「推移的」であるという強い前提があります。つまり、認定されたモジュールを使用して何かを構築する場合、認定する必要があるのは、実行する「追加の」ことだけです。残念ながら、これは一般的に真実ではありません。多くの場合、認定は、(最終的な責任を持つ組織として) 提供されている内容が顧客の特定のコンテキストの目的に沿って提供するのに適切であることをどのように保証するかを示すことに非常に重点を置いています。オープンソース組織は、構築するソフトウェア モジュールを自己認証するときに「上流」情報を提供できません。
認証には、モジュールの (自己) 認証が推移的であるという強い前提があります。つまり、認定されたモジュールから何かを構築する場合、実行したいくつかの追加の作業のみを認定する必要があります。残念ながら、これは一般的には真実ではありません。一般に、認定は、最終的な責任を負う組織として、顧客の特定の環境に提供したものが、提供した目的に適合していることをどのように確認したかを示すことに非常に重点を置いています。ビルディングブロックを自己認証するオープンソース組織の「上流」では入手できない情報。
認証の核心は、公開された情報がその意図された目的に対して適切に安全であることを保証することです。具体的には、セキュリティを念頭に置いて設計し、脅威アクター、ベクトル、リスクを計画することを意味します。次に、リスクに基づいてエンジニアリング上の合理的な妥協を行います。
認証の核心は、リリースするものがその意図された目的に対して適切に安全であることを確認することです。具体的には、セキュリティを設計通りに実行し、脅威アクター、ベクトル、リスクを計画しました。そして、リスクに基づいてエンジニアリング上の合理的な妥協を行いました。
残念ながら、オープンソースの世界では、ソフトウェアがどのように使用されるかわからないことがよくあります。そして、過去 10 年間に私たちが学んだように、私たちのコモンズを適切に管理するための鍵は)、ライセンスで差別したり制限したりしてはいけないということです (翻訳者注: オープンソース ソフトウェアの使用方法
残念ながら、オープンソースでは、ソフトウェアがどのように使用されるかわからないことがよくあります。そして、私たちが過去 10 年にわたって (厳しい道を経て) 学んだように、共有コモンズの適切なガバナンスを実現するには、ライセンスを差別したり制限したりしないことが重要です (実際、それはオープンソースの一部です)意味）。
| 翻訳者注: オープンソースの定義は、OSI によって策定されたオープンソース ライセンス契約の 10 の基本原則です。これらの原則に違反するライセンス契約は、それ自体を「オープンソース」ライセンス契約と呼ぶことはできません。オープンソースの定義: https://zh.wikipedia.org/zh-cn/%E5%BC%80%E6%BA%90%E5%AE%9A%E4%B9%89
一部の義務は履行がほぼ不可能です。たとえば、「既知の悪用可能な脆弱性が存在しない製品を提供する」という義務があります。これは、特にオープンソース ソフトウェアの作成者がコードが下流でどのように統合されるかを知らないし、制御することもできないため、設定するのはほぼ不可能な標準です。
義務の中には、事実上履行が不可能なものもあります。たとえば、「既知の悪用可能な脆弱性を持たずに製品を納品する」という義務があります。これは設定するのがほぼ不可能なハードルです。特にオープンソースの作成者は、コードが下流でどのように統合されるかを知りませんし、制御することもできません。
次の質問は標準に関するものです。CRAは、「今後策定される」多数の国際標準（一般にCEN-CENELECによって開発されると考えられている）について言及した。一般に IT 業界、特にオープン ソースでは、これらの標準化団体 (ASF も含む) との協力実績はあまり良くありません。その理由の 1 つは、ほぼすべての主要なインターネット標準が IETF と W3C によって維持されているためです。実際、これらの標準化団体の憲章により、オープンソース団体が有意義な方法でメンバーになることを許可していないことは珍しくありません。
次の問題は規格に関するものです。CRA は、多数の「今後作成される」国際標準 (一般に CEN-CENELEC で作成されると想定されています) を参照しています。一般に IT 業界、特にオープン ソースは、これらの標準化団体と協力した実績があまりありません。その理由の 1 つは、ほぼすべての主要なインターネット標準 (ASF も) が IETF と W3C で維持されているためです。実際、これらの標準化団体の細則により、オープンソース団体が意味のある形でメンバーになることが許可されていないことは珍しくありません。
| 翻訳者注: オープンソース組織は、意味のある方法でメンバーになることを許可されていませんhttps://blog.opensource.org/another-issue-with-the-cyber-resilience-act-european-standards-bodies-are-inaccessible-オープンソースプロジェクト/へ
CRA は、パッチが適用されていない重大な脆弱性や悪用された脆弱性を、脆弱性が修正されるまでの時間制限内に ENISA (欧州連合機関) に開示することを義務付けています。これは、修正と (回避策) を責任を持って開示するという業界のベスト プラクティスに反します。
CRA は、パッチが適用されていない重大な脆弱性や悪用された脆弱性を、修正されるまでの数時間以内に ENISA (EU 機関) に開示することを要求しています。これは、業界のベストプラクティスである修正と回避策の責任ある開示に反するものです。
さらに、そのような時期尚早な報告は、是正情報の公開の妨げになるだけでなく、国際社会が同じ情報を要求する、あるいはさらに悪いことにそのような情報の共有を禁止する他国の規制に違反することを容易にします。これは、オープンソースが依存する公平で偏りのない報道という文化の中核を損なうことになります。
そして、この早すぎる報告は問題解決の妨げになるだけでなく、国際社会にとって、同じ情報を主張したり、さらに悪いことにそのような共有を禁止したりする他国に反感を抱きやすいのです。これにより、オープンソースが依存する公正かつ公平なレポート文化の根幹が破壊されます。
さらに、この情報は広く共有された場合にのみENISA にとって有益となるため、組織は賢明で世界的に「公平な」アプローチを選択し、これらの問題が決して聞かれないようにするという簡単な方法を選択する必要があります。あるいは、その逆を行い、（最初の）報告期限が終了する前、つまり問題が解決される前に問題を公開します。
そして、この情報は広く共有されて初めて ENISA にとって有益となるため、組織にとっては賢明で世界的に「公平な」選択肢を選択し、その情報について決して聞かないようにするという安易な道を選ぶのが合理的です。あるいは、その逆に、（最初の）報告期限がロールオーバーする直前、つまり修正される前に、単に物事を公開するだけです。
| 訳者注: 問題が解決されるまでは発表されない、あるいは問題があれば即座に全世界に発表されるという意味です。欧州連合の ENISA など、一部の特定の機関にのみ問題を通知することを優先するのではなく。
したがって、これは、CRA が善意であっても、最終的に逆効果になる可能性があることを示すもう 1 つの例です。
したがって、これは、CRA が善意を尽くして、最終的には正反対のことを達成する可能性がある、もう 1 つの例です。
現在のヨーロッパの IT 業界を見ると、IT 業界の脆弱なセキュリティ体制の根本原因は、通常、オープンソース (特に ASF のような組織によるもの) ではないことがわかります。実際にはまったく逆です。
現在、ヨーロッパの IT 業界を見ると、一般にオープンソースではないことがわかります (特に ASF などからのもの)。これが、IT 業界のセキュリティの悲惨な状態の根本原因です。まったく逆です。
対照的に、ヨーロッパの中小企業の多くは、依存しているシステムをめったに更新せず、セキュリティ問題の報告を扱うのが一般的に苦手です。また、ASF の (定期的な) アップデートでは、より多くの (再) 認証作業が必要となるため、ASF のアップデートやセキュリティ修正の受け入れが遅くなる可能性があります。
対照的に、ヨーロッパのほとんどの中小企業は依存関係を更新することはめったになく、一般的にセキュリティ問題の報告への対処に精通していません。また、ASF での (定期的な) アップデートにより、さらに多くの (再) 認証作業が発生し、当社のアップデートやセキュリティ修正を理解するのがさらに遅くなる可能性があります。
ただし、CRA 内には効果的であると考えられるアプローチが多数あり、これは ASF などのオープンソース組織のレベルにも当てはまります。
ただし、CRA には実現可能であり、効果が期待できることがわかっているものも数多くあります。ASF などのオープンソース組織のレベルでも。
実際、脆弱性レポートの適切なトリアージ、責任ある開示、CVE (共通脆弱性と暴露) の登録、バージョン番号の慎重な使用など、そのほとんどは現在すでに実行されています。それに加えて、当社では適切なガバナンスも導入しており、プロジェクトは取締役会に報告され、必要なときにプロジェクトが屋根裏部屋に移動されることもあります。 )
実際、脆弱性レポートの適切なトリアージ、責任ある開示、CVE の登録、バージョン番号の注意など、そのほとんどは今日すでに実行されています。そして、これに対して私たちは、プロジェクトごとに取締役会に報告し、時が来たら屋根裏部屋に移されるプロジェクトを時折採用するなど、優れたガバナンスを適用しています。
さらに問題なのは、CRA が、オープンソースの貢献やパブリック (または共有) ドメインの非常に脆弱な「win-win」状況を脅かすか、業界のグッドプラクティスに反するか、あるいは単に達成が不可能な一連の要件も課していることです。 , つまり、オープンソースのパブリックドメインを商用ドメインと同等に扱おうとします。
さらに問題は、CRA が、オープンソースの貢献や私たちのコモンズという非常に脆弱な「win-win」を脅かす、業界の優良慣行に反するか、まったく不可能な、あらゆる範囲の要件を積み上げていることです。オープンソース・コモンズを商業部門と同様に扱います。
実際、米国はこのことを認識しているようで、米国標準技術研究所 (NIST) と協力して、業界での既存の優れた慣行を文書化しようとしています。
実際、米国はこのことを認識しているようで、NIST と協力して業界と協力してこれらの既存の優れた実践を文書化する道を歩んでいます。
ある意味、米国はボイラーコードを作成した歴史的に技術者と個人が主導したACMEプログラムに近いようだが、EUは専門家よりもメーカーに質問することに関心があるようだ。
そしてある程度、米国はボイラーコードを作成した歴史的な技術者と個人主導の ACME プロセスに近いようですが、EU は専門家ではなくメーカーに依頼する方向にあるようです。
「インターネットは検閲といううまく機能するメカニズム（まるで部屋の中の象が本物であるかのように）を不具合として扱い、それを回避しようとしている」（ジョン・ペリー・バーロウ）。
もちろん、この部屋には象がいます。それは、「インターネットは検閲を機能不全として扱い、それを回避する」（ジョン・ペリー・バーロウ）という、よくできたメカニズムです。
| 訳者注: 部屋の中に象がいます。これは、「問題があまりにも大きく、または面倒なので、誰もそれに手を出そうとしない」という意味です。
1990 年代に米国が暗号化ソフトウェアを規制しようとしたときに、このメカニズムが実際に動作しているのを目にしました。「輸出規制要件を満たす」暗号化ソフトウェア技術のみが米国から出国できる。これにより、多くの仮想通貨業界と人材が物理的かつ法的に米国を離れ、業界は米国から欧州に移転しました。そこでは、企業は BXA (輸出管理局) の規則に制限されることなく、コードを米国に入力するだけで、あるいはヨーロッパから世界中に出荷することができます。これが正常化するまでに 20 年以上かかりました (ASF では今でもこの痕跡が見られます)。
私たちは、米国が暗号ソフトウェアを規制しようとした 90 年代にこのメカニズムが機能するのを見てきました。そして、「輸出強度」のある暗号のみが米国から出国できる可能性がある。これにより、多くの暗号業界とスタッフが物理的にも法的にも米国を離れることになりました。そしてその産業が米国から欧州へ移動すること。そこから企業はコードを米国にインポートし直すか、米国の BXA 規則に邪魔されずにヨーロッパから世界の他の地域に出荷するだけです。これが正常化するまでに20年以上かかりました（そしてASFにはまだその痕跡が残っています）
| 翻訳者注: この状況の残骸は今でも ASF https://www.apache.org/licenses/exports/で見ることができます。
したがって、ASF は、CRA によってコミュニティが分断されるリスクも考慮する必要があります。特に、ヨーロッパ諸国に点在する ASF プロジェクト コミュニティが、ASF プロジェクトに CRA を実装するために十分な能力と力を動員できない場合にはなおさらです。
したがって、ASF として、CRA に関してコミュニティが分裂する可能性があるリスクも考慮する必要があります。特に、私たちのヨーロッパのコミュニティがASFでCRAを実施するのに十分な能力と能力を集めることができない場合はそうです。
産業研究エネルギー評議会 (ITRE) の投票は、2023 年 7 月 17 日の週に行われます。これは欧州議会の議員に投票方法について助言する議会委員会です。投票後、2023年夏の休会後に三者協議（トライアローグ：欧州議会、欧州連合理事会、欧州委員会）が開始される可能性が高い。これまでのところそうなっているように、ビッグスリーが合意に達すれば、早ければ12月にもプロセスが終了する可能性がある。
2023 年 7 月 17 日の週に ITRE 投票が行われます。これは欧州議会議員に投票方法を勧告する議会委員会です。それが完了すると、トライアローグは2023年夏の休会後に開始される可能性が高い。3 つの権力者の間で合意が得られれば (現時点ではそう思われますが)、このプロセスは早ければ 12 月に完了する可能性があります。
したがって、非常に短時間で産業・研究・環境省の議員に連絡を取ることができます。一般的に、メッセージが礼儀正しく、特定の政治的または経済的地位を持つ当事者（中小企業団体の CEO など）によって送信され、国会議員に現地の言語で送信されるなど、現地の文脈と一致している場合に限ります。そして、それは彼らが代表する政党の政治を認識するのに役立ちます。オープンソースの規制は意図的なものであり、CRA には多くの常識的な良い (オープンソース) 実践があるため、サイバー レジリエンス法: 私たち (オープンソース コミュニティ) が何かを達成し、要件を満たしていることが期待されています。包括的例外の段階。
したがって、非常に短期間で ITRE の MEP に連絡を取ることができます。これらのメッセージが礼儀正しく、政治的または経済的立場を持つ当事者 (CEO、中小企業団体など) によって送信され、自分の国の国会議員に自分の現地の言語で伝えるなど、自分の地域の環境に合わせて送信されている場合は、一般に役に立ちます。 、そして彼らが代表する政党の政治的立場に留意します。オープンソースの規制は意図的なものであり、CRA には多くの常識的で良い (オープンソース) 慣行も存在するため、包括的な例外を求めることが生産的である段階はすでに過ぎていると予想されています。
| 訳者注: 欧州議会議員（産業、研究、環境担当）
https://www.europarl.europa.eu/committees/en/itre/home/members
ASFはEU理事会版に焦点を当てる（その文書は通常、三者協議で「勝利」し、現在ではITREの合意文書よりも優れているため）。これを行うには、あなたの助けが必要です。特に、あなたの国の大規模な中小企業の幹部を雇用するのに協力していただけ、CRA が与えるマイナスの影響を国家レベルで説明する意欲がある場合（ASF 広報副会長に連絡してください） ; dirkx@apache@org)。
ASF では、私たちは理事会バージョンに焦点を当てることを期待しています (そのテキストは一般に「勝利」しており、現時点では ITRE コンセンサステキストよりもわずかに優れているため)。このために、私たちはあなたの助けを借りることができます。特に、あなたの国の大規模な中小企業の経営陣を関与させ、国家レベルでの影響を説明する意欲を持ってもらうのを手伝っていただければ（広報担当副社長、dirkx@apache@org までご連絡ください） ）。
| 翻訳者注: 最後の数段落の要求はかなり漠然としているように見えるかもしれませんが、実際には「オープンソースはまだ成功しておらず、同志たちはまだ努力する必要がある」という意味です。
転載元 | オープンソースレインフォレスト
編集者 | ワン・ジュン
関連読書 | 関連読書
Bobo の CommunityOverCode Asia 2023 の組織化/
COSCon'23 オープンソース マーケットへの参加の感想: 芝生のオープンソース パーティーに行こう
開元協会の紹介
2014 年に設立された開源協会は、オープンソースの理念に自発的に貢献する個人メンバーで構成され、「貢献、合意、共同統治」の原則に従って形成され、常にベンダー中立性の特徴を維持してきました。 「国際統合、コミュニティ開発、プロジェクトインキュベーション」を使命とするオープンソースコミュニティコンソーシアム。Kaiyuansheは、オープンソースをサポートするコミュニティ、企業、政府関連部門と積極的に緊密に協力し、「中国に拠点を置き、世界に貢献する」というビジョンのもと、健全で持続可能なオープンソースエコロジーを構築し、中国のオープンソースコミュニティを促進することを目指しています。グローバルなオープンソース システムの積極的な力となることを目指します。
2017 年、Kaiyuanshe は、ASF などの国際的なトップ オープンソース財団のガバナンス モデルを参照して運営される、完全に個人メンバーで構成される組織に変わりました。過去 9 年間で、何万人ものオープンソースの人々を結び付け、数千人のコミュニティ メンバーとボランティア、国内外の数百人の講師を集め、数百のスポンサー、メディア、コミュニティ パートナーと協力してきました。
