Trong hai thập kỷ qua, NVD (Cơ sở dữ liệu Lỗ hổng Quốc gia) đã đóng vai trò là nền tảng thực tế cho công tác quản lý lỗ hổng. Các công cụ quét lỗ hổng, hệ thống SIEM, công cụ vá lỗi và các khung tuân thủ đều dựa trên giả định rằng khi một mã CVE xuất hiện trong NVD, các chuyên gia phân tích của NIST sẽ nhanh chóng bổ sung các điểm mức độ nghiêm trọng, bản đồ phiên bản sản phẩm và dữ liệu bối cảnh, giúp biến một mã CVE thô thành thông tin thực sự hữu ích.
Vào ngày 15 tháng 4 năm 2026, giả định đó chính thức không còn đáng tin cậy nữa.
NIST đã thông báo rằng NVD đang chuyển sang mô hình bổ sung thông tin dựa trên rủi ro. Hầu hết các CVE mới được nhập vào cơ sở dữ liệu sẽ không còn nhận được điểm CVSS do NIST bổ sung, không có bản đồ sản phẩm CPE và không có phân tích độc lập theo mặc định. Đối với các tổ chức có quy trình xử lý lỗ hổng phụ thuộc vào dữ liệu được NVD bổ sung, điều này tạo ra một vấn đề thực sự và ngày càng nghiêm trọng về phạm vi bao phủ. Đối với các nhà phát triển và nhà cung cấp sản phẩm bảo mật nhúng dữ liệu đó vào công cụ của họ, điều này đặt ra một câu hỏi còn gay gắt hơn: chính xác thì nguồn cấp dữ liệu của bạn đang cho bạn biết điều gì?
NVD không còn đủ khả năng theo kịp các lỗ hổng bảo mật được báo cáo
Theo thông báo chính thức từ NIST, số lượng báo cáo lỗ hổng bảo mật (CVE) đã tăng 263% trong giai đoạn từ năm 2020 đến năm 2025, và số lượng báo cáo trong quý đầu tiên của năm 2026 đã cao hơn gần một phần ba so với cùng kỳ năm trước.
Năm 2025, NIST đã cập nhật thông tin chi tiết cho gần 42.000 lỗ hổng CVE, tăng 45% so với bất kỳ năm nào trước đó. Tuy nhiên, sự gia tăng năng suất này vẫn chưa đủ để theo kịp số lượng báo cáo ngày càng tăng, dẫn đến việc phải thiết lập một hệ thống phân loại chính thức.
Kể từ ngày 15 tháng 4 năm 2026, NIST sẽ chỉ bổ sung thông tin chi tiết cho các lỗ hổng xuất hiện trong danh mục KVE (Các lỗ hổng đã biết bị khai thác) của CISA, phần mềm được chính phủ liên bang sử dụng, hoặc phần mềm được chỉ định là quan trọng theo Sắc lệnh hành pháp 14028. Tất cả các trường hợp còn lại sẽ được liệt kê trong NVD nhưng không có thông tin chi tiết do NIST bổ sung và sẽ không được xử lý ngay lập tức.
Do đó, gần 300.000 lỗ hổng bảo mật (CVE) tồn đọng được công bố trước ngày 1 tháng 3 năm 2026 đã được chuyển toàn bộ sang danh mục "Chưa có lịch trình".
Đối với các lỗ hổng bảo mật (CVE) không thuộc tiêu chí ưu tiên của NIST trong tương lai, điểm mức độ nghiêm trọng sẽ được xác định dựa trên thông tin do Cơ quan Đánh số CVE (CNA) tự báo cáo – thường là nhà cung cấp phần mềm bị ảnh hưởng – thay vì dựa trên phân tích độc lập của NIST. NIST cũng sẽ ngừng tính toán lại điểm mức độ nghiêm trọng khi CNA đã cung cấp điểm này.
Mọi công cụ quét lỗ hổng bảo mật lớn, mọi quy tắc tương quan SIEM, mọi điểm đánh giá rủi ro của bên thứ ba và mọi khung tuân thủ quy định từ PCI DSS đến FedRAMP đều phụ thuộc vào quy trình bổ sung dữ liệu của NVD.
Với bản cập nhật này, quy trình đó hiện đã chính thức bị thu hẹp, dẫn đến việc các lỗ hổng bảo mật (CVE) tiềm ẩn nguy hiểm có thể không được phân loại đúng cách hoặc không được phát hiện kịp thời.
Có một yếu tố thúc đẩy khác đáng được lưu ý, đó là việc giảm mức độ tinh vi của các mối đe dọa đang diễn ra song song với sự gia tăng nhanh chóng của việc phát hiện mối đe dọa nhờ sự hỗ trợ của trí tuệ nhân tạo.
Các mô hình trí tuệ nhân tạo (AI) tiên tiến và công cụ lập trình đang giúp giảm đáng kể rào cản trong việc phát hiện các lỗ hổng có thể bị khai thác và các đường tấn công phức tạp trong các ứng dụng, từ đó dẫn đến sự gia tăng đột biến trong số lượng lỗ hổng CVE được công bố. Vào tháng 2 năm 2026, Diễn đàn Các đội ứng phó sự cố và an ninh (FIRST) đã dự báo sẽ có thêm 50.000 lỗ hổng CVE được báo cáo trong năm 2026, một con số kỷ lục. Cơ sở hạ tầng xử lý dữ liệu hiện tại không đủ khả năng xử lý khối lượng này mà vẫn đảm bảo chất lượng như trước đây.
Tại sao các sản phẩm chỉ dựa trên NVD lại gặp vấn đề
Một bản ghi CVE thô thường bao gồm mã định danh, mô tả và các tài liệu tham khảo. Dữ liệu siêu dữ liệu dùng để điều khiển quá trình quản lý lỗ hổng tự động trước đây được cung cấp bởi các chuyên gia phân tích của NVD. Dữ liệu này bao gồm các điểm đánh giá mức độ nghiêm trọng CVSS đã được xác thực độc lập, bản đồ sản phẩm CPE và phân loại điểm yếu CWE.
Nhưng chính yếu tố "bổ sung thông tin" mới là điều khiến một CVE trở nên có thể xử lý được. Nếu thiếu yếu tố này, các quy trình làm việc phụ thuộc vào nó sẽ bị suy giảm theo những cách có thể dự đoán được.
Việc xếp hạng mức độ ưu tiên dựa trên CVSS đang mất dần hiệu quả
Khi một công cụ quét lỗ hổng hoặc công cụ vá lỗi yêu cầu điểm mức độ nghiêm trọng do NVD cung cấp nhưng không tìm thấy, lỗ hổng đó có thể được hiển thị là "mức độ nghiêm trọng không xác định", nằm ngoài phạm vi của các chính sách vá lỗi dựa trên SLA, hoặc bị hạ mức ưu tiên.
Bản cập nhật tháng 4 năm 2026 của NIST đã xác nhận rằng:
- Các lỗ hổng bảo mật (CVE) không thuộc các tiêu chí ưu tiên mới sẽ không tự động được chấm điểm độc lập
- NIST sẽ không còn tự tính điểm CVSS nữa khi một CNA đã cung cấp điểm này (ngay cả khi CNA đó chính là nhà cung cấp phần mềm bị ảnh hưởng)
Việc lập bản đồ CPE không đầy đủ hoặc thiếu sót dẫn đến việc phát hiện CVE kém hiệu quả
Theo tài liệu chính thức của NVD, việc xác định sản phẩm được coi là một phần cơ bản của quá trình làm giàu dữ liệu, bởi vì nó cho phép người dùng kiểm tra một cách tự động xem liệu một lỗ hổng đã biết có ảnh hưởng đến các sản phẩm trong môi trường của họ hay không.
Nếu các bản đồ CPE bị thiếu, không đầy đủ hoặc bị chậm trễ, các công cụ chủ yếu dựa vào việc khớp CPE có thể không hiển thị kết quả khớp hoặc hiển thị kết quả muộn.
Các nhà cung cấp sản phẩm bảo mật là một trong những đối tượng bị ảnh hưởng nặng nề nhất, bởi vì các sản phẩm của họ thường phụ thuộc vào việc đối chiếu thiết bị đầu cuối (CPE) và việc bổ sung thông tin CVE. Các công cụ quản lý bản vá, bảo vệ điểm cuối, kiểm soát truy cập mạng và quản lý tài sản đều dựa vào thông tin lỗ hổng chính xác để xác định những gì bị ảnh hưởng, mức độ nghiêm trọng của vấn đề và các biện pháp cần thực hiện tiếp theo.
Đối với các nhóm đang phát triển các sản phẩm bảo mật mới, việc chỉ dựa vào NVD ngay từ đầu đồng nghĩa với việc xây dựng trên một nền tảng có thể đã tồn tại những lỗ hổng quan trọng: phạm vi bao phủ các lỗ hổng zero-day còn hạn chế, thiếu thông tin bổ sung cho một tỷ lệ ngày càng tăng các lỗ hổng CVE, cùng với chu kỳ cập nhật có thể khó theo kịp tốc độ phát hiện và khai thác lỗ hổng do trí tuệ nhân tạo (AI) mang lại.
Đối với các nhóm đã có khả năng vá lỗi hoặc khắc phục sự cố, rủi ro có thể khác biệt nhưng cũng không kém phần quan trọng. Hiệu quả của một công cụ khắc phục sự cố phụ thuộc hoàn toàn vào chất lượng thông tin về lỗ hổng bảo mật mà nó nhận được. Nếu thông tin đó không đầy đủ, bị chậm trễ hoặc quá phụ thuộc vào dữ liệu bổ sung từ NVD, các quy trình làm việc tiếp theo có thể bỏ sót các sản phẩm bị ảnh hưởng, hạ thấp mức độ ưu tiên đối với các lỗ hổng có mức độ nghiêm trọng chưa xác định, hoặc không kịp thời xử lý trước khi mức độ rủi ro gia tăng.
Nếu những sản phẩm đó mắc phải những điểm yếu của NVD, thì những điểm yếu đó có thể sẽ ảnh hưởng đến tất cả các khách hàng ở các khâu sau.
Đó chính là khoảng trống mà Khung đánh giá lỗ hổng OESIS được thiết kế để giải quyết: giúp các nhóm phát triển sản phẩm bảo mật củng cố thông tin tình báo về lỗ hổng mà không chỉ dựa vào việc bổ sung dữ liệu từ NVD.
Cách OPSWAT khác biệt của OPSWAT
OPSWAT mô-đun Đánh giá Lỗ hổng của Khung OESIS dành riêng cho các nhà phát triển sản phẩm bảo mật, những người cần dữ liệu về lỗ hổng đáng tin cậy và có thể áp dụng được tích hợp sẵn trong các công cụ của họ.
Thiết kế xoay quanh khoảng trống
Mô-đun này tổng hợp dữ liệu từ nhiều nguồn, thay vì chỉ dựa vào một nguồn duy nhất.
Giải pháp này tận dụng nhiều nguồn thông tin về lỗ hổng bảo mật thương mại và mã nguồn mở để đảm bảo phạm vi bao quát kịp thời và chính xác đối với hàng trăm nhà cung cấp và ứng dụng.
Danh mục lỗ hổng OESIS hiện bao gồm hơn 65.000 mã CVE riêng biệt và hơn 150.000 trường hợp lỗ hổng, đồng thời được cập nhật liên tục — nhiều lần mỗi ngày — thay vì phải chờ các chu kỳ xử lý của NVD.
Một thang điểm mức độ nghiêm trọng độc quyền vượt trội hơn CVSS, cung cấp nhiều thông tin bối cảnh hơn.
Dữ liệu về lỗ hổng bảo mật OPSWAT bao gồm Chỉ sốOPSWAT (OPSWAT Severity Score) – một thang điểm độc quyền vượt trội so với thang điểm CVSS cơ bản nhờ tích hợp các yếu tố bổ sung, bao gồm mức độ phổ biến của CVE, nguy cơ bị khai thác và vòng đời của CVE.
Trong bối cảnh ngày càng có nhiều điểm số CVSS được chính các tổ chức đánh giá rủi ro (CNA) tự báo cáo, lớp phân tích độc lập này có thể giúp các sản phẩm bảo mật cung cấp cho người dùng những tín hiệu ưu tiên có cơ sở vững chắc hơn.
Dịch vụ thông tin về lỗ hổng bảo mật OESIS hỗ trợ hai phương thức tích hợp, mà không cần quá trình triển khai phức tạp:
- Dữ liệu danh mục: So sánh dữ liệu lỗ hổng OESIS với danh mục phần mềm hiện có của bạn ngay trên máy chủ — không cần cài đặt trình điều khiển trên thiết bị đầu cuối. Các sản phẩm hiện có hỗ trợ tính năng quản lý danh mục phần mềm có thể sử dụng dữ liệu OESIS để phát hiện lỗ hổng trên các tài sản được quản lý.
- Bộ công cụSoftware (Endpoint )Endpoint : Tích hợp trực tiếp Khung OESIS vào sản phẩm của bạn để vulnerability detection theo thời gian thực ngay trên thiết bị. Rất phù hợp cho các sản phẩm bảo mật chạy trên thiết bị đầu cuối
Nghiên cứu về lỗ hổng bảo mật nội bộ
Đội ngũ nghiên cứu mối đe dọa nội bộ OPSWAT, Unit 515, liên tục tiến hành các hoạt động nghiên cứu an ninh tấn công, mô phỏng tình huống đối đầu, thử nghiệm nâng cao và công bố có trách nhiệm trên cơ sở hạ tầng trọng yếu phần mềm doanh nghiệp. Đội ngũ này đã phát hiện và báo cáo hơn 50 lỗ hổng zero-day, bao gồm các phát hiện nghiêm trọng trong các phần mềm được triển khai rộng rãi như các nền tảng ICS/OT (ví dụ: PLC Delta) và các nền tảng tích hợp trí tuệ nhân tạo (AI).
Kết quả cuối cùng đối với các nhà phát triển sản phẩm bảo mật là các công cụ của họ vẫn có thể duy trì phạm vi phát hiện lỗ hổng rộng hơn ngay cả khi phạm vi mở rộng dữ liệu của NVD bị thu hẹp — mà không yêu cầu khách hàng phải chấp nhận việc giảm khả năng theo dõi hoặc phải thực hiện các biện pháp khắc phục thủ công.
Phát hiện + Khắc phục: Quy trình khép kín
Việc phát hiện giúp xác định các lỗ hổng. Việc khắc phục giúp giải quyết các lỗ hổng đó. Khi kết hợp với nhau, hai quá trình này giúp giảm thiểu rủi ro ở mức tối đa. Giải pháp Đánh giá Lỗ hổng OESIS đảm nhận việc phát hiện và xếp hạng mức độ ưu tiên. Patch Management OESIS dành cho các nhóm muốn tích hợp cả hai tính năng này trong cùng một khung nền:
- Phát hiện: Các ứng dụng có lỗ hổng, phù hợp về phiên bản, OPSWAT và được KEV đánh dấu
- Xếp hạng ưu tiên: OPSWAT giúp xác định những vấn đề cần khắc phục trước tiên, dựa trên các tín hiệu khai thác thực tế
- Giải pháp khắc phục: Hệ thống hiện tại của bạn có thể xử lý dữ liệu đầu ra từ OESIS — hoặc OESIS Patch Management tự động cập nhật bản vá, áp dụng các phiên bản bắt buộc hoặc chặn quyền truy cập trực tiếp
- Xác minh: OESIS tiến hành quét lại sau khi khắc phục sự cố để đảm bảo thiết bị đầu cuối không còn bị nhiễm virus trước khi khôi phục quyền truy cập
Việc phát hiện mà không khắc phục chỉ là một báo cáo. Việc phát hiện kèm theo khắc phục mới là rủi ro đã được giải quyết. OESIS hướng đến việc mang lại cả hai yếu tố này cho sản phẩm của bạn, giúp hoàn thiện chu trình phát hiện và khắc phục nhanh chóng hơn, từ đó đáp ứng hiệu quả hơn trước các mối đe dọa phát triển với tốc độ của trí tuệ nhân tạo.
Các lỗ hổng bảo mật liên quan đến AI-Speed cần được phát hiện bằng AI-Speed
Các nhà sản xuất sản phẩm bảo mật không thể coi thông tin về lỗ hổng bảo mật như một yếu tố phụ thuộc phía sau hệ thống với tốc độ cập nhật chậm chạp. Khi số lượng CVE ngày càng gia tăng và việc bổ sung thông tin trở nên thiếu nhất quán, các nhóm phát triển sản phẩm cần có giải pháp để đảm bảo các quy trình phát hiện, xếp hạng mức độ ưu tiên và khắc phục sự cố luôn phù hợp với thực tế rủi ro trong môi trường thực tế.
Đó chính là lúc Giải pháp Đánh giá Lỗ hổng Bảo mật OESIS Framework phát huy tác dụng. Giải pháp này mang đến cho các nhà phát triển sản phẩm một phương pháp thiết thực để mở rộng phạm vi phát hiện lỗ hổng mà không cần phải xây dựng lại hệ thống quản lý thiết bị đầu cuối hay quy trình khắc phục từ đầu. Đối với các đội ngũ đang ra mắt sản phẩm mới, giải pháp này giúp thiết lập phạm vi phát hiện đáng tin cậy ngay từ sớm. Đối với các đội ngũ đang cải tiến sản phẩm hiện có, giải pháp này cung cấp một phương thức thuận tiện hơn để so sánh phạm vi phát hiện, xác thực các cải tiến và quyết định hướng đi cho việc tích hợp sâu hơn.
