← Archive
lm-002450 · 2026-08

安全能力覆蓋缺口

zh-Hant · md Raw source ↗ Metadata ↗
下載 MD 檔 ⬇

安全能力覆蓋缺口

為什麼「有資安人員」不等於「具有完整資安能力」

英文工作名： 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 系統安全等不同計算與組織領域的能力集合。

因此：

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

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

R={r1,r2,…,rn},R= \{r_1,r_2,\ldots,r_n\},

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

C={c1,c2,…,cm}.C= \{c_1,c_2,\ldots,c_m\}.

安全問題不應只問：

m>0?m>0?

即「有沒有資安人員」，

而應問：

R∖C\boxed{ R\setminus C }

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

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

Nominal Coverage\text{Nominal Coverage}

與：

Effective Coverage.\text{Effective Coverage}.

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

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

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

Fixed Security Staffing\text{Fixed Security Staffing}

轉向：

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

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

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

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

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

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

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

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

因為：

Cybersecurity\text{Cybersecurity}

可能同時包含：

Cryptography+Identity Security+Application Security+API Security+Cloud Security+Network Security+Endpoint Security+Supply Chain Security+Vulnerability Management+Threat Intelligence+Detection Engineering+Incident Response+Digital Forensics+GRC+AI Security+⋯\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}

因此：

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

與：

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

是完全不同的命題。

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

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

DCS={D1,D2,…,Dn}.\mathcal D_{\mathrm{CS}} = \{ D_1,D_2,\ldots,D_n \}.

例如：

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

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

S≈DCS×A\boxed{ \mathcal S \approx \mathcal D_{\mathrm{CS}} \times \mathcal A }

其中：

A\mathcal A

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

因此資料庫會有：

Database Security;\text{Database Security};

網路有：

Network Security;\text{Network Security};

AI 有：

AI Security;\text{AI Security};

軟體生命週期則有：

DevSecOps.\text{DevSecOps}.

所以資安並不像：

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

它更接近：

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

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

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

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

NIST 特別指出：

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

也就是一個人的職稱：

Cybersecurity Engineer

並不能直接告訴我們：

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

這正是本文的起點。

3.1 職稱不是能力單位

定義：

J=Job TitleJ=\text{Job Title}

與：

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

通常：

J≠R.J\neq R.

一個 Job：

J1J_1

可能同時包含：

R1+R2+R3.R_1+R_2+R_3.

而同一個 Work Role：

R1R_1

也可能由：

JA,JB,JCJ_A,J_B,J_C

共同完成。

因此：

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

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

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

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

Work Role，

並加入：

Cryptography\text{Cryptography}

與：

DevSecOps\text{DevSecOps}

Competency Areas。

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

NICE 又增加幾個名詞。

而是：

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

本身會隨技術環境改變。

因此：

R(t0)≠R(t1).\mathcal R(t_0) \neq \mathcal R(t_1).

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

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

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

它的存在本身便支持：

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

只是一個上位集合。

真正工作單位是：

{R1,R2,…,Rn}.\{ R_1,R_2,\ldots,R_n \}.

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

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

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

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

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

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

而是：

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

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

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

E={e1,e2,…,ek}.E= \{ e_1,e_2,\ldots,e_k \}.

例如某公司可能使用：

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

則需要的安全能力：

RR

並不是固定的。

而是：

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

其中：

  • EE ：Technology Environment；
  • AA ：Assets；
  • VV ：Value / Impact；
  • LL ：Legal / Regulatory Requirements；
  • TT ：Threat Landscape。

因此：

Rbank≠Rgame studio≠Rhospital≠Rstartup.R_{\mathrm{bank}} \neq R_{\mathrm{game\ studio}} \neq R_{\mathrm{hospital}} \neq R_{\mathrm{startup}}.

八、安全能力覆蓋缺口

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

令：

R={r1,r2,…,rn}R= \{r_1,r_2,\ldots,r_n\}

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

實際可取得能力為：

C={c1,c2,…,cm}.C= \{c_1,c_2,\ldots,c_m\}.

則：

GSCC=R∖C\boxed{ G_{\mathrm{SCC}} = R\setminus C }

本文稱：

Security Capability Coverage Gap

安全能力覆蓋缺口

它回答：

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

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

安全能力通常不是：

0/1.0/1.

例如某工程師：

會 AWS Security，

可能介於：

0.2, 0.5, 0.8, 1.0.0.2,\ 0.5,\ 0.8,\ 1.0.

因此定義：

Mij∈[0,1]M_{ij} \in[0,1]

表示第 jj 個能力提供者對能力：

rir_i

的實際覆蓋程度。

其中能力提供者可以是：

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

形成：

M=[M11⋯M1m⋮⋮Mn1⋯Mnm].M= \begin{bmatrix} M_{11}&\cdots&M_{1m}\\ \vdots&&\vdots\\ M_{n1}&\cdots&M_{nm} \end{bmatrix}.

這就是：

Security Capability Coverage Matrix

安全能力覆蓋矩陣。

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

對某一能力：

ri,r_i,

可以簡化定義：

qi=max⁡jMij.q_i = \max_j M_{ij}.

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

但若需要多人合作，

則可以改成：

qi=F(Mi1,…,Mim).q_i = F( M_{i1},\ldots,M_{im} ).

例如：

Incident Response\text{Incident Response}

可能需要：

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

因此並不是：

max⁡Mij\max M_{ij}

就足夠。

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

不是所有能力同等重要。

例如：

r1=Web App Securityr_1=\text{Web App Security}

對一個沒有 Web App 的公司，

權重可能很低。

因此給每一項能力：

wi.w_i.

定義：

CCR=∑i=1nwiqi∑i=1nwi\boxed{ CCR = \frac{ \sum_{i=1}^{n} w_iq_i }{ \sum_{i=1}^{n}w_i } }

稱為：

Capability Coverage Ratio

能力覆蓋率

例如：

公司 A：

CCR=0.35CCR=0.35

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

公司 B：

CCR=0.85.CCR=0.85.

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

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

因此：

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

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

假設公司 A 有：

55

名資安工程師。

但五人全部專長：

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

則：

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

可能仍缺：

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

公司 B 只有：

22

名內部人員，

但搭配：

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

則：

CBC_B

可能更接近：

R.R.

因此：

∣HA∣>∣HB∣\boxed{ |H_A|>|H_B| }

完全不保證：

CCRA>CCRB.CCR_A>CCR_B.

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

企業真正應問：

「我們缺什麼？」

而不是先問：

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

順序應該是：

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

而不是：

Hire Security Person→Assume Security Exists.\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 的概念。

組織可以建立：

PcurrentP_{\mathrm{current}}

與：

Ptarget,P_{\mathrm{target}},

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

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

Ptarget−PcurrentP_{\mathrm{target}} - P_{\mathrm{current}}

可以轉換成：

Rneeded−Cavailable.R_{\mathrm{needed}} - C_{\mathrm{available}}.

也就是：

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

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

這是另一個重要問題。

組織可能說：

「Cloud Security 有人負責。」

因此：

qi=1?q_i=1?

不一定。

因為真正能力可能受：

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

限制。

因此本文區分：

CN=Nominal CoverageC_N=\text{Nominal Coverage}

與：

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

通常：

CE≤CN.\boxed{ C_E\leq C_N. }

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

令：

KiK_i

為知識能力，

TiT_i

為可投入時間比例，

AiA_i

為授權程度，

DiD_i

為必要資料可取得程度，

QiQ_i

為工具品質。

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

qi=KiTiAiDiQi.q_i = K_iT_iA_iD_iQ_i.

即使：

Ki=1,K_i=1,

若：

Ti=0.1,T_i=0.1,

實際能力仍然有限。

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

不是完全不懂。

而是：

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

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

假設一名 generalist 初始負責：

R1,R2,R3.R_1,R_2,R_3.

組織逐漸增加：

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

最後他可能名義上負責：

R1,…,R15.R_1,\ldots,R_{15}.

但：

ThumanT_{\mathrm{human}}

沒有增加。

因此：

Tavailable∣R∣↓.\frac{ T_{\mathrm{available}} }{ |R| } \downarrow.

本文稱為：

Security Responsibility Dilution

資安責任稀釋

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

當開發者認為：

Security 是資安部門的事。

則 Developer 自己可能降低：

Sdeveloper.S_{\mathrm{developer}}.

DevOps 亦然。

最後形成：

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

而安全本來就是：

Shared Responsibility.\text{Shared Responsibility}.

因此專責資安團隊應該：

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

而不是：

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

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

假設：

RaR_a

由 Team A 負責，

RbR_b

由 Team B 負責。

某事件恰好落在：

Ra∩Rb.R_a\cap R_b.

如果雙方都認為：

「是另一邊的。」

則：

qab→0.q_{ab}\rightarrow0.

本文稱為：

Responsibility Boundary Loss

責任邊界損失

二十、典型責任邊界

例如：

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

Developer：

Security 應該檢查。

Security：

Business Logic 是 Backend 負責。

Platform：

我只管 deployment。

結果：

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

所以：

Shared\text{Shared}

必須不等於：

Undefined.\text{Undefined}.

二十一、責任矩陣

因此除了：

MijM_{ij}

能力矩陣之外，

還需要：

AijA_{ij}

責任矩陣。

例如：

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

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

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

否則：

rir_i

即形成：

Orphan Security Capability

孤兒安全能力

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

可能：

情況 A

有人負責，

但不會。

Ai=1,Ci=0.A_i=1, \quad C_i=0.

情況 B

有人會，

但沒人指定他負責。

Ai=0,Ci=1.A_i=0, \quad C_i=1.

兩種都危險。

因此完整條件：

Si=Ci⋅Ai.\boxed{ S_i = C_i \cdot A_i. }

如果任何一項為零：

Si=0.S_i=0.

二十三、單一專家依賴

公司可能存在：

「只有 Alice 知道這個。」

這其實是一種：

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

令：

NiN_i

為可可靠執行能力：

rir_i

的人數。

若：

Ni=1,N_i=1,

則形成：

Single-Expert Dependency

單一專家依賴

如果：

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

則：

qi→0.q_i\rightarrow0.

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

有沒有人會？

還應問：

有多少人可以接替？

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

SOC 是最明顯案例。

假設：

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

但每天只有人工作：

8 hours.8\text{ hours}.

那麼：

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

如果威脅：

24/724/7

存在，

則能力也必須包含：

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

因此：

qi=F(Ki,Ti,Ai,Di,Qi,τi)q_i = F( K_i, T_i, A_i, D_i, Q_i, \tau_i )

其中：

τi\tau_i

代表時間覆蓋。

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

跨國企業還有：

Gi=Geographic CoverageG_i=\text{Geographic Coverage}

及：

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

因為：

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

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

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

把：

Company\text{Company}

換成：

State,\text{State},

問題完全沒有消失。

反而變得更大。

國家要保護：

Government Systems+Defense+Finance+Energy+Telecom+Health+Transportation+Critical Infrastructure+Citizen Data+Supply Chains.\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}

所以：

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

仍然不是完整問題。

真正問題是：

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

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

令：

RNR_N

為國家所需要的 cyber capability set，

CNC_N

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

則：

GN=RN−CN.G_N = R_N-C_N.

一個國家可能具有：

Strong Military Cyber\text{Strong Military Cyber}

但缺：

SMB Security.\text{SMB Security}.

或者：

Strong Incident Response\text{Strong Incident Response}

但缺：

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

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

「有／沒有國家 CERT。」

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

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

其本質可以表示為：

Mij↑.M_{ij} \uparrow.

教育不是抽象地：

「培養更多資安人。」

而應：

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

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

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

假設公司只有：

2020

人。

要求它內部擁有：

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

完全不合理。

因此：

CC

不應限制為：

Cinternal.C_{\mathrm{internal}}.

而應：

C=Cinternal+Cexternal+Cplatform+CAI.\boxed{ C = C_{\mathrm{internal}} + C_{\mathrm{external}} + C_{\mathrm{platform}} + C_{\mathrm{AI}}. }

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

這跟雲端計算非常類似。

企業不需要：

擁有一座 data center。

只需要：

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

同理，

也不一定需要：

雇用每一種安全專家。

只需要：

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

這是後續：

Security-as-Infrastructure

命題的重要前提。

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

如果：

CexternalC_{\mathrm{external}}

存在，

公司仍然需要：

OinternalO_{\mathrm{internal}}

內部 ownership。

否則：

外部團隊說有問題。

沒有人決定怎麼處理。

因此：

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

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

令：

AkA_k

表示 Security AI Agent。

它可能提供：

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

因此：

Mi,Ak>0.M_{i,A_k}>0.

也就是：

AkA_k

正式進入能力覆蓋矩陣。

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

不能寫：

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

只因：

「我們有 AI。」

AI 也有：

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

因此：

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

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

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

更理想的組合是：

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

AI 擅長：

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

人類擅長：

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

所以：

H+A\boxed{ H+A }

可能比：

HH

或：

AA

單獨更可靠。

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

未來最重要的不一定是：

一個 AI 什麼都會。

而是：

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

它接收到事件：

E.E.

先判斷：

ri=Classify⁡(E).r_i=\operatorname{Classify}(E).

然後將其派給：

arg⁡max⁡jMij.\arg\max_j M_{ij}.

例如：

E→{AAppSecHIRHLegalACloudHDFIRE \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 到底差在哪？

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

∣Rsecurity∣|\mathcal R_{\mathrm{security}}|

本來就不合理。

成熟服務應該讓客戶說：

「我要保護我的公司。」

服務系統自己計算：

RR

再調度：

C.C.

三十七、從 Staffing 轉向 Coverage

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

傳統：

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

轉向：

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

即：

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

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

本文提出：

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

若：

∣H∣>0,|H|>0,

但存在：

ri∈Rr_i\in R

使：

qi=0,q_i=0,

則：

GSCC≠∅.G_{\mathrm{SCC}}\neq\varnothing.

因此：

∣H∣>0⇏GSCC=∅.\boxed{ |H|>0 \not\Rightarrow G_{\mathrm{SCC}}=\varnothing. }

證畢。

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

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

若新增人員：

Hm+1H_{m+1}

只提高已高度覆蓋能力：

qk,q_k,

而所有缺口：

qi=0q_i=0

仍保持不變，

則：

CCRCCR

可能只有極小提升。

因此：

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

四十、最小充分能力集合

可以進一步定義：

C∗⊆CC^* \subseteq C

為：

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

即：

∀ri:wi>wmin⁡,\forall r_i: w_i>w_{\min},

滿足：

qi≥qmin⁡.q_i\geq q_{\min}.

則：

C∗C^*

就是：

Minimum Sufficient Security Capability Set

最小充分安全能力集合。

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

中小企業真正需要的是：

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

subject to：

qi≥qi∗.q_i\geq q_i^*.

也就是：

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

而不是：

所有東西都自己雇人。

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

當：

R(t)R(t)

隨技術環境改變，

昨天的：

CCR(t0)=0.9CCR(t_0)=0.9

不代表：

CCR(t1)=0.9.CCR(t_1)=0.9.

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

R(t1)=R(t0)+rAgentSec.R(t_1) = R(t_0) + r_{\mathrm{AgentSec}}.

如果：

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

則：

CCR↓.CCR\downarrow.

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

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

Vibe Coding 可以讓：

dEdt↑.\frac{dE}{dt} \uparrow.

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

但是：

dCdt\frac{dC}{dt}

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

因此：

dRdt>dCdt\boxed{ \frac{dR}{dt} > \frac{dC}{dt} }

時：

∣GSCC∣↑.|G_{\mathrm{SCC}}| \uparrow.

這就是一種：

Security Capability Debt

安全能力債務

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

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

但 AI 攻擊平台可以：

Aattack={A1,A2,…,An}A_{\mathrm{attack}} = \{ A_1,A_2,\ldots,A_n \}

分別分析：

  • code；
  • cloud；
  • identity；
  • dependency；
  • endpoint。

再由：

AOA_O

統一調度。

因此：

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

但防禦方可能仍然：

AppSec team doesn't talk to SOC.

SOC doesn't own cloud.

Cloud team doesn't own IAM.

IAM doesn't review application logic.

這就形成新的不對稱：

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

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

而是：

organizational integration\text{organizational integration}

不同。

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

單純人員名冊：

H={h1,…,hm}H= \{h_1,\ldots,h_m\}

已經不夠。

應該維護：

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

其中：

  • RR ：Required Capabilities；
  • CC ：Available Capability Providers；
  • AA ：Accountability；
  • DD ：Dependencies；
  • TT ：Temporal Availability。

這是一張：

Security Capability Graph

安全能力圖。

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

而是：

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

持續回答：

What do we have?\text{What do we have?} What do we need?\text{What do we need?} What is uncovered?\text{What is uncovered?} Who owns it?\text{Who owns it?} Who can actually perform it?\text{Who can actually perform it?} Who is available now?\text{Who is available now?}

這比：

又多掃一次 malware hash

可能更加根本。

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

本系列第二篇提出：

Bsys=min⁡p∈PC(p).B_{\mathrm{sys}} = \min_{p\in\mathcal P} C(p).

如果某條攻擊路徑：

pkp_k

構成最低安全下界，

防禦者需要某一能力：

rkr_k

去提高：

C(pk).C(p_k).

但如果：

rk∈GSCC,r_k\in G_{\mathrm{SCC}},

即：

沒有人能處理，

則：

BsysB_{\mathrm{sys}}

很難提高。

所以：

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

這兩個模型正式接起來。

四十八、組織安全下界

因此可以提出：

Borg=F(Bsys,CCR,AC,TC).B_{\mathrm{org}} = F( B_{\mathrm{sys}}, CCR, A_C, T_C ).

其中：

  • BsysB_{\mathrm{sys}} ：技術系統最低攻擊路徑；
  • CCRCCR ：能力覆蓋率；
  • ACA_C ：責任明確度；
  • TCT_C ：時間覆蓋。

即使技術配置很好，

若：

CCR→0,CCR\rightarrow0,

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

四十九、可驗證命題

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

比較企業：

∣H∣|H|

與：

CCR.CCR.

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

則支持本文。

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

若某事件涉及：

Ri+Rj+Rk,R_i+R_j+R_k,

而分屬不同團隊，

預測：

Tresponse↑.T_{\mathrm{response}} \uparrow.

這可用來測量：

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

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

控制技術能力相同，

比較：

Ai=0A_i=0

與：

Ai=1.A_i=1.

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

則證明：

Accountability\text{Accountability}

本身是一個安全變量。

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

比較：

CHC_H

與：

CH+CA.C_H+C_A.

測量：

ΔCCR.\Delta CCR.

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

則：

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

五十、研究限制

本文不主張：

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

本文真正主張的是：

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

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

一個組織說：

「我們有資安工程師。」

這只能證明：

∣H∣>0.|H|>0.

它沒有證明：

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

也沒有證明：

CCR≈1.CCR\approx1.

更沒有證明：

AiA_i

責任清楚，

或：

τi\tau_i

時間覆蓋充足。

因此：

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

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

我們需要哪些安全能力？\boxed{ \text{我們需要哪些安全能力？} } 目前哪些已經被可靠覆蓋？\boxed{ \text{目前哪些已經被可靠覆蓋？} } 哪些仍然沒有任何人真正負責？\boxed{ \text{哪些仍然沒有任何人真正負責？} }

這使資安治理從：

People Counting\text{People Counting}

轉向：

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

而且當：

R(t)R(t)

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

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

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

這就產生下一個問題。

即使企業知道：

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

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

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

換句話說：

Security\text{Security}

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

而是由：

Attacker Attention Scarcity\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 時代駭客生態的四層分化與生物終局》。