SAST、SCA 與 Secret Scanning:每個 CI 管線最低限度的三層防線

每條 production 管線都需要三層自動掃描。少了其中之一,事故回顧時你就得花好幾個小時解釋「為什麼我們沒能更早發現?」

最低限度的三層——以及它們的理由

層級	用來偵測	常見工具
SAST	原始碼中的弱點 (SQLi、XSS、path traversal、insecure deserialization)	Semgrep、CodeQL、SonarQube
SCA	相依套件中的 CVE、license 違規	Trivy、Grype、Snyk、Dependency-Track
Secret scan	不小心 commit 的 API key、token、私鑰	Gitleaks、Trufflehog、GitHub secret scanning

SAST:從 Semgrep 開始

Semgrep 容易啟用,有大量開源規則集,規則語法接近真實程式碼。最小可行的 GitHub Actions workflow:

name: semgrep
on:
  pull_request:
  push:
    branches: [main]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    container: returntocorp/semgrep
    steps:
      - uses: actions/checkout@v4
      - run: semgrep ci --config=p/owasp-top-ten --baseline-ref=origin/main

兩個重要技巧:

Baseline diff scan:PR 上只擋新出現的 finding,舊 finding 進入有 owner 的 backlog。避免一啟用就全面 break build。
自訂規則:寫 5-10 條規則攔截內部 pattern (例如:log secret、繞過內部 client wrapper 直接呼叫 API)。這才是真正帶來差異化價值的部分。

SCA 與 SBOM:Trivy/Grype + Syft

在同一條管線中產生 CycloneDX SBOM 並掃描 CVE:

- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    format: cyclonedx-json
    output-file: sbom.cdx.json

name: Scan SBOM with Grype
uses: anchore/scan-action@v3
with:
sbom: sbom.cdx.json
fail-build: true
severity-cutoff: high

把 SBOM 推送到 OWASP Dependency-Track 以追蹤 long-tail:當新 CVE 公布時,儀表板會自動警示受影響的專案。SLA 政策參考:

有修補的 CRITICAL:7 天內修復。
有修補的 HIGH:30 天內修復。
MEDIUM/LOW:每季檢視,接受或排入 backlog。

Secret scanning:pre-commit + CI + 全 repo

三層:

Pre-commit hook 用 gitleaks protect:在開發者 local commit 時就擋下。
CI 掃描每個 PR:抓住繞過 hook 或從 web UI commit 的 secret。
定期全 repo 歷史掃描:找出仍躺在 git log 中的舊 secret。

當發現 secret 外洩時:

第 1 步——當作已外洩處理:立即輪換金鑰/token,不要寄望刪掉歷史就沒事。
第 2 步:稽核使用情況 (CloudTrail、Vault audit log) 看有無異常行為。
第 3 步:若 repo 是 public,用 BFG 或 git filter-repo 清理歷史。
第 4 步:加上 pre-commit 規則,讓相同 pattern 不再發生。

正確管理 secret

理想狀態:程式碼中永遠不含 secret,連密文也不行。選項:

Vault / AWS Secrets Manager / Azure Key Vault,對 DB、queue 使用 dynamic credential。
Mozilla SOPS 對 checkin git 的 secret 檔案加密,金鑰存在 KMS——適合 GitOps。
OIDC federation 串接 GitHub Actions 與雲端,完全擺脫 long-lived access key。

警告:警報疲勞

同時在 100 個 legacy repo 開三層掃描 = 第一天就有數千個 finding。後果:沒人處理,每個人都把它停掉。安全的策略:

啟用 baseline mode:只擋新 finding。
從高 severity (CRITICAL/HIGH) 開始,逐步下調門檻。
有一位 triage owner,在 24 小時內把 finding 派到正確的團隊。
唯一的 KPI 是依 severity 區分的 MTTR 儀表板,而不是已執行的掃描次數。

結論

SAST + SCA + Secret scanning 是這週你能啟用、最便宜也最有效的基線。從小規模開始——1 個 repo、1 個規則集、1 個 pre-commit hook——衡量 MTTR,逐步擴大。3-4 個月後,這三層能擋下大部分基礎類型的缺陷,讓資安團隊把精力集中在威脅模型、供應鏈與 runtime 上。