原版查證 2026-08-30;時效資訊更新至 2026-09-29:重要狀態已依官方來源覆核;其他歷史數據以各段標示日期為準。引用前請依 附錄 G 查證缺口清單 重新確認。

Appendices A – H

附錄:總表、問卷與工具套件

手冊的可操作資產——標準與合規總表、事件與控制項庫、自評問卷,以及把手冊 repo 化的 Claude Code + GitHub Prompt 套件。

安全前提:本手冊 repo 應設為 private——它包含集團的控制項現況與缺口,這本身就是高價值的攻擊情報。所有 GitHub Actions workflow 一律以 commit SHA 釘選、宣告最小 permissions、不輸出環境變數、不對 fork PR 提供機密。

Appendix A

主標準總表(版本 × 日期 × 發行機構)

全手冊引用之標準與框架的版本、發布日期與發行機構。原版查證:2026-08-30;重要時效資訊更新:2026-09-29。對應 registry/standards.yml。

標準/框架現行版本發布/更新日期發行機構等級
NIST Cybersecurity FrameworkCSF 2.0(NIST CSWP 29)2024-02-26NIST已證實
↳ Resource & Overview GuideNIST SP 1299—NIST已證實
↳ Organizational ProfilesNIST SP 1301—NIST已證實
↳ TiersNIST SP 1302—NIST已證實
↳ C-SCRM Quick-StartNIST SP 1305—NIST已證實
↳ Informative ReferencesNIST SP 1347—NIST已證實
CSF 2.0 Manufacturing ProfileNIST IR 8183 Rev. 2(草案 ipd)2025-09-29NIST已證實 — 仍為草案
CSF v1.1 Manufacturing ProfileNIST IR 8183 Rev. 1(定稿)2020-10-07NIST已證實
CSF 2.0 Semiconductor Manufacturing ProfileNIST IR 8546(草案 ipd)2025-02-27NIST已證實 — 仍為草案
ISO/IEC 270012022(Ed. 3)2022-10-25ISO/IEC已證實
ISO/IEC 27001 Amd 1Amd 1:2024「Climate action changes」2024-02-23ISO/IEC已證實
ISO/IEC 270022022(Ed. 3)2022-02-15ISO/IEC已證實
ISO/IEC 270052022(Ed. 4)2022-10-25ISO/IEC已證實
ISO/IEC 27017 ⚠️2026(Ed. 2);2015 版已撤銷2026-07-27ISO/IEC已證實
ISO/IEC 27018 ⚠️2025(Ed. 3)2025-08ISO/IEC已證實
ISO/IEC 27701 ⚠️2025(Ed. 2)2025-10-14ISO/IEC已證實
ISO/IEC 27036-12021(Ed. 2)2021-09ISO/IEC已證實
ISO/IEC 27036-22022(Ed. 2)— 供應商關係要求型標準2022-06-15ISO/IEC已證實
ISO/IEC 27036-32023 — 硬體/軟體/服務供應鏈2023ISO/IEC第三方評論
ISO 223012019(Ed. 2)+ Amd 1:20242019-10ISO/TC 292已證實
ISO/IEC 291472018(Ed. 2)— 漏洞揭露2018ISO/IEC已證實
ISO/IEC 301112019 — 漏洞處理流程2019ISO/IEC已證實
ISO/IEC 420012023 — AI 管理系統2023ISO/IEC已證實
ISO/IEC 201532025 — 即 CSAF v2.02025ISO/IEC已證實
ISO/SAE 214342021(Ed. 1)— 車輛資安工程2021-08-31ISO/SAE已證實
IEC TS 62443-1-1Ed. 1.02009-07-30IEC TC65已證實
IEC PAS 62443-1-6Ed. 1.0(IIoT)2025-12-19IEC已證實
IEC 62443-2-1Ed. 2.0(8 個 SPE,消除與 ISMS 重複)2024-08-07IEC已證實
IEC 62443-2-4Ed. 2.02023-12-15IEC已證實
IEC 62443-3-2Ed. 1.0(zones & conduits)2020-06-24IEC已證實
IEC 62443-3-3Ed. 1.0(SL、7 FRs)2013-08-07IEC已證實
IEC 62443-4-1Ed. 1.0(SDL)2018-01-15IEC已證實
IEC 62443-4-2Ed. 1.02019-02-27IEC已證實
IEC TS 62443-6-1Ed. 1.0(2-4 評估法)2024-03IEC第三方評論
IEC TS 62443-6-2Ed. 1.0(4-2 評估法)2025-01-21IEC已證實
ANSI/ISA-62443-2-120242024ISA已證實
ISA-TR62443-2-22025(新出技術報告,IEC 對應版本未檢索到)2025ISA已證實
ANSI/ISA-62443-2-42018 ⚠️(與 IEC Ed.2/2023 不同步)2018ISA已證實
ANSI/ISA-62443-4-22018 ⚠️(與 IEC 2019 不同步)2018ISA已證實
NIST SP 800-207初版(無 Rev.1)2020-08-11NIST已證實
NIST SP 800-207A初版2023-09-13NIST已證實
NIST SP 1800-35Final(Vol. A–E)2025-06-10NIST NCCoE已證實
CISA Zero Trust Maturity Modelv2.0(5 支柱 + 3 跨領域能力;4 階段)2023-04CISA已證實
DoD Zero Trust Reference Architecturev2.0(7 支柱)2022-07DoD CIO已證實
CIS Critical Security Controlsv8.1(18 Controls / 153 Safeguards;無 v9)2024(月份未證)CIS已證實 / 日期 第三方評論
CIS Community Defense Modelv2.0(基準為 v8 時期)2021-09-29CIS已證實
NIST SP 800-53Rev. 5, Release 5.2.02025-08-27NIST已證實
NIST SP 800-161Rev. 1 upd1(無 Rev.2 進行中)2022-05;更新 2024-11-01NIST已證實
NIST SP 800-61Rev. 3(CSF 2.0 Community Profile)2025-04NIST已證實
NIST SP 800-171Rev. 3(CMMC 仍用 Rev 2)2024-05-14NIST已證實
NIST SP 800-172Rev. 3(2026 年新出)2026-05-13NIST已證實
NIST SP 800-218 (SSDF)v1.1 正式版;v1.2(Rev.1)草案2022-02-03(Rev.1 ipd:2025-12-17)NIST已證實
NIST SP 800-218AFinal(GenAI SSDF Profile)2024-07-26NIST已證實
NIST SP 800-63Rev. 42025-07-31NIST已證實
NIST AI RMF1.0(修訂中,未公布時程)2023-01NIST已證實
NIST IR 8596Cyber AI Profile(初步草案 iprd)2025-12-16NIST已證實 — 仍為草案
NIST SP 800-82Rev. 3(OT 安全指南);Rev. 4 ipd 2026-09-21(意見至 2026-11-30)2023-09NIST已證實
NIST IR 8536Supply Chain Traceability: Manufacturing Meta-Framework2026-09-09NIST已證實
NIST AI 600-1GenAI Profile(12 風險類別)2024-07NIST已證實
DOE C2M2v2.1(10 domains、350+ practices、MIL1–3)2022-06US DOE已證實
MITRE ATT&CKv19.2(首個 Agile release);v19 拆分 Defense Evasion → Stealth + Defense Impairment2026-08-06(v19: 2026-04-28)MITRE已證實
MITRE D3FEND1.6.0(7 類戰術)未載明(GitHub 提交 2026-09-01)MITRE版本 已證實 / 日期 尚未證實
MITRE ATLASdata v2026.092026-09-15MITRE已證實
SLSAv1.2(新增 Source Track)2025-11-24OpenSSF已證實
SPDX3.0.1(3.1-RC1 自 2026-01-24 測試中)3.0.1:2024-12-17Linux Foundation已證實
ISO/IEC 59622021(= SPDX 2.2.1,Stage 90.92 待改版)2021-08ISO/IEC已證實
CycloneDXv1.7(修補版 1.7.2)規格 2025-10-21;發布 2025-12-10;1.7.2:2026-09-17OWASP / Ecma已證實
ECMA-4242nd edition(= CycloneDX 1.7)2025-12Ecma International已證實
CVSSv4.02023-11-01FIRST已證實
EPSSv2026.06.15 模型(前一版 v4)2026-06-15(v4:2025-03-16)FIRST EPSS SIG / Empirical Security模型切換 已證實 /「v5」名稱 尚未證實
FIRST PSIRT Services Frameworkv1.1(6 服務領域)日期未載明FIRST版本 已證實 / 日期 尚未證實
CSAFv2.0(= ISO/IEC 20153:2025)OASIS 公告 2025-05-20OASIS已證實
CISA Minimum Requirements for VEX—2023-04CISA已證實
SEMI E187Cybersecurity of Fab Equipment2022-01SEMI已證實
SEMI E188Malware Free Equipment Integration2022-02SEMI已證實
SEMI E191Computing Device Cybersecurity Status Reporting2024-10SEMI已證實
OWASP Top 10 for LLM Applications2026 版2026 年 8 月初(來源日期歧異)OWASP已證實但有歧異
OWASP Top 10 for Agentic Applications2026 版2025-12-09OWASP已證實 — 發布日
OWASP Non-Human Identities Top 102025日期未載明OWASP清單 已證實 / 日期 尚未證實
RBA Code of Conduct8.02024-01-01 生效RBA已證實
RBA VAP StandardV8.1(範圍不含資安,待以 V8.1 重新確認)2026-09-27RBA已證實
VDA ISA / TISAXISA 6(2026 現行)→ ISA 2027(2026-07-01 發布,2027-01-01 起委託之評鑑適用)2026-07-01ENX已證實

↑ 回附錄目錄

Appendix B

主合規總表

各法規/標準的適用地區、生效時程、對 ODM/OEM 的核心義務與通報時限。對應 registry/regulations.yml。

法規/標準適用地區生效/適用日期對 ODM/OEM 的核心義務等級
EU CRA — Reg (EU) 2024/2847EU(產品投放市場)生效 2024-12-10;Art.14 通報 2026-09-11;Ch.IV 2026-06-11;全面 2027-12-11產品資安 by design(Annex I Part I);漏洞處理與 SBOM(Part II);24h/72h/14d 或 1 個月通報至 CSIRT+ENISA;支援期 ≥5 年;CVD 政策;技術文件與 CE已證實
CRA 調和標準 M/606EU交付時程涵蓋 2026-08-30、2026-10-30 與 2027 年;OJ 引用須逐項核對僅經 OJ 引用之標準可產生符合推定已證實
ENISA Single Reporting PlatformEU2026-09-11 已上線完成 EU Login 與平台代表人註冊,選定協調者 CSIRT已證實
NIS2 — Dir (EU) 2022/2555EU(各國轉換)轉換期限 2024-10-17;IE/ES/FR/NL 於 2026-07-08 遭移送 CJEUArt.21(2) 十項措施(含供應鏈、漏洞處理、MFA);Art.23 24h/72h/1 個月;管理層責任已證實
捷克 Act 264/2025 Sb. + Vyhláška 408/2025 Sb.捷克廠2025-11-01 生效;60 日內登記;登記決定送達後 1 年內開始執行措施與通報高/低階雙軌;所有事件均須通報;高階 24h/72h/30d;明示 ISO 27001 不足;罰鍰上限 CZK 2.5 億。CZ-NACE 26 中大型企業屬低階納管已證實
EU RED DA (EU) 2022/30EU(無線產品)2025-08-01 適用(依 2023/2444 延期)Art.3(3)(d)(e)(f);依 EN 18031-1/-2/-3 或 NB 型式審查第三方評論
Impl. Decision (EU) 2025/138EU2025-01-28 決定,2025-01-30 OJEN 18031 之 OJ 引用附限制:允許使用者不設密碼即失去符合推定已證實
GDPR (EU) 2016/679EU + 處理歐盟個資2018-05-25Art.32 技術組織措施;Art.33 72h 通報;Art.35 DPIA;Art.44-49 + SCC 2021/914公知
Data Act (EU) 2023/2854EU生效 2024-01-11;適用 2025-09-12連網產品資料可取用性 by design;使用者/第三方存取;營業秘密保護配套已證實
AI Act (EU) 2024/1689 + Digital OmnibusEUOmnibus=Reg (EU) 2026/1744,2026-07-27 生效;Annex III 延至 2027-12-02;Annex I 延至 2028-08-02;Art. 50 透明度 2026-08-02 起適用(既有系統標示過渡至 2026-12-02)高風險 AI 之風險管理、資料治理、紀錄、人為監督;招募/員工管理 AI 屬 Annex III 第 4 類已證實
CMMC — 32 CFR Part 170美國(DoD 供應鏈)刊登 2024-10-15;生效 2024-12-16L1 FAR 52.204-21 十五項;L2 NIST SP 800-171 Rev 2 一百一十項;L3 SP 800-172 二十四項已證實
CMMC — 48 CFR DFARS 2019-D041美國刊登 2025-09-10;生效 2025-11-10DFARS 252.204-7021/-7025;SPRS 登錄與 CMMC UID;流下至處理 FCI/CUI 之分包商已證實
🚩 CMMC Phase II 暫停美國2026-07-13 起立即暫停;2026-09 以 DFARS 類別偏離 2026-O0025 Rev.3 制度化僅得要求 Level 1/Level 2 自評;DFARS 252.204-7012 仍有效;Task Force 公開報告待查已證實
DFARS 252.204-7012美國現行72 小時內報 DIBNet;媒體保存 90 天已證實
EAR — 15 CFR 730-774美國/全球持續ECCN 分類、國別管制、deemed export、Entity List 篩查已證實 — 部號
ITAR — 22 CFR 120-130美國持續DDTC 註冊;USML 技術資料依國籍圍籬;120.54(a)(5) 端對端加密安全港已證實 — eCFR 2026-09-25 覆核
中國 CSL(2025 修正)中國廠原法 2017-06-01;修正 2026-01-01 生效等保、CIIO、事件應急與通報;罰鍰上限 RMB 1,000 萬、個人 RMB 100 萬已證實
中國 DSL中國廠2021-09-01資料分級分類;Art.36 未經批准不得向境外司法/執法提供資料已證實
中國 PIPL中國廠2021-11-01Art.38 跨境三軌;Art.51 安全措施;Art.41 境外執法請求須批准已證實
網路數據安全管理條例(790 號令)中國廠2025-01-01Art.9 技術措施;Art.10 危害國安者 24h 報告;Art.33 重要資料年度風險評估報省級;Art.37 重要資料出境須 CAC 評估已證實
CAC 跨境資料流動規定中國廠2024-03-22 公布即生效<10 萬人豁免;10 萬–100 萬人或敏感 <1 萬人→標準合約/認證;>100 萬人或敏感 >1 萬人或 CIIO→CAC 安全評估;HR 管理豁免(須有合法勞動規章制度)第三方評論
MLPS 2.0(GB/T 22239-2019)中國廠2019-12-01系統定級、公安備案、等保測評已證實
中國 國家網絡安全事件報告管理辦法中國廠2025-11-01一般網路營運者 4 小時、CII 1 小時報告已證實
中國 網絡數據安全風險評估辦法中國廠2026-08-20重要資料處理者每年評估,20 個工作日內報送已證實
台灣 資通安全管理法(2025 修正)台灣現行法 2019-01-01;修正三讀 2025-08-29;2025-09-24 公布、2025-12-01 施行適用公務機關與特定非公務機關;禁用危害國安資通產品;通報罰鍰上限提高至 1,000 萬元。一般民營 ODM 原則不納管已證實
台灣 個資法(2025 修正)台灣三讀 2025-10-17;公布 2025-11-11;🚩施行日截至 2026-09-29 未定知悉即通知當事人+通報個資會;子法 2026-01-22 起陸續預告,均尚未發布;72 小時通報(特種個資/>1 萬筆/>100 人);非公務機關罰鍰上限 1,500 萬元第三方評論/施行日 已證實
金管會 上市櫃資安人力台灣上市櫃第一級 2022 年底(115 家);第二級 2023 年底(1,387 家)第一級:資安長+資安專責主管+專責人員 ≥2 人已證實
金管會 年報揭露台灣上市櫃2022 年度起揭露資安風險管理架構、政策、方案、投入資源、重大事件損失與因應已證實
ESG 評鑑指標 S-12(原公司治理評鑑指標 2.24)台灣上市櫃115 年 ESG 評鑑(第一屆)要件 1–3 須全符合方得基本分;要件 3 量化揭露保險金額、人力數、會議頻率、資產監控覆蓋率;要件 4 ISO 27001 驗證加 1 分已證實
TWSE 重大訊息(資安)台灣上市現行第 4 條第 1 項第 26 款;核心系統無法營運/個資有外洩之虞/罰鍰累計 100 萬元;回應媒體報導 2 小時內已證實
國家核心關鍵技術/國安法第 3 條台灣22 項 2023-12-05;32 項 2024-12-31;現 42 項(2026-02-13 公告生效)經濟間諜罪加重;人員赴陸審查;營業秘密高強度保護已證實
SEC 資安揭露規則美國上市客戶(間接)事件揭露自 2023-12-18Item 1.05 Form 8-K 4 個營業日;Item 106 年度揭露 → 供應商合約通知 SLA 24–48h已證實
TISAX / VDA ISA車用客戶(全球)2026 現行 ISA 6;ISA 2027 自 2027-01-01 起委託之評鑑適用資訊安全+原型保護(Basic AL2/Facilities AL3)+資料保護;無獨立 AI 模組已證實
RBA CoC 8.0 / VAP V8.1電子業客戶CoC 8.0 2024-01-01Ethics(檢舉人身分保護、隱私、智財)+Management Systems;VAP 稽核範圍不含資安已證實
ISO/SAE 21434車用電子2021-08-31資安工程生命週期、TARA、Cybersecurity Interface Agreement(ODM 須簽署)已證實
IEC 62443-4-1工控/OT 產品2018-01-15SDL:需求、設計、編碼、V&V、缺陷與修補管理、EOL已證實
SEMI E187/E188/E191半導體設備供應鏈2022-01 / 2022-02 / 2024-10設備 by-design 資安;出貨免惡意程式;運算裝置資安狀態回報已證實
Microsoft SSPA / DPR v12Microsoft 供應商FY26 現行未完成 SSPA 前不得開始工作;年度合規循環;AI Systems 為新增觸發分類已證實
Apple SCoC v5 §6.5–6.8Apple 供應商2025-11-11 生效隱私與資料保護;Information Security(併入引用不公開之技術要求);保密;智財保護框架 已證實 / 內容 尚未證實
EU AEOEU 據點2008-01-01 起UCC Art.38-39;Art.39(e) 安全保安標準;AEO Guidelines 明訂 IT 安全措施已證實
US CTPAT MSC美國進口現行 Foreign Manufacturers MSC(2021-10)第 4 節 Cybersecurity(4.1–4.13):政策、存取控制、強密碼(MFA 為建議)、備份(Should)、媒體與個人裝置管控;訓練見 12.8已證實

↑ 回附錄目錄

Appendix C

已驗證事件總表

完整表格見 第 3 章 §3.1、§3.3、§3.4、§3.5。以下為依教訓類型重新索引的速查表。對應 registry/incidents.yml,標記 verified: true 者非有新一手來源不得修改。

教訓類型案例關鍵事實對應章節
作業程序失效導致病毒擴散TSMC 2018新機台軟體安裝操作失誤;Q3 營收影響 3%§14.3 設備入網管制
供應商事件出現在下游財測MKS → Applied MaterialsUS$200M → US$250M§21.3 供應商分級
供應商測試環境是攻擊面TSMC / Kinmax「內部特定測試環境」;台積電終止資料交換§21.4 問卷補充題 1
一家供應商停掉整國產能Kojima → Toyota日本 14 廠停產一日;紙本看板維持運作§22.4 降級作業手冊
外包服務台是身分驗證邊界Clorox → CognizantUS$49M(SEC);「該專員在所有通話中均未曾驗證來電者確為該員工」§12.2 服務台驗證
IT 事件停掉產線Asahi / JLR / Foxconn 20266 廠 / 5 週 / 單班無生產§19.1 OT 策略前提
下游供應鏈的外溢損失JLR£19 億、逾 5,000 家組織§21.2 曝險規模
內部威脅:合法帳號 + 螢幕拍攝台積電 2nm 案(2026-04-27 判決)在職員工 10 年/6 年徒刑;外商子公司罰金 1.5 億§16.3 資料層控制
流程失效而非技術失效Arup 深偽US$25.6M;「none of our internal systems were compromised」§23.2 付款流程
CI/CD 供應鏈污染tj-actions(CVE-2025-30066)KEV 收錄 2025-03-18;機密傾印至公開日誌§15.3 釘選政策
npm 自我複製蠕蟲Shai-Hulud 兩波逾 500 套件(第一波);25,000+ 惡意 repo(第二波)§15.3 開源治理
邊界裝置 ROM 級持久化Cisco ASA(ED 25-03)可竄改 ROM 於重開機與升級後持存;48 小時修補要求原則三
國家級鎖定台灣半導體供應鏈Proofpoint 2025-07-11三個集群;冒用大學電郵、鎖定法務人員§4.2
五年潛伏、不用惡意程式Volt Typhoon(AA24-038A)「至少五年」;living-off-the-land原則六 日誌保存期
策略轉向入侵 IT 供應商Silk Typhoon(2025-03-05)濫用 API 金鑰;於 GitHub 蒐集外洩密碼§21.6 第三方存取
硬體製造商是明確的 APT 目標APT41 起訴書(DOJ 2020-09-16)逾 100 個受害組織,明列「電腦硬體製造商」,受害地含台灣§4.5

↑ 回附錄目錄

Appendix D

控制項庫與多框架對映矩陣

節錄 60 項核心控制(實際列出 104 列),每一列同時對映 ISO 27001:2022、CIS v8.1、CSF 2.0 與 NIS2 Art.21,使一份證據可回應多個框架。

⚠️ 重要聲明:本矩陣為本手冊自行編製,非任何標準機構的官方對映。特別注意:目前不存在 NIST 官方發行、經 OLIR 驗證的「CSF 2.0 ↔ IEC 62443」對映表 已證實(負面確認)。集團在對外文件中提供類似對照時,必須做相同標示(mapping_source: self-authored)。

D.1 使用方式

每個控制項的欄位設計,使一份證據可回應多個框架(見 §11.6)。建議以 YAML 或資料庫維護(見 附錄 F 的 repo 結構)。

D.2 控制項庫(節錄 60 項核心控制)

ID控制項層ISO 27001:2022CIS v8.1CSF 2.0NIS2 Art.21其他
GOV-01資訊安全政策經最高管理階層核准並年度檢視L0A.5.114.1GV.PO-01(a)評鑑 S-12 要件 2
GOV-02指派資安長並設資安專責單位L0A.5.2—GV.RR-02—金管會第一級
GOV-03定期向董事會報告資安狀況L0A.5.4—GV.OV-01管理層責任評鑑 S-12 要件 1
GOV-04量化揭露資安投入資源(人力、保險、會議)L0——GV.RR-03—評鑑 S-12 要件 3
GOV-05單一控制項庫與多框架對映維護L0A.5.31—GV.OC-03——
GOV-06例外管理(到期日、補償控制、風險承擔者)L0A.5.36—GV.RM-04——
GOV-07取得 ISO/IEC 27001:2022 第三方驗證L0全部———評鑑 S-12 要件 4(加分)
IAM-01全體使用者、全部應用啟用 MFAL1A.5.17, A.8.56.3, 6.4, 6.5PR.AA-03(j)CMMC IA.L2-3.5.3
IAM-02遠端存取使用防釣魚 MFA(FIDO2/憑證)L1A.8.56.4PR.AA-03(j)—
IAM-03所有特權存取經 PAM,session 錄影L1A.8.25.4, 6.8PR.AA-05(i)—
IAM-04AD 依 Microsoft Enterprise Access Model 分層L1A.8.25.4PR.AA-05(i)—
IAM-05高敏感存取每半年再認證L1A.5.186.1, 6.2PR.AA-05(i)—
IAM-06離職當日撤銷全部存取L1A.5.11, A.6.55.3, 6.2PR.AA-01(i)CTPAT
IAM-07服務台密碼/MFA 重設須帶外驗證L1A.5.176.3PR.AA-01(i)—
IAM-08NHI 清冊(擁有者、用途、輪換週期、下線)L1A.5.16, A.8.25.2, 5.6PR.AA-01(i)OWASP NHI1/NHI7
IAM-09禁止長期有效 API 金鑰,改用短期憑證L1A.8.55.2PR.AA-03(i)OWASP NHI7
IAM-10人不得使用服務帳號登入(違反須告警)L1A.8.25.4DE.CM-03(i)OWASP NHI10
IAM-11第三方帳號經 PAM/ZTNA,有效期 ≤90 天L1A.5.19, A.8.26.2, 15.4GV.SC-07(d)—
IAM-12ABAC:專案、客戶、國籍屬性驅動授權L1A.5.15, A.8.36.8PR.AA-05(i)ITAR/EAR
IAM-13專案結案自動觸發權限回收L1A.5.186.2PR.AA-05(i)—
NET-01對外資產清冊與持續 EASM 發現L2A.5.9, A.8.161.1, 1.2, 12.1ID.AM-01, ID.RA-01(a)CTEM Discovery
NET-02KEV 且 known ransomware:24h 內修補或隔離L2/L7A.8.87.3, 7.4ID.RA-01, PR.PS-02(e)CISA ED 25-03
NET-03EOL 邊界裝置有明確下線期限L2A.8.8, A.5.92.2, 12.1PR.PS-02(e)—
NET-04ZTNA 取代 VPN;VPN 有下線計畫L2A.8.20, A.8.2112.7PR.AA-06(i)SP 800-207
NET-05微分段(伺服器/使用者、管理平面、產線、專案)L2A.8.2212.2PR.IR-01(a)—
NET-06conduit 清冊含業務目的、法遵依據、可切斷性L2A.8.21, A.8.2212.4ID.AM-03, PR.IR-01(a)(d)IEC 62443-3-2
NET-07NDR 東西向異常偵測L2/L6A.8.1613.1, 13.3DE.CM-01(b)—
NET-08遞迴 DNS 集中、記錄、過濾L2A.8.204.9, 9.2DE.CM-01(a)—
NET-09對外服務置於 WAF/DDoS 防護後L2A.8.2313.10PR.IR-01(a)—
EPP-01EDR/XDR 覆蓋率報表(以 CMDB/AD 為分母)L3A.8.710.1, 10.7DE.CM-01(g)—
EPP-02產線/設備電腦以差異化控制納入 ISMSL3/L8A.8.7, A.8.910.1, 12.2PR.PS-01(a)SEMI E187
EPP-03設備入網管制(quarantine → 掃描 → 基線 → 核准)L3/L8A.8.9, A.5.191.1, 4.1ID.AM-01, PR.PS-01(d)SEMI E188
EPP-04移除本機管理員權限;工程機以 JIT 提權L3A.8.25.4PR.AA-05(i)—
EPP-05磁碟加密全面覆蓋L3A.8.243.6PR.DS-01(h)—
EPP-06USB 管制與例外流程L3A.7.10, A.8.710.3PR.PS-01(i)CTPAT
EPP-07對高信心告警自動隔離主機(白名單管理例外)L3/L6A.5.2613.7RS.MI-01(b)—
APP-01CSPM 持續組態合規檢查L4A.5.23, A.8.94.1, 4.2PR.PS-01(e)ISO 27017:2026
APP-02IaC 於 PR 階段掃描L4A.8.2816.1PR.PS-06(e)SSDF PW
APP-03Secret 掃描(pre-commit + repo 全歷史)L4A.8.28, A.5.1616.9PR.DS-01(e)SSDF PS
APP-04SAST 於 PR 階段執行L4A.8.2816.12PR.PS-06(e)SSDF PW
APP-05SCA 掃描並產出 SBOML4/L9A.8.28, A.5.2116.4, 16.11ID.AM-08, GV.SC-04(e)CRA Annex I Part II §1
APP-06建置與簽章環境與開發環境分離L4A.8.3116.1PR.PS-01(e)SSDF PS
APP-07GitHub Actions 以 commit SHA 釘選L4A.8.28, A.5.2116.4GV.SC-04(e)CVE-2025-30066
APP-08建置機密使用 OIDC 短期憑證L4A.8.55.2, 16.4PR.AA-03(e)—
APP-09簽章金鑰置於 HSM,雙人授權L4/L9A.8.243.11PR.DS-01(h)IEC 62443-4-1
APP-10SaaS 清冊與影子 IT 發現L4A.5.232.1, 2.3ID.AM-02(a)—
APP-11OAuth 第三方應用須管理員審核L4A.5.23, A.8.22.3, 6.8PR.AA-05(i)Silk Typhoon
DAT-01四維資料分類(敏感度/所有權/法域/生命週期)L5A.5.12, A.5.133.2, 3.7ID.AM-07(i)—
DAT-02DSPM 資料發現與清冊L5A.5.123.1, 3.2ID.AM-07(i)—
DAT-03DLP(郵件/Web/端點/雲端)L5A.8.123.13PR.DS-05(i)ISO 27002 8.12(新增)
DAT-04EDRM/IRM 保護客戶 IP 與極機密文件L5A.5.13, A.8.123.13PR.DS-05(i)客戶合約
DAT-05靜態與傳輸加密;金鑰置於 KMS/HSML5A.8.243.11PR.DS-01, PR.DS-02(h)GDPR Art.32;CSL 790 號令 Art.9
DAT-06高敏感資料庫活動監控 + UEBAL5/L6A.8.168.11, 13.5DE.CM-03, DE.AE-03(b)台積電 2nm 案
DAT-07動態浮水印L5A.5.133.13PR.DS-05(i)台積電 2nm 案
DAT-08保存期政策與到期自動刪除L5A.8.103.5PR.DS-01(i)ISO 27002 8.10(新增)
DAT-09中國區重要資料年度風險評估報省級L5A.5.31—GV.OC-03—790 號令 Art.33
SOC-01P1 遙測來源全部接入 SIEML6A.8.15, A.8.168.2, 8.5, 8.9DE.CM-01, DE.AE-03(b)ISO 27002 8.16(新增)
SOC-02日誌保存:熱 ≥90 天;身分/網路 ≥24 個月L6A.8.158.3, 8.10DE.AE-03(b)Volt Typhoon
SOC-03單一通報決策樹(六路徑同時判定)L6/L0A.5.24, A.5.2517.4RS.CO-02, RS.MA-01(b)TWSE 2h / CRA 24h / GDPR 72h
SOC-04事件分級標準(P0–P4)與通報層級L6A.5.2517.4RS.MA-02(b)SP 800-61r3
SOC-05預擬重訊草稿(三情境)L6/L0A.5.2417.5RS.CO-02—TWSE 2 小時
SOC-06桌上演練(含法務與公關),年度至少一次L6A.5.2417.8ID.IM-02(b)—
SOC-07威脅獵捕,每月至少一次L6A.5.713.1DE.AE-07(b)ISO 27002 5.7(新增)
EXP-01弱點優先序以 KEV + EPSS + 可達性L7A.8.87.1–7.7ID.RA-01(e)EPSS
EXP-02CTEM 每輪產出進入工單系統的待辦L7A.8.87.2ID.RA-06(e)—
EXP-03EASM 與 CMDB 季度差異報告L7A.5.91.1, 1.5ID.AM-01(a)—
EXP-04AEV 驗證微分段、備份不可變性、EDR 攔阻、權限提升路徑L7A.8.8, A.5.3518.1–18.5ID.IM-01(f)—
EXP-05紅隊涵蓋服務台 vishing、HR 履歷、供應商冒充L7/X3A.5.35, A.6.318.3ID.IM-02(g)Clorox / UNK_FistBump
EXP-06產線降級演練(IT 全斷)L7/X2A.5.3011.5ID.IM-02, RC.RP-01(c)Kojima / Asahi
OT-01OT 資產清冊(被動發現為主)L8A.5.91.1, 1.2ID.AM-01(a)IEC 62443-2-1 CM
OT-02Level 3.5 DMZ 為唯一 IT↔OT 跨越點L8A.8.2212.2PR.IR-01(a)IEC 62443-3-2
OT-03堡壘機為 OT 遠端存取唯一入口,session 錄影L8A.8.2, A.8.216.8, 12.7PR.AA-05(i)IEC 62443-2-1 USER
OT-04供應商遠端維運:事前申請 + 時窗 + 錄影 + PAML8/X1A.5.19, A.8.215.4, 6.8GV.SC-07(d)IEC 62443-2-4
OT-05OT 備份(PLC 程式、組態、recipe)年度還原測試L8/X2A.8.1311.5RC.RP-01(c)IEC 62443-2-1 AVAIL
SUP-01供應商雙軸分級(營運依賴 × 資料存取)X1A.5.19, A.5.2115.1, 15.2GV.SC-04(d)SP 800-161r1
SUP-02T1/T2 供應商完整問卷(含非生產環境)X1A.5.19, A.5.2215.3GV.SC-06(d)Kinmax 案
SUP-03關鍵供應商 24h 事件通知條款X1A.5.20, A.5.2215.4GV.SC-08(d)SEC Item 1.05 下壓
SUP-04T1 供應商第二來源與退場計畫X1A.5.3015.5GV.SC-10(c)(d)MKS 案
SUP-05供應商 ISO 27001 證書須為 :2022 版X1A.5.2115.2GV.SC-06(d)IAF MD 26 轉版期已屆滿
RES-013-2-1-1-0;至少一份不可變備份X2A.8.1311.1–11.4PR.DS-11(c)—
RES-02備份系統身分與網域完全隔離X2A.8.13, A.8.211.3PR.DS-11(c)—
RES-03還原測試:關鍵系統每季、其餘每年X2A.8.1311.5RC.RP-01(c)—
RES-04以出貨鏈為單位的 RTO/RPOX2A.5.29, A.5.3011.1RC.RP-02(c)ISO 22301
RES-05降級作業手冊 + 離線資料副本X2A.5.3011.1RC.RP-01(c)ISO 27002 5.30(新增)
RES-06SaaS 資料獨立備份X2A.8.13, A.5.2311.2PR.DS-11(c)—
HUM-01資安意識訓練(含高風險族群強化)X3A.6.314.1–14.9PR.AT-01(g)—
HUM-02釣魚演練(以回報率為主指標)X3A.6.314.2PR.AT-01(g)—
HUM-03付款雙人覆核與帶外驗證X3A.5.14—PR.AA-05—Arup 案
HUM-04新進/離職營業秘密程序X3A.6.1, A.6.5, A.6.66.2GV.RR-04(i)台積電 2nm 案
HUM-05離職前 90 天回溯 + 前瞻高敏感存取稽核X3/L5A.5.18, A.8.166.2, 8.11DE.CM-03(i)台積電 2nm 案
AI-01AI 使用政策與技術強制X3A.5.1, A.8.232.3GV.PO-01—ISO/IEC 42001
AI-02AI 清冊(服務、自建應用、擁有者、資料流)X3A.5.92.1ID.AM-02(a)NIST AI RMF
AI-03Gateway 層資料分類、DLP、去識別化X3/L5A.8.123.13PR.DS-05(i)—
AI-04Agentic AI 納入 NHI 治理,最小權限,動作審計X3/L1A.8.25.4, 8.5PR.AA-05(i)OWASP LLM03 2026
AI-05HR 系統 AI 功能盤點(AI Act Annex III 第 4 類)X3A.5.31—GV.OC-03—EU AI Act 2027-12-02
PSI-01PSIRT 章程、值班、24h 通報能力L9A.5.24, A.5.2617.1RS.MA-01(e)FIRST PSIRT SF v1.1
PSI-02公開的 CVD 政策(security.txt + 網頁)L9A.5.5, A.6.817.2RS.CO-02(e)CRA Annex I Part II §5
PSI-03SBOM 自動產出(雙格式,每個發行版本)L9A.5.2116.11ID.AM-08(e)CRA Annex I Part II §1
PSI-04元件 → 產品 → 客戶反向對映資料庫L9A.5.9, A.5.211.1, 16.11ID.AM-08(e)—
PSI-05VEX 產出流程(CSAF 2.0 或 OpenVEX)L9A.5.267.2RS.AN-06(e)ISO/IEC 20153:2025
PSI-06依 IEC 62443-4-1 建立 SDLL9A.8.25–8.3116.1–16.14PR.PS-06(e)CRA 過渡策略
PSI-07上游供應商漏洞通知與修補承諾條款L9/X1A.5.20, A.5.2115.4GV.SC-05(d)—
PSI-08支援期承諾(≥5 年)與成本模型L9A.5.20—GV.SC-09—CRA Annex I Part II
PSI-09PSIRT 資料庫預留 EUVD ID 欄位L9————識別碼分裂風險

(完整版建議以 YAML 維護,見 附錄 F 的 controls/ 目錄結構。)

↑ 回附錄目錄

Appendix E

成熟度自評問卷(60 題)

每題以 0–3 分評分,依 §26.1 的 C2M2 MIL 對應;每一個分區(Z1–Z5)分別評分,不要以集團平均掩蓋分區落差。

分數對應 MIL判準
0 分—未執行
1 分≈MIL1 Initiated有做,但臨時性、無文件、依賴個人
2 分≈MIL2 Performed有文件化程序,一致執行,有紀錄
3 分≈MIL3 Managed有指派負責人、有資源、有績效衡量、定期檢視改善

E.1 治理(GOV,6 題)

  1. 資訊安全政策是否經最高管理階層核准,並於過去 12 個月內檢視?
  2. 是否指派資安長並設有專責單位(非兼任)?
  3. 是否定期(至少每年)向董事會報告資安狀況,且有正式紀錄?
  4. 是否維護單一控制項庫並對映至所有適用的外部框架?
  5. 資安例外是否全部有到期日、補償控制與具名的風險承擔者?
  6. 對外揭露的資安資訊(年報、客戶回覆)是否可逐項回溯至內部證據?

E.2 身分與存取(IAM,8 題)

  1. MFA 覆蓋率是否可以「應用清單」為分母精確計算,且 ≥95%?
  2. 遠端存取是否使用防釣魚 MFA(FIDO2/憑證),而非簡訊 OTP?
  3. 所有管理員存取是否經 PAM,且無網路層旁路?
  4. 高敏感系統的存取名單是否每半年由用人主管重新確認?
  5. 服務台的密碼/MFA 重設是否要求帶外驗證,且過去 12 個月做過 vishing 演練?
  6. 是否有完整的 NHI 清冊(含擁有者、用途、輪換週期)?
  7. 是否已禁止長期有效的 API 金鑰?
  8. 專案結案是否自動觸發存取權限回收?

E.3 網路與邊緣(NET,6 題)

  1. 是否有持續更新的對外資產清冊,且每季與 EASM 結果比對?
  2. KEV 收錄且標記 known ransomware use 的漏洞,是否於 24 小時內完成修補或隔離?
  3. EOL 邊界裝置是否有明確且被追蹤的下線期限?
  4. 是否有完整的 conduit 清冊,含法遵依據與可切斷性?
  5. 微分段的有效性是否經實測驗證(而非僅有設計文件)?
  6. 第三方遠端存取是否全部經 PAM/ZTNA,且有效期 ≤90 天?

E.4 端點與工作負載(EPP,5 題)

  1. EDR/XDR 覆蓋率是否以 CMDB/AD 為分母精確計算,並分三類資產統計?
  2. 產線與設備電腦是否正式納入 ISMS 範圍(以差異化控制而非豁免處理)?
  3. 是否有設備入網管制流程(quarantine → 掃描 → 基線 → 核准),且有執行紀錄?
  4. 對高信心告警是否已啟用自動隔離(不等待人工確認)?
  5. EDR 例外是否全部有到期日與補償控制?

E.5 應用與雲端(APP,6 題)

  1. CSPM 告警是否以「可從網際網路達到 + 高權限」分級,而非全部同級?
  2. 是否對所有 repo 執行 Secret 掃描(含全歷史)?
  3. GitHub Actions 是否以 commit SHA 而非版本標籤釘選?
  4. 建置與簽章環境是否與開發環境分離,且開發者無法直接登入?
  5. 是否有 SaaS 清冊與影子 IT 發現機制?
  6. OAuth 第三方應用是否需管理員審核(而非使用者自助授權)?

E.6 資料(DAT,6 題)

  1. 資料分類是否包含所有權與法域兩個維度(而非僅敏感度)?
  2. DSPM 掃描是否產出「可執行的處理清單」(含負責人與期限)?
  3. DLP 是否已有部分政策進入阻擋模式(而非全部僅監控)?
  4. 高敏感資料庫是否有活動監控與 UEBA 異常偵測?
  5. 是否對高敏感文件實施動態浮水印?
  6. 加密金鑰是否置於 KMS/HSM 且與資料分離?

E.7 偵測與應變(SOC,7 題)

  1. P1 遙測來源是否全部接入 SIEM?
  2. 身分與網路日誌保存期是否 ≥24 個月?
  3. 是否有單一通報決策樹,可在 2 小時內同時完成六條路徑的判定?
  4. 是否有預擬的重大訊息草稿範本?
  5. MTTC(偵測到圍堵)是否 <30 分鐘?
  6. 過去 12 個月是否舉行過包含法務與公關的桌上演練?
  7. 是否每月至少進行一次主動威脅獵捕?

E.8 暴露面與驗證(EXP,5 題)

  1. 弱點優先序是否採用 KEV + EPSS + 可達性(而非 CVSS 排序)?
  2. CTEM 的發現是否進入正式工單系統並追蹤關閉率?
  3. 是否以 AEV/BAS 驗證微分段、備份不可變性與 EDR 攔阻能力?
  4. 紅隊/演練是否涵蓋服務台 vishing、HR 履歷、供應商冒充?
  5. 過去 12 個月是否執行過產線降級演練(IT 全斷情境)?

E.9 OT(OT,5 題)

  1. 是否有 OT 資產清冊(型號、韌體、協定、供應商、連線關係)?
  2. Level 3.5 DMZ 是否為 IT↔OT 的唯一跨越點(無直接穿越)?
  3. OT 遠端存取是否全部經堡壘機且 session 錄影?
  4. OT 帳號是否個別化(而非共用帳號)?
  5. PLC 程式、設備組態與 recipe 是否於過去 12 個月做過還原測試?

E.10 供應鏈(SUP,4 題)

  1. 供應商分級是否依「營運依賴 × 資料存取」雙軸(而非採購金額)?
  2. T1 供應商是否全部簽署 24 小時事件通知條款?
  3. 供應商問卷是否涵蓋非生產環境(測試、開發、Demo)?
  4. T1 供應商是否有第二來源或退場計畫?

E.11 韌性與人員(RES/HUM,2 題)

  1. 備份系統的管理帳號是否與網域帳號完全隔離?
  2. 超過門檻的付款是否要求雙人覆核與帶外驗證?

E.12 評分解讀

平均分對應說明
< 1.0前 MIL1多數控制未建立;優先處理粗體題(高風險缺口)
1.0–1.9MIL1有做但不一致;重點在文件化與一致執行
2.0–2.4MIL2已文件化執行;重點在負責人指派與績效衡量
2.5–3.0MIL3已管理;重點在持續改善與跨分區一致性

特別注意:本問卷中的粗體題(共 20 題)對應本手冊「常見失敗模式」中影響最大的項目。若這 20 題平均低於 2.0,建議優先處理,其投資報酬率高於整體平均提升。

↑ 回附錄目錄

Appendix F

Claude Code + GitHub Prompt 套件

把手冊本身變成可持續維護的 repo:repo 結構、CLAUDE.md 專案指令、九組可直接複製的 Prompt、四個 GitHub Actions workflow、控制項 JSON schema 與 YAML 範例、兩個 Issue 範本。

本附錄提供一套可直接複製使用的 Prompt 與設定檔,涵蓋三種用途:

用途說明對應章節
F.1 手冊 repo 化與持續維護把本手冊放進 GitHub repo,用 Claude Code 做版本更新、法規追蹤、引用查證、CI 自動檢查F.3 – F.6
F.2 資安防護網落地評估用 Claude Code 對集團現況做 gap assessment,產出成熟度評分與改善待辦,可對接 GitHub Issues/ProjectsF.7
F.3 控制項+政策文件即程式碼以 YAML/Markdown 管理控制項、政策、KPI,Claude Code 自動產生政策文件、對應矩陣與稽核證據包F.8 – F.9

安全前提(務必先讀):本套件建立在 GitHub 之上,而 GitHub Actions 本身是已證實的供應鏈攻擊面(CVE-2025-30066 / tj-actions,CISA 2025-03-18 列入 KEV已證實)。因此本套件的所有 workflow 一律:

  • 以 commit SHA 而非版本標籤釘選 Action
  • 明確宣告最小 permissions
  • 不在 workflow 中輸出環境變數
  • 對 fork 的 PR 不提供任何機密

此外,本手冊 repo 應設為 private,因為它包含集團的控制項現況與缺口——這本身就是高價值的攻擊情報。

F.1 建議的 Repository 結構

gsmd-security-fabric/
├── CLAUDE.md                     # Claude Code 的專案指令(見 F.2)
├── README.md
├── .github/
│   ├── workflows/
│   │   ├── link-check.yml        # 引用連結有效性檢查
│   │   ├── evidence-check.yml    # 證據分級標註完整性檢查
│   │   ├── control-lint.yml      # 控制項 YAML schema 驗證
│   │   ├── freshness-check.yml   # 標準/法規版本時效性檢查
│   │   └── build-docs.yml        # Markdown → HTML/PDF
│   ├── ISSUE_TEMPLATE/
│   │   ├── gap.yml               # 落地缺口
│   │   ├── regulatory-change.yml # 法規變更
│   │   └── citation-issue.yml    # 引用查證問題
│   └── CODEOWNERS
├── manual/                       # 手冊本體
│   ├── 00-front.md
│   ├── 01-part1-background.md
│   ├── ...
│   └── 99-sources.md
├── controls/                     # 控制項即程式碼
│   ├── _schema.json              # JSON Schema
│   ├── gov.yml                   # 治理層控制項
│   ├── iam.yml
│   ├── net.yml
│   ├── epp.yml
│   ├── app.yml
│   ├── dat.yml
│   ├── soc.yml
│   ├── exp.yml
│   ├── ot.yml
│   ├── sup.yml
│   ├── res.yml
│   ├── hum.yml
│   ├── ai.yml
│   └── psi.yml
├── policies/                     # 政策文件(由控制項自動產生 + 人工補述)
│   ├── _templates/
│   └── generated/
├── assessments/                  # 落地評估
│   ├── _questionnaire.yml        # 60 題自評問卷(附錄 E)
│   ├── 2026-Q3/
│   │   ├── z1-global.yml
│   │   ├── z2-china.yml
│   │   ├── z3-customer.yml
│   │   ├── z4-product.yml
│   │   └── z5-ot.yml
│   └── reports/
├── registry/                     # 追蹤註冊表
│   ├── standards.yml             # 標準版本與檢視日期(附錄 A)
│   ├── regulations.yml           # 法規時程(附錄 B)
│   ├── incidents.yml             # 已驗證事件(附錄 C)
│   ├── analyst-reports.yml       # 分析師報告市場結構(§28.3)
│   └── verification-gaps.yml     # 查證缺口(附錄 G)
├── evidence/                     # 證據索引(不放實際證據,只放索引)
│   └── index.yml
└── scripts/
    ├── check_links.py
    ├── check_evidence_tags.py
    ├── check_freshness.py
    ├── render_matrix.py          # 產生多框架對映矩陣
    └── render_policy.py          # 由控制項產生政策文件

F.2 CLAUDE.md(專案指令檔)

將以下內容存為 repo 根目錄的 CLAUDE.md。Claude Code 每次啟動會自動讀取。

# 專案:跨國 ODM/OEM 製造業集團 IT 資安防護網手冊

## 專案性質

這是一份**企業內部的資安治理文件庫**,同時是**控制項與政策的單一真實來源(single source of truth)**。
文件編號 GSMD-RPT-2026-0830-01。讀者為資安治理決策層與技術落地層。

## 不可違反的規則

### 1. 證據分級是強制的
每一個事實性陳述都必須標註以下四種等級之一:
- 【已證實】= 一手/官方來源(標準機構官方頁、法規正式文本、主管機關新聞稿、上市公司財報或 SEC 申報、法院判決、受害組織官方聲明)
- 【廠商主張】= 具名廠商自行發布的研究或行銷數據,未經獨立驗證
- 【第三方評論】= 具名分析機構、測試機構或主流媒體的評論與整理
- 【尚未證實】= 廣泛流傳但無法回溯至可靠來源,或來源互相矛盾

**未標註等級的事實性陳述,視為錯誤,必須修正。**

### 2. 無來源不列入
若無法取得可靠來源,**不要寫入正文**。改為記錄在 `registry/verification-gaps.yml`。
絕不使用「據報導」「一般認為」「業界普遍」等模糊歸因來規避查證。

### 3. 口徑一致才可比較
不同來源的數字若口徑不同(例如 SEC 申報的增量費用 vs 媒體含營收損失的估計),
**不可放在同一張表或同一句話中比較**。必須註明口徑差異。

### 4. 方法一致才可畫趨勢
若跨年度調查的樣本數或題目定義改變(且來源未說明),**只引用單一年度數字並註明 n**,不畫趨勢線。

### 5. 分析師報告的引用紀律
- 任何分析師定位必須註明:**報告正式名稱 + 發布日期 + 分析師姓名**
- **Market Guide 沒有 Leader**,只有 "Representative Vendor"
- **Gartner Peer Insights 是客戶評分,不是分析師評測**
- 以下市場目前**沒有 Magic Quadrant**:CNAPP、DSPM、Data Security Platforms、IGA、MDR、SOAR、SSPM、EASM、API Protection、微分段、SD-WAN(現行)、AI Gateway / AI SOC
- 現行市場結構請查 `registry/analyst-reports.yml`

### 6. 語言與術語
- 正體中文,臺灣慣用語
- 英文專業術語、標準編號、法規名稱一律保留原文(不翻譯 CRA、NIS2、SBOM、ZTNA 等)
- 標準引用必須含版本與日期,且註明是 IEC 版或 ANSI/ISA 版(兩者編號不同步)

### 7. 不得聲稱不存在的官方對映
**不存在 NIST 官方發行、經 OLIR 驗證的「CSF 2.0 ↔ IEC 62443」對映表。**
本 repo 的 `controls/*.yml` 中的 62443 對映欄位一律標示為 `mapping_source: self-authored`。

## 資料模型

### controls/*.yml
每個控制項的必要欄位見 `controls/_schema.json`。修改控制項時:
1. 必須同時更新 `frameworks` 對映
2. 必須指定 `owner`(組織功能,非個人姓名)
3. 必須指定 `evidence`(可稽核產出)
4. 若新增外部框架,必須同時更新所有相關控制項的該欄位

### assessments/*/*.yml
自評結果。評分為 0–3(對應 C2M2 MIL)。每個分區(Z1–Z5)獨立評分。
評分變更時**必須填寫 `justification` 與 `evidence_ref`**。

### registry/standards.yml 與 registry/regulations.yml
標準與法規的版本追蹤。每筆必須有 `next_review` 日期。
`freshness-check.yml` workflow 會在 `next_review` 到期時開 Issue。

## 常用任務

當我要求以下事情時,請這樣做:

### 「更新某個標準的版本」
1. 用 WebFetch 存取該標準的**官方頁面**(ISO、IEC、NIST CSRC、EUR-Lex 等),不要用二手來源
2. 更新 `registry/standards.yml`
3. 用 grep 找出手冊中所有引用該標準的位置並更新
4. 若版本變更影響控制項對映,同步更新 `controls/*.yml`
5. 在 commit message 中列出所有變更的檔案與變更理由

### 「查證某個引用」
1. 用 WebFetch 存取原始 URL
2. 確認引述內容與來源一致(逐字比對關鍵數字與日期)
3. 若不一致,**不要自行修正數字**,而是在 `registry/verification-gaps.yml` 記錄矛盾並回報給我
4. 若 URL 失效,尋找官方的替代 URL;找不到則標記為 `[dead-link]` 並降級為【尚未證實】

### 「做落地評估」
見 `assessments/_questionnaire.yml`。逐題詢問,每題必須取得 `evidence_ref`(證據文件、系統截圖位置、報表名稱)。
**沒有證據的自評分數一律以低一級記錄,並在 `justification` 中註明「自評無證據」。**

### 「產生政策文件」
執行 `scripts/render_policy.py`,由 `controls/*.yml` 產生 `policies/generated/`。
產生的檔案不可手動編輯(會被覆寫);人工補述放在 `policies/_templates/` 的對應區塊。

### 「產生對映矩陣」
執行 `scripts/render_matrix.py`,產出 `manual/appendix-d-matrix.md`。
矩陣頂端必須自動加上「本矩陣為本手冊自行編製,非官方對映」的聲明。

## 絕對不要做的事

1. 不要為了讓文件看起來完整而編造來源或 URL
2. 不要把【廠商主張】的數字寫成【已證實】
3. 不要在 GitHub Actions 中使用版本標籤(`@v4`)釘選 Action,一律用 commit SHA
4. 不要在 workflow 或 script 中輸出環境變數或 secrets
5. 不要把實際的稽核證據(截圖、日誌、報表)提交到 repo;`evidence/index.yml` 只放索引
6. 不要修改 `registry/incidents.yml` 中已標記 `verified: true` 的事件,除非有新的一手來源
7. 不要在沒有我明確確認的情況下 push 到 main 分支

## 提交規範

Commit message 格式:
```
<type>(<scope>): <subject>

<body:說明變更理由與證據來源>

Refs: <相關 Issue 編號>
```

type: `manual`(手冊內容)、`control`(控制項)、`registry`(追蹤表)、`assessment`(評估)、`ci`(workflow)、`fix`(修正錯誤)

**若變更涉及事實性陳述,body 中必須列出來源 URL 與查證日期。**

F.3 用途一:手冊 repo 化與持續維護的 Prompt

F.3.1 初始化 Prompt(一次性)

請把這份資安防護網手冊初始化為一個可持續維護的 GitHub repo。

輸入:manual/ 目錄下的 Markdown 檔案(GSMD-RPT-2026-0830-01)

請執行以下步驟,每完成一步先讓我確認再繼續:

步驟 1:解析並建立 registry
從手冊中萃取出所有被引用的「標準」「法規」「分析師報告」「已驗證事件」,
分別建立 registry/standards.yml、registry/regulations.yml、
registry/analyst-reports.yml、registry/incidents.yml。

每筆記錄必須包含:
- id(穩定識別碼)
- name(正式名稱,保留原文)
- version(版本或編號)
- date(發布/生效日期)
- issuer(發行機構)
- url(官方來源 URL)
- evidence_level(已證實/廠商主張/第三方評論/尚未證實)
- cited_in(手冊中引用的章節清單)
- next_review(下次檢視日期:標準每 6 個月、法規每 3 個月、分析師報告每 6 個月)

步驟 2:建立控制項庫
從手冊附錄 D 萃取控制項,依前綴(GOV/IAM/NET/EPP/APP/DAT/SOC/EXP/OT/SUP/RES/HUM/AI/PSI)
拆成 controls/*.yml,並建立 controls/_schema.json。

每個控制項必須包含:
id, title, layer, zone_applicability[], owner, frameworks{}, evidence[],
failure_modes[], references[], mapping_source

frameworks 欄位包含:iso27001_2022, cis_v81, csf_20, nis2_art21, cra_annex_i,
cmmc_l2, iec62443, semi, other

mapping_source 對 IEC 62443 一律填 "self-authored"。

步驟 3:建立查證缺口表
從手冊附錄 G 萃取所有【尚未證實】項目,建立 registry/verification-gaps.yml,
每筆包含:id, description, why_unverified, impact, suggested_action, owner, target_date

步驟 4:建立 CI workflows
依 F.5 的範例建立四個 workflow,所有 Action 以 commit SHA 釘選。

步驟 5:建立 CLAUDE.md
使用 F.2 的內容。

完成後產出一份 SETUP-REPORT.md,說明:
- 萃取出多少筆標準/法規/報告/事件/控制項/缺口
- 哪些項目因資訊不完整而需要人工補齊
- 建議的第一批待辦

F.3.2 定期維護 Prompt(建議每月執行)

執行本 repo 的月度維護。今天是 {DATE}。

任務 1:時效性檢查
讀取 registry/standards.yml 與 registry/regulations.yml,
找出 next_review 已到期或即將到期(30 天內)的項目。
對每一筆:
- 用 WebFetch 存取其 official url
- 確認版本號與日期是否仍為現行
- 若已改版,記錄新版本、新日期,並用 grep 找出手冊中所有引用位置
- 若官方頁面無法存取,記錄為 [fetch-failed] 並保留原資料,不要猜測

任務 2:法規時程檢查
讀取 registry/regulations.yml,找出未來 90 天內有里程碑的法規。
產出一份「即將到期的合規義務」清單,包含:法規、里程碑、日期、
本集團的準備狀態(從 assessments/ 讀取)、負責人。

任務 3:新增威脅情報檢查
搜尋以下項目自上次維護以來的更新:
- CISA KEV 新增項目中,涉及本 repo registry/vendors.yml 所列廠商者
- MITRE ATT&CK 是否有新版本(目前記錄為 v19.2 / 2026-08-06)
- 製造業重大資安事件(須有受害方聲明或權威具名來源才列入)

任務 4:連結健康檢查
執行 scripts/check_links.py,回報失效連結。
對每個失效連結,嘗試尋找官方替代 URL;找不到則標記 [dead-link]。

輸出:
1. 一份 MAINTENANCE-{YYYY-MM}.md 報告
2. 為每個需要人工處理的項目建立 GitHub Issue(使用對應的 ISSUE_TEMPLATE)
3. 對可自動更新的項目(純版本號變更)建立一個 PR

不要直接 push 到 main。

F.3.3 引用查證 Prompt(在 PR review 時使用)

請對這個 PR 中所有新增或修改的事實性陳述執行查證。

對每一項陳述:
1. 確認是否有證據等級標註。沒有的話,標記為必須修正。
2. 若標註為【已證實】,用 WebFetch 存取來源 URL,逐字比對關鍵數字與日期。
   不一致時,指出差異,並建議正確的等級或正確的數字。
3. 若標註為【廠商主張】或【第三方評論】,確認來源是否具名(廠商名/機構名/報告名/日期)。
   不具名者,要求補齊或降級。
4. 檢查是否有口徑混用(例如把不同定義的兩個數字並列比較)。
5. 檢查是否有跨年度趨勢線但方法可能不一致的情況。
6. 檢查分析師報告的引用是否含「報告正式名稱 + 日期 + 分析師姓名」,
   以及是否誤把 Market Guide 的 Representative Vendor 說成 Leader。

輸出格式:對每一項問題,給出
- 檔案與行號
- 問題類型(缺少等級 / 等級錯誤 / 數字不符 / 來源不具名 / 口徑混用 / 假象限 / 死連結)
- 建議的修正文字

不要自行修改檔案,只提出 review comments。

F.4 用途二:資安防護網落地評估的 Prompt

F.4.1 分區評估 Prompt

請對 {ZONE}(Z1 全球區 / Z2 中國區 / Z3 客戶專案區 / Z4 產品開發區 / Z5 廠務 OT 區)
執行資安防護網落地評估。

使用 assessments/_questionnaire.yml 的 60 題問卷。

執行規則:
1. 一次問一題,等我回答後再問下一題。不要一次列出所有問題。
2. 每題除了 0–3 的評分外,必須追問「證據是什麼」——
   具體的文件名稱、系統報表、設定截圖位置或稽核紀錄。
3. 若我無法提供證據,該題評分自動降一級(最低 0),
   並在 justification 中記錄「自評 N 分但無證據,降級記錄」。
4. 若我的回答顯示該題對本分區不適用,記為 N/A 並要求說明理由。
5. 對粗體題(高風險缺口項),若評分 ≤1,立即追問「是否有補償控制」。

問卷完成後,產出:

A. assessments/{PERIOD}/{ZONE}.yml
   包含每題的:score, evidence_ref, justification, gaps[], compensating_controls[]

B. 一份評估報告 assessments/reports/{PERIOD}-{ZONE}.md,包含:
   - 各領域(GOV/IAM/NET/EPP/APP/DAT/SOC/EXP/OT/SUP/RES/HUM)的平均分與 MIL 對應
   - 與目標成熟度(見手冊 §26.2)的差距
   - 依「風險 × 改善難度」排序的前 10 項改善建議
   - 每項改善建議對應到手冊的哪一章、哪個控制項 ID

C. GitHub Issues:
   對評分 ≤1 且無補償控制的項目,各建立一個 Issue,使用 gap.yml 範本,
   標題格式:[GAP][{ZONE}][{CONTROL_ID}] {簡述}
   內容包含:目前狀態、目標狀態、對應控制項、手冊章節、建議行動、預估工作量
   標籤:gap, zone/{zone}, layer/{layer}, priority/{p1|p2|p3}

不要在我沒有回答完所有問題前就產出報告。

F.4.2 缺口優先排序 Prompt

讀取 assessments/{PERIOD}/ 下所有分區的評估結果,
產出一份跨分區的整合改善計畫。

排序邏輯(依序):
1. 有外部截止日的合規項(讀取 registry/regulations.yml)— 最優先,不可延後
2. 對應到手冊「常見失敗模式」中影響最大的十項者
3. 依「風險降低量 ÷ 改善工作量」排序

風險降低量的評估依據(必須在輸出中說明引用了哪一項):
- 手冊第 2 章的威脅統計(哪個入侵途徑佔比高)
- 手冊第 3 章的已驗證事件(該缺口是否為某個實際事件的成因)
- 該控制項覆蓋的框架數(覆蓋越多,一次改善的合規效益越高)

輸出 assessments/reports/{PERIOD}-roadmap.md,包含:
1. 立即行動(30 天內,通常是合規截止日與高風險無補償控制項)
2. 短期(Q1–Q2)
3. 中期(Q3–Q4)
4. 長期(次年以後)

每一項包含:控制項 ID、分區、目前分數、目標分數、負責組織功能、
預估工作量(人天)、依賴項、驗收標準(引用手冊的「可稽核產出」)。

同時產出一個 GitHub Projects 的匯入用 CSV。

F.5 GitHub Actions Workflow 範例

所有範例均以 commit SHA 釘選 Action,並宣告最小 permissions。 使用時請自行確認 SHA 對應的版本(以下 SHA 為示意,必須替換為你自己驗證過的 SHA)。

F.5.1 .github/workflows/link-check.yml

name: Link Check

on:
  schedule:
    - cron: '0 2 * * 1'   # 每週一 02:00 UTC
  workflow_dispatch:
  pull_request:
    paths:
      - 'manual/**'
      - 'registry/**'

permissions:
  contents: read
  issues: write

jobs:
  check-links:
    runs-on: ubuntu-latest
    steps:
      # 請以你驗證過的 commit SHA 取代(不要用 @v4)
      - name: Checkout
        uses: actions/checkout@<COMMIT_SHA_FOR_ACTIONS_CHECKOUT>

      - name: Setup Python
        uses: actions/setup-python@<COMMIT_SHA_FOR_ACTIONS_SETUP_PYTHON>
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: pip install --require-hashes -r scripts/requirements.txt

      - name: Run link check
        run: python scripts/check_links.py --input manual registry --output link-report.json

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@<COMMIT_SHA_FOR_ACTIONS_UPLOAD_ARTIFACT>
        with:
          name: link-report
          path: link-report.json

      - name: Fail on dead links in verified citations
        run: python scripts/check_links.py --assert-verified-alive --input link-report.json

F.5.2 .github/workflows/evidence-check.yml

name: Evidence Tag Check

on:
  pull_request:
    paths:
      - 'manual/**'

permissions:
  contents: read
  pull-requests: write

jobs:
  evidence-tags:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@<COMMIT_SHA_FOR_ACTIONS_CHECKOUT>
        with:
          fetch-depth: 0

      - name: Setup Python
        uses: actions/setup-python@<COMMIT_SHA_FOR_ACTIONS_SETUP_PYTHON>
        with:
          python-version: '3.12'

      # 檢查新增/修改的行中,含有數字、日期或標準編號的事實性陳述
      # 是否帶有【已證實】/【廠商主張】/【第三方評論】/【尚未證實】標註
      - name: Check evidence tags on changed lines
        run: |
          git diff --unified=0 origin/${{ github.base_ref }}...HEAD -- 'manual/*.md' \
            > changed.diff
          python scripts/check_evidence_tags.py --diff changed.diff --strict

      # 檢查是否有「假象限」用語
      - name: Check for false Magic Quadrant claims
        run: python scripts/check_evidence_tags.py --check-analyst-claims --input manual/

F.5.3 .github/workflows/control-lint.yml

name: Control Schema Lint

on:
  pull_request:
    paths:
      - 'controls/**'
  push:
    branches: [main]
    paths:
      - 'controls/**'

permissions:
  contents: read

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@<COMMIT_SHA_FOR_ACTIONS_CHECKOUT>

      - name: Setup Python
        uses: actions/setup-python@<COMMIT_SHA_FOR_ACTIONS_SETUP_PYTHON>
        with:
          python-version: '3.12'

      - run: pip install --require-hashes -r scripts/requirements.txt

      - name: Validate control YAML against schema
        run: |
          python - <<'PY'
          import json, sys, glob
          import yaml
          from jsonschema import Draft202012Validator

          schema = json.load(open('controls/_schema.json'))
          validator = Draft202012Validator(schema)
          errors = 0
          ids = set()
          for path in glob.glob('controls/*.yml'):
              data = yaml.safe_load(open(path))
              for ctrl in data.get('controls', []):
                  for e in validator.iter_errors(ctrl):
                      print(f"{path}:{ctrl.get('id','?')}: {e.message}")
                      errors += 1
                  cid = ctrl.get('id')
                  if cid in ids:
                      print(f"{path}: duplicate control id {cid}")
                      errors += 1
                  ids.add(cid)
                  # IEC 62443 對映必須標示為自行編製
                  fw = ctrl.get('frameworks', {})
                  if fw.get('iec62443') and ctrl.get('mapping_source') != 'self-authored':
                      print(f"{path}:{cid}: IEC 62443 mapping must set mapping_source: self-authored")
                      errors += 1
          sys.exit(1 if errors else 0)
          PY

F.5.4 .github/workflows/freshness-check.yml

name: Standards & Regulations Freshness

on:
  schedule:
    - cron: '0 1 1 * *'   # 每月 1 日
  workflow_dispatch:

permissions:
  contents: read
  issues: write

jobs:
  freshness:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@<COMMIT_SHA_FOR_ACTIONS_CHECKOUT>

      - name: Setup Python
        uses: actions/setup-python@<COMMIT_SHA_FOR_ACTIONS_SETUP_PYTHON>
        with:
          python-version: '3.12'

      - run: pip install --require-hashes -r scripts/requirements.txt

      # 找出 next_review 到期者,並為每一筆建立 Issue
      - name: Find items due for review
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: python scripts/check_freshness.py --create-issues

注意:--require-hashes 要求 scripts/requirements.txt 中每個套件都釘選雜湊值。這是對應 §3.4 中 npm/PyPI 供應鏈攻擊(Shai-Hulud 兩波)的直接控制。

F.6 控制項 YAML 範例與 Schema

F.6.1 controls/_schema.json(節錄)

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["id", "title", "layer", "owner", "frameworks", "evidence"],
  "properties": {
    "id": {
      "type": "string",
      "pattern": "^(GOV|IAM|NET|EPP|APP|DAT|SOC|EXP|OT|SUP|RES|HUM|AI|PSI)-[0-9]{2}$"
    },
    "title": { "type": "string", "minLength": 5 },
    "layer": {
      "type": "string",
      "enum": ["L0","L1","L2","L3","L4","L5","L6","L7","L8","L9","X1","X2","X3"]
    },
    "zone_applicability": {
      "type": "array",
      "items": { "type": "string", "enum": ["Z1","Z2","Z3","Z4","Z5"] },
      "minItems": 1
    },
    "owner": { "type": "string" },
    "frameworks": {
      "type": "object",
      "properties": {
        "iso27001_2022": { "type": "array", "items": { "type": "string" } },
        "cis_v81":       { "type": "array", "items": { "type": "string" } },
        "csf_20":        { "type": "array", "items": { "type": "string" } },
        "nis2_art21":    { "type": "array", "items": { "type": "string" } },
        "cra_annex_i":   { "type": "array", "items": { "type": "string" } },
        "cmmc_l2":       { "type": "array", "items": { "type": "string" } },
        "iec62443":      { "type": "array", "items": { "type": "string" } },
        "semi":          { "type": "array", "items": { "type": "string" } },
        "other":         { "type": "array", "items": { "type": "string" } }
      },
      "additionalProperties": false
    },
    "mapping_source": {
      "type": "string",
      "enum": ["nist-olir", "issuer-official", "self-authored"]
    },
    "evidence": {
      "type": "array",
      "items": { "type": "string" },
      "minItems": 1,
      "description": "可稽核產出:具體的文件、報表或系統設定"
    },
    "failure_modes": { "type": "array", "items": { "type": "string" } },
    "references": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["text", "evidence_level"],
        "properties": {
          "text": { "type": "string" },
          "url": { "type": "string", "format": "uri" },
          "date": { "type": "string" },
          "evidence_level": {
            "type": "string",
            "enum": ["已證實", "廠商主張", "第三方評論", "尚未證實"]
          }
        }
      }
    },
    "target_mil": {
      "type": "object",
      "patternProperties": {
        "^Z[1-5]$": { "type": "integer", "minimum": 0, "maximum": 3 }
      }
    }
  }
}

F.6.2 controls/net.yml(範例,兩個控制項)

metadata:
  domain: Network and Edge
  layer: L2
  last_updated: 2026-08-30
  owner: Security Architecture

controls:
  - id: NET-02
    title: KEV 收錄且標記 known ransomware use 的漏洞於 24 小時內完成修補或隔離
    layer: L2
    zone_applicability: [Z1, Z2, Z3, Z4, Z5]
    owner: SecOps / Vulnerability Management
    frameworks:
      iso27001_2022: ["A.8.8"]
      cis_v81: ["7.3", "7.4"]
      csf_20: ["ID.RA-01", "PR.PS-02"]
      nis2_art21: ["(e)"]
      cmmc_l2: ["RA.L2-3.11.2"]
      other: ["CISA ED 25-03"]
    mapping_source: self-authored
    target_mil:
      Z1: 3
      Z2: 2
      Z3: 2
      Z4: 3
      Z5: 2
    evidence:
      - 邊界裝置清冊(型號、韌體版本、EOL 日期、對外服務、負責人)
      - KEV 緊急修補 SLA 執行紀錄(發現時間、完成時間、逾期原因)
      - 無法修補項目的隔離措施證據
    failure_modes:
      - 修補 SLA 以「工作日」計算,實際超過 24 小時
      - 邊界裝置清冊不完整,KEV 比對有遺漏
      - 修補後未輪換該裝置經手的憑證
    references:
      - text: "CISA ED 25-03 要求 Cisco 更新於釋出後 48 小時內套用;並指出攻擊者可竄改 ROM 於重開機與升級後持續存在"
        url: "https://www.cisa.gov/news-events/directives/ed-25-03-identify-and-mitigate-potential-compromise-cisco-devices"
        date: "2025-09-25"
        evidence_level: "已證實"
      - text: "IBM X-Force 2026:製造業初始入侵 32% 為對外服務應用程式漏洞利用"
        date: "2026-02"
        evidence_level: "廠商主張"

  - id: NET-06
    title: conduit 清冊須含業務目的、法遵依據與可切斷性
    layer: L2
    zone_applicability: [Z1, Z2, Z3, Z4, Z5]
    owner: Security Architecture
    frameworks:
      iso27001_2022: ["A.8.21", "A.8.22"]
      cis_v81: ["12.4"]
      csf_20: ["ID.AM-03", "PR.IR-01"]
      nis2_art21: ["(a)", "(d)"]
      iec62443: ["3-2 zones and conduits"]
    mapping_source: self-authored
    target_mil:
      Z1: 3
      Z2: 3
      Z3: 2
      Z4: 2
      Z5: 2
    evidence:
      - conduit 清冊(含 conduit ID、來源/目的分區、業務目的、協定與埠、資料類型、法遵依據、認證方式、監控點、可切斷性、擁有者、檢視週期)
      - 每年度的 conduit 複審紀錄
    failure_modes:
      - 只記錄「有什麼連線」,未記錄「怎麼關」
      - 第三方連線未納入清冊
      - 跨境 conduit 未記錄法遵依據
    references:
      - text: "台積電於 Kinmax 供應商事件中的處置為終止與該供應商的資料交換"
        date: "2023-06"
        evidence_level: "已證實"

F.7 用途三:政策文件即程式碼

F.7.1 產生政策文件的 Prompt

請由 controls/*.yml 產生政策文件。

規則:
1. 依 layer 分組,每個 layer 產生一份標準文件(Standard),
   放在 policies/generated/{layer}-standard.md
2. 每份文件的結構:
   - 目的與範圍(含適用的分區)
   - 規範性要求(逐條列出該 layer 的控制項 title,以「應」開頭改寫為規範語氣)
   - 分區差異(依 zone_applicability 與 target_mil 產生)
   - 例外處理(統一引用集團例外管理程序)
   - 稽核證據(列出所有 evidence 欄位)
   - 外部依據(列出 frameworks 對映,並在 IEC 62443 欄位加註「本對映為自行編製」)
3. 每份文件頂端加上自動產生標記:
   「本文件由 controls/*.yml 自動產生,請勿直接編輯。人工補述請寫在 policies/_templates/ 對應區塊。」
4. 版本號取自 git 的最新 commit SHA 前 7 碼與日期。

另外產生一份 policies/generated/_coverage.md,說明:
- 每個外部框架的覆蓋率(該框架有多少條款被至少一個控制項對映到)
- 未被任何控制項覆蓋的框架條款清單(這就是控制缺口)

F.7.2 產生稽核證據包的 Prompt

客戶 {CUSTOMER} 要對我們做資安稽核,稽核範圍是 {SCOPE}。
請產生一份稽核準備包。

步驟:
1. 從 controls/*.yml 篩選出與稽核範圍相關的控制項
2. 從 evidence/index.yml 找出每個控制項對應的實際證據文件位置
3. 從 assessments/ 最新一期讀取這些控制項的自評分數
4. 產出 audit-prep/{CUSTOMER}-{DATE}.md,包含:

   A. 控制項對照表:控制項 ID | 控制項描述 | 我方實作說明 | 證據文件 | 自評分數
   B. 已知缺口與補償控制(自評 ≤1 者)
   C. 預期問題與建議回覆(依據過去稽核紀錄中的重複問題)
   D. 證據文件清單(哪些可直接提供、哪些需遮蔽、哪些不可提供及理由)

5. 特別檢查:
   - 若稽核涉及 Z2 中國區,標示出因 DSL 第 36 條/PIPL 第 41 條而不可提供原始資料的項目,
     並提供替代方案(匯總指標、境內執行的稽核報告、現場檢視不帶走)
   - 若我方文件中有任何以「通過 RBA VAP」回應資安問題的內容,標記為必須修正
     (RBA VAP 官方範圍不含資安)
   - 若引用了任何分析師定位,檢查是否符合引用紀律(報告名稱+日期+分析師)

6. 稽核結束後,請我提供稽核發現,你負責:
   - 更新 registry/audit-findings.yml
   - 比對是否為重複發現(同一控制項在不同客戶稽核中重複出現)
   - 為每個發現建立 GitHub Issue 並連結到對應控制項

F.8 Issue 範本

.github/ISSUE_TEMPLATE/gap.yml

name: 落地缺口 (Gap)
description: 由評估或稽核發現的控制項缺口
title: "[GAP][ZONE][CONTROL-ID] "
labels: ["gap"]
body:
  - type: input
    id: control_id
    attributes:
      label: 控制項 ID
      placeholder: NET-02
    validations:
      required: true
  - type: dropdown
    id: zone
    attributes:
      label: 分區
      options: ["Z1 全球", "Z2 中國", "Z3 客戶專案", "Z4 產品開發", "Z5 廠務 OT"]
    validations:
      required: true
  - type: dropdown
    id: current_score
    attributes:
      label: 目前自評分數
      options: ["0 未執行", "1 臨時性", "2 已文件化執行", "3 已管理"]
    validations:
      required: true
  - type: input
    id: target_score
    attributes:
      label: 目標分數
    validations:
      required: true
  - type: textarea
    id: evidence
    attributes:
      label: 現況證據
      description: 目前有什麼文件/報表/設定可以證明現況?沒有的話請寫「無」
    validations:
      required: true
  - type: textarea
    id: compensating
    attributes:
      label: 補償控制
      description: 在缺口未關閉前,有什麼替代措施降低風險?
  - type: dropdown
    id: driver
    attributes:
      label: 驅動因素
      options:
        - 法規截止日(不可延後)
        - 客戶要求
        - 常見失敗模式前十項
        - 風險降低
    validations:
      required: true
  - type: input
    id: deadline
    attributes:
      label: 外部截止日(若有)
      placeholder: 2026-09-11
  - type: input
    id: effort
    attributes:
      label: 預估工作量(人天)
  - type: textarea
    id: acceptance
    attributes:
      label: 驗收標準
      description: 引用手冊該章的「可稽核產出」
    validations:
      required: true

.github/ISSUE_TEMPLATE/regulatory-change.yml

name: 法規變更 (Regulatory Change)
description: 追蹤外部法規或標準的變更及其影響
title: "[REG] "
labels: ["regulatory"]
body:
  - type: input
    id: regulation
    attributes:
      label: 法規/標準名稱(保留原文)
      placeholder: EU Cyber Resilience Act — Regulation (EU) 2024/2847
    validations:
      required: true
  - type: input
    id: change_date
    attributes:
      label: 變更/生效日期
    validations:
      required: true
  - type: input
    id: source_url
    attributes:
      label: 官方來源 URL
    validations:
      required: true
  - type: dropdown
    id: evidence_level
    attributes:
      label: 證據等級
      options: ["已證實", "廠商主張", "第三方評論", "尚未證實"]
    validations:
      required: true
  - type: textarea
    id: impact
    attributes:
      label: 對本集團的影響
      description: 影響哪些分區、哪些控制項、哪些產品線
    validations:
      required: true
  - type: textarea
    id: affected_controls
    attributes:
      label: 受影響的控制項 ID
  - type: textarea
    id: manual_sections
    attributes:
      label: 需更新的手冊章節

F.9 使用本套件的三個注意事項

  1. repo 必須是 private。它包含集團的控制項現況、自評分數與缺口清單——這對攻擊者是高價值情報。建議另設 branch protection、required reviews 與 CODEOWNERS。
  2. 不要把實際證據提交到 repo。evidence/index.yml 只放索引(文件名稱、存放系統、負責人、更新日期)。實際的截圖、日誌、稽核報告放在文件管理系統中,並依第 16 章的資料分類保護。
  3. CI 本身是攻擊面。除了本附錄已納入的 SHA 釘選、最小 permissions、--require-hashes 之外,建議:
    • 定期檢視 repo 的 Actions 使用清單,移除不再需要的
    • 對 self-hosted runner 特別謹慎(Shai-Hulud 2.0 即建立 workflow 作為 self-hosted runner 持久化)
    • 監控 repo 中新增的 workflow 檔案

↑ 回附錄目錄

Appendix G

查證缺口清單(本次研究無法證實的項目)

誠實列出 62 項無法回溯至可靠一手來源、或來源互相矛盾的項目——列出它們,是為了避免它們在未來被誤當成已證實資訊使用。

本清單記錄本次研究中無法回溯至可靠一手來源、或來源互相矛盾的項目。列出它們是為了避免它們在未來被誤當成已證實資訊使用。

截至 2026-09-29:已結案 13 項(#10、#11、#14、#15、#16、#22、#24、#25、#27、#28、#30、#31、#60,保留於表中以利追溯),仍待查證 49 項。

G.1 標準與框架(20 項)

#項目原因建議處置
1CSF 2.0 之 Category / Subcategory 精確數量NIST 官方文件未列總數;抓取結果與業界數字(22/106)衝突手冊避免引用數量,或標示為業界統計
2ISO/IEC 27002:2022 之 11 項新增控制逐條清單ISO 付費牆;OBP 需 JavaScript購買正本核對 Annex B
3ISO/IEC 27002:2022 之 93 控制 / 4 主題分布(37/8/14/34)僅第三方來源;ISO 官網未載明同上
4IEC 62443 SL 1–SL 4 逐字定義IEC 付費牆購買 IEC 62443-3-3 正本
5IEC 62443 七項 FR(FR1–FR7)名稱免費摘要僅確認「seven FRs」存在,未列名同上
6Zones & Conduits 定義文字IEC 62443-3-2 付費牆購買 IEC 62443-3-2 正本
7IEC 62443-2-1:2024 之 ML(成熟度)等級定義預覽本截斷購買正本
8CIS Controls v8.1 精確發布日cisecurity.org 未於可存取頁面標示寫「v8.1(2024 年)」或標第三方
9CIS Safeguards 數:153 vs 171兩次抓取衝突採用 153(官方 IG 頁一手來源)
10CISA ZTMM v2.0 五支柱/三跨領域能力逐字名稱已取得 CISA 官方 PDF(April 2023 Version 2.0)查證缺口已結案
11CISA Secure by Design Pledge 2026 現況Pledge 頁面現仍存在(自願、7 項目標)查證缺口已結案;可作參考項,不宜作為唯一評分依據
12"Shifting the Balance of Cybersecurity Risk" 發布日CISA 頁未載人工查證
13MITRE D3FEND 1.6.0 正式發布日官網未標示;GitHub 無正式 Release,僅有 2026-09-01 提交以提交日為參考,勿寫成發布日
14MITRE ATLAS 戰術/技法計數已由 atlas-data v2026.09 release notes 取得(16/120)查證缺口已結案
15SPDX 3.1-RC1 日期(2025-01-24 vs 2026-01-26)GitHub Releases API 顯示 2026-01-24(prerelease)查證缺口已結案
16SLSA v1.2 Source Track 各等級名稱已自 slsa.dev/spec/v1.2/source-requirements 取得(L1–L4)查證缺口已結案
17ISO/IEC 27036-3 與 -4 之 ISO 標準頁編號未能直接抓取,編號由搜尋推得送印前人工確認
18ISAGCA 是否有官方 62443↔CSF/27001 對映白皮書子頁面 404人工瀏覽 isagca.org Technical Resources
19ISA-TR62443-2-2-2025 對應之 IEC 版本IEC Webstore 未檢索到查 IEC TC65 WG10 進度
20NIST SSDF 四大實務群組(PO/PS/PW/RV)逐字定義未自 PDF 逐字取證人工核對 SP 800-218 PDF

G.2 法規(12 項)

#項目原因影響與建議處置
21CRA Annex I 與 Art. 14/16 官方逐字條文EUR-Lex 僅回傳前言出版前以 EUR-Lex PDF 覆核中譯
22捷克 vyhláška 408/2025 Sb. 是否涵蓋 CZ-NACE 26 電子製造已取得 e-Sbírka 現行條文:附表第 7.1 項涵蓋 CZ-NACE 26 中大型企業(低階)查證缺口已結案;仍由捷克廠透過 NÚKIB 入口正式自我識別並取得法律意見書
23台灣個資法 2025 修正之施行日期截至 2026-09-29 仍未定;個資會組織法尚未完成立法追蹤行政院公報與個資會籌備處
24國家核心關鍵技術 42 項清單是否已正式公告已查得行政院 2026-02-13 公告(院臺科字第1141037623號)查證缺口已結案
25VDA ISA 是否存在 AI 模組已取得 ENX ISA 2027 目錄:無獨立 AI 模組查證缺口已結案
26BIS Entity List Affiliates Rule(50% 規則)最新版本已以 Federal Register API 取得:90 FR 47201、90 FR 50857(暫停至 2026-11-09);再延長之說尚無 FR 公告🚩 2026-11-09 前向法務/貿易合規確認是否延長
27CTPAT MSC 現行條文已取得 CBP Foreign Manufacturers MSC(2021-10)查證缺口已結案
28MLPS 2.0 / GB/T 22239-2019 一手來源與日期已由國家標準全文公開系統確認(2019-05-10 發布、2019-12-01 實施、現行)查證缺口已結案
29AS9100D 與 NAS9933 現行版次未取得 IAQG/SAE 一手來源若有航太客戶,須向 IAQG/SAE 覆核
30Data Act Article 50 關於 Art.3(1) 之 2026-09-12 適用範圍已取得 EUR-Lex 一手條文查證缺口已結案
31ITAR 22 CFR 條號(120–130、120.54(a)(5)、Part 122)已以 eCFR(2026-09-25)覆核查證缺口已結案
32RBA Code of Conduct 8.0 逐字條文(Ethics 章節之資安相關條款)未取得 Code 8.0 全文下載 RBACodeofConduct8.0_English.pdf 覆核

G.3 市場與分析師報告(13 項)

#項目查證結論
33Gartner MQ for SIEM 2025 版完整象限名單與各家 Cautions僅確認 Microsoft、Splunk、Exabeam、Gurucul、Google 為 Leader;完整名單未取得
34Gartner MQ for SASE Platforms 2026 版完整名單僅確認 Cato、Netskope 為 Leader
35Gartner MQ for SSE 2026 版完整名單各廠商各自宣告 Leader,完整象限未取得
36Gartner MQ for NDR 2026 版完整名單僅確認 Darktrace、Vectra AI 宣告 Leader
37Gartner MQ for CPS Protection Platforms 2026 之第 4 家 Leader已確認 Claroty、Armis、Nozomi;第 4 家未確認
38Gartner MQ for EAP 2025 各家 Cautions僅確認 Tenable、Rapid7、Qualys 為 Leader
39Gartner MQ for Email Security 2025 完整象限僅確認 Microsoft 為 Leader
40Gartner 是否曾發行過 SOAR MQ現況確定無 SOAR MQ;但「曾存在過」此前提本身無法查證
41Gartner Market Guide for SSPM 是否存在未能確認任何版本或日期;市面「SSPM 排名」多為 SEO 部落格
42Gartner Market Guide for DSPM 2025 版之確切月份存在已確認,月份未確認
43Gartner AI TRiSM Market Guide 之出版日與作者內容經第三方引述,報告本身資訊未取得
44AI SOC agents 的獨立效能評測不存在任何公開獨立評測(無 MITRE/SE Labs/AV-C 對應項目)——證據空白區
45Dragos CHERNOVITE/PIPEDREAM 在 2025/2026 年報中的具體引述新聞稿未提及;需取得報告全文

G.4 數據與 benchmark(8 項)

#常見說法查證結論
46「資安預算應佔營收 0.5%–1%」IANS/Artico 公開材料未提供任何「% of revenue」數字。僅 % of IT spend(2025: 10.9%)可查證
47「製造業資安預算 benchmark 為 X%」IANS 公開產業拆分不含製造業
48「每 1,000 員工需 X 名資安人員」Avasant 報告付費;無免費一手來源
49「Siemens:電子業停機每小時成本」Siemens 數字為汽車業(US$2.3M/hr);無電子組裝業一手數據;Siemens 原始報告未取得
50「Heidrick 顯示向 CEO 匯報比例逐年上升至 42%」2024→2025 由 14% 躍升 42%,樣本由 370 降至 231,來源未說明方法變更。不可作時間序列使用
51「DBIR:第三方涉入由 15% 增至 30%」30% 與「倍增」為原文;15% 係反推,Verizon 未直接列出基數。應寫「倍增至 30%」
52Norsk Hydro 損失「US$71M/NOK 800M」與公司季報不符。原文為 NOK 650–750M
53Clorox 損失「US$356M」出自媒體非 SEC 申報;申報數字為 US$49M(增量費用,口徑不同)

G.5 事件(9 項)

#項目原因
54Pegatron(和碩)2020 年事件未取得公司聲明或權威報導
55Nichirin 2022 年美國子公司勒索事件未完成驗證
56SolarWinds SUNBURST 具體受害數(18,000 / ~100)未取得一手來源確認
57Kaseya VSA 2021 事件細節僅確認 CVE-2021-30116 列入 KEV(2021-11-03,known ransomware use)
58Polyfill.io(2024)未完成驗證
59Ultralytics YOLO PyPI 遭污染(2024-12)未完成驗證
60ENISA Threat Landscape 20262026-09-22 已發布;本項查證缺口已結案
61Kojima → Toyota「28 條產線/13,000 輛」Toyota 官方僅確認 14 廠停產一日;細部數字僅見第三方報導
62Norsk Hydro 最終總成本僅取得 Q3 2019 財報之上半年估計;全年最終數字未驗證

G.6 使用本清單的方式

  1. 這份清單本身應納入 repo(registry/verification-gaps.yml),並在每次維護時檢視是否已可補證
  2. 對外文件不得引用本清單中的項目,除非已完成補證
  3. 第 22 項(捷克廠納管)與第 27 項(CTPAT MSC)原為影響最大的兩項,已於 2026-09-29 結案;目前影響最大的未結項目為第 26 項(Affiliates Rule 暫停是否延長)
  4. 本清單也是採購標準正本的預算理由:第 2–7 項全部需要購買 ISO/IEC 標準正本才能解決

↑ 回附錄目錄

Appendix H

引用來源總表

全手冊引用之來源清單,依主題分類(標準機構、政府與監理機關、威脅情報與事件、分析師與市場、客戶要求與產業、產業與公司資料)。

原版查證:2026-08-30;重要時效資訊更新:2026-09-29。以下依主題分類;時效更新新增的來源已併入各分類。

H.1 標準機構

NIST

ISO / IEC

IEC Webstore

其他標準

H.2 政府與監理機關

美國

歐盟

中國

台灣

H.3 威脅情報與事件

具名事件來源

H.4 分析師與市場

H.5 客戶要求與產業

H.6 產業與公司資料

↑ 回附錄目錄

Document control

文件資訊

本頁內容摘自手冊全文(docs/GSMDRPT2026083001.md)之文件結束頁。

項目內容
文件編號GSMD-RPT-2026-0830-01
版本v1.0
發行日期2026 年 8 月 30 日
查證基準日2026 年 8 月 30 日
取代文件GSMD-RPT-2026-0815-01
下次檢視2026 年 11 月 30 日(法規類每 3 個月、標準類每 6 個月)

↑ 回附錄目錄