CRA 評估目標（AO）拆分與各 AO 的建議證據

• 狀態：AI 依法條與 ENISA 子要求拆分，待顧問確認。 拆點是我們對法條的詮釋，不是官方內容；決策者裁定不等顧問、先讓流程跑起來，顧問日後有真實案件再調整。
• 依據：AO 句與建議證據依法條原文自寫（Annex I、II：docs/reference/CRA/annex-I-II-original-text.md；Article 13、14：docs/reference/CRA/article-13-14-original-text.md）。ENISA／JRC 對照報告（JRC137340）只拿來參考「拆在哪裡」，報告與 EN 40000 的文字都不抄進框架。各 AO 的 Basis 欄只留在本檔，不進框架，客戶看不到。
• 四個群組：Annex I Part I、Annex I Part II、Annex II，加上「Articles 13 and 14」（風險評估、支援期、通報三件製造商義務，法源在 Article 13／14，不在 Annex I）。
• 編號規則：part_id 是 <控制項代號>_obj.<N>，N 從 3 起（1 是條文 _smt、2 是控制項層建議證據 _gdn），sort_order 與 N 相同。AO 句首的 [a]、[b]… 是畫面與證據分類器看的字母，分類器從句首解析，句首格式不能改。
• 建議證據掛在各 AO 底下：每個 AO 有一筆子段落 <AO part_id>_gdn（name=guidance、parent_id 指向 AO），內容是三段式。有 AO 的控制項，控制項層建議證據只剩一句「See assessment objectives [a]–[x].」；沒 AO 的 18 條，控制項層就是三段式（見 cra-suggested-evidence.md）。
• 三段式：Deliverable＝交什麼檔或紀錄；Must show＝審閱者要在裡面看到什麼；Evidence＝從哪來——upload（客戶自有檔上傳）、system — <頁面>（客戶在系統其他頁填完就有，不該再上傳）、template — <範本>（系統給範本，客戶填完產出）。標 (Phase N) 的系統落點是之後才上線的功能，在那之前先上傳。標 system 的 AO 由 seed 006 在 props 標上 evidence-source，規劃頁與稽核判定頁直接連到那個系統物件、顯示填了沒；每筆證據都是系統內的，畫面不收程序書。報告模組（Phase 3）還沒有系統物件，仍是上傳。
• 改內容改 scripts/cra_ao_content.py，再跑 python scripts/gen_cra_ao_restructure.py：同時重產本檔、cra-suggested-evidence.md 的建議證據段與 jedi-oscal-v2 migrations/005-cra-2024-ao-restructure.sql、006-cra-2024-ao-evidence-source.sql。不要直接改 md 或 seed。
• 生效範圍：只對之後新建的資源庫與專案有效（建資源庫時整份複製框架 catalog，AO 的收證據流程範本也在那時建）。既有的資源庫與專案吃不到，要重建。
• 搬移不刪除：從 CRA.I.1 搬到 CRA.ART.13.RA 的三個 AO 在 seed 裡是改掛（換控制項與 part_id），不是刪掉重建。
• EN 40000-1-4 出版後要替換。 CRA 調和標準預估 2027 年出版，屆時以框架新版本替換，舊專案沿用舊版。

CRA.I.1 Risk-Based Cybersecurity by Design

拆分說明：Part I (1) 只要求「依風險做到適當水準」。風險評估文件、逐條適用判定、評估更新的法源在 Article 13，已搬到新群組 CRA.ART.13.RA；本條留「安全開發流程有執行」與「每個風險都有處理並對到控制項」兩件。

[a] Suggested evidence

• Deliverable: Secure development records for the released version: one design review record, one code review record and one security test record.
  Must show: the product version they apply to; date; reviewer or tester; findings and how each was closed. The development procedure itself belongs in the Document Pool, not here.
  Evidence: upload

[b] Suggested evidence

• Deliverable: Risk treatment table.
  Must show: every identified risk with its treatment (mitigate, accept, transfer or avoid), the control measures applied and the Part I (2) requirement(s) each measure addresses; no risk left without a treatment.
  Evidence: system — Risk Assessment tab (Phase 2); until available: upload the table

CRA.I.2.b Secure-by-Default Configuration & Reset

拆分說明：預設設定、初始帳密、重設三件事證據不同（設定清單、帳密產生方式、重設測試）。客製化產品的例外併在 [a]，因為它取代的就是預設設定本身。

[a] Suggested evidence

• Deliverable: Factory default configuration list.
  Must show: every security-relevant setting, its default value and why that value is secure.
  Evidence: upload
• Deliverable: For a tailor-made product: the agreement with the business user on a different configuration.
  Must show: the parties; the settings that differ from the secure default; signature and date.
  Evidence: upload

[b] Suggested evidence

• Deliverable: Description of how initial credentials are generated, or a screenshot of the forced change at first login.
  Must show: that each device or installation gets a different, randomly generated credential, or that the product refuses to continue until the credential is changed.
  Evidence: upload

[c] Suggested evidence

• Deliverable: Reset procedure and a test record of a reset.
  Must show: the steps a user follows; that after the reset the settings match the factory default list in [a]; test date and product version.
  Evidence: upload

CRA.I.2.c Security Updates & Automatic Updating

拆分說明：法條一句列了五件事：能用安全更新修漏洞、自動更新預設開啟且有期限、退出機制、通知使用者、可延後。截圖與設計文件各不相同，拆五個 AO。支援期承諾屬 Article 13(8)，在 CRA.ART.13.SP。

[a] Suggested evidence

• Deliverable: Update mechanism design.
  Must show: how an update is obtained; how its signature or hash is checked before installation; what happens when the check or installation fails.
  Evidence: upload
• Deliverable: Security Update and Decommissioning Procedure, update section.
  Must show: who builds, signs and releases an update and how users receive it.
  Evidence: template — Security Update and Decommissioning Procedure

[b] Suggested evidence

• Deliverable: Screenshot of the factory default update setting, and the document page stating the installation timeframe.
  Must show: automatic security updates switched on out of the box; the stated timeframe (e.g. within 24 hours of availability).
  Evidence: upload

[c] Suggested evidence

• Deliverable: Screenshot of the opt-out setting.
  Must show: where the setting is and that one action turns automatic updates off.
  Evidence: upload

[d] Suggested evidence

• Deliverable: Example of an update notification.
  Must show: the message a user receives (in-product prompt, email or notice page) naming the update and how to install it.
  Evidence: upload

[e] Suggested evidence

• Deliverable: Screenshot of the postpone option.
  Must show: that the user can delay an update and for how long.
  Evidence: upload

CRA.I.2.d Protection from Unauthorised Access

拆分說明：「有機制」是設計文件、「各角色真的不能越權」是授權測試，兩種證據分開判；「回報可能的未授權存取」是正式版新增的第三件事。

[a] Suggested evidence

• Deliverable: Authentication and authorisation design.
  Must show: login methods; identity and access management; role-permission matrix; lockout and multi-factor settings.
  Evidence: upload
• Deliverable: Where the product includes hardware: measures against unauthorised physical access required by the risk assessment (not applicable to software-only products).
  Must show: the physical measure and the risk it addresses.
  Evidence: upload

[b] Suggested evidence

• Deliverable: Authorisation test report.
  Must show: for each role, the administrative functions and protected data tried; expected and actual result; test date and product version.
  Evidence: upload

[c] Suggested evidence

• Deliverable: Detection rules and an example report of possible unauthorised access.
  Must show: the events that raise an alert; who or what receives the report; one example alert or event record.
  Evidence: upload

CRA.I.2.f Integrity of Data, Programs & Configuration

拆分說明：完整性保護與「回報損毀」是兩件事，證據分開（保護設計與測試 vs. 告警範例），與 I.2.d 拆出「回報」同理。

[a] Suggested evidence

• Deliverable: Integrity protection design.
  Must show: for stored data, data in transit, commands, programs and configuration: the mechanism used (hash, signature, message authentication code, authenticated command channel).
  Evidence: upload
• Deliverable: Test record of the integrity checks.
  Must show: a tampered program, configuration or message is rejected; test date and product version.
  Evidence: upload

[b] Suggested evidence

• Deliverable: Example of a corruption report.
  Must show: the alert, log entry or user notification produced when tampering or corruption is detected.
  Evidence: upload

CRA.I.2.h Availability of Essential & Basic Functions

拆分說明：平時可用（含抗 DoS）與事件後維持是兩種證據（防護設定與測試 vs. 復原演練紀錄）。哪些算基本功能的清單是兩者共同前提，放在 [a]。

[a] Suggested evidence

• Deliverable: List of essential and basic functions with the denial-of-service measures that protect each.
  Must show: each function; measures such as rate limits, request size and connection limits, timeouts, load balancing.
  Evidence: upload
• Deliverable: Load, stress or rate-limit test record.
  Must show: the function tested; load applied; that it stayed available; test date and product version.
  Evidence: upload

[b] Suggested evidence

• Deliverable: Recovery drill record.
  Must show: the incident simulated; the functions restored; time to restore; date.
  Evidence: upload

CRA.I.2.l Recording & Monitoring of Internal Activity

拆分說明：記錄、紀錄保護、監控、退出機制四件事證據不同。[b] 紀錄防竄改法條未明文，依 ENISA 3.1.12 保留。

[a] Suggested evidence

• Deliverable: List of recorded events and sample log entries.
  Must show: the events recorded (logins, permission changes, configuration changes, data access and modification); one sample entry each for access to and modification of data, a service and a function.
  Evidence: upload

[b] Suggested evidence

• Deliverable: Log protection settings.
  Must show: who can read, change or delete the logs; the tamper protection used (append-only storage, forwarding to a separate system, signatures).
  Evidence: upload

[c] Suggested evidence

• Deliverable: Monitoring rules and execution records.
  Must show: the alert rules or the review frequency; who monitors; records of recent reviews or alerts handled. The alerts used for CRA.I.2.d [c] may be reused.
  Evidence: upload

[d] Suggested evidence

• Deliverable: Screenshot of the opt-out setting.
  Must show: where the user switches recording and monitoring off, and what stops being recorded.
  Evidence: upload

CRA.I.2.m Secure Data Removal & Transfer

拆分說明：永久刪除與安全轉移是兩件事，轉移是條件式（資料可轉移時才適用）。

[a] Suggested evidence

• Deliverable: Removal procedure and a test record.
  Must show: the steps a user follows; that after removal the data cannot be recovered; test date and product version.
  Evidence: upload

[b] Suggested evidence

• Deliverable: Data export or transfer design.
  Must show: how transferred data is protected (encryption, authentication of the receiving side).
  Evidence: upload

CRA.II.1 Vulnerability & Component Identification (SBOM)

拆分說明：SBOM 與漏洞清單是兩份不同產出（原始碼掃描也分開產出），拆兩個 AO。第三方元件的盡職調查（Art. 13(5)）併在 [b] 證據。

[a] Suggested evidence

• Deliverable: SBOM of the released version (SPDX or CycloneDX).
  Must show: product version it describes; generation date; at least the top-level dependencies with their versions.
  Evidence: system — Source Scan results (FR-134); until linked as evidence: upload the exported file

[b] Suggested evidence

• Deliverable: Vulnerability list of the released version, including third-party and open-source components.
  Must show: each vulnerability; affected component and version; severity; status.
  Evidence: system — Source Scan results (FR-134); until linked as evidence: upload the exported file
• Deliverable: Third-party component selection records.
  Must show: how components (including open-source) are chosen and checked before integration: source, maintenance status, known vulnerabilities.
  Evidence: upload

CRA.II.2 Timely Vulnerability Remediation

拆分說明：依風險排優先（程序與期限）、在期限內修補（執行紀錄）、安全更新與功能更新分開（發布做法），三種證據不同。

[a] Suggested evidence

• Deliverable: Vulnerability handling procedure.
  Must show: the severity rating method (e.g. CVSS); the remediation deadline for each severity level; the sources monitored (vulnerability alerts from CERTs and CVE databases, dependency advisories).
  Evidence: template — Security Update and Decommissioning Procedure

[b] Suggested evidence

• Deliverable: Vulnerability tracking records.
  Must show: for each vulnerability: discovery date, severity, deadline, fix date, release version; the reason for each one fixed after its deadline; third-party component fixes included.
  Evidence: upload

[c] Suggested evidence

• Deliverable: Release records.
  Must show: security-only releases listed apart from feature releases, or the recorded reason why they cannot be separated.
  Evidence: upload

CRA.II.4 Public Disclosure of Fixed Vulnerabilities

拆分說明：修補後公開、公開內容五要素、延後公開的例外（條件式），證據各不相同。與 II.8 共用同一份安全通告，II.4 看公開內容、II.8 看隨更新發給使用者。

[a] Suggested evidence

• Deliverable: Public advisory page and its publication records.
  Must show: the URL; for each fixed vulnerability, the advisory date on or after the update release date.
  Evidence: system — Assessed target, public links (security advisories URL)

[b] Suggested evidence

• Deliverable: One published security advisory.
  Must show: description; affected product and versions; impact; severity; how users remediate; CVE identifier where one exists.
  Evidence: template — Security Advisory

[c] Suggested evidence

• Deliverable: Record of each delayed disclosure.
  Must show: why publication risks outweighed the benefits; the update release date; the final publication date. If no disclosure has been delayed, state so.
  Evidence: upload

CRA.II.8 Timely, Free Security Updates with Advisories

拆分說明：不延遲發送、免費（客製例外）、附通告三件事證據不同。通告與 II.4 共用同一份，本條看「隨更新給使用者、寫明使用者要做什麼」。

[a] Suggested evidence

• Deliverable: Release timeliness records.
  Must show: for each security update: fix completion date and the date it reached users.
  Evidence: upload

[b] Suggested evidence

• Deliverable: Terms or policy stating that security updates are free of charge; for a tailor-made product, the agreement with the business user.
  Must show: the clause on security update cost.
  Evidence: template — Support Period Statement

[c] Suggested evidence

• Deliverable: Advisory message sent with one security update.
  Must show: what was fixed; how to apply the update; any action the user must take. The advisory used for CRA.II.4 [b] may be reused.
  Evidence: template — Security Advisory

CRA.A2.8 Detailed Secure-Use Instructions

拆分說明：法條自己列了 (a)～(f) 六項，每項是使用者資訊裡獨立的一節。(f) 只在產品會被整合進其他產品時適用。

[a] Suggested evidence

• Deliverable: The section of the user information (Annex II), or the URL, on secure commissioning and use.
  Must show: the steps a user takes at first setup and during use to keep the product secure.
  Evidence: template — Information and Instructions to the User

[b] Suggested evidence

• Deliverable: The section of the user information (Annex II), or the URL, on changes and data security.
  Must show: which user changes (configuration, add-ons, integrations) can weaken data security and how.
  Evidence: upload

[c] Suggested evidence

• Deliverable: The section of the user information (Annex II), or the URL, on installing updates.
  Must show: the steps to install a security update.
  Evidence: template — Security Update and Decommissioning Procedure

[d] Suggested evidence

• Deliverable: The section of the user information (Annex II), or the URL, on decommissioning.
  Must show: the steps to take the product out of service and remove user data. The removal function itself is CRA.I.2.m [a].
  Evidence: template — Security Update and Decommissioning Procedure

[e] Suggested evidence

• Deliverable: The section of the user information (Annex II), or the URL, on turning off automatic updates.
  Must show: the steps to turn off automatic installation. The setting itself is CRA.I.2.c [c].
  Evidence: template — Information and Instructions to the User

[f] Suggested evidence

• Deliverable: The integrator information, or the URL.
  Must show: the information an integrator needs to meet Annex I and the Annex VII documentation requirements.
  Evidence: upload

CRA.ART.13.RA Cybersecurity Risk Assessment

Legal basis: Article 13(2)(3)(4)(7)

拆分說明：風險評估要有文件、逐條判定 Part I (2) 適用與如何實作、支援期內更新，法源都在 Article 13，從 CRA.I.1 搬來。

[a] Suggested evidence

• Deliverable: Cybersecurity risk assessment.
  Must show: intended purpose; reasonably foreseeable use; conditions of use (operational environment, assets to protect); threats; impact and likelihood; treatment; residual risk; version and assessment date.
  Evidence: system — Risk Assessment tab (Phase 2); purpose, misuse and environment: system — Assessed target, CRA fields

[b] Suggested evidence

• Deliverable: Applicability and implementation statement for Part I (2)(a)–(m).
  Must show: for each of the 13 requirements: applies or not; if it applies, how it is implemented; if not, the justification.
  Evidence: system — Applicability status and justification on each control (Planning page)

[c] Suggested evidence

• Deliverable: Risk assessment revision history.
  Must show: each revision with its date and trigger (release, new vulnerability, change in threats); the latest revision is dated after the latest release.
  Evidence: system — Risk Assessment tab (Phase 2); until available: upload the revision history

CRA.ART.13.SP Support Period

Legal basis: Article 13(8)(9)(19)

拆分說明：支援期至少五年、結束日至少到年月且購買時告知、每個安全更新保存十年，原框架沒有落點，新開一條。

[a] Suggested evidence

• Deliverable: Support period and the reasons for its length.
  Must show: the end date; the expected use time; the factors considered (user expectations, nature of the product, support periods of integrated components).
  Evidence: system — Assessed target, CRA fields

[b] Suggested evidence

• Deliverable: Support Period Statement, and a screenshot of where it is shown at purchase.
  Must show: the end month and year, visible on the product page, packaging or order flow before purchase.
  Evidence: template — Support Period Statement

[c] Suggested evidence

• Deliverable: Update retention policy and the archive location.
  Must show: where past security updates are kept; the retention period; a past update still downloadable.
  Evidence: upload

CRA.ART.14.RP Reporting of Exploited Vulnerabilities and Severe Incidents

Legal basis: Article 14(1)–(5)

拆分說明：被利用的漏洞與重大事件要在 24 小時／72 小時／最終報告期限內通報 CSIRT 與 ENISA，原框架沒有，新開一條。

[a] Suggested evidence

• Deliverable: Notification procedure.
  Must show: who decides to notify; the three deadlines (24 hours, 72 hours, final report within 14 days of a fix for vulnerabilities or one month for incidents); the content of each notification; the reporting platform.
  Evidence: system — Reporting module (Phase 3; until then: upload the notification procedure document)

[b] Suggested evidence

• Deliverable: Severity criteria.
  Must show: the conditions that make an incident severe: impact on availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or introduction or execution of malicious code.
  Evidence: system — Reporting module (Phase 3; until then: upload the notification procedure document)

[c] Suggested evidence

• Deliverable: Notification records.
  Must show: for each notified case: dates of awareness, early warning, notification and final report; what was sent. If nothing has been notified yet, state so.
  Evidence: system — Reporting module (Phase 3; until then: upload the notification records)