cvENGINE: hợp nhất kiểm kê bề mặt tấn công và bằng chứng CVE cho SOC

cvENGINE là công cụ mã nguồn mở, tự lưu trữ, kết hợp khám phá tài sản, đối sánh CVE và kiểm tra xác thực chỉ đọc. Với SOC, điểm đáng chú ý là đưa ngữ cảnh tài sản, mức ưu tiên và bằng chứng vào cùng một quy trình.

Một CVE đang bị khai thác xuất hiện trong nguồn tin tình báo mối đe dọa. Câu hỏi quan trọng với SOC không chỉ là “CVE này nghiêm trọng đến đâu?”, mà là: tổ chức có đang phơi lộ đúng sản phẩm và phiên bản bị ảnh hưởng không, và bằng chứng đã đủ để hành động chưa?

cvENGINE là một dự án mã nguồn mở, tự lưu trữ, hướng đến việc nối ba phần việc thường tách rời: khám phá bề mặt tấn công, đối sánh CVE và xác thực phát hiện. Theo README của dự án, công cụ tập hợp ngữ cảnh tài sản, mức ưu tiên và bằng chứng trong một quy trình liên tục.

Tuy nhiên, đây là các năng lực do dự án công bố trong README. Tài liệu cung cấp không có đánh giá độc lập về độ chính xác, tỷ lệ dương tính giả, hiệu năng hay khả năng mở rộng của cvENGINE. SOC nên kiểm chứng các yếu tố này bằng một đợt thử nghiệm có kiểm soát trước khi đưa vào vận hành rộng.

cvENGINE là gì?

Theo README, cvENGINE được triển khai bằng Docker Compose trên hạ tầng do tổ chức kiểm soát. Công cụ nhận mục tiêu là tên miền, địa chỉ IP, dải CIDR hoặc URL; sau đó thực hiện khám phá, lập danh mục tài sản, kiểm tra phơi lộ, đối sánh CVE và xác thực kết quả.

Mục tiêu mà dự án đặt ra là trả lời: trong các CVE đang bị khai thác, tổ chức đang có gì bị phơi lộ?

Các khả năng đáng chú ý gồm:

Khám phá tên miền, tên miền con, chứng thư số, IP và cổng với bbot và naabu. Dùng nmap để lấy dấu vân tay dịch vụ và hệ điều hành. Kiểm tra TLS bằng testssl.sh trên các cổng TLS, bao gồm giao thức, bộ mật mã và các lỗ hổng TLS được nêu tên. Thực hiện các bước thăm dò để kiểm tra web route, trạng thái đăng nhập, cơ sở dữ liệu phơi lộ, lưu trữ đám mây, firewall, WordPress, DNS và vệ sinh email. Đối sánh CVE theo sản phẩm và dải phiên bản bị ảnh hưởng. README bản 1.3 nêu rằng chỉ tên sản phẩm sẽ không còn đủ để tạo kết quả khớp. Xếp hạng CVE theo ba mức fire, smoke, ice, dựa trên các nguồn khai thác mà công cụ sử dụng. Xác thực chỉ đọc với Nuclei, nmap và banner probe; ghi lại lệnh đã dùng để tái hiện phát hiện. Theo dõi host mới, cổng mở, thay đổi phiên bản hoặc thay đổi trang web qua dòng thời gian và so sánh ảnh chụp màn hình.

Điểm cần lưu ý: fire, smoke, ice là hệ thống ưu tiên riêng của cvENGINE, không đồng nghĩa trực tiếp với các mức severity phổ biến như high, critical hay CVSS. SOC cần xác định rõ cách quy đổi hoặc sử dụng các nhãn này trong quy trình ưu tiên nội bộ.

Từ phát hiện đến bằng chứng

README mô tả quy trình gồm bốn lớp: tìm tài sản, thăm dò, đối sánh và đưa ra quyết định.

1. Tìm tài sản

cvENGINE khám phá tài sản liên quan đến mục tiêu và đưa chúng vào danh mục có thể tìm kiếm theo phong cách Shodan nội bộ. Danh mục này có thể bao gồm hostname, IP, cổng, sản phẩm, phiên bản, TLS và công nghệ.

Dữ liệu này hữu ích để đối chiếu với CMDB, DNS, tài khoản đám mây và danh mục ứng dụng. Nhưng một tài sản mới phát hiện không nên tự động được xem là dữ liệu CMDB chuẩn nếu chưa xác định chủ sở hữu, phạm vi vận hành và mức độ quan trọng.

2. Thăm dò phơi lộ

README nêu các kiểm tra về dịch vụ, web route, trạng thái đăng nhập, firewall, cơ sở dữ liệu phơi lộ, WordPress, UDP, lưu trữ đám mây và các mục vệ sinh như SPF, DKIM, DMARC, CAA.

Với TLS, dự án dùng testssl.sh để kiểm tra giao thức, cipher suite và các lỗ hổng TLS được nêu tên. Đây là phần riêng với việc nmap lấy dấu vân tay dịch vụ và hệ điều hành.

3. Đối sánh CVE

CVE được liên hệ với sản phẩm và phiên bản quan sát được. README cho biết cvENGINE yêu cầu cùng sản phẩm và phiên bản nằm trong dải ảnh hưởng có giới hạn trước khi tạo một kết quả khớp.

Dự án cũng nêu việc dùng các probe an toàn về phiên bản và định danh host để bổ sung thông tin khi fingerprint chưa đủ. Dù vậy, banner, fingerprint và thông tin phiên bản vẫn có thể thiếu hoặc không phản ánh đầy đủ môi trường thực tế. Kết quả đối sánh nên là đầu vào cho xác minh, không phải kết luận tuyệt đối về khả năng khai thác.

4. Phân loại và xác thực

cvENGINE dùng AI để phân loại phát hiện thành confirmed, likely hoặc needs validation, đồng thời hỗ trợ kiểm tra xác thực chỉ đọc.

Nhãn do AI tạo ra nên được dùng để sắp xếp hàng đợi, không thay thế đánh giá của analyst. Với phát hiện ưu tiên cao, đội SOC vẫn cần kiểm tra phạm vi, chủ sở hữu tài sản, mức độ internet-facing, tác động nghiệp vụ và bằng chứng kỹ thuật trước khi mở incident hoặc yêu cầu vá khẩn.

Cách đưa vào quy trình SOC

Chỉ quét tên miền, IP, CIDR hoặc private range mà tổ chức sở hữu hoặc có ủy quyền rõ ràng. Đây là điều kiện vận hành cơ bản với mọi công cụ khám phá và quét bề mặt tấn công.

Xây dựng phạm vi quan sát

Sau khi triển khai trên máy chủ do tổ chức kiểm soát, có thể thêm các tên miền hoặc IP thuộc phạm vi quản lý. cvENGINE có thể khám phá tên miền con, chứng thư, IP và cổng để duy trì danh mục tài sản.

Mỗi tài sản phát hiện nên được bổ sung thông tin vận hành:

Chủ sở hữu kỹ thuật của host hoặc ứng dụng. Môi trường: production, staging hoặc dùng chung. Mức độ phơi lộ: internet-facing, private hoặc chưa xác định. Mức độ quan trọng với hoạt động kinh doanh.

Tạo hàng đợi dựa trên bằng chứng

Một hàng đợi phù hợp cho SOC có thể ưu tiên các phát hiện hội đủ nhiều tín hiệu:

CVE được cvENGINE xếp mức fire hoặc smoke. Host phơi lộ ra internet. Sản phẩm và phiên bản khớp với dải bị ảnh hưởng. Có kết quả xác thực chỉ đọc hoặc bằng chứng TLS rõ ràng. Thay đổi mới xuất hiện trên dòng thời gian.

README đưa ra ví dụ tìm kiếm trong danh mục tài sản:

text port:3389 -host:vpn

Hoặc lọc theo công nghệ và mức độ nghiêm trọng:

text tech:"apache tomcat" sev:high

Một ticket chất lượng không nên chỉ ghi “Tomcat có CVE”. Ticket cần có host, cổng, sản phẩm hoặc phiên bản quan sát được, nhãn ưu tiên, thời điểm thay đổi và bằng chứng từ bước xác thực.

Sentinel: mở rộng quan sát vào mạng nội bộ

Bản 1.3 bổ sung Sentinel, một thành phần có thể chạy trên máy trong mạng để cvENGINE thực hiện quét thông qua thành phần này. Theo README, Sentinel có thể khám phá host trong private range và thực hiện các kiểm tra như nmap, naabu, Nuclei, TLS, UDP, WordPress và OpenVAS khi OpenVAS được bật.

Về vận hành, Sentinel cần được xem là một scanner có quyền truy cập mạng. Đội an ninh nên:

Giới hạn phạm vi quét của từng Sentinel. Phân tách mạng quản trị khi phù hợp. Kiểm soát cập nhật và thay đổi cấu hình. Theo dõi quyền truy cập cùng phạm vi mạng Sentinel có thể chạm tới. Có phê duyệt rõ ràng trước khi đặt Sentinel vào mạng nhạy cảm.

Không nên mở rộng độ bao phủ vào các vùng mạng quan trọng chỉ vì công cụ hỗ trợ, nếu chưa đánh giá tác động và quyền quét.

API, MCP và cảnh báo

README nêu cvENGINE có REST API, MCP server và cảnh báo qua Slack, Discord, Telegram và Lark.

Tài liệu không khẳng định có tích hợp sẵn với một nền tảng ticketing hoặc SIEM cụ thể. Vì vậy, không nên giả định có kết nối trực tiếp với Jira, ServiceNow hay hệ thống SIEM. Trước khi tích hợp, đội kỹ thuật cần kiểm tra API, cơ chế xác thực, schema dữ liệu và mô hình phân quyền trong môi trường thực tế.

Với API và MCP, các kiểm soát tối thiểu nên gồm:

Xác thực phù hợp và quản lý khóa truy cập như secret. Phân quyền tối thiểu theo vai trò và mục đích sử dụng. Nhật ký truy cập, truy vấn và hành động được gọi. Giới hạn hành động mà agent hoặc ứng dụng tích hợp có thể thực hiện. Rà soát dữ liệu trả về, đặc biệt khi có hostname nội bộ, banner, header, cookie hoặc thông tin cấu hình.

Một quy trình có kiểm soát có thể là:

> Cảnh báo cvENGINE → analyst kiểm tra bằng chứng → tạo case hoặc ticket → phân công asset owner → khắc phục → quét lại để xác nhận.

API hoặc MCP có thể hỗ trợ tự động hóa một phần luồng này, nhưng quyết định mở incident và đóng phát hiện vẫn nên có bước kiểm tra của con người.

AI, OpenVAS và dữ liệu nhạy cảm

cvENGINE hỗ trợ khóa của Anthropic, OpenAI, OpenRouter hoặc mô hình cục bộ qua Ollama, LM Studio và vLLM. README cũng nêu rằng nếu không cấu hình mô hình AI, công cụ vẫn có thể khám phá, quét, đối sánh và xác thực.

Nếu danh mục tài sản chứa hostname nội bộ, banner, header, cookie hoặc dấu vết cấu hình, tổ chức cần rà soát luồng dữ liệu trước khi dùng nhà cung cấp AI bên ngoài. Với môi trường nhạy cảm, mô hình cục bộ là một phương án cần cân nhắc theo chính sách dữ liệu của doanh nghiệp.

OpenVAS được tích hợp nhưng tắt mặc định. README mô tả các bài kiểm tra chạy chậm, có throttling và chỉ dùng safe checks. Dù vậy, việc bật OpenVAS trong production vẫn nên gắn với phê duyệt phạm vi, khung thời gian và chủ sở hữu rõ ràng.

Pilot: cần đo gì trước khi triển khai rộng?

Một đợt thử nghiệm nên bắt đầu với phạm vi nhỏ, có chủ sở hữu rõ ràng và quyền quét được phê duyệt. Các tiêu chí đánh giá có thể gồm:

Thời gian hoàn thành quét ban đầu và các lần quét lặp lại. Tải mạng, ảnh hưởng tới hệ thống đích và mức phù hợp của throttling. Độ phủ tài sản so với CMDB, DNS, công cụ cloud hoặc nguồn kiểm kê hiện có. Tỷ lệ dương tính giả trong kết quả đối sánh CVE và xác thực. Chất lượng bằng chứng: có đủ thông tin về host, cổng, sản phẩm, phiên bản và bước kiểm tra hay không. Khả năng xác định chủ sở hữu tài sản và chuyển phát hiện thành ticket có thể xử lý. Tính phù hợp của dữ liệu trả về qua API, MCP và các kênh cảnh báo.

Checklist cho SOC

[ ] Xác nhận quyền quét cho từng tên miền, IP, CIDR và private range. [ ] Pilot với phạm vi nhỏ trước khi triển khai rộng. [ ] Đo thời gian quét, tải mạng, độ phủ tài sản, dương tính giả và chất lượng bằng chứng. [ ] Đối chiếu tài sản mới phát hiện với CMDB và asset owner. [ ] Dùng AI triage để ưu tiên, không dùng như kết luận cuối cùng. [ ] Phân biệt nhãn fire, smoke, ice với severity hoặc CVSS nội bộ. [ ] Yêu cầu bằng chứng về phiên bản, dải ảnh hưởng và kiểm tra chỉ đọc trước khi mở ticket mức cao. [ ] Quản lý khóa AI, API và MCP như secret; áp dụng phân quyền tối thiểu và ghi nhật ký truy cập. [ ] Hạn chế quyền, phạm vi mạng và cấu hình của Sentinel. [ ] Bật OpenVAS trong cửa sổ thay đổi đã được phê duyệt. [ ] Kiểm tra API và MCP trước khi kết nối với SIEM, SOAR hoặc ticketing. [ ] Dùng dòng thời gian thay đổi để phân biệt rủi ro mới với phát hiện đã tồn tại.

cvENGINE đáng chú ý vì cố gắng hợp nhất kiểm kê tài sản, ưu tiên CVE và lưu bằng chứng để hành động. Giá trị thực tế với SOC sẽ phụ thuộc vào chất lượng inventory, kỷ luật quản lý phạm vi, kiểm soát tích hợp và quy trình xác minh của con người.