[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-nist-narrows-nvd-container-security-zh":3,"article-related-nist-narrows-nvd-container-security-zh":34,"series-industry-f3d6752c-0e52-48cc-a51f-25c30d3286b1":87},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":26,"views":30,"created_at":31,"published_at":32,"topic_cluster_id":33},"f3d6752c-0e52-48cc-a51f-25c30d3286b1","nist-narrows-nvd-container-security-zh","NIST縮減NVD後，容器資安怎麼辦","\u003Cp data-speakable=\"summary\">NIST開始縮減NVD補強範圍，容器資安團隊得重新調整評分、CPE比對與合規證據鏈。\u003C\u002Fp>\u003Cp>\u003Ca href=\"\u002Fnews\u002F2026-system-design-interview-prep-exponent-zh\">2026\u003C\u002Fa> 年 4 月 15 日，\u003Ca href=\"https:\u002F\u002Fwww.nist.gov\u002F\" target=\"_blank\" rel=\"noopener\">NIST\u003C\u002Fa> 公布新做法。它不再想把每一筆 CVE 都補到完整。\u003Ca href=\"https:\u002F\u002Fnvd.nist.gov\u002F\" target=\"_blank\" rel=\"noopener\">National Vulnerability Database\u003C\u002Fa> 會先挑重點處理。\u003C\u002Fp>\u003Cp>講白了，這代表容器團隊不能再把 NVD 當萬能答案。很多掃描器、SLA、稽核文件，都還靠 NVD 的 CVSS、CPE、CWE。現在這條鏈開始鬆了。\u003C\u002Fp>\u003Cp>這件事很現實。2025 年 NVD 大約補強了 42,000 筆 CVE。2026 年的 CVE 預估卻接近 59,500 筆。資料量還在衝，人工補強卻跟不上。\u003C\u002Fp>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>指標\u003C\u002Fth>\u003Cth>數值\u003C\u002Fth>\u003Cth>意義\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>NIST 新政策日期\u003C\u002Ftd>\u003Ctd>2026\u002F04\u002F15\u003C\u002Ftd>\u003Ctd>開始改成優先補強\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>未排程項目\u003C\u002Ftd>\u003Ctd>2026\u002F03\u002F01 前未補強 CVE\u003C\u002Ftd>\u003Ctd>舊紀錄可能要重算風險\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>2025 年補強量\u003C\u002Ftd>\u003Ctd>約 42,000 筆 CVE\u003C\u002Ftd>\u003Ctd>已經追不上輸入速度\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>2026 年預估量\u003C\u002Ftd>\u003Ctd>約 59,500 筆 CVE\u003C\u002Ftd>\u003Ctd>缺口還會繼續擴大\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch2>NIST 到底改了什麼\u003C\u002Fh2>\u003Cp>NIST 還是會發 CVE。只是，後面的補作業少很多。像 CVSS 分數、CPE 對應、CWE 分類，這些原本很靠 NVD 的欄位，現在不會每筆都補。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779320646443-5e1e.png\" alt=\"NIST縮減NVD後，容器資安怎麼辦\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>只有三類會優先處理。第一是 \u003Ca href=\"https:\u002F\u002Fwww.cisa.gov\u002Fknown-exploited-vulnerabilities-catalog\" target=\"_blank\" rel=\"noopener\">CISA KEV\u003C\u002Fa> 裡的漏洞。第二是美國聯邦政府用到的軟體。第三是 \u003Ca href=\"https:\u002F\u002Fwww.whitehouse.gov\u002Fbriefing-room\u002Fpresidential-actions\u002F2021\u002F05\u002F12\u002Fexecutive-order-on-improving-the-nations-cybersecurity\u002F\" target=\"_blank\" rel=\"noopener\">Executive Order 14028\u003C\u002Fa> 定義的 critical software。\u003C\u002Fp>\u003Cp>其他 CVE 會先進「Not Scheduled」。如果你想要補強，只能寫信問。問題是，NIST 沒給服務時程保證。這就很像叫你排隊，但沒說前面有幾個人。\u003C\u002Fp>\u003Cp>另外，NIST 也不再重複寫 CNA 已經提供的 CVSS 分數。這樣可以省工，但也讓 NVD 不再像以前那樣，像一個通吃的標準來源。\u003C\u002Fp>\u003Cul>\u003Cli>KEV、聯邦軟體、critical software 會優先補強。\u003C\u002Fli>\u003Cli>其他 CVE 先進 Not Scheduled。\u003C\u002Fli>\u003Cli>CNA 已有分數時，NIST 不再重抄。\u003C\u002Fli>\u003Cli>想補強只能寄信，但沒有 SLA。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>為什麼這次不是小改版\u003C\u002Fh2>\u003Cp>這不是臨時調整。這比較像 NIST 承認現實。CVE 數量一直往上跑，人工補強的速度根本不夠。資料庫還想保有品質，就只能縮小範圍。\u003C\u002Fp>\u003Cp>數字很直接。NIST 說，2020 到 2025 年，CVE 提交量成長了 263%。而 2026 年第一季，又比去年同期高出約三分之一。這種增幅，任何靠人工補資料的團隊都會很痛。\u003C\u002Fp>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.first.org\u002F\" target=\"_blank\" rel=\"noopener\">FIRST\u003C\u002Fa> 的預測也很硬。更多 CNA 加入了。更多開源專案自己揭露漏洞。更多掃描工具也挖出以前看不到的問題。資料只會越來越多。\u003C\u002Fp>\u003Cblockquote>\u003Cp>“Death by a thousand slops.”\u003C\u002Fp>\u003Cfooter>Daniel Stenberg，curl 創辦人\u003C\u002Ffooter>\u003C\u002Fblockquote>\u003Cp>這句話很毒，但很準。\u003Ca href=\"https:\u002F\u002Fcurl.se\u002F\" target=\"_blank\" rel=\"noopener\">curl\u003C\u002Fa> 的 Daniel Stenberg 早就被 AI 垃圾回報搞到快爆。另一頭，AI 也真的找出不少漏洞。兩邊一起來，審查隊列就會炸。\u003C\u002Fp>\u003Cp>\u003Ca href=\"\u002Ftag\u002Fdocker\">Docker\u003C\u002Fa> 提到，Stenberg 因為 AI 垃圾報告太多，關掉了 curl 的 HackerOne bounty。另一方面，\u003Ca href=\"\u002Ftag\u002Fanthropic\">Anthropic\u003C\u002Fa> 也說過，\u003Ca href=\"\u002Ftag\u002Fclaude\">Claude\u003C\u002Fa> 在研究中找到上千個 zero-day，還包含 FreeBSD NFS server 一個 17 年的未授權 RCE。\u003C\u002Fp>\u003Cul>\u003Cli>curl 的 bounty 開了 6.5 年後關掉。\u003C\u002Fli>\u003Cli>AI 垃圾回報讓 triage 變很難做。\u003C\u002Fli>\u003Cli>Anthropic 表示 Claude 找到上千個 zero-day。\u003C\u002Fli>\u003Cli>FreeBSD NFS server 還出現 17 年漏洞。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>容器資安為什麼最先中槍\u003C\u002Fh2>\u003Cp>容器環境很吃資料完整度。映像檔有 base layer、應用依賴、轉依賴。只要其中一個 CVE 沒補好，掃描器就可能漏掉，或直接顯示 UNKNOWN。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779320640778-8mpy.png\" alt=\"NIST縮減NVD後，容器資安怎麼辦\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>很多工具以前很依賴 CPE。問題是，CPE 對容器世界不夠貼。容器常常是套件、\u003Ca href=\"\u002Fnews\u002F5-docker-engine-versions-to-watch-2026-zh\">版本\u003C\u002Fa>、發行版、私有映像一起混。你用老方法硬套，命中率就會掉。\u003C\u002Fp>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fproducts\u002Fdocker-scout\" target=\"_blank\" rel=\"noopener\">Docker Scout\u003C\u002Fa> 的做法比較務實。Docker 說它會串 22 個 advisory sources。裡面有 NVD、CISA KEV、EPSS、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fadvisories\" target=\"_blank\" rel=\"noopener\">GitHub Advisory Database\u003C\u002Fa>，還有 13 個 Linux 發行版追蹤器。\u003C\u002Fp>\u003Cp>它也改用 PURL 來做比對，不只看 CPE。對容器來說，這種方式比較像實戰。因為你真正想知道的是：這個 image 裡有沒有那個套件。\u003C\u002Fp>\u003Cp>Docker 的 \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fproducts\u002Fdocker-hardened-images\" target=\"_blank\" rel=\"noopener\">Docker Hardened Images\u003C\u002Fa> 也補了另一層。它有 signed build attestations、CycloneDX 和 SPDX SBOM、OpenVEX、掃描結果。Docker 說這些來自 SLSA Build Level 3 pipeline，不太靠 NVD 完整度吃飯。\u003C\u002Fp>\u003Cul>\u003Cli>Docker Scout 串 22 個資料來源。\u003C\u002Fli>\u003Cli>它用 PURL，不只靠 CPE。\u003C\u002Fli>\u003Cli>Hardened Images 提供 SBOM 與 attestations。\u003C\u002Fli>\u003Cli>掃描結果可以直接跟映像檔綁在一起。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>合規團隊現在要補哪幾塊\u003C\u002Fh2>\u003Cp>如果你的流程還假設 NVD 會補齊所有資料，那現在就該改。先問自己，掃描器除了 NVD，還吃哪些來源。再問，CVSS 不見時，系統會不會直接卡住。\u003C\u002Fp>\u003Cp>第二個問題更麻煩。你的 SLA 是從 CVE 公布開始算，還是從 NVD 補強開始算。這兩種算法差很多。以前還能偷懶，現在不行了。\u003C\u002Fp>\u003Cp>合規文件也會受影響。\u003Ca href=\"https:\u002F\u002Fwww.fedramp.gov\u002F\" target=\"_blank\" rel=\"noopener\">FedRAMP\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.pcisecuritystandards.org\u002F\" target=\"_blank\" rel=\"noopener\">PCI DSS 4.0\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fcsrc.nist.gov\u002Fpublications\u002Fdetail\u002Fsp\u002F800-53\u002Frev-5\u002Ffinal\" target=\"_blank\" rel=\"noopener\">NIST SP 800-53\u003C\u002Fa>、SOC 2，這些都不完全依賴 NVD，但都要你說清楚風險依據。你不能只寫「等 NVD」。\u003C\u002Fp>\u003Cp>說真的，稽核最愛抓這種空白。工具說一套，政策寫一套，最後出事就很難圓。這次改動會逼很多團隊回頭補證據鏈。\u003C\u002Fp>\u003Cul>\u003Cli>FedRAMP 會看 CVSSv3，但可接受替代來源。\u003C\u002Fli>\u003Cli>PCI DSS 4.0 也會碰到外部掃描與 CVSS。\u003C\u002Fli>\u003Cli>SOC 2 和 DORA 偏原則導向。\u003C\u002Fli>\u003Cli>書面風險理由現在更重要。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>數據差異會讓採購更難\u003C\u002Fh2>\u003Cp>買工具的人也會更頭痛。以前你可能只問，這套掃描器有沒有接 NVD。現在不夠了。你要問，它是不是把 NVD 當唯一來源。\u003C\u002Fp>\u003Cp>如果一個 CVE 沒有 NVD 補強，有些工具就只會顯示 UNKNOWN。更糟的是，CPE 對不上，套件就像不存在。這不是理論問題，是會直接漏單。\u003C\u002Fp>\u003Cp>比較一下就很清楚。只靠 NVD 的工具，遇到缺資料時會卡。多來源工具，會把 advisory、EPSS、發行版資料一起看。對容器場景來說，後者比較像現在該有的樣子。\u003C\u002Fp>\u003Cp>Docker 的做法也很明白。它把漏洞資訊、SBOM、OpenVEX、映像簽章放在一起。這樣你追的是整個 image 的狀態，不是等一個外部資料庫慢慢補。\u003C\u002Fp>\u003Cul>\u003Cli>只看 NVD 的工具，缺資料時容易失真。\u003C\u002Fli>\u003Cli>多來源工具比較能補上空缺。\u003C\u002Fli>\u003Cli>EPSS 可幫你看可利用性，不只看分數。\u003C\u002Fli>\u003Cli>SBOM 和簽章能補證據鏈。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>這件事背後的產業脈絡\u003C\u002Fh2>\u003Cp>這次變動其實是整個漏洞生態的縮影。CVE 越來越多，不是因為世界突然變爛，而是揭露管道變多了。開源專案、雲端供應鏈、AI 輔助掃描，都在增加輸入量。\u003C\u002Fp>\u003Cp>問題在於，\u003Ca href=\"\u002Ftag\u002F資料治理\">資料治理\u003C\u002Fa>沒跟上。NVD 原本像一個中央整理站。現在它選擇先處理高風險項目。這很合理，但也代表其他人要自己補位。\u003C\u002Fp>\u003Cp>對台灣團隊來說，這不是美國政府內部文件而已。只要你有容器、CI\u002FCD、SBOM、合規報告，就會碰到。尤其是金融、SaaS、製造業雲端團隊，影響會很實際。\u003C\u002Fp>\u003Cp>我覺得最該改的，不是掃描器畫面，而是內部規則。你得先定義哪個來源算準，哪個時間點算開始，哪種缺資料要人工介入。規則沒寫清楚，後面一定吵。\u003C\u002Fp>\u003Ch2>容器團隊現在該怎麼做\u003C\u002Fh2>\u003Cp>先拿 10 筆最近的 CVE 來測。故意挑幾筆 NVD 沒補強的。看你的掃描器會不會漏，SLA 會不會停，報表會不會空白。這比開一場長會有用。\u003C\u002Fp>\u003Cp>再看政策文件。把「等待 NVD」這種模糊字眼刪掉。改成明確規則：沒有 NVD 時看哪個來源，沒有 CVSS 時怎麼分級，沒有 CPE 時怎麼比對。\u003C\u002Fp>\u003Cp>如果你管的是容器平台，最好把 SBOM、OpenVEX、簽章、掃描結果一起納入。這樣即使外部資料延遲，你還是能靠自己的資產資料做判斷。這才是現在比較穩的做法。\u003C\u002Fp>\u003Cp>我會直接下這個結論：NVD 不會消失，但它不再是唯一答案。下一次你\u003Ca href=\"\u002Fnews\u002F5-docker-desktop-updates-for-may-2026-zh\">更新\u003C\u002Fa>資安政策時，先把資料來源和例外流程寫死。不要等到稽核來敲門，才發現整條鏈都靠運氣。\u003C\u002Fp>","NIST開始縮減 NVD 的補強範圍，容器資安團隊得重新看待 CVSS、CPE 比對與合規證據鏈。","www.docker.com","https:\u002F\u002Fwww.docker.com\u002Fblog\u002Fnist-narrows-the-nvd-what-container-security-programs-should-reassess\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779320646443-5e1e.png","industry","zh","485a8f71-6e22-4130-8b38-11d4446995d5",[17,18,19,20,21,22,23,24,25],"NIST","NVD","container security","CVE","CVSS","CPE","SBOM","Docker Scout","合規",[27,28,29],"NIST 開始縮減 NVD 補強範圍，容器團隊不能再只靠單一來源。","CVSS、CPE、CWE 不完整時，掃描器、SLA、稽核證據都會受影響。","多來源資料、PURL、SBOM 和 OpenVEX 會變得更重要。",4,"2026-05-20T23:43:39.508496+00:00","2026-05-20T23:43:39.288+00:00","d05acb33-72ce-4c62-9389-34e5f8f228ca",{"tags":35,"relatedLang":46,"relatedPosts":50},[36,38,40,42,44],{"name":17,"slug":37},"nist",{"name":19,"slug":39},"container-security",{"name":21,"slug":41},"cvss",{"name":20,"slug":43},"cve",{"name":18,"slug":45},"nvd",{"id":15,"slug":47,"title":48,"language":49},"nist-narrows-nvd-container-security-en","NIST Narrows the NVD for Container Security","en",[51,57,63,69,75,81],{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"47541f42-33f6-4432-a673-3d93d8b88236","gemini-apple-developer-stack-zh","Gemini 進入 Apple 開發堆疊","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781062380898-pnpb.png","2026-06-10T03:32:34.147949+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"fac85234-56b6-42b5-904d-9e3faabd4a14","5-ai-coding-ides-real-workflows-zh","5 款 AI 編程 IDE，按工作流挑最省事","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781061495099-n7sg.png","2026-06-10T03:17:28.48076+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"1b99a2d6-9a07-4e29-9c7e-21cc94c7769e","devin-desktop-windsurf-agent-hub-zh","Devin Desktop 把 Windsurf 變成代理中樞","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781060576683-lxvs.png","2026-06-10T03:02:18.748963+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"0d604500-3a70-40ec-a70e-370f972a66ab","korea-nvidia-talks-ai-factory-push-zh","韓國與 Nvidia 對話，重點是 AI 工廠","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781057871797-7uxx.png","2026-06-10T02:17:21.099824+00:00",{"id":76,"slug":77,"title":78,"cover_image":79,"image_url":79,"created_at":80,"category":13},"173b8876-1867-4e0b-948f-27891d6b6364","openai-should-not-rush-its-ipo-just-to-win-the-ai-race-zh","OpenAI 不該為了搶 AI 賽道而急著 IPO","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781053365610-1hko.png","2026-06-10T01:02:19.886627+00:00",{"id":82,"slug":83,"title":84,"cover_image":85,"image_url":85,"created_at":86,"category":13},"3d7ff80a-4045-4b66-9e21-b6a8eb3b6f6d","openai-europe-privacy-policy-zh","OpenAI 歐洲隱私政策更新重點","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781052479369-yomr.png","2026-06-10T00:47:31.176745+00:00",[88,93,98,103,108,113,118,123,128,133],{"id":89,"slug":90,"title":91,"created_at":92},"ee073da7-28b3-4752-a319-5a501459fb87","ai-in-2026-what-actually-matters-now-zh","2026 AI 真正重要的事","2026-03-26T07:09:12.008134+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"83bd1795-8548-44c9-9a7e-de50a0923f71","trump-ai-framework-power-speech-state-preemption-zh","川普 AI 框架瞄準電力、言論與州權","2026-03-26T07:12:18.695466+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"ea6be18b-c903-4e54-97b7-5f7447a612e0","nvidia-gtc-2026-big-ai-announcements-zh","NVIDIA GTC 2026 重點拆解","2026-03-26T07:14:26.62638+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"4bcec76f-4c36-4daa-909f-54cd702f7c93","claude-users-spreading-out-and-getting-better-zh","Claude 用戶更分散，也更會用","2026-03-26T07:22:52.325888+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"bd903b15-2473-4178-9789-b7557816e535","openclaw-raises-hard-question-for-ai-models-zh","OpenClaw 逼問 AI 模型價值","2026-03-26T07:24:54.707486+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"eeac6b9e-ad9d-4831-8eec-8bba3f9bca6a","gap-google-gemini-checkout-fashion-search-zh","Gap 把結帳搬進 Gemini","2026-03-26T07:28:23.937768+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"0740e53f-605d-4d57-8601-c10beb126f3c","google-pushes-gemini-transition-to-march-2026-zh","Google 把 Gemini 轉換延到 2026 年 3…","2026-03-26T07:30:12.825269+00:00",{"id":124,"slug":125,"title":126,"created_at":127},"e660d801-2421-4529-8fa9-86b82b066990","metas-llama-4-benchmark-scandal-gets-worse-zh","Meta Llama 4 分數風波又擴大","2026-03-26T07:34:21.156421+00:00",{"id":129,"slug":130,"title":131,"created_at":132},"183f9e7c-e143-40bb-a6d5-67ba84a3a8bc","accenture-mistral-ai-sovereign-enterprise-deal-zh","Accenture 攜手 Mistral AI 賣主權 AI","2026-03-26T07:38:14.818906+00:00",{"id":134,"slug":135,"title":136,"created_at":137},"191d9b1b-768a-478c-978c-dd7431a38149","mistral-ai-faces-its-hardest-year-yet-zh","Mistral AI 迎來最硬的一年","2026-03-26T07:40:23.716374+00:00"]