如果你曾經需要根據合規框架檢查程式碼或基礎架構，你一定知道流程：有人得讀 100 頁的 PDF，再讀你的程式碼庫，然後做出判斷。這既緩慢又不一致，而且無法自動化。

所以我建立了一條真正的解決管道。

問題

CMMC Level 1 與 NIST SP 800-171 Rev 2 是小型國防承包商及政府相關企業最常需要符合的兩大合規框架。這兩者都只以密集的法規文字形式存在，沒有官方的機器可讀版本。

這代表每次合規檢查都是手動的。每個審查基礎架構的 AI 編碼助理都完全沒有內建對這些要求的認知。每條 CI/CD 管道不是完全跳過合規檢查，就是得靠人記得去查。

** 我做了什麼 **

一個 Python 管道，功能如下：

  1. 抓取真正的法規來源資料——NIST 官方 CPRT 匯出的 SP 800-171，以及 48 CFR § 52.204-21 的逐字文字（CMMC Level 1）
  2. 將其正規化成結構化的 SQLite 綱要
  3. 為每個控制項目產生一條 JSON 規則，並附上機器可執行的指示

以下是一個實際規則的範例：

\json
{
"rule_id": "nist_sp_800-171_rev_2_3.1.1",
"framework": "NIST SP 800-171 Rev 2",
"control_id": "3.1.1",
"title": "ACCESS CONTROL — 3.1.1",
"requirement": "Limit system access to authorized users, processes acting on behalf of authorized users, and devices.",
"agent_guidance": "When generating or reviewing code/infrastructure, ensure compliance with NIST SP 800-171 Rev 2 control 3.1.1. Flag any implementation that does not satisfy: Limit system access to authorized users, processes acting on behalf of authorized users, and devices.",
"generated_at": "2026-07-15T16:42:56.026218+00:00"
}
\\

其中 agent_guidance 欄位最有趣——它是專門寫來直接放入 AI 編碼代理系統提示詞，作為合規護欄。

三種實際用法

1. AI 編碼代理系統提示詞

\`python
import json

with open("nist_800-171_rules.json") as f:
rules = json.load(f)

guardrails = "\n".join(r["agent_guidance"] for r in rules)
system_prompt = f"Apply these compliance rules when writing or reviewing code:\n{guardrails}"
`\

2. CI/CD 合規門檻——將規則逐一放入管道步驟，標記觸及相關系統但未處理適用控制項的 PR，並使用 rule_id 作為追蹤例外狀況的穩定參考。

3. GRC 平台匯入——大多數 GRC 工具都有自己的框架對應；control_id 提供乾淨的 join key。

建立管道時學到的教訓

最困難的部分不是規則產生，而是來源資料。NIST 的 CPRT REST API 會對直接自動化存取回傳 403，因此必須先從其目錄手動匯出。此外，其 JSON 綱要在不同版本間確實不一致——我曾遇到一個 bug：因為 CVSS v3 把 baseSeverity 嵌在 cvssData 裡，而 CVSS v2 則是同層欄位，導致嚴重性資料連續數週默默預設為「UNKNOWN」。典型的「資料看起來沒問題，直到實際檢查才發現」的 bug。

未來發展

最後我得到了涵蓋兩個框架的 125 條規則——完整涵蓋，而非抽樣。我已把完整的輸出（兩個 JSON 檔案）打包成一次性授權，供不想自己建置管道的人直接取得成品資料集：[link]。但老實說，對我來說更有趣的是這個模式本身——把靜態的法規文字轉成 AI 代理真正能推理的東西，而非讓人類去記得檢查的文件。

好奇是否有人也針對其他框架（如 SOC 2、ISO 27001、HIPAA）處理過合規即程式碼——歡迎在留言區分享解析方法的比較。