Article 24 Regulation (EU) 2024/2847 · Chapter II 法規 (EU) 2024/2847 · 第二章

Open-source software stewards — the light-touch regime 開源軟體 stewards，輕觸式規範

A short article about a contested figure. Foundations, registries and corporate-OSS programmes that "play a main role in ensuring the viability" of FOSS used in commercial products carry a documented cybersecurity policy, partial Article 14 reporting, and a duty to cooperate with market surveillance authorities. They do not become manufacturers, do not affix CE markings, and do not carry full Article 13. 針對一個爭議角色的短條文。對商用產品所使用的 FOSS「於確保其存續上扮演主要角色」的基金會、登錄處與企業 OSS 計畫，應持有書面網路安全政策、部分第 14 條通報義務、並負與市場監督機關合作的責。它們不成為製造商、不加施 CE 標示、不承擔完整第 13 條義務。

Paragraphs段落數 · 3 Applies from適用起始 · 11 Dec 2027 (Art 14 obligations from 11 Sep 2026) Primary audience主要對象 · FOSS foundations · Corporate OSS programmes · Package registriesFOSS 基金會 · 企業 OSS 計畫 · 套件登錄處 Last reviewed最後校閱 · 2026-04-25 Status狀態 · Working書寫

Block 1 · Official text 區塊 1 · 官方條文

What the Regulation actually says 條文實際怎麼寫

Source. Consolidated text from Regulation (EU) 2024/2847, Article 24, as published in OJ L 2024/2847, 20 November 2024. The definition of "open-source software steward" sits in Article 3(14); it is reproduced below for context. Translation is unofficial; refer to EUR-Lex for binding text. 來源。條文自《法規 (EU) 2024/2847》第 24 條整合文本，發布於 OJ L 2024/2847，2024 年 11 月 20 日。「開源軟體 steward」之定義位於第 3 條第 14 項；下方一併附上以供脈絡。中文為非官方翻譯。

Definition (Article 3(14)) 定義（第 3 條第 14 項） Article 3(14)

"Open-source software steward" means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products.

「開源軟體 steward」係指除製造商以外之法人，其目的或宗旨為系統性、持續性地支援特定具數位元素產品之開發，該等產品須符合自由開源軟體之定義且為商業活動所擬使用，並確保該等產品之存續。

Recital 19 elaborates: includes "certain foundations as well as entities that develop and publish free and open-source software in a business context, including not-for-profit entities". Sustained support includes "hosting and managing of software development collaboration platforms, the hosting of source code or software, the governing or managing of products with digital elements qualifying as free and open-source software as well as the steering of the development of such products". Stewards do not affix the CE marking.

Recital 19 進一步說明：包含「某些基金會以及在商業脈絡下開發並發佈自由開源軟體之實體，含非營利實體」。持續性支援包括「託管與管理軟體開發協作平台、託管原始碼或軟體、治理或管理符合自由開源軟體之具數位元素產品、以及引導該等產品之開發」。Stewards 不加施 CE 標示。

Cybersecurity policy 網路安全政策 ¶ 1

1. Open-source software stewards shall put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product. That policy shall also foster the voluntary reporting of vulnerabilities as laid down in Article 15 by the developers of that product and take into account the specific nature of the open-source software steward and the legal and organisational arrangements to which it is subject. That policy shall, in particular, include aspects related to documenting, addressing and remediating vulnerabilities and promote the sharing of information concerning discovered vulnerabilities within the open-source community.

1. 開源軟體 stewards 應建立並以可驗證之方式書面記載一份網路安全政策，以促進具數位元素產品之安全開發，並使該產品開發者能有效處理弱點。該政策亦應促進該產品開發者依第 15 條進行弱點之自願通報，並斟酌開源軟體 steward 之特殊性質、其所適用之法律與組織安排。該政策尤應包含與弱點之記錄、處理、修補相關之面向，並促進開源社群內就所發現之弱點相互分享資訊。

Cooperation with market surveillance 與市場監督機關之合作 ¶ 2

2. Open-source software stewards shall cooperate with the market surveillance authorities, at their request, with a view to mitigating the cybersecurity risks posed by a product with digital elements qualifying as free and open-source software. Further to a reasoned request from a market surveillance authority, open-source software stewards shall provide that authority, in a language which can be easily understood by that authority, with the documentation referred to in paragraph 1, in paper or electronic form.

2. 開源軟體 stewards 應於市場監督機關提出請求時與其合作，以減緩符合自由開源軟體之具數位元素產品所構成之網路安全風險。經市場監督機關書面合理請求，開源軟體 stewards 應以該機關易於理解之語言，提供第 1 項所指之文件，紙本或電子形式皆可。

Partial Article 14 application 第 14 條之部分適用 ¶ 3

3. The obligations laid down in Article 14(1) shall apply to open-source software stewards to the extent that they are involved in the development of the products with digital elements. The obligations laid down in Article 14(3) and (8) shall apply to open-source software stewards to the extent that severe incidents having an impact on the security of products with digital elements affect network and information systems provided by the open-source software stewards for the development of such products.

3. 第 14(1) 條所定之義務，於開源軟體 steward 參與該具數位元素產品開發之範圍內適用之。第 14(3) 條與第 14(8) 條所定之義務，於影響具數位元素產品安全之重大事件波及該開源軟體 steward 為該等產品開發所提供之網路與資訊系統之範圍內適用之。

The Article 14 paragraphs not applying to stewards: §2 (early-warning + intermediate + final report cadence detail for products), §4 (post-resolution reporting), §5 (manufacturer-CSIRT cadence further specs), §6 (CSIRT helpdesk), §7 (delegated act for delay), §10 (implementing acts on format). Article 14(1) (severe-incident notification trigger) and Art 14(3) + (8) (notify users when relevant) are the substantive applicable provisions, scoped to development involvement.

第 14 條不適用於 steward 之段落：§2（產品早期警訊 + 中間 + 終結報告節奏細節）、§4（事後回報）、§5（製造商 - CSIRT 節奏進一步規範）、§6（CSIRT helpdesk）、§7（授權法案延遲機制）、§10（格式執行法案）。實際適用之實質條款為第 14(1) 條（重大事件通報觸發）與第 14(3) + (8) 條（必要時通知使用者），且範圍限於 steward 參與開發之部分。

Block 2 · Plain language 區塊 2 · 白話解讀

What "steward" actually means in practice 「steward」實務上是什麼意思

Article 24 was the most contested clause during the CRA's legislative passage. The Commission's original proposal would have treated open-source software developers as manufacturers — drawing immediate alarm from foundations, large maintainers, and the wider FOSS community. The final text introduces the "steward" category as a middle ground: a regulated party, but with a smaller footprint than a full Article 13 manufacturer.

第 24 條是 CRA 立法過程中爭議最大的條款。執委會原本的提案會把開源軟體開發者視同 manufacturer，此舉立刻引發基金會、主要維護者跟更廣大 FOSS 社群的警報。最終條文引入「steward」這個中間地帶類別：受規範但其規範足跡比完整第 13 條製造商小很多。

The article does three things — and explicitly does not do four others.

這條做了三件事，而且明確說它不做另外四件事：

Stewards mustStewards 必須	Reference引用
Have a documented cybersecurity policy具備書面網路安全政策 — covering vulnerability documentation, addressing, remediation, community sharing涵蓋弱點記錄、處理、修補、社群分享	Article 24(1)
Cooperate with market surveillance與市場監督機關合作 — on reasoned request, provide policy documentation in a language the authority understands經書面合理請求，以該機關易於理解的語言提供政策文件	Article 24(2)
Apply Article 14 partially部分適用第 14 條 — to the extent the steward is involved in development; covers severe incidents impacting steward-provided dev infrastructure於 steward 參與開發的範圍；涵蓋影響 steward 所提供開發基礎設施的重大事件	Article 24(3)

Stewards do NOTStewards 不須	Reference引用
Become a manufacturer or assume Article 13 obligations成為製造商、承擔第 13 條義務	Implicit in Recital 19 final sentence + Art 3(14) "other than a manufacturer"隱含於 Recital 19 最後一句與第 3(14) 條「製造商以外的法人」
Affix the CE marking加施 CE 標示	Recital 19 final sentence (explicit)Recital 19 最後一句（明示）
Conduct conformity assessment under Article 32 / Annex VIII執行第 32 條 / 附件八符合性評鑑	Conformity assessment is a manufacturer obligation; stewards are not manufacturers符合性評鑑為製造商義務；steward 非製造商
Maintain a technical file under Article 31 / Annex VII依第 31 條 / 附件七維護技術檔案	Article 31 applies to manufacturers第 31 條適用於製造商

Three points worth absorbing before figuring out whether your organisation falls under Article 24.

在判斷你的組織會不會落入第 24 條之前，三個要點先抓住：

"Steward" requires legal personhood plus sustained, systematic support. A natural person who maintains a popular GitHub repo in their spare time is not a steward — Article 3(14) is explicit that a steward is a legal person. A small unincorporated open-source collective is not a steward. A foundation registered as a non-profit corporation that hosts and maintains a project's release infrastructure on an ongoing basis is. The qualifier "systematically providing support on a sustained basis" excludes one-off donations or sporadic contributions.

「Steward」要求具備法人地位、且系統性、持續性提供支援。下班時間維護熱門 GitHub repo 的個人不是 steward：第 3(14) 條明確規定 steward 必須是法人。小型沒有法人化的開源集體也不是 steward。但註冊為非營利法人、持續託管並維護某個專案發布基礎建設的基金會就是。「系統性、持續性提供支援」這個修飾語把一次性捐款或零散貢獻排除在外。
Commercial-intent qualifier limits scope, but not as much as it appears. Article 3(14) requires the products to be "intended for commercial activities". Recital 19 expands this — an intention for integration into monetised products counts even when the FOSS itself is freely distributed. So a steward of a library used by commercial vendors as an embedded component (which is most popular libraries) falls within scope. The Commission's 2026 published draft guidance on CRA application is expected to give 16 examples of how this scope test applies in practice; until that lands, scope is read broadly.

「為商業活動所用」這個修飾語限縮範圍，但限縮幅度沒有表面看起來大。第 3(14) 條要求產品必須是「為商業活動所用」。Recital 19 對此做了擴充，即使 FOSS 本身免費發佈，只要意圖被整合進變現產品就算。所以商業廠商作為嵌入元件使用的函式庫的 steward（也就是大部分熱門函式庫）都落入範圍。執委會 2026 公開草案版的 CRA 適用指引預計提供 16 個範圍判斷的適用案例；在這份指引落地之前，範圍應該用較寬的方式解讀。
Article 14 partial application is narrower than first reading suggests. Art 24(3) is carefully scoped. Article 14(1) — the severe-incident notification trigger — applies "to the extent that they are involved in the development". So a foundation that hosts source-code infrastructure but does not direct or commission development of a specific product owes Article 14(1) to a much thinner perimeter than a steward that actively governs releases. Article 14(3) and (8) — user notification when severe incidents impact products — apply only "to the extent that severe incidents... affect network and information systems provided by the open-source software stewards for the development of such products". The trigger is incidents that hit the steward's own infrastructure, not arbitrary downstream incidents in commercial products that integrate the FOSS.

第 14 條的部分適用，比初讀的感受還窄。第 24(3) 條的措辭很精準。第 14(1) 條（嚴重事件通報觸發）適用於「steward 參與這些產品開發的範圍」。所以一個只託管原始碼基礎建設、不主導或委託特定產品開發的基金會，第 14(1) 條義務的範圍比積極治理發布的 steward 窄得多。第 14(3) 條跟第 14(8) 條（嚴重事件影響產品時通知使用者）只在「嚴重事件...影響該開源軟體 stewards 為這些產品開發所提供的網路與資訊系統的範圍」內適用。觸發要件是命中 steward 自有基礎建設的事件，不是整合該 FOSS 的商業產品下游發生的任意事件。

A practical note on identification. Whether a specific organisation is a "steward" is a fact-finding exercise, not a self-declaration. A market surveillance authority, looking at a popular FOSS project that has caused downstream incidents, can ask: who is the legal person providing sustained support? Is the project intended for commercial activities? If the answers point to a single registered legal person who governs releases, hosts infrastructure, and steers development, Article 24 likely applies — regardless of whether the organisation calls itself a "steward" in its own marketing.

實務認定提示：某個組織是不是「steward」，是事實調查的事，不是自我宣告。市場監督機關在檢視造成下游事件的熱門 FOSS 專案時可以問：誰是提供持續性支援的法人？這個專案是不是被商業活動所用？如果答案指向某一個已登記法人，它治理發布、託管基礎建設、引導開發：第 24 條很可能適用，不論這個組織自家行銷中有沒有自稱「steward」。

Block 3 · APAC perspective 區塊 3 · APAC 觀點

Three patterns APAC manufacturers should map to their FOSS dependencies APAC 製造商應該套到自己 FOSS 依賴的三種型態

For APAC OEMs and ODMs, Article 24 is rarely about becoming a steward — most APAC manufacturers integrate FOSS rather than steward it. The article matters because it determines who upstream is on the hook when a vulnerability lands in a FOSS component shipped inside a commercial product.

對 APAC OEM 跟 ODM 來說，第 24 條很少跟成為 steward 有關，多數 APAC 製造商是在整合 FOSS、不是 steward FOSS。這條重要的地方在於：當弱點出現在商用產品內部搭載的 FOSS 元件時，上游誰要負責。

Three patterns are worth mapping out concretely.

三種型態值得具體對照：

Pattern A: FOSS with an identifiable steward. Examples include Linux kernel (Linux Foundation), Python (Python Software Foundation), Apache projects (Apache Software Foundation), Eclipse projects (Eclipse Foundation). When a kernel-level vulnerability hits, the steward has Article 24(2) cooperation obligations and partial Article 14 reporting obligations under Art 24(3). The APAC manufacturer integrating the FOSS still carries full Article 13 responsibility for the integrated product — the steward's regime does not transfer or share the manufacturer's burden, only adds an upstream cooperation point. Practical implication: when assessing FOSS components in your SBOM, check whether each significant component has an identifiable legal-person steward. That is the entity that may receive a market surveillance enquiry alongside (not instead of) the manufacturer.

型態 A：有可識別 steward 的 FOSS。例如 Linux kernel（Linux Foundation）、Python（PSF）、Apache 專案（ASF）、Eclipse 專案（Eclipse Foundation）。當核心層級弱點出現時，steward 依第 24(2) 條承擔合作義務、依第 24(3) 條承擔部分第 14 條通報義務。整合這個 FOSS 的 APAC 製造商仍然對整合後產品負完整第 13 條責任，steward 規範不會移轉或分擔製造商負擔，只是多一個上游合作點。實務意涵：評估 SBOM 裡的 FOSS 元件時，檢查每個重要元件有沒有可識別的法人 steward。這個主體可能跟製造商並列（不是替代）收到市場監督機關的查詢。

Pattern B: FOSS with no identifiable steward. Examples include many small libraries on npm / PyPI / crates.io / Maven Central maintained by individuals or unincorporated collectives, or abandoned projects without active governance. When a vulnerability lands here, there is no Article 24 entity to cooperate with — the regulatory burden flows entirely to the manufacturer integrating the FOSS, under Article 13(5) due-diligence obligations. APAC manufacturers should treat unstewarded FOSS components as higher-risk: not because they are technically less secure, but because there is no upstream cooperation point and the manufacturer carries the full coordinated-vulnerability-disclosure load alone. Documentation in the technical file (Annex VII) should reflect this — explicitly note the absence of a steward and the manufacturer's mitigation plan.

型態 B：找不到 steward 的 FOSS。例如 npm / PyPI / crates.io / Maven Central 上由個人或未法人化集體維護的小型函式庫，或沒治理的廢棄專案。當弱點出現在這裡時，沒有第 24 條主體可以合作，規範負擔完全流向整合這個 FOSS 的製造商，落在第 13(5) 條盡職調查義務上。APAC 製造商應該把沒 steward 的 FOSS 元件當成較高風險來對待：不是因為它們在技術上較不安全，而是因為沒有上游合作點，製造商必須獨自承擔完整的協調弱點揭露負擔。技術檔案（附件七）中的文件應該反映這一點，明示這個元件沒有 steward，並載明製造商的緩解計畫。

Pattern C: corporate-OSS programmes that may qualify as stewards. Examples include Google's open-source releases (Tensorflow, Kubernetes early stages), Meta's React, Microsoft's TypeScript / VS Code, large hardware vendors' driver projects. When a corporate entity systematically supports a FOSS project intended for commercial integration, that entity may meet the Article 3(14) test and become a steward — regardless of whether it considers itself a foundation. For APAC manufacturers integrating these projects, the practical question is: who within the corporate parent is the named legal person responsible for steward obligations? Often this is unclear in the early CRA period and may only become testable when an incident occurs. Building a contact path with the upstream entity early — not just a GitHub issue tracker, but a documented legal-cooperation channel — is the practical hedge.

型態 C：可能符合 steward 的企業 OSS 計畫。例如 Google 的開源發布（Tensorflow、Kubernetes 早期）、Meta 的 React、Microsoft 的 TypeScript / VS Code、大型硬體商的驅動程式專案。當某個企業實體系統性支援一個被商業整合所用的 FOSS 專案時，這個實體可能符合第 3(14) 條測試而成為 steward，不管它自己是不是把自己當成基金會。對整合這類專案的 APAC 製造商，實務問題是：企業母公司內哪一個人是承擔 steward 義務的具名法人？這在 CRA 早期通常不清楚，可能要到事件發生時才能驗證。實務上的避險方式是：在事件發生前先跟上游實體建立聯繫路徑，不只是 GitHub issue tracker，而是書面的法律合作管道。

A practical conclusion. For APAC manufacturers, Article 24 should drive an addition to your existing FOSS due-diligence process under Article 13(5): for each significant FOSS component in your SBOM, classify it as Pattern A / B / C, document the steward (or its absence) in the technical file, and establish written cooperation channels with Pattern A and Pattern C upstreams before an incident occurs. This does not eliminate manufacturer responsibility but does materially reduce the time-to-cooperation when a real vulnerability hits.

實務結論：對 APAC 製造商來說，第 24 條應該驅動既有第 13(5) 條 FOSS 盡職調查流程的擴充：把 SBOM 裡每個重要 FOSS 元件分類成型態 A / B / C，在技術檔案中記載 steward（或記載「沒有 steward」），並在事件發生之前跟型態 A 跟型態 C 的上游建立書面合作管道。這雖然沒辦法消除製造商責任，但能在真實弱點出現時、明顯縮短合作的回應時間。

Block 4 · Cross-regulation map 區塊 4 · 跨法規對照

Open-source treatment across regulatory regimes 各規範體制對開源之處理

CRA Article 24 is one of the first concrete legal regimes in the world specifically targeting open-source software organisations. The table below compares Article 24 against adjacent frameworks across jurisdictions — some of which are themselves laws (NIS2, NIS2 Implementing Reg, US EO 14028) and some are voluntary technical guidance (NIST SP 800-218 SSDF). The mix is deliberate: APAC manufacturers and FOSS stewards routinely face all of these in the same conversation, and conflating the legal force of each is a common error. Each row's legal status is noted in the FOSS-treatment cell.

CRA 第 24 條是全球少數具體針對開源軟體組織的法律規範之一。下表跨司法管轄區比較第 24 條跟其他相鄰框架，有些本身是法律（NIS2、NIS2 Implementing Reg、US EO 14028）、有些是 voluntary 技術指引（NIST SP 800-218 SSDF）。這個混合是刻意的：APAC 製造商跟 FOSS stewards 常常在同一場對話裡同時面對這些東西，把它們的法律強度當成一樣是常見的錯誤。每一列的法律地位都在「FOSS 處理」欄裡標出來。

CRA Article 24

Steward category: documented cybersecurity policy + cooperation + partial Art 14 reporting; no manufacturer status. Reference point.

Steward 類別：書面網路安全政策 + 合作 + 部分第 14 條通報；不是製造商。 基準點。

NIS2 Directive (EU) 2022/2555

EU law (Directive). Applies to "essential" and "important" entities by sector and size; FOSS organisations are not specifically named, but a foundation that operates a registry / hosting platform may fall within "digital infrastructure" or "ICT service management" sectors. Different axis. NIS2 regulates organisations as cybersecurity-mature entities; CRA Article 24 regulates stewards as upstream-of-product participants. Both can apply to the same entity simultaneously.

歐盟法律（Directive）。依部門與規模適用於「重要」跟「關鍵」實體；FOSS 組織沒被具體點名，但營運登錄處 / 託管平台的基金會可能落入「數位基礎設施」或「ICT 服務管理」部門。 不同軸。NIS2 將組織當作網路安全成熟實體規範；CRA 第 24 條將 steward 當作產品上游參與者規範。兩者可同時適用於同一實體。

NIST SP 800-218 SSDF (US)

Voluntary technical guidance. Secure-development framework, not a law. Specifically references FOSS components in supply-chain (PO.1.3, PS.3.1, PS.3.2). Targets producers; no separate steward category. SSDF puts the FOSS-handling obligation entirely on the integrating producer, mirroring CRA Article 13(5). It does not create a steward-side regime. CRA Article 24 is innovative in regulating upstream stewards as named parties.

voluntary 技術指引。是安全開發框架、不是法律。在供應鏈中具體引用 FOSS 元件（PO.1.3、PS.3.1、PS.3.2）。目標是生產者；沒獨立 steward 類別。 SSDF 將 FOSS 處理義務完全置於整合性生產者，鏡射 CRA 第 13(5) 條。其不建立 steward 側規範。CRA 第 24 條於將上游 steward 規範為具名當事人方面具創新性。

NIS2 Implementing Regulation (EU) 2024/2690

EU law (Implementing Regulation). Sector-specific NIS2 obligations for cloud, DNS, registries, etc. — does not specifically address FOSS stewards. Adjacent for stewards that operate registry-like platforms (e.g. PyPI, npm). Such platforms may face NIS2 sector obligations regardless of CRA steward status.

歐盟法律（Implementing Regulation）。針對雲端、DNS、登錄處等部門的 NIS2 特定義務，沒特別處理 FOSS stewards。 對營運登錄處型平台的 stewards（如 PyPI、npm）相鄰。該類平台可能不論 CRA steward 地位，都受 NIS2 部門義務規範。

US Executive Order 14028 + OMB M-22-18

US executive instrument (binding on federal procurement only). Federal procurement of software requires SBOM and self-attestation by software producers. FOSS-only producers (no commercial distribution) generally not in scope. No equivalent steward concept. The US framework treats FOSS as a supply-chain input to commercial producers, not as a separately regulated category.

美國行政命令（只對聯邦採購具強制力）。聯邦軟體採購要求軟體生產者提供 SBOM 跟自我聲明。只是 FOSS 的生產者（沒商業發佈）通常不在範圍。 無對應 steward 概念。美國框架將 FOSS 視為商業生產者的供應鏈投入，非獨立受規範類別。

Article 25 (Voluntary security attestation)

Future delegated act will create voluntary attestation programmes for FOSS, distinct from the steward regime. Companion mechanism within CRA. Stewards may participate in Article 25 attestation; manufacturers integrating FOSS may use Article 25 attestations to support due-diligence under Article 13(5). The two articles work together.

未來授權法案將為 FOSS 建立自願性聲明計畫，與 steward 規範區別。 CRA 內部的配套機制。Stewards 可參與第 25 條聲明；整合 FOSS 的製造商可使用第 25 條聲明以支援第 13(5) 條盡職調查。兩條文相輔相成。