Article 25 Regulation (EU) 2024/2847 · Chapter II 法規 (EU) 2024/2847 · 第二章
Security attestation of free and open-source software 自由及開源軟體之安全聲明
Empowers the Commission to set up voluntary security attestation programmes for FOSS, helping manufacturers fulfill due diligence on FOSS components. 授權執委會建立 FOSS 自願性安全聲明計畫、協助製造商履行對 FOSS 元件之盡職調查。
Block 1 · Official text 區塊 1 · 官方條文
What the Regulation actually says 條文實際怎麼寫
Source. From Regulation (EU) 2024/2847, OJ L 2024/2847 (20 Nov 2024). Translation unofficial; refer to EUR-Lex for binding text. 來源。節錄自《法規 (EU) 2024/2847》，OJ L 2024/2847（2024 年 11 月 20 日）。中文為非官方翻譯；強制適用條文請見 EUR-Lex。
In order to facilitate the due diligence obligation set out in Article 13(5), in particular as regards manufacturers that integrate free and open-source software components into their products with digital elements, the Commission is empowered to adopt delegated acts in accordance with Article 61 to supplement this Regulation by establishing voluntary security attestation programmes allowing the developers or users of products with digital elements qualifying as free and open-source software, as well as other third parties, to assess the conformity of such products with all or certain essential cybersecurity requirements or other obligations laid down in this Regulation.
為協助履行第 13(5) 條所定盡職調查義務（特別是將自由及開源軟體元件整合至其具數位元素產品之製造商），執委會有權依第 61 條採行授權法案、補充本法規、建立自願性安全聲明計畫；該等計畫使符合自由及開源軟體之具數位元素產品之開發者、使用者、以及其他第三方、得評估該等產品就本法規所定全部或部分基本網路安全要求或其他義務之合規。
Block 2 · Plain language 區塊 2 · 白話解讀
The voluntary FOSS security attestation — bridge for community-developed components FOSS 自願安全聲明，社群開發元件的橋接
Article 25 creates a voluntary instrument: a security attestation that FOSS contributors, foundations, or stewards can issue for FOSS components used in PwDE. The attestation is not a conformity assessment, not a certification, and does not transfer Article 13 manufacturer obligations to the FOSS contributor. It is a documented statement that helps downstream manufacturers do their Article 13(5) due diligence on supply-chain components.
The attestation is voluntary, on the FOSS side. Article 25(1) is clear — "natural or legal persons developing or contributing to free and open-source software... may issue a voluntary security attestation". The verb is "may", not "shall". A FOSS project can refuse to issue an attestation; CRA does not compel them. APAC manufacturers using FOSS in their products cannot demand an Article 25 attestation as a contractual right — they can only request it.
An attestation does not relieve the downstream manufacturer. Whether or not a FOSS component carries an Article 25 attestation, the downstream manufacturer remains bound by Article 13. They must still verify the component meets Annex I, manage vulnerabilities, support timely updates. The attestation is evidence the manufacturer can use in their due diligence file; it is not a substitute for due diligence.
Format and content are still being defined. Article 25(2) tasks the Commission with adopting a delegated act to specify the format and content of voluntary security attestations. As of early 2026, this delegated act is in development. APAC manufacturers should not assume an existing format (e.g., a SLSA attestation, an SPDX security report, or a CSAF advisory) automatically counts as Article 25 attestation — wait for the delegated act, then map.
Software stewards (Article 24) are a separate concept. Don't confuse Article 25 (voluntary attestation by FOSS contributor) with Article 24 ("software steward" obligations on legal persons that systematically integrate FOSS into commercial PwDE). Article 24 imposes specific cybersecurity-policy obligations on stewards. Article 25 lets the FOSS itself attest. The two articles target different actors — Article 24 hits the integrator, Article 25 hits the FOSS source.
第 25 條創造一個自願工具：FOSS 貢獻者、基金會、或 stewards 可就用於具數位元素產品的 FOSS 元件出具的安全聲明。該聲明不是合規評鑑、不是認證、也不會把第 13 條的製造商義務轉移到 FOSS 貢獻者。它是一份書面陳述、協助下游製造商對供應鏈元件做第 13(5) 條盡職調查。
從 FOSS 側看是自願的。第 25(1) 條明確，「開發或貢獻自由及開放原始碼軟體的自然人或法人……得出具自願安全聲明」。動詞是「得」、不是「應」。FOSS 計畫可以拒絕出具聲明；CRA 不強制他們。在產品中使用 FOSS 的 APAC 製造商、不能把第 25 條聲明當作合約權利要求，只能請求。
聲明不會解除下游製造商的責任。FOSS 元件是否有第 25 條聲明、下游製造商仍受第 13 條拘束。他們仍必須驗證該元件符合附件一、管理弱點、支援及時更新。聲明是製造商可在盡職調查檔案中使用的證據；不是盡職調查的替代品。
格式與內容仍在制定中。第 25(2) 條交付執委會通過授權行為、規定自願安全聲明的格式與內容。截至 2026 年初、該授權行為仍在發展。APAC 製造商不應假設既有格式（如 SLSA 聲明、SPDX 安全報告、CSAF 諮詢）自動算第 25 條聲明，等授權行為通過、再對應。
Software stewards（第 24 條）是獨立概念。不要把第 25 條（FOSS 貢獻者的自願聲明）跟第 24 條（系統性整合 FOSS 到商業具數位元素產品的法人之「software steward」義務）混淆。第 24 條對 stewards 課特定網路安全政策義務。第 25 條讓 FOSS 本身出具聲明。兩條條文針對不同行為者：第 24 條打整合者、第 25 條打 FOSS 源頭。
Block 3 · APAC perspective 區塊 3 · APAC 觀點
FOSS attestation and APAC supply-chain due diligence FOSS 聲明跟 APAC 供應鏈盡職調查
FOSS is the foundation of most APAC ICT products. Linux kernels in routers, OpenSSL in IoT firmware, BusyBox in industrial controllers, JavaScript libraries in web UIs — the entire APAC ICT export industry runs on community-developed code. Article 25 changes how this code interacts with EU compliance.
FOSS 是多數 APAC ICT 產品的基礎。router 裡的 Linux 核心、IoT 韌體裡的 OpenSSL、工控裡的 BusyBox、網頁 UI 裡的 JavaScript 函式庫，整個 APAC ICT 出口產業運行在社群開發程式碼上。第 25 條改變這些程式碼跟 EU 合規的互動。
The first-order operational impact: APAC manufacturers can no longer treat "upstream FOSS" as a black box that they integrate without diligence. Article 13(5) demands due diligence on third-party components, and Article 25 attestations (when available) are evidence that fits in the diligence file.
第一階營運影響：APAC 製造商不能再把「上游 FOSS」當成不用盡職調查就整合的黑箱。第 13(5) 條要求對第三方元件做盡職調查、而第 25 條聲明（有提供時）是符合該盡職調查檔案的證據。
| FOSS source patternFOSS 來源模式 | Likelihood of Article 25 attestation第 25 條聲明的可能性 | APAC mitigationAPAC 對策 |
|---|---|---|
| Major foundations (Linux Foundation, Apache, Eclipse)主要基金會（Linux 基金會、Apache、Eclipse） | High — these foundations have institutional capacity and incentive to issue attestations to support EU adoption.高，這些基金會有機構量能跟誘因出具聲明以支持 EU 採用。 | Use foundation-issued attestations directly. Track CRA-related foundation announcements.直接使用基金會出具的聲明。追蹤基金會 CRA 相關公告。 |
| Major commercial open source (Red Hat, SUSE, Canonical)主要商業開源（Red Hat、SUSE、Canonical） | High — but bundled with commercial support contracts; the company may also be the manufacturer / steward.高，但跟商業支援合約捆綁；該公司本身可能是製造商 / steward。 | Read commercial agreements for attestation language; expect attestation to be tied to subscription tier.讀商業協議找聲明條款；預期聲明跟訂閱等級綁定。 |
| Hobbyist FOSS / GitHub repo with single maintainer業餘 FOSS / 單一維護者的 GitHub repo | Low — individual maintainers have neither legal capacity nor incentive to issue attestations.低，個別維護者既沒法律量能也沒誘因出具聲明。 | Either fork and self-maintain (you become the FOSS source for compliance), find replacement, or accept the diligence-file gap.要嘛 fork 並自己維護（你成為合規的 FOSS 源頭）、找替代品、或接受盡職調查檔案的空缺。 |
| Internal FOSS (company maintains its own derivative)內部 FOSS（公司維護自己的衍生版） | N/A — the manufacturer is the FOSS source. No external attestation needed.不適用，製造商就是 FOSS 源頭。不需要外部聲明。 | Document upstream-to-derivative tracking. Assume direct CRA Article 13 obligations on derivative.記錄上游到衍生版的追蹤。對衍生版假設直接的 CRA 第 13 條義務。 |
| Asian-origin FOSS (NTT, Samsung, MediaTek upstream)亞洲起源 FOSS（NTT、Samsung、聯發科 upstream） | Mid — Asian corporate FOSS contributors are still adapting to EU regulatory expectations.中，亞洲企業 FOSS 貢獻者仍在適應 EU 法規期待。 | Engage upstream contact to clarify CRA-readiness; expect 12–24 month transition.跟上游聯絡釐清 CRA 就緒度；預期 12-24 個月過渡。 |
A key strategic question for Tier-1 APAC manufacturers: should we invest in becoming an Article 24 software steward for FOSS components we depend on, rather than relying on Article 25 attestations from external sources?
給 Tier-1 APAC 製造商的關鍵策略問題：是否該投資成為我們依賴的 FOSS 元件的第 24 條 software steward、而不是仰賴外部來源的第 25 條聲明？
The math: a Taiwan ODM that ships 50M routers depending on a specific Linux kernel version has more incentive to fund Article 24 stewardship of that kernel branch than to wait for an external attestation. Stewardship is a heavier obligation but gives control. The pattern parallels how Asian corporate contributors became major Linux Foundation contributors over 2010–2025 — economic incentive aligned with code dependency. CRA Article 24/25 makes this calculus explicit.
計算：出貨 5,000 萬台 router、依賴特定 Linux 核心版本的台灣 ODM、比起等外部聲明、更有誘因資助該核心分支的第 24 條 stewardship。stewardship 是較重的義務但給控制權。模式平行於 2010-2025 年亞洲企業貢獻者如何成為 Linux 基金會主要貢獻者，經濟誘因跟程式碼依賴對齊。CRA 第 24 / 25 條讓這個計算明確化。
Block 4 · Cross-regulation map 區塊 4 · 跨法規對照
Article 25 in the global software supply-chain attestation landscape 第 25 條在全球軟體供應鏈聲明全景中
Article 25 is one of multiple emerging instruments globally that try to bring software supply chain transparency to a regulatory-acceptable form. Knowing the parallel instruments helps APAC manufacturers reuse documentation across regimes. 第 25 條是全球新興多個工具之一、試圖讓軟體供應鏈透明度成為法規可接受形式。了解平行工具、有助於 APAC 製造商跨制度重用文件。
US Executive Order 14028 + NIST SSDF SP 800-218美國 EO 14028 + NIST SSDF SP 800-218
EO 14028 (2021) requires US federal software suppliers to attest to secure software development practices following NIST SSDF. The form M-22-18 + M-23-16 attestations are the US analog of Article 25-style attestations — though EO 14028 is supplier-mandatory for federal procurement, not voluntary. APAC vendors selling to US federal agencies already produce SSDF attestations; some content can map to CRA Article 25 once the EU delegated act lands.
EO 14028（2021）要求美國聯邦軟體供應商依 NIST SSDF 對安全軟體開發實務出具聲明。Form M-22-18 + M-23-16 聲明是第 25 條風格聲明的美國對應，但 EO 14028 對聯邦採購供應商強制、不是自願。賣給美國聯邦機關的 APAC 廠商已經產出 SSDF 聲明；EU 授權行為通過後、部分內容可對應 CRA 第 25 條。
SLSA — Supply chain Levels for Software ArtifactsSLSA：軟體供應鏈層級
SLSA is the open-source-led framework for build-process attestation, with Levels 1–4 indicating increasing rigour of build provenance. SLSA Level 3+ provides build-level attestations that map well to certain Article 25 attestation contents. The OpenSSF and Linux Foundation are positioning SLSA as a CRA-acceptable attestation standard. APAC manufacturers using SLSA-attested upstream FOSS will likely have stronger Article 13(5) due-diligence position.
SLSA 是 open-source 主導的建置流程聲明框架、第 1 到 4 級表示遞增的建置溯源嚴謹度。SLSA 第 3+ 級提供建置層級聲明、跟某些第 25 條聲明內容對應良好。OpenSSF 跟 Linux 基金會把 SLSA 定位為 CRA 可接受聲明標準。使用 SLSA 聲明上游 FOSS 的 APAC 製造商、可能在第 13(5) 條盡職調查上有較強立場。
SPDX 3.0 / CycloneDX SBOM extensionsSPDX 3.0 / CycloneDX SBOM 擴充
SPDX and CycloneDX are the two dominant SBOM formats. Both have evolved to include security attestation extensions — SPDX 3.0 adds a Security Profile, CycloneDX has the VEX (Vulnerability Exploitability Exchange) extension. These extensions can carry Article 25-relevant attestation content. APAC manufacturers should adopt SBOM tooling that supports these extensions to ride out future Article 25 delegated act requirements.
SPDX 跟 CycloneDX 是兩個主導 SBOM 格式。兩者都已演進、加上安全聲明擴充，SPDX 3.0 加 Security Profile、CycloneDX 有 VEX（Vulnerability Exploitability Exchange）擴充。這些擴充可以承載第 25 條相關聲明內容。APAC 製造商應採用支援這些擴充的 SBOM 工具、以承接未來第 25 條授權行為要求。
CSAF — Common Security Advisory FrameworkCSAF：通用安全諮詢框架
CSAF (OASIS standard) is the machine-readable format for vulnerability advisories. While CSAF itself is not an Article 25 attestation, the combination of "this software has been published with CSAF advisories on detected vulnerabilities" is reasonable evidence of vulnerability handling maturity, supporting attestation content. ENISA endorses CSAF as the EU vulnerability database's preferred input format.
CSAF（OASIS 標準）是弱點諮詢的機讀格式。雖然 CSAF 本身不是第 25 條聲明、「該軟體已透過 CSAF 諮詢發布偵測到的弱點」這個組合、是弱點處理成熟度的合理證據、支持聲明內容。ENISA 認可 CSAF 為 EU 弱點資料庫偏好的輸入格式。
CRA Article 24 — Software steward (related but separate)CRA 第 24 條：Software steward（相關但獨立）
Article 24 imposes obligations on software stewards — legal persons that systematically integrate FOSS into commercial PwDE. Stewards must adopt cybersecurity policy, document SSDLC for FOSS integration, cooperate with market surveillance. Article 24 + Article 25 together cover the FOSS supply chain: Article 24 covers the integrator, Article 25 covers the FOSS source. APAC Tier-1 vendors heavily integrating FOSS into their products may need to operate as both stewards (under Article 24) and as users of upstream Article 25 attestations.
第 24 條對 software stewards 課義務，系統性整合 FOSS 到商業具數位元素產品的法人。Stewards 必須採用網路安全政策、記錄 FOSS 整合的 SSDLC、跟市場監督合作。第 24 + 25 條一起涵蓋 FOSS 供應鏈：第 24 條涵蓋整合者、第 25 條涵蓋 FOSS 源頭。重度把 FOSS 整合到產品的 APAC Tier-1 廠商、可能需要同時運作為 stewards（第 24 條下）跟上游第 25 條聲明的使用者。