---
title: FR-159 SEMI E187 示範資源庫與專案 — 計畫
status: 計畫定案（2026-10-22），母卡 CM-3021、子卡 CM-3022～3025 已建，等工作坊派
relates: [FR-158, FR-138]
---

# FR-159 SEMI E187 示範資源庫與專案

## 1. 要做什麼（白話）

用 FR-158 剛做好的 SEMI E187 框架，在 DEV 做一組可以拿去 demo 的完整資料：一間虛構的半導體設備商、它要送驗的一個設備型號、顧問跟它談好的導入方式、一份填好的 SSP、照 Excel「查核文件準備清單」寫出來的程序書與技術文件、每條查核步驟的現況說明，以及上傳到專案任務裡的證據（文件、截圖、圖片、日誌）。

做法照 FR-138 CRA 自評那套已經跑通的流程：下載框架版本的空白 SSP 樣板 → 用腳本填好 → 「從 Excel 建立」一次建出資源庫 → 匯入後填設備型號表單 → 起專案 → 逐任務上傳證據與評論。**專案停在規劃階段，不啟動稽核、不產系統缺失與結案報告**（決策者 2026-10-22 裁：做到產證據為止）。

## 2. 情境要先講清楚的一件事

**SEMI E187 查的是「設備型號」，送驗的是設備製造商，不是晶圓廠。** 規範 1.3.3 定義申請者是「對設備具設計或出場設定控制權之設備製造商、代理商」，第 4 章查的是設備編碼規則與出場品管，晶圓廠拿不出這些東西。建庫預設也是照「設備商自評、送驗前準備」做的（FR-158 D4）。

所以「晶圓廠有幾台設備要過 SEMI」實務上是這樣運作：晶圓廠在採購規格裡要求設備商提出 E187 驗證，設備商準備文件送檢測實驗室。

**我的建議（情境 A）**：虛構一家**台灣本土半導體設備製造商**，它的電漿蝕刻機要賣進晶圓廠，晶圓廠採購要求 E187 驗證，所以請顧問導入。這跟規範和建庫預設完全對得上，demo 時每一條都說得通。

**另一個選項（情境 B）**：照字面做晶圓廠。晶圓廠把每台進廠設備當受評標的，自己做進廠查核。問題是第 4 章三條（編碼規則、出場品管）晶圓廠只能記「向設備商索取」，5.5 弱點掃描、5.8 系統強化說明也都是設備商的文件，demo 起來會變成「晶圓廠一直在跟供應商要東西」，而且跟系統建庫預設的角色不一致。

**請決策者選 A 或 B。以下內容以 A 寫。**

## 3. 虛構的公司與設備（情境 A）

### 3.1 公司

| 項目 | 內容 |
|---|---|
| 公司 | 鈞拓精密設備股份有限公司（JunTuo Precision Equipment，虛構） |
| 地址 | 新竹科學園區研發三路 18 號 |
| 規模 | 員工約 420 人；做蝕刻與沉積設備，客戶是台灣與日本的 12 吋晶圓廠 |
| 為什麼導入 | 主要客戶（虛構「晶辰半導體」）2026 年新採購規格要求：2027-Q1 起進廠設備須取得 SEMI E187 驗證 |
| 顧問 | 虛構「恆鑑資安顧問」，兩人小組 |
| 檢測實驗室 | 虛構「台灣設備資安檢測實驗室（ISO/IEC 17025）」 |

### 3.2 送驗設備型號（只送一台，決策者 2026-10-22 裁）

| 項目 | 內容 |
|---|---|
| 型號 | **JT-EP700** |
| 設備 | 12 吋電漿蝕刻機（Plasma Etcher），四腔體 |
| 內部運算節點 | 機台主控電腦（Windows 10 IoT Enterprise LTSC 2021，EOL 2032-01）、腔體製程控制器（嵌入式 PLC）、HMI 觸控面板 |
| 聯網 | 有：SECS/GEM（HSMS，TCP 5000）連工廠主機、遠端維護 SSH（預設關閉、維護時開）、時間同步 |
| API | 無；對外只走 SECS/GEM。示範 5.10.2「不支援 API，於查核文件中記錄」那條路 |
| 型號編碼 | JT-EP700-<腔體數>-<射頻規格>；主型號 EP700 決定資安功能，次型號（腔體數、射頻規格）不影響 → 4.2 以主型號送驗 |

一個型號一份查核，系統上就是**一個資源庫、一個專案**，受評標的就是 JT-EP700。

預計查核結果（刻意做出有符合、有不符合，demo 才有缺失可看）：

- **大致符合**：作業系統支援期充足（5.1）、安全協定正常（5.3）、網路組態文件與實機相符（5.4）、惡意軟體掃描 0 偵測（5.6）等。
- **5.5 弱點緩解**：掃到一個高風險弱點（主控電腦上舊版 OpenSSL），以「限制 SSH 只在維護模式開放＋防火牆白名單」緩解，資安主管簽核在案 → 符合。
- **5.12 日誌類別**：存取控制與系統錯誤有記，**配置變更沒記**（配方與網路設定變更只在 HMI 畫面顯示、沒落 log）→ **不符合**，開缺失與改善建議。
- **5.8 系統強化**：強化說明有，但實機 USB 儲存在預設狀態下未停用、與說明不一致 → **不符合**，開缺失。

## 4. 顧問與公司談好的導入方式（寫進 SSP 與現況說明的前提）

- **範圍**：JT-EP700 一個型號；本專案是送驗前的內部準備（自評）。
- **時程**：導入啟動 2026-08-01；文件備齊 2026-11-30；內部預查 2026-12；送實驗室查核基準日預定 2027-01-15。
- **分工**：研發處負責 5.1～5.12 技術面；品保處負責第 4 章（編碼規則、出場品管）；資訊安全室負責弱點與惡意軟體掃描；顧問負責差距分析與文件審閱。
- **掃描做法**：5.5 弱點掃描、5.6 惡意軟體掃描採「申請者於檢測實驗室監督下執行」（Note1 第三種），本專案先交內部預掃報告。
- **判準**：現在拿得出紀錄的才算符合；只寫在程序書、還沒做的記規劃中並開缺失（跟 FR-138 一樣，不做假的「已完成」）。

## 5. 要產出的東西

### 5.1 SSP（Excel → 從 Excel 新建）

| SSP 分頁 | 內容 |
|---|---|
| 基本資料／受評標的 | 鈞拓、JT-EP700；建庫表單：設備型號、申請者、作業系統與版本、EOL、LTS、聯網、對外介面、API、查核基準日、檢測實驗室 |
| 負責單位 | 研發處、品保處、資訊安全室、製造處、恆鑑資安顧問、檢測實驗室 |
| 責任人員 | 約 8 人（虛構姓名，含申請者窗口、研發主管、品保主管、資安工程師、顧問兩人） |
| 設備資產 | JT-EP700 內部三個運算節點：機台主控電腦、腔體製程控制器、HMI 觸控面板 |
| 系統資產 | 機台主控軟體 JT-EtchCtrl v4.2、製程配方管理、SECS/GEM 模組、HMI 程式 |
| 系統依賴元件 | Windows 10 IoT LTSC 2021、.NET 6、OpenSSH、OpenSSL、Microsoft Defender、SQL Server Express |
| 適用控制項 | 15 條控制項的狀態與現況、31 個 AO 的狀態／現況／缺失／建議、每個 AO 一個任務（名稱、描述、指南） |

### 5.2 程序書與技術文件（對 Excel「查核文件準備清單」13 項）

| # | 文件（Excel 清單） | 怎麼產 | 格式 |
|---|---|---|---|
| 1 | 設備編碼規則 | 新寫：鈞拓型號命名規則（主型號／次型號／哪一層變動影響資安功能） | docx 程序書 |
| 2 | 設備出場品管作業相關文件 | 新寫：出場品管程序＋資安出場檢查表（帳號、網路、強化、日誌四類） | docx 程序書＋xlsx 檢查表 |
| 3 | 設備規格文件 | 新寫：JT-EP700 規格書（硬體、OS、軟體版本、聯網功能） | docx（含架構圖 png） |
| 4 | LTS 證明文件 | 清單標○（如需）；Windows 10 IoT LTSC 2021 EOL 2032-01，距基準日超過 12 個月，5.1.3 即符合，**不需要** | — |
| 5 | 安全性更新程序 | 新寫：作業系統安全性更新程序（相容性、相依性、效能、副作用四段，對 5.2 Note1） | docx 程序書 |
| 6 | 設備操作手冊 | 新寫：操作手冊節錄（聯網功能章、遠端維護章） | docx |
| 7 | 設備安全指南或使用者文件 | 新寫：JT-EP700 Security Guide（網路組態、反惡意軟體、強化、帳號、日誌各章，對 5.4／5.7～5.12） | docx |
| 8 | 設備弱點掃描報告 | 模擬：弱點掃描報告（工具與版本、範圍、日期、CVSS 分級、高風險一筆＋緩解） | pdf |
| 9 | 弱點管理機制說明 | 新寫：弱點管理程序（分級、修補時限、緩解簽核） | docx 程序書 |
| 10 | 惡意軟體掃描報告 | 模擬：Defender 全機掃描報告（版本、病毒碼日期、結果 0 偵測） | pdf |
| 11 | 惡意軟體掃描管理機制說明 | 新寫：惡意軟體防護程序 | docx 程序書 |
| 12 | API 相關技術文件 | 清單標○（如需）；JT-EP700 無 API，**不需要**，在 5.10.2 現況記「不支援」 | — |
| 13 | 設備 LOG 紀錄檔 | 模擬：Windows 事件記錄匯出（4624 登入、4720 建帳號、4719 稽核原則變更、7031 服務錯誤）＋設備軟體 log | csv／txt |

另外用 FR-158 已有的「系統強化說明範本」填成 JT-EP700 版（對 5.8），以及兩張截圖型證據（帳號管理畫面、防火牆規則畫面），用程式繪製的畫面，不拿任何真實系統截圖。

**程序書格式**照 FR-138 `docs/01～05-*.docx`：封面、文件管制表、核准欄、各節「依據」。畫面與文件上**不標「示範」「虛構」字樣**（決策者 2026-10-22 裁：demo 時很突兀）；虛構這件事只記在本資料夾 README 與 Notion 卡。

### 5.3 每條的現況說明與上傳

- 31 個 AO 各寫現況（現在做到哪、拿得出什麼）、缺失與建議。預計結果見 §3.2：大部分符合，5.8、5.12 不符合。
- 每個任務上傳對應證據：一份原始文件一件、不合併、不加封面（FR-138 硬規則）；同一份文件涵蓋多個 AO 就重複上傳。
- 每個任務寫一則評論：證什麼、來源、判定、缺口。沒有對應檔的 AO 只寫評論、不造檔。
- 不符合的 AO 寫在 SSP 的狀態與缺失／建議欄，以及任務評論的判定段；**不開系統缺失**（那是稽核流程推進後才有的）。

## 6. 拆卡（3 批 4 棒）

| 批 | 卡 | 做什麼 | 改哪 | Model／Effort |
|---|---|---|---|---|
| 1 | **A 情境與 SSP 內容** | 寫情境設定檔（公司、設備、人員、時程、分工）＋15 條／31 AO 的狀態、現況、缺失、建議、任務三欄；下載框架版本空白樣板、填 Excel、從 Excel 建立（一次建庫）、填設備型號表單、起專案 | `docs/features/FR-159-…/tools/semi-ssp-excel/`（照 FR-138 `ga-ssp-excel` 形狀）；DEV 資料 | opus／high |
| 1 | **B 程序書與技術文件** | 5.2 表的 13 項＋強化說明，docx／pdf／xlsx／csv／png | `docs/features/FR-159-…/demo-docs/`、產生腳本 | opus／high |
| 2 | **C 上傳證據與評論** | 依 A 的任務對照把 B 的檔逐任務上傳（`evidence_type` 大寫 `FILE`、上傳後 DB 核 `file_id`）、寫評論；不符合項寫在評論判定段，不開系統缺失 | DEV 資料；上傳腳本放 `tools/` | sonnet／medium |
| 3 | **D 收尾驗收與 demo 腳本** | 實際登入走一次 demo 路線、截圖、寫一頁 demo 導覽（先看哪裡、講什麼） | `docs/features/FR-159-…/demo-guide.md` | sonnet／medium |

A 與 B 可同時做：A 只寫 SSP 內容與 DEV 資料，B 只產文件。C 要等 A 的專案與任務建好、B 的檔案齊了才能上傳。

## 7. 紀律與邊界

- **只動 DEV**。這份示範資料不上 STG／POC，要上另外裁。
- 所有公司、人名、地址、型號都是虛構，但**產出上不標「示範」**，照正式文件寫。不用任何真實公司名或商標（晶圓廠也用虛構名）。
- 截圖用程式繪製，不擷取任何真實系統畫面。
- 掃描報告與 log 是模擬內容，工具名用虛構名（例 JT-VScan），不冒用真實工具名當產出者。
- 不改系統程式碼。若做的過程碰到系統 bug，回寫卡片、另開修正卡，不在這幾棒順手修。
- 簽核欄、核准欄、檢查紀錄填寫人一律用情境虛構人名，與 SSP 責任人員一致；人名由 A／B 誰先開工誰定，append 在母卡。

## 8. 決策

全部照首腦建議（決策者 2026-10-22 裁）：

- 情境 A：設備製造商送驗，晶圓廠是要求驗證的客戶。
- 只送一台 JT-EP700 電漿蝕刻機，一個資源庫、一個專案。
- 虛構名稱：鈞拓精密設備、晶辰半導體、恆鑑資安顧問、台灣設備資安檢測實驗室。

卡片：母卡 CM-3021；第 1 批 CM-3022（A SSP 與 DEV 建庫）、CM-3023（B 文件）；第 2 批 CM-3024（C 上傳）；第 3 批 CM-3025（D 走查與導覽）。