OSV-Scanner: kiểm kê và quét lỗ hổng thư viện phụ thuộc cho chuỗi siêu thị mini
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Câu trả lời ngắn: OSV-Scanner đối chiếu danh sách thư viện của bạn với cơ sở dữ liệu lỗ hổng mở
OSV-Scanner là công cụ dòng lệnh viết bằng Go, tìm các lỗ hổng đã biết trong những thư viện mà dự án phụ thuộc vào. README mô tả nó là giao diện chính thức cho cơ sở dữ liệu OSV.dev, đồng thời là CLI của thư viện OSV-Scalibr, nối danh sách phụ thuộc của dự án với các lỗ hổng ảnh hưởng đến chúng. [1]
Công cụ đáng dùng khi một nhóm phát triển cần quét thư viện trong mã nguồn, tệp khóa, SBOM hoặc container image mà không muốn phụ thuộc vào một nền tảng thương mại. Nó chưa phải lựa chọn đủ cho các nhu cầu như quét mã tĩnh, kiểm thử xâm nhập hay quản lý lỗ hổng toàn doanh nghiệp. Kết quả cũng chỉ tốt bằng dữ liệu trong cơ sở dữ liệu và độ chính xác khi nhận diện gói.
Giấy phép là Apache-2.0, thuận lợi cho dùng nội bộ lẫn tích hợp vào quy trình CI. Cần lưu ý dữ liệu lỗ hổng và dữ liệu giấy phép lấy từ dịch vụ bên ngoài, vốn có điều khoản riêng, và các tính năng như hỗ trợ sửa lỗi có hướng dẫn vẫn đang ở mức thử nghiệm. [1][2]
Khi phần mềm bán lẻ được ghép từ hàng trăm thư viện mà không ai kiểm kê
Phần mềm hiện đại hiếm khi chỉ gồm mã do đội mình viết. Một ứng dụng web bán hàng thường kéo theo hàng trăm gói từ npm, PyPI hay Maven, và mỗi gói lại kéo thêm các phụ thuộc gián tiếp. Khi một lỗ hổng được công bố, câu hỏi đầu tiên là hệ thống của mình có đang dùng phiên bản bị ảnh hưởng hay không, và câu trả lời thường nằm rải rác trong tệp khóa của nhiều kho mã.
Cách thủ công, như đọc bản tin an ninh rồi tìm trong từng dự án, không theo kịp. Một công cụ quét tự động giúp biến câu hỏi đó thành lệnh chạy được trong CI. README cho biết OSV-Scanner hỗ trợ nhiều ngôn ngữ như C/C++, Dart, Elixir, Go, Java, JavaScript, PHP, Python, R, Ruby và Rust, cùng nhiều trình quản lý gói như npm, pip, yarn, Maven, cargo, gem, composer và nuget. [1]
Có thêm hai bài toán liên quan. Thứ nhất là biết lỗ hổng nào thực sự bị gọi đến trong mã, để đội không phải xử lý hàng loạt cảnh báo vô hại. Thứ hai là kiểm tra giấy phép của thư viện, vì một thư viện an toàn về bảo mật vẫn có thể có điều khoản không phù hợp với sản phẩm thương mại. Cả hai nằm trong phạm vi tài liệu của công cụ. [1][3]
Bên dưới lệnh scan: OSV-Scalibr, OSV.dev và deps.dev
OSV-Scanner không tự làm mọi việc. README nói công cụ dùng thư viện OSV-Scalibr để trích xuất danh sách gói, rồi tra cứu lỗ hổng trong cơ sở dữ liệu OSV.dev. Nếu một ngôn ngữ hay trình quản lý gói chưa được hỗ trợ, README hướng dẫn gửi yêu cầu tính năng, cho thấy năng lực quét phụ thuộc vào các trình trích xuất của thư viện bên dưới. [1]
Dịch vụ thứ hai là deps.dev. README liệt kê các mục đích sử dụng gồm phân giải đồ thị phụ thuộc, lấy siêu dữ liệu ảnh container, lấy thông tin giấy phép khi dùng cờ licenses và kiểm tra gói đã bị đánh dấu ngừng hỗ trợ hay chưa. Khi dùng cơ chế phân giải gốc của registry thay cho deps.dev, công cụ có thể gọi tới Maven Central, npm registry hoặc PyPI. [1]
Về dữ liệu, OSV.dev được README mô tả là bao phủ nhiều hệ sinh thái nguồn mở, mỗi thông báo đến từ nguồn công khai như GitHub Security Advisories hay RustSec, và định dạng OSV lưu thông tin phiên bản bị ảnh hưởng ở dạng máy đọc được. Đây là mô tả của chính dự án, cần xem như tuyên bố của nhà phát triển, không phải kết quả đánh giá độc lập. [1]
Lần quét đầu tiên đi qua những bước nào: từ thư mục mã nguồn tới báo cáo
Lệnh quét cơ bản là quét thư mục nguồn với cờ đệ quy. Theo tài liệu, công cụ tìm tệp khóa, SBOM và thư mục git trong thư mục đích, dùng chúng để xác định phụ thuộc, rồi đối chiếu với cơ sở dữ liệu OSV. Đệ quy giúp tìm thêm tệp nhưng có thể chậm nếu cây thư mục sâu. Mặc định tệp bị .gitignore loại ra cũng không được quét, trừ khi dùng cờ no-ignore. [3]
Dữ liệu rời máy là điểm cần chú ý. README nêu rõ các thông tin gửi tới OSV.dev gồm tên gói, phiên bản, hệ sinh thái và mã băm tệp, còn deps.dev nhận tên gói, phiên bản và hệ sinh thái. README khẳng định không có mã nguồn được truyền đi. Phát biểu này đáng tin ở mức tài liệu, và vẫn nên được kiểm chứng bằng cách quan sát lưu lượng mạng khi thử nghiệm. [1]
Với chế độ ngoại tuyến, luồng khác hẳn. Cờ offline khiến công cụ quét theo cơ sở dữ liệu cục bộ đã tải trước, không tải mới và không gửi thông tin dự án hay phụ thuộc ra ngoài. Thư mục cơ sở dữ liệu chứa các tệp all.zip theo từng hệ sinh thái, vị trí đặt qua biến môi trường OSV_SCANNER_LOCAL_DB_CACHE_DIRECTORY. [4]
Những khả năng có dẫn chứng trong README và tài liệu
Quét mã nguồn là lệnh mặc định, nên viết tắt không cần chỉ rõ subcommand. Công cụ nhận diện SBOM theo tên tệp chuẩn của SPDX và CycloneDX, cho phép chỉ định từng tệp khóa, hỗ trợ cả việc chọn bộ phân tích cho tệp có tên tùy ý. Tính năng loại trừ thư mục bằng cờ x-exclude được gắn nhãn thử nghiệm và hiện chỉ loại thư mục, không loại từng tệp. [3]
Phân tích lời gọi (call analysis) kiểm tra xem hàm dễ bị tấn công có thực sự được thực thi hay không; những lỗ hổng không được gọi sẽ được đánh dấu là chưa thực thi. Với Go, tính năng bật theo mặc định, dùng thư viện govulncheck và yêu cầu trình biên dịch Go có trên PATH. Với Rust, tính năng vẫn thử nghiệm, biên dịch mã và đọc thông tin DWARF, và tài liệu cảnh báo rằng nó chạy build script của các phụ thuộc, tức có thể thực thi mã tùy ý. [3]
Quét container image là quét theo lớp, hỗ trợ gói hệ điều hành Alpine, Debian, Ubuntu và gói ngôn ngữ Go, Java, Node, Python. Quét giấy phép dùng dữ liệu deps.dev, hiển thị tóm tắt hoặc so với danh sách cho phép theo mã SPDX. Hướng dẫn khắc phục (guided remediation) được README ghi là thử nghiệm và chỉ hỗ trợ npm với package-lock.json hoặc package.json, cùng Maven với pom.xml. [1][6]
Ai sẽ được lợi nhất, và ai nên chọn công cụ khác
Nhóm đầu tiên là các đội phát triển nhỏ và vừa đang tự xây ứng dụng bằng nhiều ngôn ngữ, cần một bước kiểm tra phụ thuộc trong CI mà không phải ký hợp đồng nền tảng lớn. Công cụ chạy bằng một tệp nhị phân dựng sẵn hoặc cài bằng go install nên việc đưa vào quy trình khá nhẹ. [1]
Nhóm thứ hai là đội an ninh cần bằng chứng kiểm kê phụ thuộc cho kiểm toán nội bộ. Khả năng đọc SBOM giúp quét cả những sản phẩm do nhà cung cấp bàn giao dưới dạng danh mục thành phần, miễn là SBOM dùng Package URL. Điều kiện này được tài liệu nêu rõ. [3]
Công cụ ít phù hợp với tổ chức mà phần lớn rủi ro nằm ở cấu hình, mật khẩu, lỗi logic nghiệp vụ hay hạ tầng. OSV-Scanner chỉ trả lời câu hỏi về lỗ hổng đã biết ở thư viện. Nó cũng không thay thế việc cập nhật bản vá thường xuyên và việc tìm hiểu lỗ hổng chưa có mã định danh. [1]
Kịch bản đề xuất: chuỗi siêu thị mini kiểm kê thư viện trong phần mềm bán hàng và ứng dụng giao hàng
Đây là kịch bản giả định, không phải trường hợp đã triển khai. Một chuỗi siêu thị mini khoảng năm mươi cửa hàng có phần mềm bán hàng tại quầy, một trang web đặt hàng, ứng dụng giao hàng và hệ thống báo cáo nội bộ. Đội phát triển gồm vài lập trình viên nội bộ và một nhà thầu bên ngoài. Hệ thống dùng Node.js cho web, Python cho báo cáo và Java cho dịch vụ hóa đơn.
Đề xuất gồm bốn bước. Chạy quét thư mục nguồn trong CI của từng kho mã, ở chế độ chỉ cảnh báo vài tuần đầu. Dùng tệp osv-scanner.toml để ghi nhận lỗ hổng đã chấp nhận rủi ro kèm lý do và ngày hết hạn. Quét container image của dịch vụ giao hàng trước khi triển khai. Yêu cầu nhà thầu bàn giao SBOM để chạy quét theo cùng chuẩn. Tài liệu cấu hình mô tả rõ khóa ignoreUntil và reason cho việc này. [3][5]
Một chi tiết vận hành đáng lưu ý: máy build của chuỗi có thể bị giới hạn truy cập Internet. Khi đó chế độ ngoại tuyến cho phép tải trước cơ sở dữ liệu lỗ hổng rồi quét mà không gửi gì ra ngoài. Cần lập lịch cập nhật cơ sở dữ liệu định kỳ, vì dữ liệu cũ sẽ bỏ sót lỗ hổng mới. [4]
Đưa vào quy trình: cấu hình theo thư mục, cache cơ sở dữ liệu và những tệp bị bỏ qua
Cấu hình đặt trong tệp osv-scanner.toml cạnh tệp được quét và không lan xuống thư mục con. Ví dụ trong tài liệu: một tệp cấu hình ở thư mục gốc chỉ áp dụng cho tệp khóa cùng thư mục đó, còn tệp ở thư mục con chỉ áp dụng cho thư mục con. Có thể truyền cờ config để áp một cấu hình duy nhất cho mọi tệp, bỏ qua mọi tệp toml ở thư mục khác. Cấu trúc này nên được phản ánh khi dựng quy ước cho nhiều kho. [5]
Khóa IgnoredVulns cho phép bỏ qua lỗ hổng theo mã, kèm ngày hết hạn và lý do, và việc bỏ qua cũng bao gồm các lỗ hổng được xem là bí danh. Khóa PackageOverrides có thể bỏ qua cả gói hoặc chỉ phần lỗ hổng, phần giấy phép, hay ghi đè giấy phép, kèm effectiveUntil. Nên bắt buộc điền reason và ngày hết hạn để ngoại lệ không sống mãi. [5]
Ở ngoại tuyến, nếu không đặt biến môi trường, công cụ tìm cơ sở dữ liệu ở thư mục cache của người dùng rồi tới thư mục tạm. Cơ sở dữ liệu lấy được từ kho GCS do OSV duy trì, theo từng hệ sinh thái. Tài liệu ghi rõ một hạn chế: quét ở mức commit không được hỗ trợ trong chế độ này. [4]
Dữ liệu rời khỏi máy build và rủi ro khi quét mã không tin cậy
Rủi ro đầu tiên là quyền riêng tư của danh mục phụ thuộc. Tên gói nội bộ, phiên bản và mã băm tệp có thể tiết lộ cấu trúc sản phẩm. README nói các dữ liệu này được gửi tới OSV.dev khi quét trực tuyến, và hướng dẫn dùng chế độ ngoại tuyến để tắt yêu cầu mạng. Doanh nghiệp nên xem tên gói nội bộ có nhạy cảm không, rồi chọn chế độ phù hợp. [1]
Rủi ro thứ hai là thực thi mã. README cảnh báo lệnh fix của hướng dẫn khắc phục có thể nguy hiểm với dự án không tin cậy vì có thể khiến trình quản lý gói chạy script hoặc theo registry bên ngoài do dự án chỉ định. Tương tự, phân tích lời gọi cho Rust chạy build.rs của phụ thuộc. Vì vậy các tính năng này không nên chạy trên mã của bên thứ ba chưa rà soát hoặc trong runner CI có quyền cao. [1][3]
Rủi ro thứ ba là hiểu nhầm kết quả. Báo cáo sạch không chứng minh phần mềm an toàn, chỉ cho biết không thấy lỗ hổng đã biết trong dữ liệu và trình trích xuất hiện có. Tài liệu cấu hình còn nêu rằng mặc định công cụ không quét phiên bản Go trong go.mod vì đó là phiên bản ngôn ngữ tối thiểu, không nhất thiết là bộ công cụ build. Đây là ví dụ cho thấy quy tắc nhận diện ảnh hưởng đến kết quả. [5]
Apache-2.0 cho mã công cụ, điều khoản riêng cho dữ liệu và dịch vụ
Tệp LICENSE tại commit khảo sát là Apache License 2.0. Văn bản gồm các định nghĩa, cấp quyền bản quyền và quyền bằng sáng chế, điều khoản phân phối lại, và điều khoản nêu rõ giấy phép không cấp quyền sử dụng nhãn hiệu. Với doanh nghiệp, đây là giấy phép dễ chấp nhận khi dùng nội bộ và tích hợp vào CI. [2]
Giấy phép chỉ bao phủ mã nguồn của OSV-Scanner tại commit này. Nó không bao phủ OSV-Scalibr, thư viện được dùng bên dưới, các thư viện phụ thuộc của công cụ, dữ liệu OSV.dev, dữ liệu deps.dev hay quy định sử dụng API của các dịch vụ đó. Cây tệp còn chứa dữ liệu kiểm thử như thư viện zlib vendored có LICENSE riêng; bài này không đọc nên không kết luận về chúng. [1][2]
Điều đáng tách bạch là quét giấy phép của công cụ chỉ báo cáo giấy phép mà deps.dev cung cấp, hoặc giấy phép bạn ghi đè trong cấu hình. Kết quả đó không phải ý kiến pháp lý. Khi sản phẩm bán ra ngoài, hãy để bộ phận pháp chế quyết định danh sách giấy phép được phép. [6]
Chi phí: ít bản quyền, nhưng có chi phí phân loại cảnh báo
Công cụ không tính phí giấy phép ở lớp mã nguồn và chạy từ một tệp nhị phân, nên chi phí phần cứng thường chỉ là thời gian chạy trong runner CI. Bài không có số đo thời gian quét, và README cảnh báo quét đệ quy cây thư mục sâu có thể lâu. Hãy đo trên kho mã thực tế của mình. [1][3]
Chi phí lớn hơn là sức người: đọc cảnh báo, quyết định cái nào cần sửa ngay, nâng cấp thư viện và kiểm thử lại. Với tính năng hướng dẫn khắc phục thử nghiệm, vẫn cần lập trình viên xem xét thay đổi. Hãy ước lượng thời gian phân loại ban đầu cho từng kho, vì lần quét đầu thường cho nhiều cảnh báo tồn đọng.
Nếu chọn chế độ ngoại tuyến, cần thêm dung lượng đĩa cho các tệp cơ sở dữ liệu và một tác vụ định kỳ làm mới chúng. Dung lượng thực tế phụ thuộc vào hệ sinh thái bạn quét, và bài không nêu con số. [4]
So với các cách kiểm tra phụ thuộc khác
Một hướng quen thuộc là dùng tính năng cảnh báo phụ thuộc có sẵn trên nền tảng lưu trữ mã nguồn. Hướng này tiện vì không cần cài đặt, nhưng thường gắn với một nền tảng, còn OSV-Scanner chạy được trên máy build bất kỳ, quét được cả thư mục không nằm trên nền tảng đó. Bài không so sánh độ phủ dữ liệu giữa hai bên vì chưa đọc tài liệu của họ.
Hướng thứ hai là các công cụ quét lỗ hổng khác như Trivy hay các sản phẩm phân tích thành phần phần mềm thương mại. Chúng có thể có thêm quản trị tập trung, bảng điều khiển và hỗ trợ thương mại. Lựa chọn nên dựa trên thử nghiệm song song trên cùng một kho mã, so sánh số cảnh báo đúng và sai, thay vì tin vào số lượng đã công bố.
Điểm riêng của OSV-Scanner theo nguồn đã đọc gồm chế độ ngoại tuyến chính thức, quét giấy phép và phân tích lời gọi, ngoài việc dùng cơ sở dữ liệu mở có nguồn gốc rõ ràng. README tự nhận cơ sở dữ liệu này có ưu điểm so với cơ sở dữ liệu đóng nguồn, tuy nhiên đó là lời của dự án. [1][4]
Hạn chế và khi nào không nên dựa vào kết quả quét
Phạm vi hỗ trợ có giới hạn. Container image chỉ hỗ trợ một số bản phân phối và ngôn ngữ như đã nêu, nên một image dùng hệ điều hành khác sẽ không được phủ đầy đủ. Phân tích lời gọi bị hạn chế với Rust: không hỗ trợ phụ thuộc proc-macro, phụ thuộc liên kết động hoặc liên kết mã không phải Rust. [1][3]
Ngoại tuyến không hỗ trợ quét ở mức commit, và cơ sở dữ liệu cục bộ phải được tự làm mới. README còn ghi các hướng dẫn trong đó là cho bản V2 và gọi nó là beta, trong khi nhãn phiên bản gần nhất lúc thu thập đã là 2.7.0; sự khác biệt này nên được xác nhận với tài liệu chính thức. Cũng có một lỗi đã biết về ranh giới kho git khi áp dụng .gitignore. [1][3][4]
Không nên dùng báo cáo của công cụ này làm bằng chứng duy nhất cho tuân thủ. Hãy kết hợp với rà soát thủ công, kiểm thử bảo mật và theo dõi nguồn thông báo của nhà cung cấp.
Kế hoạch thử nghiệm hai pha trên ba kho mã đại diện
Pha một, tuần một và hai: chọn ba kho mã đại diện cho Node.js, Python và Java, chạy quét thủ công trước, chưa gắn vào CI. Ghi lại số gói phát hiện, số cảnh báo và thời gian quét. Hai lập trình viên độc lập phân loại mười cảnh báo ngẫu nhiên thành cần sửa, chấp nhận rủi ro hoặc nhiễu. Tiêu chí: ít nhất một nửa số mẫu được hai người đánh giá nhất quán, và mọi gói trong tệp khóa được liệt kê đúng. [3]
Pha hai, tuần ba và bốn: gắn vào CI ở chế độ cảnh báo, thêm osv-scanner.toml với lý do và ngày hết hạn cho các ngoại lệ, và thử quét một container image. Chạy thử ngoại tuyến trên một máy build không có Internet để xác nhận cơ sở dữ liệu tải trước dùng được. Theo dõi lưu lượng mạng trong lần quét trực tuyến để đối chiếu với phần dữ liệu README nêu. [4][5]
Điều kiện dừng gồm: thời gian quét làm CI chậm quá ngưỡng đội chấp nhận, tỷ lệ cảnh báo nhiễu quá cao khiến mọi người bỏ qua, hoặc phát hiện dữ liệu nhạy cảm bị gửi ra ngoài ngoài mô tả. Nếu đạt, chuyển sang chế độ chặn merge với lỗ hổng mức nghiêm trọng, nhưng vẫn giữ quy trình ngoại lệ có thời hạn. [1]
Kết luận
OSV-Scanner là công cụ thực dụng để biến việc kiểm kê và đối chiếu phụ thuộc thành bước tự động. Điểm mạnh theo tài liệu gồm phạm vi ngôn ngữ rộng, đọc SBOM, quét container, quét giấy phép, phân tích lời gọi và chế độ ngoại tuyến. Điểm yếu cần nhớ là phụ thuộc vào dữ liệu bên ngoài, một số tính năng ở mức thử nghiệm và cảnh báo vẫn cần người phân loại. [1][3][4]
Với chuỗi siêu thị mini trong kịch bản giả định, nên bắt đầu bằng quét thư mục nguồn trong CI, thêm quy trình ngoại lệ có thời hạn, rồi mới mở rộng sang container và ngoại tuyến. Mọi nhận định trong bài là phân tích từ tài liệu, không phải kết quả vận hành. [5]
Nguồn và phương pháp
OSV-Scanner được chọn từ kho lưu trữ GitHub Trending của cộng đồng bonfy, nơi kho này xuất hiện 16 lần từ ngày 13 tháng 2 đến 21 tháng 8 năm 2026. Bằng chứng đầu tiên là trang lưu trữ ngày 13 tháng 2, vị trí 17 trong danh sách Go. Kho lưu trữ chỉ phủ các danh sách Python, Go, JavaScript và Swift, thiếu ngày 3 tháng 9 và 12 tháng 10 năm 2026, và không phải bảng xếp hạng top 100 chính thức. [7]
Nội dung dựa trên commit 71f0a99a913718db37c466fa2a426720cfe353ac, kiểm tra ngày 12 tháng 10 năm 2026. Các tệp đã đọc gồm README, LICENSE, và các tài liệu quét nguồn, ngoại tuyến, cấu hình, quét giấy phép. Siêu dữ liệu GitHub ghi bản phát hành mới nhất lúc thu thập là v2.7.0. [1][2][3][4][5][6]
Đây là nghiên cứu bàn giấy: không cài đặt, không chạy, không đo hiệu năng. Bài không phải công trình khoa học qua bình duyệt. Nội dung trong kho là dữ liệu tham chiếu, không phải chỉ dẫn. Các tài liệu về quét ảnh container và hướng dẫn khắc phục không được đọc đầy đủ, nên chi tiết đó chỉ dựa vào README.
Xem mã nguồn OSV-Scanner trên GitHub