# 安全能力覆蓋缺口  
## 為什麼「有資安人員」不等於「具有完整資安能力」

**英文工作名：** *The Security Capability Coverage Gap: Why Having Cybersecurity Staff Does Not Mean Having Complete Cybersecurity Capability*  
**作者：** Neo.K  
**機構：** EveMissLab／一言諾科技有限公司  
**系列：**《AI 時代的數位免疫與資安基礎設施》第四篇  
**文件性質：** 理論資安研究／組織治理模型／AI 資安基礎設施前置論文  
**版本：** v0.1  
**日期：** 2026-08-10

---

## 摘要

企業經常以「是否聘有資安工程師」、「資安部門有多少人」或「是否設有 SOC」作為安全能力的代理指標。然而，資安並非一個單一技術領域，而是一組橫跨密碼學、應用程式、身份管理、雲端、端點、網路、供應鏈、漏洞管理、事件應變、數位鑑識、治理、法規與 AI 系統安全等不同計算與組織領域的能力集合。

因此：

$$
\boxed{
\text{Security Staff Exists}
\not\Rightarrow
\text{Required Security Capability Exists}.
}
$$

本文提出「**安全能力覆蓋缺口**」（Security Capability Coverage Gap, SCCG）概念。令組織實際需要的安全能力集合為：

$$
R=
\{r_1,r_2,\ldots,r_n\},
$$

組織目前可取得的安全能力為：

$$
C=
\{c_1,c_2,\ldots,c_m\}.
$$

安全問題不應只問：

$$
m>0?
$$

即「有沒有資安人員」，

而應問：

$$
\boxed{
R\setminus C
}
$$

仍有哪些重要能力沒有被有效覆蓋。

本文進一步提出能力覆蓋矩陣、加權能力覆蓋率、責任邊界損失、單一專家依賴與外部安全能力等模型，並區分：

$$
\text{Nominal Coverage}
$$

與：

$$
\text{Effective Coverage}.
$$

名義上有人負責，並不代表該角色具備足夠能力、時間、資訊、工具與實際授權完成工作。

NIST NICE Framework、ENISA ECSF 以及台灣目前的資安人才職能建構皆已將「資安人才」拆分為多種 Work Roles、Competency Areas 或職能類別，而非假定存在一種足以涵蓋所有安全工作的通用「資安工程師」。2026 年 NICE Framework v2.2.0 甚至繼續新增供應鏈風險管理角色，以及 Cryptography、DevSecOps 等專門能力區域，顯示安全能力空間仍在擴張。

本文最後指出：當 AI 攻擊開始具備跨領域搜索與工具調度能力時，人類防禦仍以靜態部門、職稱與專業邊界切割，將形成新的攻防不對稱。未來的安全管理因此可能逐漸由：

$$
\text{Fixed Security Staffing}
$$

轉向：

$$
\boxed{
\text{Continuous Capability Coverage}
}
$$

並由常駐 AI、安全平台、外部專家池與內部人員共同維持。

---

**關鍵詞：** 資安人才、能力覆蓋、安全治理、NICE Framework、ECSF、SOC、AppSec、AI 資安、MSSP、安全能力缺口、Cybersecurity Workforce

---

# 一、問題的起點：一個人到底能負責多少資安？

企業常見一種極度自然的組織語言：

> 「這件事情是資安負責。」

這句話在行政管理上很方便。

但在技術上幾乎沒有提供足夠資訊。

因為：

$$
\text{Cybersecurity}
$$

可能同時包含：

$$
\begin{aligned}
&\text{Cryptography}\\
&+\text{Identity Security}\\
&+\text{Application Security}\\
&+\text{API Security}\\
&+\text{Cloud Security}\\
&+\text{Network Security}\\
&+\text{Endpoint Security}\\
&+\text{Supply Chain Security}\\
&+\text{Vulnerability Management}\\
&+\text{Threat Intelligence}\\
&+\text{Detection Engineering}\\
&+\text{Incident Response}\\
&+\text{Digital Forensics}\\
&+\text{GRC}\\
&+\text{AI Security}\\
&+\cdots
\end{aligned}
$$

因此：

> 「我們有一個資安工程師。」

與：

> 「我們具備這些領域所需要的安全能力。」

是完全不同的命題。

---

# 二、資安不是普通的單一垂直領域

傳統電腦科學可以粗略拆分為：

$$
\mathcal D_{\mathrm{CS}}
=
\{
D_1,D_2,\ldots,D_n
\}.
$$

例如：

- 作業系統；
- 網路；
- 資料庫；
- 分散式系統；
- 編譯器；
- Web；
- AI；
- 圖形；
- 嵌入式；
- 雲端。

然而安全具有一個特殊結構：

$$
\boxed{
\mathcal S
\approx
\mathcal D_{\mathrm{CS}}
\times
\mathcal A
}
$$

其中：

$$
\mathcal A
$$

表示攻擊、信任、身份、完整性、可用性與對抗性維度。

因此資料庫會有：

$$
\text{Database Security};
$$

網路有：

$$
\text{Network Security};
$$

AI 有：

$$
\text{AI Security};
$$

軟體生命週期則有：

$$
\text{DevSecOps}.
$$

所以資安並不像：

> 「圖形學旁邊另一個獨立領域。」

它更接近：

> **橫切整個計算系統的一種對抗性屬性。**

---

# 三、官方人才框架本身已經承認這個問題

NIST NICE Workforce Framework 的核心用途，就是建立共同語言描述：

- cybersecurity work；
- Work Roles；
- Tasks；
- Knowledge；
- Skills；
- Competency Areas。

NIST 特別指出：

> Work Role 並不等同於 job title 或 occupation。

也就是一個人的職稱：

```text id="66ybre"
Cybersecurity Engineer
```

並不能直接告訴我們：

> 他究竟負責哪些安全工作？



這正是本文的起點。

---

## 3.1 職稱不是能力單位

定義：

$$
J=\text{Job Title}
$$

與：

$$
R=\text{Work Role}.
$$

通常：

$$
J\neq R.
$$

一個 Job：

$$
J_1
$$

可能同時包含：

$$
R_1+R_2+R_3.
$$

而同一個 Work Role：

$$
R_1
$$

也可能由：

$$
J_A,J_B,J_C
$$

共同完成。

因此：

$$
\boxed{
\text{Security Organization}
\neq
\text{List of Job Titles}.
}
$$

---

# 四、安全能力空間仍然持續擴張

2026 年 4 月發布的 NICE Framework Components v2.2.0 新增：

$$
\text{Cybersecurity Supply Chain Risk Management}
$$

Work Role，

並加入：

$$
\text{Cryptography}
$$

與：

$$
\text{DevSecOps}
$$

Competency Areas。

這件事情的理論意義不是：

> NICE 又增加幾個名詞。

而是：

$$
\boxed{
|\mathcal R_{\mathrm{security}}(t)|
}
$$

本身會隨技術環境改變。

因此：

$$
\mathcal R(t_0)
\neq
\mathcal R(t_1).
$$

安全工作不是一張固定幾十年的職缺清單。

---

# 五、歐洲也不是用「一種資安人員」描述安全工作

ENISA 的 European Cybersecurity Skills Framework（ECSF）目前將典型 cybersecurity professional roles 整理成 **12 種 role profiles**，並分別描述其任務、技能、知識、能力以及不同角色之間的互相依賴。

它的存在本身便支持：

$$
\boxed{
\text{Cybersecurity Professional}
}
$$

只是一個上位集合。

真正工作單位是：

$$
\{
R_1,R_2,\ldots,R_n
\}.
$$

---

# 六、台灣其實也已經在做同樣的拆分

台灣國家資通安全研究院目前已整合美國 NICE Framework 與歐盟 ECSF，建立符合台灣產業需求的資安人才類別框架。

2026 年推出的合作職能課程至少已明確拆成：

- 資安事件應變工程師；
- 滲透測試工程師；
- 數位鑑識調查分析師；
- 資安威脅情資分析師。



因此即使只是台灣現在正式人才培育制度，也已經不是：

> 「資安就是學一套東西。」

而是：

$$
\boxed{
\text{Cyber Workforce}
=
\text{Multiple Specialized Capabilities}.
}
$$

---

# 七、需要什麼能力，取決於你的系統是什麼

令一個組織的技術環境為：

$$
E=
\{
e_1,e_2,\ldots,e_k
\}.
$$

例如某公司可能使用：

- Web App；
- AWS；
- Microsoft 365；
- GitHub；
- Kubernetes；
- employee laptops；
- APIs；
- payment services；
- LLM Agents。

則需要的安全能力：

$$
R
$$

並不是固定的。

而是：

$$
\boxed{
R
=
F(
E,
A,
V,
L,
T
)
}
$$

其中：

- $E$ ：Technology Environment；
- $A$ ：Assets；
- $V$ ：Value / Impact；
- $L$ ：Legal / Regulatory Requirements；
- $T$ ：Threat Landscape。

因此：

$$
R_{\mathrm{bank}}
\neq
R_{\mathrm{game\ studio}}
\neq
R_{\mathrm{hospital}}
\neq
R_{\mathrm{startup}}.
$$

---

# 八、安全能力覆蓋缺口

現在可以正式定義本文核心。

令：

$$
R=
\{r_1,r_2,\ldots,r_n\}
$$

表示組織所需要的完整安全能力集合。

實際可取得能力為：

$$
C=
\{c_1,c_2,\ldots,c_m\}.
$$

則：

$$
\boxed{
G_{\mathrm{SCC}}
=
R\setminus C
}
$$

本文稱：

# Security Capability Coverage Gap  
## 安全能力覆蓋缺口

它回答：

> 組織需要但目前無法可靠取得的安全能力有哪些？

---

# 九、不能只算「有／沒有」

安全能力通常不是：

$$
0/1.
$$

例如某工程師：

> 會 AWS Security，

可能介於：

$$
0.2,\ 0.5,\ 0.8,\ 1.0.
$$

因此定義：

$$
M_{ij}
\in[0,1]
$$

表示第 $j$ 個能力提供者對能力：

$$
r_i
$$

的實際覆蓋程度。

其中能力提供者可以是：

- 員工；
- 部門；
- 外包商；
- MSSP；
- AI；
- SaaS 平台。

形成：

$$
M=
\begin{bmatrix}
M_{11}&\cdots&M_{1m}\\
\vdots&&\vdots\\
M_{n1}&\cdots&M_{nm}
\end{bmatrix}.
$$

這就是：

## Security Capability Coverage Matrix

安全能力覆蓋矩陣。

---

# 十、每項能力的有效覆蓋程度

對某一能力：

$$
r_i,
$$

可以簡化定義：

$$
q_i
=
\max_j M_{ij}.
$$

表示組織目前最可靠的能力來源。

但若需要多人合作，

則可以改成：

$$
q_i
=
F(
M_{i1},\ldots,M_{im}
).
$$

例如：

$$
\text{Incident Response}
$$

可能需要：

$$
\text{SOC}
+
\text{Endpoint}
+
\text{Legal}
+
\text{Management}.
$$

因此並不是：

$$
\max M_{ij}
$$

就足夠。

---

# 十一、加權安全能力覆蓋率

不是所有能力同等重要。

例如：

$$
r_1=\text{Web App Security}
$$

對一個沒有 Web App 的公司，

權重可能很低。

因此給每一項能力：

$$
w_i.
$$

定義：

$$
\boxed{
CCR
=
\frac{
\sum_{i=1}^{n}
w_iq_i
}{
\sum_{i=1}^{n}w_i
}
}
$$

稱為：

## Capability Coverage Ratio  
### 能力覆蓋率

---

例如：

公司 A：

$$
CCR=0.35
$$

代表大量必要能力實際沒有覆蓋。

公司 B：

$$
CCR=0.85.
$$

即使 B 的資安人員數比 A 少，

其有效防禦能力仍可能更完整。

因此：

$$
\boxed{
\text{Security Headcount}
\not\propto
\text{Capability Coverage}.
}
$$

---

# 十二、五個人不一定比兩個人安全

假設公司 A 有：

$$
5
$$

名資安工程師。

但五人全部專長：

$$
\text{SOC / Detection}.
$$

則：

$$
C_A
=
\{
\text{SOC},
\text{Detection},
\text{IR}
\}.
$$

可能仍缺：

$$
\{
\text{AppSec},
\text{CloudSec},
\text{IAM},
\text{Supply Chain},
\text{GRC}
\}.
$$

公司 B 只有：

$$
2
$$

名內部人員，

但搭配：

- managed SOC；
- external AppSec；
- cloud security platform；
- legal/GRC consultant。

則：

$$
C_B
$$

可能更接近：

$$
R.
$$

因此：

$$
\boxed{
|H_A|>|H_B|
}
$$

完全不保證：

$$
CCR_A>CCR_B.
$$

---

# 十三、這就是為什麼「請一個資安工程師」是一個不完整問題

企業真正應問：

> 「我們缺什麼？」

而不是先問：

> 「我們要請幾個資安工程師？」

順序應該是：

$$
\text{Assets}
\rightarrow
\text{Threats}
\rightarrow
\text{Required Outcomes}
\rightarrow
\text{Required Capabilities}
\rightarrow
\text{Staffing}.
$$

而不是：

$$
\text{Hire Security Person}
\rightarrow
\text{Assume Security Exists}.
$$

NIST 2026 年發布的 CSF 2.0 Enterprise Risk Management and Workforce Management Quick-Start Guide，也正把 cyber risk、enterprise risk 與 workforce decisions 放到同一套規劃流程中，強調人力配置應由實際風險與風險處置需求驅動，而不是脫離風險單獨規劃。

---

# 十四、Current Profile 與 Target Profile

NIST CSF 2.0 已提供 Organizational Profile 的概念。

組織可以建立：

$$
P_{\mathrm{current}}
$$

與：

$$
P_{\mathrm{target}},
$$

比較目前已達成的 cybersecurity outcomes 與預期目標之間的差距。

本文將這個概念再推進一步：

$$
P_{\mathrm{target}}
-
P_{\mathrm{current}}
$$

可以轉換成：

$$
R_{\mathrm{needed}}
-
C_{\mathrm{available}}.
$$

也就是：

$$
\boxed{
\text{Risk Gap}
\rightarrow
\text{Capability Gap}.
}
$$

---

# 十五、名義覆蓋與實際覆蓋

這是另一個重要問題。

組織可能說：

> 「Cloud Security 有人負責。」

因此：

$$
q_i=1?
$$

不一定。

因為真正能力可能受：

- 時間；
- 技術水平；
- 工具；
- 資料存取；
- 權限；
- 人數；
- 值班；
- 組織支持；

限制。

因此本文區分：

$$
C_N=\text{Nominal Coverage}
$$

與：

$$
C_E=\text{Effective Coverage}.
$$

通常：

$$
\boxed{
C_E\leq C_N.
}
$$

---

# 十六、能力存在但沒有時間，也等於部分不存在

令：

$$
K_i
$$

為知識能力，

$$
T_i
$$

為可投入時間比例，

$$
A_i
$$

為授權程度，

$$
D_i
$$

為必要資料可取得程度，

$$
Q_i
$$

為工具品質。

則實際覆蓋可以粗略表示：

$$
q_i
=
K_iT_iA_iD_iQ_i.
$$

即使：

$$
K_i=1,
$$

若：

$$
T_i=0.1,
$$

實際能力仍然有限。

這就是很多小型資安團隊的真實問題：

> 不是完全不懂。

而是：

> 根本沒有足夠時間全部做。

---

# 十七、資安人的「責任膨脹」

假設一名 generalist 初始負責：

$$
R_1,R_2,R_3.
$$

組織逐漸增加：

- AWS；
- SaaS；
- Kubernetes；
- AI Agent；
- GitHub Actions；
- remote workforce。

最後他可能名義上負責：

$$
R_1,\ldots,R_{15}.
$$

但：

$$
T_{\mathrm{human}}
$$

沒有增加。

因此：

$$
\frac{
T_{\mathrm{available}}
}{
|R|
}
\downarrow.
$$

本文稱為：

# Security Responsibility Dilution  
## 資安責任稀釋

---

# 十八、「全部交給資安」甚至可能降低安全

當開發者認為：

> Security 是資安部門的事。

則 Developer 自己可能降低：

$$
S_{\mathrm{developer}}.
$$

DevOps 亦然。

最後形成：

$$
\boxed{
\text{Everybody delegates security}
\rightarrow
\text{Security team becomes bottleneck}.
}
$$

而安全本來就是：

$$
\text{Shared Responsibility}.
$$

因此專責資安團隊應該：

> 提供能力、架構、監控、驗證與高階支援，

而不是：

> 替所有工程團隊承擔所有安全操作。

---

# 十九、責任邊界本身也是安全漏洞

假設：

$$
R_a
$$

由 Team A 負責，

$$
R_b
$$

由 Team B 負責。

某事件恰好落在：

$$
R_a\cap R_b.
$$

如果雙方都認為：

> 「是另一邊的。」

則：

$$
q_{ab}\rightarrow0.
$$

本文稱為：

# Responsibility Boundary Loss  
## 責任邊界損失

---

# 二十、典型責任邊界

例如：

$$
\text{API Authorization Bug}.
$$

Developer：

> Security 應該檢查。

Security：

> Business Logic 是 Backend 負責。

Platform：

> 我只管 deployment。

結果：

$$
\boxed{
\text{Shared Responsibility}
\rightarrow
\text{Unowned Responsibility}.
}
$$

所以：

$$
\text{Shared}
$$

必須不等於：

$$
\text{Undefined}.
$$

---

# 二十一、責任矩陣

因此除了：

$$
M_{ij}
$$

能力矩陣之外，

還需要：

$$
A_{ij}
$$

責任矩陣。

例如：

$$
A_{ij}\in
\{
\text{Owner},
\text{Support},
\text{Consult},
\text{None}
\}.
$$

每項重大安全能力至少必須存在：

$$
\boxed{
\exists j:
A_{ij}=\text{Owner}.
}
$$

否則：

$$
r_i
$$

即形成：

# Orphan Security Capability  
## 孤兒安全能力

---

# 二十二、能力缺口與責任缺口不是一回事

可能：

### 情況 A

有人負責，

但不會。

$$
A_i=1,
\quad
C_i=0.
$$

### 情況 B

有人會，

但沒人指定他負責。

$$
A_i=0,
\quad
C_i=1.
$$

兩種都危險。

因此完整條件：

$$
\boxed{
S_i
=
C_i
\cdot
A_i.
}
$$

如果任何一項為零：

$$
S_i=0.
$$

---

# 二十三、單一專家依賴

公司可能存在：

> 「只有 Alice 知道這個。」

這其實是一種：

$$
\text{Single Point of Security Knowledge}.
$$

令：

$$
N_i
$$

為可可靠執行能力：

$$
r_i
$$

的人數。

若：

$$
N_i=1,
$$

則形成：

# Single-Expert Dependency  
## 單一專家依賴

---

如果：

- 離職；
- 生病；
- 休假；
- 聯絡不到；

則：

$$
q_i\rightarrow0.
$$

因此高成熟安全組織不應只問：

> 有沒有人會？

還應問：

> 有多少人可以接替？

---

# 二十四、時間覆蓋也是能力的一部分

SOC 是最明顯案例。

假設：

$$
q_{\mathrm{SOC}}=1
$$

但每天只有人工作：

$$
8\text{ hours}.
$$

那麼：

$$
C_{\mathrm{temporal}}
=
\frac{8}{24}
=
0.33.
$$

如果威脅：

$$
24/7
$$

存在，

則能力也必須包含：

$$
\boxed{
\text{Temporal Coverage}.
}
$$

因此：

$$
q_i
=
F(
K_i,
T_i,
A_i,
D_i,
Q_i,
\tau_i
)
$$

其中：

$$
\tau_i
$$

代表時間覆蓋。

---

# 二十五、地理覆蓋與司法覆蓋

跨國企業還有：

$$
G_i=\text{Geographic Coverage}
$$

及：

$$
L_i=\text{Legal Coverage}.
$$

因為：

- 法規不同；
- 語言不同；
- incident reporting 不同；
- law enforcement 接口不同。

所以同一安全團隊也未必能完整處理所有國家。

---

# 二十六、政府其實面臨同一個問題

把：

$$
\text{Company}
$$

換成：

$$
\text{State},
$$

問題完全沒有消失。

反而變得更大。

國家要保護：

$$
\begin{aligned}
&\text{Government Systems}\\
&+\text{Defense}\\
&+\text{Finance}\\
&+\text{Energy}\\
&+\text{Telecom}\\
&+\text{Health}\\
&+\text{Transportation}\\
&+\text{Critical Infrastructure}\\
&+\text{Citizen Data}\\
&+\text{Supply Chains}.
\end{aligned}
$$

所以：

> 「國家有沒有資安單位？」

仍然不是完整問題。

真正問題是：

$$
\boxed{
CCR_{\mathrm{national}}=?
}
$$

---

# 二十七、國家安全能力也可以有缺口

令：

$$
R_N
$$

為國家所需要的 cyber capability set，

$$
C_N
$$

為政府、企業、研究機構、軍事、教育與國際合作可提供的能力。

則：

$$
G_N
=
R_N-C_N.
$$

一個國家可能具有：

$$
\text{Strong Military Cyber}
$$

但缺：

$$
\text{SMB Security}.
$$

或者：

$$
\text{Strong Incident Response}
$$

但缺：

$$
\text{Secure Software Supply Chain}.
$$

所以國家級資安成熟度同樣不能被壓成：

> 「有／沒有國家 CERT。」

---

# 二十八、人才培養本質上是在修補能力矩陣

台灣資安院目前將事件應變、滲透測試、數位鑑識與威脅情資拆成不同培訓角色，並明確指出其框架結合 NICE 與 ECSF。

其本質可以表示為：

$$
M_{ij}
\uparrow.
$$

教育不是抽象地：

> 「培養更多資安人。」

而應：

$$
\boxed{
\text{Identify Missing Capability}
\rightarrow
\text{Train Specific Capability}.
}
$$

---

# 二十九、企業真正需要的不是所有專家都自己養

這裡有一個重要經濟問題。

假設公司只有：

$$
20
$$

人。

要求它內部擁有：

- cryptographer；
- SOC analyst；
- AppSec；
- CloudSec；
- DFIR；
- threat intelligence；
- IAM engineer；
- GRC；

完全不合理。

因此：

$$
C
$$

不應限制為：

$$
C_{\mathrm{internal}}.
$$

而應：

$$
\boxed{
C
=
C_{\mathrm{internal}}
+
C_{\mathrm{external}}
+
C_{\mathrm{platform}}
+
C_{\mathrm{AI}}.
}
$$

---

# 三十、資安能力可以外部取得

這跟雲端計算非常類似。

企業不需要：

> 擁有一座 data center。

只需要：

$$
\operatorname{Access}(\text{Compute}).
$$

同理，

也不一定需要：

> 雇用每一種安全專家。

只需要：

$$
\boxed{
\operatorname{ReliableAccess}
(
\text{Security Capability}
).
}
$$

這是後續：

# Security-as-Infrastructure

命題的重要前提。

---

# 三十一、但外包不代表責任消失

如果：

$$
C_{\mathrm{external}}
$$

存在，

公司仍然需要：

$$
O_{\mathrm{internal}}
$$

內部 ownership。

否則：

> 外部團隊說有問題。

沒有人決定怎麼處理。

因此：

$$
\boxed{
\text{Outsourced Capability}
\neq
\text{Outsourced Accountability}.
}
$$

---

# 三十二、AI 可以成為新的能力提供者

令：

$$
A_k
$$

表示 Security AI Agent。

它可能提供：

- vulnerability triage；
- log analysis；
- configuration review；
- malware classification；
- code review；
- incident summarization；
- identity anomaly detection。

因此：

$$
M_{i,A_k}>0.
$$

也就是：

$$
A_k
$$

正式進入能力覆蓋矩陣。

---

# 三十三、但 AI 能力同樣不是 1

不能寫：

$$
M_{i,A}=1
$$

只因：

> 「我們有 AI。」

AI 也有：

- hallucination；
- missing context；
- permission limitations；
- model drift；
- tool failure；
- adversarial input；
- prompt injection。

因此：

$$
M_{i,A}
\in[0,1].
$$

而且不同安全任務差異可能極大。

---

# 三十四、人類與 AI 的互補覆蓋

更理想的組合是：

$$
q_i
=
F(
M_{i,H},
M_{i,A}
).
$$

AI 擅長：

$$
\text{Scale}
+
\text{Speed}
+
\text{Repetition}.
$$

人類擅長：

$$
\text{Judgment}
+
\text{Accountability}
+
\text{Novel Context}.
$$

所以：

$$
\boxed{
H+A
}
$$

可能比：

$$
H
$$

或：

$$
A
$$

單獨更可靠。

---

# 三十五、AI 還可以負責能力路由

未來最重要的不一定是：

> 一個 AI 什麼都會。

而是：

$$
A_O=\text{Security Orchestrator}.
$$

它接收到事件：

$$
E.
$$

先判斷：

$$
r_i=\operatorname{Classify}(E).
$$

然後將其派給：

$$
\arg\max_j M_{ij}.
$$

例如：

$$
E
\rightarrow
\begin{cases}
A_{\mathrm{AppSec}}\\
H_{\mathrm{IR}}\\
H_{\mathrm{Legal}}\\
A_{\mathrm{Cloud}}\\
H_{\mathrm{DFIR}}
\end{cases}
$$

形成：

# Capability Routing

能力路由。

---

# 三十六、小公司因而不需要理解完整資安人才市場

這正好回到本文最開始的問題。

一個 20 人公司老闆可能根本不知道：

> AppSec 和 SOC 到底差在哪？

要求所有企業管理者理解：

$$
|\mathcal R_{\mathrm{security}}|
$$

本來就不合理。

成熟服務應該讓客戶說：

> 「我要保護我的公司。」

服務系統自己計算：

$$
R
$$

再調度：

$$
C.
$$

---

# 三十七、從 Staffing 轉向 Coverage

因此未來安全治理的一個可能轉變是：

傳統：

$$
\boxed{
\text{How many security people do we have?}
}
$$

轉向：

$$
\boxed{
\text{How much of our required security capability is covered?}
}
$$

即：

$$
\text{Headcount}
\rightarrow
CCR.
$$

---

# 三十八、安全能力缺口定理

本文提出：

## 定理一：人員存在非充分性

若：

$$
|H|>0,
$$

但存在：

$$
r_i\in R
$$

使：

$$
q_i=0,
$$

則：

$$
G_{\mathrm{SCC}}\neq\varnothing.
$$

因此：

$$
\boxed{
|H|>0
\not\Rightarrow
G_{\mathrm{SCC}}=\varnothing.
}
$$

證畢。

---

# 三十九、增加同質人員非充分性

## 定理二：同質能力擴張不一定提高整體覆蓋率

若新增人員：

$$
H_{m+1}
$$

只提高已高度覆蓋能力：

$$
q_k,
$$

而所有缺口：

$$
q_i=0
$$

仍保持不變，

則：

$$
CCR
$$

可能只有極小提升。

因此：

$$
\boxed{
\text{More Staff}
\neq
\text{More Capability Diversity}.
}
$$

---

# 四十、最小充分能力集合

可以進一步定義：

$$
C^*
\subseteq C
$$

為：

> 能使所有高權重安全需求至少達到最低覆蓋門檻的最小能力組合。

即：

$$
\forall r_i:
w_i>w_{\min},
$$

滿足：

$$
q_i\geq q_{\min}.
$$

則：

$$
C^*
$$

就是：

# Minimum Sufficient Security Capability Set

最小充分安全能力集合。

---

# 四十一、這比「建一個完整資安部門」更適合 SME

中小企業真正需要的是：

$$
\boxed{
\min \operatorname{Cost}(C)
}
$$

subject to：

$$
q_i\geq q_i^*.
$$

也就是：

> 以最低成本取得足夠能力覆蓋。

而不是：

> 所有東西都自己雇人。

---

# 四十二、能力覆蓋具有動態性

當：

$$
R(t)
$$

隨技術環境改變，

昨天的：

$$
CCR(t_0)=0.9
$$

不代表：

$$
CCR(t_1)=0.9.
$$

例如公司突然開始部署 AI Agent：

$$
R(t_1)
=
R(t_0)
+
r_{\mathrm{AgentSec}}.
$$

如果：

$$
q_{\mathrm{AgentSec}}=0,
$$

則：

$$
CCR\downarrow.
$$

即使原團隊一個人都沒有離職。

---

# 四十三、這也是 Vibe Coding 帶來的特殊問題

Vibe Coding 可以讓：

$$
\frac{dE}{dt}
\uparrow.
$$

也就是系統、服務與應用生成速度提高。

但是：

$$
\frac{dC}{dt}
$$

安全能力建設速度未必同步提高。

因此：

$$
\boxed{
\frac{dR}{dt}
>
\frac{dC}{dt}
}
$$

時：

$$
|G_{\mathrm{SCC}}|
\uparrow.
$$

這就是一種：

# Security Capability Debt  
## 安全能力債務

---

# 四十四、AI 攻擊又進一步使這個缺口危險

傳統人類攻擊者也有專長邊界。

但 AI 攻擊平台可以：

$$
A_{\mathrm{attack}}
=
\{
A_1,A_2,\ldots,A_n
\}
$$

分別分析：

- code；
- cloud；
- identity；
- dependency；
- endpoint。

再由：

$$
A_O
$$

統一調度。

因此：

$$
\boxed{
\text{Attack Capability Integration}
\uparrow
}
$$

但防禦方可能仍然：

```text id="e1q7kp"
AppSec team doesn't talk to SOC.

SOC doesn't own cloud.

Cloud team doesn't own IAM.

IAM doesn't review application logic.
```

這就形成新的不對稱：

$$
\boxed{
\text{Integrated Attacker}
>
\text{Fragmented Defender}.
}
$$

不是因為單個攻擊者更聰明，

而是：

$$
\text{organizational integration}
$$

不同。

---

# 四十五、因此未來真正需要的是 Security Capability Graph

單純人員名冊：

$$
H=
\{h_1,\ldots,h_m\}
$$

已經不夠。

應該維護：

$$
\boxed{
\mathcal G_S
=
(
R,
C,
A,
D,
T
)
}
$$

其中：

- $R$ ：Required Capabilities；
- $C$ ：Available Capability Providers；
- $A$ ：Accountability；
- $D$ ：Dependencies；
- $T$ ：Temporal Availability。

這是一張：

# Security Capability Graph

安全能力圖。

---

# 四十六、AI Defender 的第一項任務可能不是「掃毒」

而是：

> **知道現在到底誰在負責什麼。**

持續回答：

$$
\text{What do we have?}
$$

$$
\text{What do we need?}
$$

$$
\text{What is uncovered?}
$$

$$
\text{Who owns it?}
$$

$$
\text{Who can actually perform it?}
$$

$$
\text{Who is available now?}
$$

這比：

> 又多掃一次 malware hash

可能更加根本。

---

# 四十七、從漏洞管理轉向能力管理

本系列第二篇提出：

$$
B_{\mathrm{sys}}
=
\min_{p\in\mathcal P}
C(p).
$$

如果某條攻擊路徑：

$$
p_k
$$

構成最低安全下界，

防禦者需要某一能力：

$$
r_k
$$

去提高：

$$
C(p_k).
$$

但如果：

$$
r_k\in G_{\mathrm{SCC}},
$$

即：

> 沒有人能處理，

則：

$$
B_{\mathrm{sys}}
$$

很難提高。

所以：

$$
\boxed{
\text{Attack Path Gap}
\leftrightarrow
\text{Capability Coverage Gap}.
}
$$

這兩個模型正式接起來。

---

# 四十八、組織安全下界

因此可以提出：

$$
B_{\mathrm{org}}
=
F(
B_{\mathrm{sys}},
CCR,
A_C,
T_C
).
$$

其中：

- $B_{\mathrm{sys}}$ ：技術系統最低攻擊路徑；
- $CCR$ ：能力覆蓋率；
- $A_C$ ：責任明確度；
- $T_C$ ：時間覆蓋。

即使技術配置很好，

若：

$$
CCR\rightarrow0,
$$

事件發生後仍可能無人處理。

---

# 四十九、可驗證命題

## 命題一：Headcount 與安全能力覆蓋僅弱相關

比較企業：

$$
|H|
$$

與：

$$
CCR.
$$

若不同組織在相同 headcount 下呈現巨大能力差異，

則支持本文。

---

## 命題二：跨領域事件的平均處理時間高於單領域事件

若某事件涉及：

$$
R_i+R_j+R_k,
$$

而分屬不同團隊，

預測：

$$
T_{\mathrm{response}}
\uparrow.
$$

這可用來測量：

$$
\text{Responsibility Boundary Loss}.
$$

---

## 命題三：明確 ownership 可降低處理延遲

控制技術能力相同，

比較：

$$
A_i=0
$$

與：

$$
A_i=1.
$$

若後者事件處理速度顯著提高，

則證明：

$$
\text{Accountability}
$$

本身是一個安全變量。

---

## 命題四：AI 能顯著提高低資源組織的能力覆蓋

比較：

$$
C_H
$$

與：

$$
C_H+C_A.
$$

測量：

$$
\Delta CCR.
$$

若 AI 能有效處理大量基線任務，

則：

$$
CCR_{H+A}
>
CCR_H.
$$

---

# 五十、研究限制

本文不主張：

1. 每間企業都需要所有資安專家；
2. 角色越多越安全；
3. NICE 或 ECSF 可以直接取代企業自身風險分析；
4. AI 可以可靠取代所有專業角色；
5. 所有資安工作都適合外包；
6. 能力覆蓋率可以單獨代表完整安全成熟度。

本文真正主張的是：

$$
\boxed{
\text{安全能力必須從需求與風險推導，而不是從職稱與人數反推。}
}
$$

---

# 五十一、結論：不是「有沒有資安人」，而是「安全空間有沒有被覆蓋」

一個組織說：

> 「我們有資安工程師。」

這只能證明：

$$
|H|>0.
$$

它沒有證明：

$$
G_{\mathrm{SCC}}=0.
$$

也沒有證明：

$$
CCR\approx1.
$$

更沒有證明：

$$
A_i
$$

責任清楚，

或：

$$
\tau_i
$$

時間覆蓋充足。

因此：

$$
\boxed{
\text{Security Staff}
\neq
\text{Security Capability}.
}
$$

更準確的組織安全問題應該是：

$$
\boxed{
\text{我們需要哪些安全能力？}
}
$$

$$
\boxed{
\text{目前哪些已經被可靠覆蓋？}
}
$$

$$
\boxed{
\text{哪些仍然沒有任何人真正負責？}
}
$$

這使資安治理從：

$$
\text{People Counting}
$$

轉向：

$$
\boxed{
\text{Capability Coverage Management}.
}
$$

而且當：

$$
R(t)
$$

持續隨雲端、AI Agent、Vibe Coding、供應鏈與新型攻擊面增加，

能力管理本身也必須變成：

$$
\boxed{
\text{Continuous}.
}
$$

這就產生下一個問題。

即使企業知道：

> 「我們有很多安全缺口。」

過去可能仍然存在一項意外的隱形防禦：

> **攻擊者沒有足夠時間逐一研究所有普通企業。**

換句話說：

$$
\text{Security}
$$

的一部分可能從來不是企業自己提供，

而是由：

$$
\boxed{
\text{Attacker Attention Scarcity}
}
$$

意外提供。

如果 AI 讓攻擊者可以低成本地同時研究數十萬個普通目標，

那麼這道從未寫入任何 security policy 的隱形防線會發生什麼？

因此，本系列第五篇將進入：

# 《攻擊者注意力稀缺的終結》
## AI 自動化、普遍化偵察與普通企業的隱形安全崩解

---

## 參考資料與前置節點

1. NIST, *NICE Workforce Framework for Cybersecurity (SP 800-181 Rev. 1)*：以 Work Roles、Tasks、Knowledge、Skills 與 Competencies 描述 cybersecurity work，而非以單一職稱概括。  
2. NIST/NICCS, *NICE Workforce Framework*：明確指出 Work Roles 不等同於 jobs 或 occupations。  
3. NIST, *NICE Framework Components v2.2.0*, April 28, 2026：新增 Cybersecurity Supply Chain Risk Management Work Role，以及 Cryptography、DevSecOps Competency Areas。  
4. ENISA, *European Cybersecurity Skills Framework (ECSF)*：以 12 種 cybersecurity professional role profiles 描述典型安全角色及其能力、技能與互賴關係。  
5. NIST, *Cybersecurity Framework 2.0: Organizational Profiles*：利用 Current Profile 與 Target Profile 分析組織 cybersecurity outcome gaps。  
6. NIST, *CSF 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick-Start Guide*, March 2026：將 cybersecurity risk reality 與 workforce planning 連接。  
7. 國家資通安全研究院，《115 年資安人才職能課程合作申請通過學校名單》，2026：台灣整合 ECSF 與 NICE 建構人才職能框架，目前合作課程包括事件應變、滲透測試、數位鑑識及威脅情資等專門角色。  
8. Neo.K，《不破解密碼：AI 對解密能力執行流與系統因果結構的重構攻擊》。  
9. Neo.K，《攻擊門檻壓縮：AI 時代的駭客能力普及、借用式技術能力與犯罪成本分離》。  
10. Neo.K，《終端機的右側：AI 時代駭客生態的四層分化與生物終局》。