Phát hiện lỗ hổng mã nguồn mở
trước khi thành sự cố.
Open Source Component Analysis & Response
OSCAR thu thập SBOM (danh mục thành phần phần mềm) ở mỗi lần build và liên tục kiểm tra các thành phần mã nguồn mở trong dịch vụ của bạn để tìm lỗ hổng đã biết. Giao diện dùng ngôn ngữ của bạn, và bạn có thể hỏi AI bằng lời thường — “Dự án nào đang có lỗ hổng Critical?” — để nhận ngay câu trả lời.
Dự án rủi ro nhất thành phần lỗi theo mức độ
Phát hiện mới 12 tuần qua
- loan-batchCVE-2021-44228 · log4j-core 2.14.1Critical
- payment-apiCVE-2022-22965 · spring-beans 5.3.17Critical
Dashboardrủi ro của mọi dự án trên một màn hình
Truy vấn AIcứ hỏi — không cần học menu
Ngay lúc này, bạn có biết bên trong dịch vụ của mình có gì?
Khi một lỗ hổng mã nguồn mở như Log4Shell bùng phát, câu hỏi đầu tiên luôn là “Chúng ta có đang dùng nó không?” Trong lúc từng nhóm lục danh sách thư viện bằng tay, thời gian đứng về phía kẻ tấn công. OSCAR chuẩn bị sẵn câu trả lời đó từ trước.
| Hạng mục | Trước đây | Với OSCAR |
|---|---|---|
| Tần suất | Rà soát thủ công mỗi năm một lần — lỗ hổng mới xuất hiện giữa kỳ bị bỏ sót | SBOM được tải lên ở mỗi lần build và được kiểm tra lại khi có lỗ hổng mới công bố |
| Phương pháp | Con người dò danh sách thư viện bằng tay — dễ bỏ sót | Máy đối chiếu danh mục thành phần với cơ sở dữ liệu lỗ hổng (tên, phiên bản, hash) |
| Thời gian phản ứng | Mất nhiều ngày chỉ để xác nhận “Chúng ta có dùng cái này không?” | Từ một mã CVE, tìm ngay mọi dự án bị ảnh hưởng |
| Giao diện | Công cụ chỉ có tiếng Anh, các nhóm nghiệp vụ khó đọc | Giao diện bản địa hóa; toàn văn giấy phép hiển thị bản dịch ngay cạnh bản gốc |
| Cách hỏi | Phải học menu và bộ lọc mới lấy được bảng cần thiết | Hỏi AI bằng ngôn ngữ thường ngày — 47 công cụ lo phần tra cứu |
Tổng quan nhanh
Tìm ra lỗ hổng mới chỉ là bước đầu: OSCAR giúp bạn đọc hiểu chúng, ghi lại ai đã tải lên những gì và truy ra thành phần lọt vào bằng đường nào. Các màn hình dưới đây dùng dữ liệu giả lập.
└ spring-boot-starter-log4j2
└ log4j-core 2.14.1
OSCAR làm được gì
OSCAR dùng nguyên bản một engine phân tích mã nguồn mở đã được kiểm chứng (OWASP Dependency-Track) và bổ sung những gì các nhóm cần xung quanh nó.
SBOM tự động — ba kiểu build
Plugin pom cho Maven, script tải lên cho npm, và CLI ssemsbom cho dự án Ant hoặc build thủ công không có pom.xml — SBOM được tải lên ngay khi build xong.
Phát hiện liên tục
Kết hợp NVD, GitHub Advisory, OSV, Sonatype OSS Index và Trivy. Khi có lỗ hổng mới được công bố, các danh mục thành phần hiện có sẽ được kiểm tra lại.
AI ngôn ngữ tự nhiên (MCP)
47 công cụ cho dự án, lỗ hổng, thành phần, chính sách, giấy phép và SBOM, cung cấp qua MCP. Hỏi từ ứng dụng AI như Claude, hoặc từ LLM nội bộ.
Giao diện bản địa hóa · dịch giấy phép
Giao diện tiếng Hàn có sẵn, và toàn văn giấy phép được LLM dịch, hiển thị cạnh bản gốc. Chọn LLM nội bộ (Ollama, LM Studio) hoặc Gemini.
Lịch sử tải lên · thẻ chuẩn
Ghi lại ai đã tải lên từng SBOM, vào lúc nào và cho dự án nào. Các thẻ chuẩn — nhóm, loại dịch vụ, công nghệ, công cụ build, máy chủ ứng dụng — giúp gom nhóm hàng trăm dự án.
Nhận diện JAR cũ lộn xộn
Sáu bước — tên file, pom.properties, MANIFEST, suy luận group, Vendor-Id và (tùy chọn) tra hash trên Maven Central — khôi phục tên và phiên bản. Khi không chắc chắn, OSCAR không đoán.
Các nhóm sử dụng như thế nào
Lập trình viên không phải học công cụ mới: chỉ thêm một bước vào build, rồi xem kết quả trên màn hình hoặc hỏi AI.
Cài trên máy chủ của bạn
Engine phân tích và cơ sở dữ liệu chạy trên Docker; gateway và giao diện chạy trên Tomcat 11. Mọi thứ nằm trong mạng nội bộ của bạn.
Thêm bước SBOM
Một plugin trong pom, một script cho npm, một dòng ssemsbom trong build Ant. Từ đó, mỗi lần build đều tự động tải lên.
Nhận dữ liệu lỗ hổng
Cơ sở dữ liệu lỗ hổng được cập nhật định kỳ. Trong mạng cách ly, bạn chỉ cần mở chiều vào qua cầu nối mạng.
Xem · hỏi · khắc phục
Theo dõi rủi ro trên dashboard, hỏi AI về mức ảnh hưởng và ghi lại trạng thái phân tích (đang xử lý, không bị ảnh hưởng).
Cách hoạt động
Mọi luồng đều đi qua một gateway OSCAR duy nhất. Giao diện, build và AI không bao giờ gọi trực tiếp engine phân tích, nên gateway có thể bổ sung bản dịch và lịch sử — còn engine có thể nâng cấp mà không phải sửa đổi.
- Engine phân tích không bị sửa đổi. OSCAR chạy bản phát hành chính thức của OWASP Dependency-Track và thay đổi phản hồi tại gateway đặt phía trước. Nâng cấp engine không ảnh hưởng đến OSCAR.
- Việc dịch diễn ra ở gateway, không phải ở giao diện, nên màn hình, AI và các client API đều nhận cùng một bản dịch.
- MCP server chạy trên PC của từng người dùng, do ứng dụng AI khởi động, và vào gateway bằng API key được cấp. AI chỉ làm được những gì key đó cho phép.
- Đường nét đứt chỉ có chiều vào. Dữ liệu lỗ hổng đi vào engine; danh mục thành phần của bạn không bao giờ rời khỏi mạng nội bộ.
Dependency-Track 4.13
Mã nguồn mở OWASP · Docker. Phân tích SBOM; đánh giá lỗ hổng, chính sách và giấy phép.
Java 21 · Tomcat 11
Chuyển tiếp yêu cầu, dịch giấy phép và lưu lịch sử tải lên, phục vụ cùng giao diện bản địa hóa.
MCP server · 47 công cụ
Một file jar Java duy nhất chạy qua STDIO. Dùng được với Claude Desktop, Claude Code và các MCP client khác.
CycloneDX 1.5 · PURL
Tiêu chuẩn SBOM quốc tế (ECMA-424). Thành phần được nhận diện bằng PURL và đối chiếu với dữ liệu lỗ hổng.
Nguyên tắc bảo mật
Một công cụ bảo mật không được trở thành rủi ro mới, vì vậy chúng tôi vạch ra những giới hạn này trước tiên.
- Cài trên máy chủ của bạn — danh mục thành phần và kết quả không được chuyển lên cloud bên ngoài.
- Thứ được tải lên là danh mục thành phần (SBOM), không phải mã nguồn — chỉ gồm tên, phiên bản và hash.
- Kết nối ra bên ngoài duy nhất là kéo về dữ liệu lỗ hổng, giúp việc phê duyệt trong mạng cách ly dễ dàng hơn.
- Khi dùng LLM nội bộ (Ollama, LM Studio) để dịch giấy phép, ngay cả văn bản cần dịch cũng không rời khỏi mạng nội bộ.
- AI chỉ gọi công cụ, không tự phán đoán — câu trả lời luôn dựa trên dữ liệu của engine.
- Truy cập của AI dùng API key riêng và không thể vượt quá quyền của key đó (đọc, tải lên, …).
- Nếu dịch thất bại, bản gốc vẫn được hiển thị — không có gì bị mất vì việc dịch.
- Engine là mã nguồn mở đã được kiểm chứng, dùng nguyên bản; OSCAR chỉ thêm một lớp mỏng phía trước.
Yêu cầu hệ thống
Những gì OSCAR cần để vận hành.
- Docker (engine phân tích, PostgreSQL) và Tomcat 11 (Java 21) trên máy chủ của bạn. Engine phân tích cần nhiều bộ nhớ (từ vài GB trở lên).
- Một đường vào từ internet để nhận dữ liệu lỗ hổng. Trong mạng cách ly, chỉ cho phép các địa chỉ cần thiết đi qua cầu nối mạng.
- SBOM được tạo ra từ quá trình build, nên bạn phải thêm được bước SBOM vào pipeline (Maven, npm, Ant, build thủ công).
- JAR thương mại hoặc nội bộ không có metadata sẽ không nhận diện được và có thể bị bỏ sót khi đối chiếu lỗ hổng.
- Truy vấn AI cần một client hỗ trợ MCP; LLM nội bộ phải hỗ trợ gọi công cụ (tool calling).
- Bản dịch giấy phép chỉ mang tính tham khảo. Các quyết định pháp lý căn cứ vào văn bản gốc.
Bạn đang cân nhắc OSCAR?
Hãy cho chúng tôi biết về môi trường của bạn — có cách ly mạng hay không, số lượng dự án, công cụ build — chúng tôi sẽ cùng bạn lên kế hoạch triển khai và lịch trình.
Liên hệ tư vấn