[安全教育] 001 Security Champion 計畫：讓開發者成為安全推手｜建立機制、培訓與激勵的完整實戰指南
「最好的防火牆，不是裝在伺服器上的那道，而是裝在每個開發者腦中的那道。
Security Champion 不是多一個頭銜，而是讓安全有了在每個團隊生根的土壤。」
— SSDLC by 飛飛
一、Security Champion 是什麼？為什麼你的團隊需要「安全種子選手」？
在 SSDLC 蓋房子的旅程中，我們已經走過了安全需求、安全設計、安全編碼、安全測試、安全部署、安全維運。到了階段七：教育與持續改進（Education & Continuous Improvement）——也就是社區防災演練、經驗傳承的階段。
但這裡有一個殘酷的現實：再好的安全制度，如果沒有「人」在團隊裡日復一日地推動，最終都會變成牆上的海報。
想像你住的社區，管委會請了一位消防顧問來演講，大家聽完拍拍手，然後繼續把滅火器當門擋用。但如果你們棟有一位鄰居，本身就住在這裡、了解大家的習慣，他會在群組裡提醒「瓦斯記得關」、在樓梯間順手檢查滅火器、住戶裝修時提醒「不要擋到消防通道」——這位鄰居就是你的 Security Champion。
Security Champion（安全冠軍 / 安全倡導者） 是開發團隊中願意多學一點資安知識、在日常開發中推廣安全實踐的開發者。他們不是資安專家，也不需要轉職成資安工程師，而是在原本的開發角色上，多戴一頂安全的帽子。
| 面向 | 專職資安團隊 | Security Champion |
|---|---|---|
| 身份 | 獨立的資安部門成員 | 開發團隊中的一員 |
| 比喻 | 消防局派來的消防員 | 社區裡懂消防的鄰居 |
| 優勢 | 專業深度、全局視野 | 了解團隊痛點、即時回應 |
| 劣勢 | 不了解每個團隊的細節 | 安全知識有限，需要持續學習 |
| 角色 | 制定政策、審計、應變 | 推廣實踐、第一線把關、橋樑溝通 |
根據 OWASP Security Champions Playbook 的定義，Security Champion 是團隊中安全事務的單一聯絡窗口，他們與資安團隊保持聯繫、監督安全最佳實踐的落實，並協助推動安全文化活動。
飛飛觀點：
在台灣，很多中小型軟體公司根本沒有專職資安人員。這不代表你可以不做安全——而是代表你更需要 Security Champion。就像小公寓沒有物管公司，更需要有個熱心鄰居幫忙注意門禁安全。
二、沒有 Security Champion 會怎樣？那些血淋淋的場景
在你決定要不要建立 Security Champion 計畫之前，先看看沒有它的團隊長什麼樣子：
場景一：資安警報變成噪音
CI/CD Pipeline 加入了 SAST 掃描（太好了，你讀了前幾篇文章！），每次掃出 20 條警告。但沒有人知道哪些重要、哪些是誤報，開發者開始習慣性忽略。三個月後，Pipeline 裡的安全掃描變成了裝飾品。
場景二：安全知識斷層
團隊裡那個懂資安的前輩離職了。他腦中的安全設計決策、為什麼密碼要用 Argon2 而不是 bcrypt、為什麼那個 API 要加 Rate Limit——全部跟著他走了。新人接手後，這些防護措施逐漸被「簡化」掉。
場景三：資安團隊變成瓶頸
公司有一個兩人的資安團隊，但他們要審全公司八個團隊的程式碼。結果？安全審查排隊排到天荒地老，開發者為了趕 deadline 直接跳過安全審查上線。
場景四：安全只在出事時被想起
平時大家各忙各的，直到某天客戶資料外洩上了新聞。老闆緊急召開會議：「誰來負責？」大家面面相覷——因為安全從來不是「誰的事」。
這些場景有沒有很眼熟？Security Champion 計畫正是為了解決這些問題而存在的。
三、Security Champion 的角色定義：他們到底要做什麼？
Security Champion 不是「兼職資安工程師」，也不是「背鍋俠」。他們的角色更像是一座橋——連結開發團隊與資安團隊，讓安全知識能在日常開發中流動。
核心職責清單
## Security Champion 職責定義
### 日常職責（每週投入 2-4 小時）
- [ ] Code Review 時關注安全面向（輸入驗證、權限檢查、錯誤處理）
- [ ] 協助團隊判讀 SAST / DAST / SCA 掃描結果
- [ ] 在 Sprint Planning 提出安全考量（「這個功能需要做威脅建模嗎？」）
- [ ] 追蹤團隊的安全技術債，確保高風險項目被排入修復計畫
### 推廣職責（每月 2-4 小時）
- [ ] 在團隊內分享最新的安全漏洞案例或技術趨勢
- [ ] 帶領團隊做安全相關的 Workshop 或 Lunch & Learn
- [ ] 維護團隊的安全 Checklist 和最佳實踐文件
### 橋樑職責（持續性）
- [ ] 作為團隊與資安團隊之間的聯絡窗口
- [ ] 將資安團隊的政策「翻譯」成開發者聽得懂的語言
- [ ] 回報團隊遇到的安全工具問題或流程卡點
- [ ] 參加跨團隊的 Security Champion 定期會議
### 進階職責（視經驗逐步加入）
- [ ] 協助進行新功能的威脅建模（STRIDE 分析）
- [ ] 撰寫安全相關的自訂 Semgrep / ESLint 規則
- [ ] 協助規劃安全驗收標準（Gherkin 格式）
- [ ] 在事件回應時提供技術支援Security Champion ≠ 這些角色
很多團隊對 Security Champion 有誤解，這裡先釐清：
| Security Champion 是 | Security Champion 不是 |
|---|---|
| 安全意識的推廣者 | 所有安全工作的執行者 |
| 團隊的安全諮詢窗口 | 唯一需要關心安全的人 |
| 資安團隊的延伸觸角 | 資安團隊的替代品 |
| 持續學習安全的開發者 | 已經精通資安的專家 |
| 提出安全建議的人 | 有權否決功能上線的人 |
飛飛觀點：
最常見的失敗原因是把 Security Champion 當成「免費的資安工程師」——什麼安全工作都丟給他，但不給他時間、資源和支持。這就像讓一個志工消防員去處理化學工廠大火，既不公平也不實際。
四、從零建立 Security Champion 計畫：六步驟實戰指南
第一步：取得管理層支持（最重要的一步）
沒有管理層的支持，Security Champion 計畫注定失敗。因為 Champion 需要被允許在工作時間花一部分精力在安全上。如果主管認為「寫 Code 才是正事，搞安全是浪費時間」，那 Champion 就會在產出壓力和安全責任之間被夾扁。
怎麼說服老闆？用數據和錢說話：
## 給主管的電梯簡報
### 問題
- 台灣企業每年因資安事件平均損失 NT$ 3,200 萬
- 上線後才發現的安全漏洞，修復成本是設計階段的 30-100 倍
- 我們目前沒有人在開發過程中把關安全
### 解決方案
- 建立 Security Champion 計畫
- 每個團隊指定一位開發者，每週投入 2-4 小時關注安全
- 不需要額外招人，不需要大額預算
### 預期效益
- 安全漏洞在開發階段被發現的比率提升 40-60%
- 減少上線後的安全修補成本
- 提升團隊整體安全意識與程式碼品質
- 符合客戶與法規（個資法、資安法）的安全要求
### 需要的支持
- 允許 Champion 每週有 2-4 小時的安全學習與實踐時間
- 提供基礎的培訓資源（約 NT$ 30,000-50,000 / 年）
- 在績效考核中認可 Champion 的貢獻第二步：選對人（心態比技能重要）
Security Champion 不需要是團隊裡技術最強的人，但一定要是對安全有好奇心、願意學習、能影響他人的人。
理想的 Security Champion 特質：
- 好奇心強：看到一個 API 會想「如果有人亂打參數會怎樣？」
- 樂於分享：願意在團隊內分享學到的東西，不藏私
- 溝通能力好：能把技術概念用大家聽得懂的方式說明
- 有影響力：團隊成員信任他、願意聽他的建議
- 主動積極：不需要人追著跑，自己會找資源學習
建議的人數比例： 每 5-10 位開發者配一位 Security Champion。太少覆蓋不了，太多反而沒人認真投入。
選人方式：
| 方式 | 優點 | 缺點 |
|---|---|---|
| 自願報名 | 動機最強、投入度高 | 可能沒人報名 |
| 主管推薦 | 可確保每個團隊都有 | 被推薦的人可能不情願 |
| 結合兩者 | 平衡覆蓋率與投入度 | 需要更多溝通協調 |
台灣場景的建議： 先從自願報名開始，搭配一場「Security Champion 是什麼」的說明會。我的經驗是，當大家知道這不是額外加班，而是有資源支持的成長機會時，通常都會有人主動舉手。
飛飛觀點：
最怕的就是「被志願」的 Champion。研究指出，被強迫擔任的 Champion 往往會心生不滿、敷衍了事。招募應該強調吸引力和好奇心，而不是強制指派。如果一個團隊真的沒人想當，那代表安全文化需要先從更基礎的地方開始培養。
第三步：建立培訓路線圖（漸進式學習）
Security Champion 不需要一開始就精通所有資安知識。好的培訓計畫是漸進式的——先打基礎，再逐步加深。
培訓路線圖（建議 6 個月為一個週期）
第 1 個月：安全意識基礎
├─ OWASP Top 10 概覽（讀完本系列文章就夠了！）
├─ 常見漏洞 Demo（SQL Injection、XSS 實際操作）
├─ 認識團隊使用的安全工具（SAST、DAST、SCA）
└─ 完成 OWASP Juice Shop 前 10 個挑戰
第 2-3 個月：工具與流程實戰
├─ 學會判讀 SonarQube / Semgrep 的掃描報告
├─ 練習做簡單的 Code Review（安全面向）
├─ 參與一次威脅建模 Workshop（STRIDE）
└─ 撰寫第一份 Abuse Case
第 4-5 個月：深化與分享
├─ 學習進階主題（認證授權設計、密碼學基礎、供應鏈安全）
├─ 在團隊內做一次 Lunch & Learn 分享
├─ 協助定義一個功能的安全驗收標準
└─ 參加外部資安社群活動或研討會
第 6 個月：評估與規劃
├─ 自我評估成長（對照初始基準）
├─ 收集團隊回饋
├─ 規劃下一期的學習重點
└─ 將經驗文件化，加入團隊知識庫推薦的學習資源：
| 資源 | 類型 | 費用 | 適合階段 |
|---|---|---|---|
| SSDLC by 飛飛 系列文章 | 文章 | 免費 | 第 1 個月 |
| OWASP Juice Shop | 實作平台 | 免費 | 第 1-2 個月 |
| PortSwigger Web Security Academy | 線上課程 + Lab | 免費 | 第 2-3 個月 |
| OWASP Security Champions Guide | 指南 | 免費 | 持續參考 |
| AWS Security Champion Knowledge Path | 線上課程 + Badge | 付費（Skill Builder） | 第 3-5 個月 |
| 資安實務研討會（如 HITCON、CYBERSEC） | 研討會 | 付費（NT$ 2,000-8,000） | 第 4-5 個月 |
第四步：建立溝通機制與社群
Security Champion 不該是孤軍奮戰。他們需要一個互相支持的社群。
建議建立以下溝通管道：
1. 專屬 Slack / Teams 頻道
建一個 <code>#security-champions</code> 頻道，讓所有 Champion 可以：
- 分享遇到的安全問題和解決方式
- 討論掃描結果中不確定的發現
- 轉發最新的安全資訊和漏洞通報
2. 雙週定期會議（30 分鐘）
每兩週一次的短會議，議程很簡單：
## Security Champion 雙週會議議程（30 分鐘）
1. 【5 分鐘】近期安全動態（資安團隊分享）
2. 【10 分鐘】各團隊安全近況回報
- 有沒有遇到新的安全問題？
- 掃描結果有什麼需要討論的？
- 有沒有什麼安全改善的好消息？
3. 【10 分鐘】主題討論 / 案例分享
- 輪流由一位 Champion 分享學到的東西
4. 【5 分鐘】行動項目確認3. 知識庫（Wiki / Notion / Confluence）
集中管理所有安全相關的知識：
/security-knowledge-base
/onboarding ← 新進 Champion 的入門指南
/checklists ← 各類安全 Checklist
/case-studies ← 團隊遇過的安全案例
/tool-guides ← 安全工具使用指南
/templates ← 威脅建模、Abuse Case 模板
/meeting-notes ← 雙週會議紀錄第五步：設計激勵機制（讓人想繼續做下去）
Security Champion 是額外付出時間和精力的角色，如果沒有適當的激勵，熱情很快就會消退。
激勵不只是獎金，而是認可、成長和影響力。
| 激勵類型 | 具體做法 | 成本 |
|---|---|---|
| 公開認可 | 在全公司月會上介紹 Champion 和他們的貢獻 | 免費 |
| 學習資源 | 贊助參加資安研討會（如 HITCON、CYBERSEC） | NT$ 3,000-8,000 / 次 |
| 證照補助 | 補助考取 Security+ 或 CEH 等證照 | NT$ 10,000-30,000 |
| 績效認可 | 將 Champion 工作納入績效考核的加分項目 | 免費 |
| 成長路徑 | 提供 Tech Lead 或 Security Engineer 的晉升參考 | 免費 |
| 季度表彰 | 「最佳安全倡導者」獎，附贈小禮物或獎金 | NT$ 1,000-3,000 |
| 時間保障 | 明確規定每週有 2-4 小時的安全學習時間 | 免費（但最珍貴） |
台灣企業的實戰做法：
- 某台灣電商公司：每季評選「安全之星」，在公司群組公開表揚，並送一張 NT$ 3,000 的書券（買技術書籍用）
- 某台灣金融科技新創：Security Champion 的工作納入 OKR，佔個人績效的 10%，確保主管不會忽視他們的貢獻
- 某台灣 SaaS 公司：每年贊助一位 Champion 去參加海外資安研討會，回來後做一場公司內部分享
飛飛觀點：
在所有激勵中，「時間保障」是最重要的。很多公司口頭支持安全，但 Champion 一忙起來就被要求「先趕功能，安全的事晚點再說」。如果連學習和實踐的時間都沒有，其他激勵都是空談。
第六步：衡量成效，持續改進
Security Champion 計畫不是設立了就萬事大吉。你需要追蹤指標，確認計畫真的有在產生效果。
建議追蹤的指標：
// Security Champion 計畫成效指標
const securityChampionMetrics = {
// 安全品質指標
vulnerabilities: {
'開發階段發現的漏洞數': '應該逐漸增加（代表更多問題被提前發現）',
'上線後才發現的漏洞數': '應該逐漸減少',
'平均漏洞修復時間': '應該逐漸縮短',
'SAST 掃描合格率': '應該逐漸提升',
},
// 文化指標
culture: {
'Champion 活動參與率': '每月分享會的出席率',
'Security PR Review 參與度': 'Champion 參與安全相關 Code Review 的頻率',
'安全議題提出次數': 'Sprint Planning 中提出安全考量的次數',
'知識庫更新頻率': '安全文件被新增或更新的次數',
},
// Champion 個人成長指標
growth: {
'培訓完成率': '預定課程的完成比例',
'安全技能自評分數': '每季一次，1-5 分自評',
'分享次數': 'Lunch & Learn 或文章分享的次數',
},
// 滿意度指標
satisfaction: {
'Champion 滿意度': '對計畫的整體滿意度（季度調查）',
'團隊感受': '團隊成員是否感覺安全意識有提升',
}
};簡易的季度報告模板：
## Security Champion 計畫 Q_ 季度報告
### 本季重點數據
- Security Champion 人數：_ 人（覆蓋 _ 個團隊）
- 開發階段發現漏洞：_ 件（上季：_ 件）
- 上線後安全事件：_ 件（上季：_ 件）
- 平均漏洞修復時間：_ 天（上季：_ 天）
### 本季活動
- 舉辦 _ 場安全分享會
- 完成 _ 次威脅建模
- 更新 _ 份安全文件
### 成功案例
[記錄一個具體的、Champion 發現或預防安全問題的案例]
### 挑戰與改進
[記錄遇到的困難和下季改進方向]五、台灣場景實戰：一個 20 人團隊的導入案例
讓我們用一個虛構但寫實的台灣場景，走一遍 Security Champion 計畫的完整導入。
背景
「好買網」是一間台灣的中型電商平台，團隊 20 人（3 個 Scrum 小組，每組 5-7 人），使用 Node.js + React 技術棧。沒有專職資安人員，過去安全靠上線前找外部廠商做一次滲透測試。
導入過程
Month 0：準備階段
CTO 閱讀了 SSDLC 系列文章（就是你現在在看的這個系列），決定導入 Security Champion 計畫。他向 CEO 提出提案，用「去年滲透測試發現 15 個高風險漏洞，修復花了 3 個 Sprint」的數據說服管理層支持。
Month 1：啟動
- 舉辦一場 1 小時的全員說明會，介紹 Security Champion 計畫
- 三個 Scrum 小組各有一人自願報名（前端組的小美、後端組的阿凱、DevOps 組的志明）
- 每位 Champion 每週有 3 小時的安全學習時間
- 建立 <code>#security-champions</code> Slack 頻道
Month 2-3：基礎培訓
- 三人一起讀完 SSDLC 系列文章的安全需求和安全編碼篇
- 各自完成 OWASP Juice Shop 前 15 個挑戰
- 阿凱在 Code Review 時發現一個 SQL Injection 風險，提交修復 PR
- 志明把 Semgrep 的掃描結果整理成團隊看得懂的報告格式
Month 4-6：實戰累積
- 小美在 Sprint Planning 提出「這個新的社群分享功能需要做 Abuse Case 分析」
- 三人合作完成了登入系統的 STRIDE 威脅建模
- 阿凱做了第一場 Lunch & Learn：「我如何用 5 分鐘在好買網找到 XSS 漏洞」（用測試環境 demo）
- 志明建立了團隊的「部署前安全 Checklist」
- 外部滲透測試結果：高風險漏洞從去年的 15 個降到 4 個
Month 7-12：持續改進
- 新進的開發者入職時，由 Champion 帶他做一次安全基礎導覽
- 建立了安全知識庫，累積了 12 篇安全案例
- CTO 在年度大會上公開表揚三位 Champion
- 阿凱開始對團隊的自訂 Semgrep 規則做貢獻
- 計畫吸引了另外兩位開發者加入，Champion 團隊擴大到 5 人
成果數據
| 指標 | 導入前 | 導入後（一年） |
|---|---|---|
| 外部滲透測試高風險漏洞數 | 15 個 | 4 個 |
| 開發階段發現的安全問題 | 0 件 / 季 | 12 件 / 季 |
| 安全修復平均時間 | 14 天 | 3 天 |
| 團隊安全意識自評（1-5） | 2.1 分 | 3.8 分 |
| Sprint Planning 提出安全議題次數 | 0 次 / 月 | 4 次 / 月 |
六、Security Champion 的成熟度模型：你的計畫在哪個階段？
Security Champion 計畫不是一步到位的，它有自己的成長曲線。以下是四個成熟度等級，幫你評估目前的狀態和下一步方向：
| 等級 | 名稱 | 特徵 | 下一步行動 |
|---|---|---|---|
| Level 1 | 萌芽期 | 剛指定 Champion，角色定義模糊，培訓剛開始 | 明確職責、建立培訓路線圖 |
| Level 2 | 建立期 | Champion 開始在 Code Review 中關注安全，定期會議已建立 | 建立激勵機制、開始量化指標 |
| Level 3 | 成長期 | Champion 主動發現問題、帶動團隊文化改變、有系統的知識分享 | 深化技能（威脅建模、自訂規則）、建立知識庫 |
| Level 4 | 成熟期 | 安全融入開發日常、Champion 影響架構決策、形成安全社群 | 建立 Community of Practice、影響組織策略 |
根據 BSIMM（Building Security In Maturity Model）的數據，在安全成熟度最高的企業中，有 92% 設有 Security Champion 計畫，而成熟度最低的企業只有 32%。這充分說明了 Security Champion 與組織安全水準的正相關。
七、常見問題 FAQ
Q1：我們團隊只有 5 個人，也需要 Security Champion 嗎？
需要，而且更需要。小團隊沒有專職資安人員，代表安全責任完全分散，結果就是沒人負責。指定一位 Champion，哪怕每週只花 1-2 小時關注安全，都比「大家都有責任 = 沒人有責任」好太多了。
Q2：Security Champion 需要什麼背景？需要資安證照嗎？
不需要任何資安背景或證照。最重要的是對安全有興趣和好奇心。培訓計畫會逐步補足知識。事實上，很多優秀的 Champion 是從「想知道為什麼這行程式碼不安全」這個好奇心開始的。證照可以作為後續的成長目標，但絕不是門檻。
Q3：Champion 會不會變成團隊的瓶頸？什麼安全決策都要經過他？
不應該。Champion 的角色是「推廣者」和「諮詢者」，不是「審核者」。安全檢查應該盡量自動化（SAST、DAST、SCA 整合進 CI/CD），Champion 負責的是幫助團隊理解掃描結果、推動安全文化，而不是親自審每一行 Code。
Q4：如果 Champion 離職了怎麼辦？
這正是為什麼每個團隊至少要有一位 Champion、公司整體要有多位 Champion 的原因。另外，Champion 累積的知識應該被文件化在知識庫中，而不是只存在個人腦中。建議每位 Champion 培養至少一位「備援」，就像值班制度一樣。
Q5：這跟之前文章提到的「威脅建模引導者」是同一個角色嗎？
是的！在威脅建模入門那篇文章中提到的「威脅建模引導者」，就是 Security Champion 的職責之一。Champion 是一個更全面的角色，威脅建模、安全 Code Review、工具結果判讀、安全教育——這些都是 Champion 的工作範疇。
八、Security Champion Onboarding Checklist
如果你已經決定要成為或指定 Security Champion，以下是一份可以直接使用的入職清單：
## Security Champion 新手入職 Checklist
### 第一週：認識角色
- [ ] 閱讀 Security Champion 職責定義文件
- [ ] 加入 #security-champions 頻道
- [ ] 認識資安團隊的聯絡窗口
- [ ] 了解公司目前使用的安全工具（SAST、DAST、SCA）
- [ ] 閱讀 SSDLC by 飛飛 的「什麼是 SSDLC」入門文章
### 第一個月：打基礎
- [ ] 完成 OWASP Top 10 概覽學習
- [ ] 在 OWASP Juice Shop 完成前 10 個挑戰
- [ ] 學會查看 CI/CD Pipeline 中的安全掃描報告
- [ ] 在一次 Code Review 中嘗試從安全角度提出建議
- [ ] 參加第一次 Security Champion 雙週會議
### 第二個月：開始實踐
- [ ] 獨立判讀一次 SAST 掃描結果（區分真陽性和誤報）
- [ ] 在 Sprint Planning 中提出至少一個安全考量
- [ ] 閱讀 SSDLC 系列的安全需求和安全編碼文章
- [ ] 建立或更新一份團隊的安全 Checklist
### 第三個月：分享與連結
- [ ] 在團隊內做一次 15 分鐘的安全分享
- [ ] 將一個學到的安全知識寫成文件，加入知識庫
- [ ] 嘗試為一個功能撰寫 Abuse Case
- [ ] 評估自己的學習進度，規劃下一階段目標九、結語：安全文化的最小可行單位，是一個願意多想一步的人
工具可以自動掃描、流程可以強制執行、政策可以寫得很漂亮——但真正讓安全在團隊裡生根發芽的，是人。
Security Champion 不是一個華麗的頭銜，而是一個簡單的承諾：「我願意在寫程式的同時，多想一步——這行 Code 安全嗎？這個設計會不會被攻擊者利用？這個錯誤訊息會不會洩露太多資訊？」
在 SSDLC 蓋房子的旅程中，我們學了怎麼寫安全需求、怎麼做威脅建模、怎麼安全編碼、怎麼做測試、怎麼強化系統。但所有這些知識，都需要有人在每一天的開發工作中去實踐。Security Champion 就是那個把知識變成行動的人。
回想一下你家社區裡那位熱心的鄰居——他不需要是消防員、不需要是保全專家，但因為他的存在，整個社區都更安全了一點。
你，願意成為你團隊的那個人嗎？
安全不是恐懼，而是創造的基礎。
當團隊裡有人願意為安全多想一步，安全文化就不再是政策文件裡的口號——而是每一次 Code Review、每一次 Sprint Planning、每一次部署中，自然而然發生的事。
延伸閱讀
- OWASP Security Champions Guide — OWASP 官方的 Security Champion 計畫指南
- OWASP Security Champions Playbook — 實戰手冊
- Security Champion Program Success Guide — 完整的成功計畫指南
- AWS Security Champion Knowledge Path — AWS 提供的 Security Champion 學習路徑
- OWASP SAMM — Security Assurance Maturity Model — 安全成熟度評估框架
- BSIMM — Building Security In Maturity Model — 軟體安全成熟度模型
- 系列文章：什麼是 SSDLC？讓安全融入開發的每個階段
- 系列文章：威脅建模入門：用 STRIDE 找出系統弱點
- 系列文章：SAST 靜態分析入門：讓工具幫你審程式碼
- 系列文章：CI/CD 安全整合：在 Pipeline 加入安全關卡