NIST縮減NVD後，容器資安怎麼辦
NIST開始縮減 NVD 的補強範圍，容器資安團隊得重新看待 CVSS、CPE 比對與合規證據鏈。
NIST開始縮減NVD補強範圍，容器資安團隊得重新調整評分、CPE比對與合規證據鏈。
2026 年 4 月 15 日，NIST 公布新做法。它不再想把每一筆 CVE 都補到完整。National Vulnerability Database 會先挑重點處理。
講白了，這代表容器團隊不能再把 NVD 當萬能答案。很多掃描器、SLA、稽核文件，都還靠 NVD 的 CVSS、CPE、CWE。現在這條鏈開始鬆了。
這件事很現實。2025 年 NVD 大約補強了 42,000 筆 CVE。2026 年的 CVE 預估卻接近 59,500 筆。資料量還在衝，人工補強卻跟不上。
| 指標 | 數值 | 意義 |
|---|---|---|
| NIST 新政策日期 | 2026/04/15 | 開始改成優先補強 |
| 未排程項目 | 2026/03/01 前未補強 CVE | 舊紀錄可能要重算風險 |
| 2025 年補強量 | 約 42,000 筆 CVE | 已經追不上輸入速度 |
| 2026 年預估量 | 約 59,500 筆 CVE | 缺口還會繼續擴大 |
NIST 到底改了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
NIST 還是會發 CVE。只是，後面的補作業少很多。像 CVSS 分數、CPE 對應、CWE 分類，這些原本很靠 NVD 的欄位，現在不會每筆都補。
只有三類會優先處理。第一是 CISA KEV 裡的漏洞。第二是美國聯邦政府用到的軟體。第三是 Executive Order 14028 定義的 critical software。
其他 CVE 會先進「Not Scheduled」。如果你想要補強，只能寫信問。問題是，NIST 沒給服務時程保證。這就很像叫你排隊，但沒說前面有幾個人。
另外，NIST 也不再重複寫 CNA 已經提供的 CVSS 分數。這樣可以省工，但也讓 NVD 不再像以前那樣，像一個通吃的標準來源。
- KEV、聯邦軟體、critical software 會優先補強。
- 其他 CVE 先進 Not Scheduled。
- CNA 已有分數時，NIST 不再重抄。
- 想補強只能寄信，但沒有 SLA。
為什麼這次不是小改版
這不是臨時調整。這比較像 NIST 承認現實。CVE 數量一直往上跑，人工補強的速度根本不夠。資料庫還想保有品質，就只能縮小範圍。
數字很直接。NIST 說，2020 到 2025 年，CVE 提交量成長了 263%。而 2026 年第一季，又比去年同期高出約三分之一。這種增幅，任何靠人工補資料的團隊都會很痛。
FIRST 的預測也很硬。更多 CNA 加入了。更多開源專案自己揭露漏洞。更多掃描工具也挖出以前看不到的問題。資料只會越來越多。
“Death by a thousand slops.”
Daniel Stenberg，curl 創辦人
這句話很毒，但很準。curl 的 Daniel Stenberg 早就被 AI 垃圾回報搞到快爆。另一頭，AI 也真的找出不少漏洞。兩邊一起來，審查隊列就會炸。
Docker 提到，Stenberg 因為 AI 垃圾報告太多，關掉了 curl 的 HackerOne bounty。另一方面，Anthropic 也說過，Claude 在研究中找到上千個 zero-day，還包含 FreeBSD NFS server 一個 17 年的未授權 RCE。
- curl 的 bounty 開了 6.5 年後關掉。
- AI 垃圾回報讓 triage 變很難做。
- Anthropic 表示 Claude 找到上千個 zero-day。
- FreeBSD NFS server 還出現 17 年漏洞。
容器資安為什麼最先中槍
容器環境很吃資料完整度。映像檔有 base layer、應用依賴、轉依賴。只要其中一個 CVE 沒補好，掃描器就可能漏掉，或直接顯示 UNKNOWN。
很多工具以前很依賴 CPE。問題是，CPE 對容器世界不夠貼。容器常常是套件、版本、發行版、私有映像一起混。你用老方法硬套，命中率就會掉。
Docker Scout 的做法比較務實。Docker 說它會串 22 個 advisory sources。裡面有 NVD、CISA KEV、EPSS、GitHub Advisory Database，還有 13 個 Linux 發行版追蹤器。
它也改用 PURL 來做比對，不只看 CPE。對容器來說，這種方式比較像實戰。因為你真正想知道的是：這個 image 裡有沒有那個套件。
Docker 的 Docker Hardened Images 也補了另一層。它有 signed build attestations、CycloneDX 和 SPDX SBOM、OpenVEX、掃描結果。Docker 說這些來自 SLSA Build Level 3 pipeline，不太靠 NVD 完整度吃飯。
- Docker Scout 串 22 個資料來源。
- 它用 PURL，不只靠 CPE。
- Hardened Images 提供 SBOM 與 attestations。
- 掃描結果可以直接跟映像檔綁在一起。
合規團隊現在要補哪幾塊
如果你的流程還假設 NVD 會補齊所有資料，那現在就該改。先問自己，掃描器除了 NVD，還吃哪些來源。再問，CVSS 不見時，系統會不會直接卡住。
第二個問題更麻煩。你的 SLA 是從 CVE 公布開始算，還是從 NVD 補強開始算。這兩種算法差很多。以前還能偷懶，現在不行了。
合規文件也會受影響。FedRAMP、PCI DSS 4.0、NIST SP 800-53、SOC 2，這些都不完全依賴 NVD，但都要你說清楚風險依據。你不能只寫「等 NVD」。
說真的，稽核最愛抓這種空白。工具說一套，政策寫一套，最後出事就很難圓。這次改動會逼很多團隊回頭補證據鏈。
- FedRAMP 會看 CVSSv3，但可接受替代來源。
- PCI DSS 4.0 也會碰到外部掃描與 CVSS。
- SOC 2 和 DORA 偏原則導向。
- 書面風險理由現在更重要。
數據差異會讓採購更難
買工具的人也會更頭痛。以前你可能只問，這套掃描器有沒有接 NVD。現在不夠了。你要問，它是不是把 NVD 當唯一來源。
如果一個 CVE 沒有 NVD 補強，有些工具就只會顯示 UNKNOWN。更糟的是，CPE 對不上，套件就像不存在。這不是理論問題，是會直接漏單。
比較一下就很清楚。只靠 NVD 的工具，遇到缺資料時會卡。多來源工具，會把 advisory、EPSS、發行版資料一起看。對容器場景來說，後者比較像現在該有的樣子。
Docker 的做法也很明白。它把漏洞資訊、SBOM、OpenVEX、映像簽章放在一起。這樣你追的是整個 image 的狀態，不是等一個外部資料庫慢慢補。
- 只看 NVD 的工具，缺資料時容易失真。
- 多來源工具比較能補上空缺。
- EPSS 可幫你看可利用性，不只看分數。
- SBOM 和簽章能補證據鏈。
這件事背後的產業脈絡
這次變動其實是整個漏洞生態的縮影。CVE 越來越多，不是因為世界突然變爛，而是揭露管道變多了。開源專案、雲端供應鏈、AI 輔助掃描，都在增加輸入量。
問題在於，資料治理沒跟上。NVD 原本像一個中央整理站。現在它選擇先處理高風險項目。這很合理，但也代表其他人要自己補位。
對台灣團隊來說，這不是美國政府內部文件而已。只要你有容器、CI/CD、SBOM、合規報告，就會碰到。尤其是金融、SaaS、製造業雲端團隊，影響會很實際。
我覺得最該改的，不是掃描器畫面，而是內部規則。你得先定義哪個來源算準，哪個時間點算開始，哪種缺資料要人工介入。規則沒寫清楚，後面一定吵。
容器團隊現在該怎麼做
先拿 10 筆最近的 CVE 來測。故意挑幾筆 NVD 沒補強的。看你的掃描器會不會漏，SLA 會不會停，報表會不會空白。這比開一場長會有用。
再看政策文件。把「等待 NVD」這種模糊字眼刪掉。改成明確規則：沒有 NVD 時看哪個來源，沒有 CVSS 時怎麼分級，沒有 CPE 時怎麼比對。
如果你管的是容器平台，最好把 SBOM、OpenVEX、簽章、掃描結果一起納入。這樣即使外部資料延遲，你還是能靠自己的資產資料做判斷。這才是現在比較穩的做法。
我會直接下這個結論：NVD 不會消失，但它不再是唯一答案。下一次你更新資安政策時，先把資料來源和例外流程寫死。不要等到稽核來敲門，才發現整條鏈都靠運氣。