● 前言

在前一篇我們聊到 DevSecOps 的核心是 「安全左移 (Shift Left)」。
那麼，這個概念要怎麼在日常開發流程中真正落地呢？

傳統的軟體安全檢查，往往是在開發完成、甚至上線前才進行，這樣的模式容易導致：
🔹 問題發現太晚，修復成本高
🔹 影響產品交期，甚至迫使團隊「帶病上線」

因此，近年 DevSecOps 與敏捷開發的實踐中，出現了一個核心思維：
Shift Left —— 將安全檢查往「更早期」移動。

● 什麼是 Shift Left？

定義：將測試與安全檢查從傳統的後期（測試/上線）階段，前移至開發初期。

● 為什麼要在開發階段就導入安全檢查？

• 降低修復成本
  研究指出：在需求階段修正 bug，成本最低；到上線後再修，成本可能放大 30 倍。

• 縮短回饋迴路
  開發者在寫程式的同時收到靜態分析工具提醒，比等到部署才發現漏洞有效率得多。

• 強化安全文化
  讓工程師對安全負責，而不是交給「安全部門」最後把關。

● 常見的實踐方式

1. 早期代碼審查（Code Review with Security in Mind）

Pull Request 流程中，除了可讀性/效能，也檢查：

• 是否有硬編碼密碼？
• SQL Injection 風險？
• 輸入驗證不足？

🔧 工具：GitHub Advanced Security、Gitea/GitLab Merge Request Template + 安全檢查清單

2. 靜態程式碼安全分析（SAST）

在開發階段使用工具自動檢查常見漏洞：

• Secret 泄露（例如 .env 裡的金鑰）
• 未處理的例外
• 使用過期的 API

🔧 工具：Semgrep、CodeQL、Gitleaks

3. 依賴與供應鏈安全檢查

在 CI 中加入依賴庫掃描：

• 檢查 package.json、requirements.txt、pom.xml 是否有高風險套件

🔧 工具：Trivy、Snyk、Dependabot

4. 自動化安全測試（DAST / API Test）

在 CI Pipeline 中跑自動化安全測試，而不是等到正式上線：

• API 漏洞測試（ZAP、Burp Suite）
• 基本 OWASP Top 10 檢查
• 測試腳本可在 staging 環境 持續執行

5. CI 驗證與強制策略（Policy as Code）

在 CI/CD 中，若安全測試失敗，就阻止 Merge 或 Deploy。

🔧 工具：OPA / Gatekeeper、GitHub Actions workflow

● 總結

Shift Left 不是單一工具，而是一種 思維改變：

• 安全與品質不再是最後的檢查項，而是開發過程的一部分
• 工具與文化並重：自動化檢查提供效率，團隊共識提供持續性

👉 下一篇：Day 24｜SAST 靜態程式碼分析：CI Pipeline 中的自動安全檢查