安全掃描如果只在上線前做一次，那它的作用大概跟許願差不多。漏洞是持續產生的，掃描也必須持續進行。
先講結論
安全掃描要放進 CI/CD 的早期階段，不是 release 前才補。SAST 看程式碼、SCA 看依賴、Container Scan 看映像、DAST 看跑起來的服務——每一層抓不同類型的問題。但比工具更重要的是流程：掃出來的東西誰負責修？多久要修完？這些沒定義清楚，掃描結果就只是一份沒人看的報告。
掃描類型：每層抓不同的鬼
SAST（靜態掃描）——不跑程式，直接掃 source code。能抓到 SQL injection、硬編碼密碼這類問題。速度快，適合放在 commit 階段。
SCA（依賴掃描）——掃你用的第三方套件有沒有已知漏洞。你的 code 沒問題，但你依賴的 npm 套件有 CVE？一樣會被打穿。
Container Scan——掃 Docker image 裡的 OS 套件跟 library。你的 base image 用 node:18，裡面的 OpenSSL 有漏洞？掃了才知道。
DAST（動態掃描）——對跑起來的服務做攻擊模擬。這是最接近真實攻擊者視角的掃描。
Secret Scan——抓 .env 被 commit、token 寫死、密碼出現在 README 這種低級但致命的錯誤。
放進 pipeline 的正確姿勢
不是所有掃描都放在同一個階段。按 pipeline 進度來排：
include:
- template: Security/SAST.gitlab-ci.yml
- template: Security/Dependency-Scanning.gitlab-ci.yml
- template: Security/Container-Scanning.gitlab-ci.yml
stages:
- test # SAST + SCA 放這裡
- build # build image
- security # container scan 放這裡
- deploy # 部署到 staging
# DAST 對 staging 跑SAST 跟 SCA 成本低、速度快，放最前面。DAST 需要一個跑起來的環境，放最後。
阻擋規則：不是所有漏洞都一樣嚴重
掃描結果如果動輒上百條，團隊會直接放棄。你需要分級處理：
- Critical / High：阻擋部署，必須修
- Medium：允許部署但建立追蹤 issue
- Low：紀錄但不阻擋
政策必須寫進 pipeline，不是寫在 wiki 上。寫在 wiki 上的規則不存在。
SBOM：你知道你的軟體裡有什麼嗎？
SBOM（Software Bill of Materials）是供應鏈安全的基礎。就像食品有成分表，你的軟體也應該要有。
# 用 CycloneDX 產生 SBOM
cyclonedx-npm --output-file sbom.json每次 release 都產生一份 SBOM，上傳到 artifact repository。哪天某個 library 爆出 CVE，你可以立刻查出哪些服務受影響，而不是全公司大搜索。
掃出來之後呢？
掃描只是起點。掃出一千條漏洞但沒人修，那跟沒掃一樣。
你需要：
- 修復 SLA——Critical 48 小時內修、High 一週內修
- 指派 owner——每個漏洞有明確的負責人
- 例外流程——有些漏洞確實無法立即修，但需要審批跟記錄
- 追蹤報表——漏洞趨勢是下降還是上升？
掃描工具最常見的結局是：剛導入的時候大家很認真修，三個月後報告堆成山，然後就沒有然後了。
延伸閱讀
安全掃描不是裝了工具就安全了，就像裝了煙霧偵測器不代表不會失火。偵測器響了之後你得去滅火。