北京
如果你曾經(jīng)對著數(shù)百頁合規(guī)文檔逐行比對代碼，就會明白那種往復(fù)核查的無力感。CMMC Level 1 和 NIST SP 800-171 Rev 2，這兩套聯(lián)邦合規(guī)框架是不少國防承包商繞不開的門檻，但它們長年只以密集的法規(guī)文本存在，沒有官方提供的機(jī)器可讀版本。這帶來一個直接后果：每一次合規(guī)檢查全靠人工，AI 編碼助手拿不到任何合規(guī)意識，CI/CD 管道要么跳過合規(guī)關(guān)閘，要么靠人硬記規(guī)則。
一位開發(fā)者決定結(jié)束這套流程，他搭建了一條 Python 管道直取真實(shí)監(jiān)管源——NIST 官方 CPRT 導(dǎo)出數(shù)據(jù)中的 SP 800-171，以及 48 CFR § 52.204-21 的文字版——然后把這些條文歸一化裝入 SQLite，為每一個控制項(xiàng)生成一條帶操作指令的 JSON 規(guī)則。以控制項(xiàng) 3.1.1 為例，生成的 JSON 里除了 control_id 和原文要求，還有一個 agent_guidance 字段，寫著：“在編寫或?qū)彶榇a/基礎(chǔ)設(shè)施時，確保符合 NIST SP 800-171 Rev 2 控制項(xiàng) 3.1.1。對未滿足‘將系統(tǒng)訪問限制于授權(quán)用戶、代表授權(quán)用戶的進(jìn)程以及設(shè)備’的任何實(shí)現(xiàn)，都標(biāo)記出來。”
這個 agent_guidance 字段就是關(guān)鍵——它被設(shè)計(jì)成可以直接塞進(jìn) AI 編碼代理的系統(tǒng)提示，成為一條可執(zhí)行的合規(guī)護(hù)欄。作者給出了三種直接可用的方式：第一種，從 JSON 文件里抽取所有規(guī)則的 agent_guidance，拼入系統(tǒng)提示，讓生成或?qū)彶榇a時自動掛上這些約束；第二種，寫成 CI/CD 管道步驟，逐條掃描 PR 里涉及的系統(tǒng)，用 rule_id 作為穩(wěn)定引用追蹤合規(guī)例外；第三種，基于 control_id 與現(xiàn)有 GRC 平臺做映射導(dǎo)入，省掉手工對照的重復(fù)勞動。
藏在管道搭建背后最棘手的部分，反而不是規(guī)則生成，而是源數(shù)據(jù)本身。NIST 的 REST API 對自動化直接訪問返回 403，得先手動從目錄里導(dǎo)出文件。更麻煩的是不同版本間的 JSON schema 并不一致——作者說，有一個 bug 讓嚴(yán)重程度數(shù)據(jù)默默默認(rèn)成了“UNKNOWN”好幾周，原因就是 CVSS v3 把 baseSeverity 嵌套在 cvssData 里的結(jié)構(gòu)，和前代定義對不上。這條管道之所以能做出來，很大程度上拼的是對數(shù)據(jù)格式不一致的死磕。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
