Quay lại Quản lý lỗ hổng trong Go
Tổng quan
Vulnerability database (cơ sở dữ liệu lỗ hổng) của Go (https://vuln.go.dev) cung cấp thông tin về lỗ hổng trong Go theo lược đồ Open Source Vulnerability (OSV).
Bạn cũng có thể duyệt các lỗ hổng trong cơ sở dữ liệu tại pkg.go.dev/vuln.
Đừng dựa vào nội dung của kho Git x/vulndb. Các tệp YAML trong kho đó được duy trì theo một định dạng nội bộ có thể thay đổi mà không báo trước.
Đóng góp
Chúng tôi rất mong mọi maintainer của package Go đóng góp thông tin về các lỗ hổng công khai trong chính dự án của họ, và cập nhật thông tin sẵn có về những lỗ hổng trong package Go của họ.
Chúng tôi hướng tới việc làm cho quy trình report trở nên ít rào cản nhất, nên bạn cứ thoải mái gửi cho chúng tôi các đề xuất của bạn.
Vui lòng đừng dùng các biểu mẫu ở trên để báo cáo lỗ hổng trong thư viện chuẩn của Go hoặc các kho con. Thay vào đó, hãy làm theo quy trình tại go.dev/security/policy cho các lỗ hổng liên quan tới dự án Go.
API
Cơ sở dữ liệu lỗ hổng chính thức của Go, https://vuln.go.dev, là một máy chủ HTTP có thể đáp ứng các request GET tới những endpoint được nêu dưới đây.
Các endpoint không có tham số truy vấn, và không yêu cầu header đặc biệt nào. Vì vậy, ngay cả một site phục vụ từ một hệ thống tệp cố định (kể cả URL dạng file://) cũng có thể hiện thực API này.
Mỗi endpoint trả về một response được mã hóa JSON, ở dạng không nén (nếu được yêu cầu dưới dạng .json) hoặc dạng nén gzip (nếu được yêu cầu dưới dạng .json.gz).
Các endpoint gồm:
-
/index/db.json[.gz]Trả về siêu dữ liệu về cơ sở dữ liệu:
{ // The latest time the database should be considered // to have been modified, as an RFC3339-formatted UTC // timestamp ending in "Z". "modified": string }Lưu ý rằng thời điểm modified không nên được so sánh với thời gian đồng hồ thực, ví dụ cho mục đích vô hiệu hóa cache, vì có thể có độ trễ trong việc đưa các thay đổi của cơ sở dữ liệu lên hệ thống.
Xem /index/db.json để có ví dụ thực tế.
-
/index/modules.json[.gz]Trả về một danh sách chứa siêu dữ liệu về từng module trong cơ sở dữ liệu:
[ { // The module path. "path": string, // The vulnerabilities that affect this module. "vulns": [ { // The vulnerability ID. "id": string, // The latest time the vulnerability should be considered // to have been modified, as an RFC3339-formatted UTC // timestamp ending in "Z". "modified": string, // (Optional) The module version (in SemVer 2.0.0 format) // that contains the latest fix for the vulnerability. // If unknown or unavailable, this should be omitted. "fixed": string, } ] } ]Xem /index/modules.json để có ví dụ thực tế.
-
/index/vulns.json[.gz]Trả về một danh sách chứa siêu dữ liệu về từng lỗ hổng trong cơ sở dữ liệu:
[ { // The vulnerability ID. "id": string, // The latest time the vulnerability should be considered // to have been modified, as an RFC3339-formatted UTC // timestamp ending in "Z". "modified": string, // A list of IDs of the same vulnerability in other databases. "aliases": [ string ] } ]Xem /index/vulns.json để có ví dụ thực tế.
-
/ID/$id.json[.gz]Trả về report riêng lẻ cho lỗ hổng có ID là
$id, theo định dạng OSV (mô tả bên dưới trong phần Schema).Xem /ID/GO-2022-0191.json để có ví dụ thực tế.
Tải hàng loạt
Để việc tải toàn bộ cơ sở dữ liệu lỗ hổng của Go dễ dàng hơn, một tệp zip chứa tất cả các tệp index và tệp OSV được cung cấp tại vuln.go.dev/vulndb.zip.
Sử dụng trong govulncheck
Mặc định, govulncheck dùng cơ sở dữ liệu lỗ hổng chính thức của Go tại vuln.go.dev.
Câu lệnh này có thể được cấu hình để liên hệ với một vulnerability database khác bằng cờ -db, cờ này nhận một URL của vulnerability database với giao thức http://, https://, hoặc file://.
Để hoạt động đúng với govulncheck, vulnerability database được chỉ định phải hiện thực API mô tả ở trên. Câu lệnh govulncheck dùng các endpoint “.json.gz” đã nén khi đọc từ nguồn http(s), và các endpoint “.json” khi đọc từ nguồn là tệp.
API cũ
Cơ sở dữ liệu chính thức chứa một số endpoint bổ sung thuộc về một API cũ. Chúng tôi dự định sớm gỡ bỏ hỗ trợ cho các endpoint này. Nếu bạn đang dựa vào API cũ và cần thêm thời gian để chuyển đổi, hãy cho chúng tôi biết.
Schema
Các report dùng lược đồ Open Source Vulnerability (OSV). Cơ sở dữ liệu lỗ hổng của Go gán những ý nghĩa sau cho các trường:
id
Trường id là định danh duy nhất cho một mục lỗ hổng. Nó là một chuỗi có định dạng GO-<YEAR>-<ENTRYID>.
affected
Trường affected là một mảng JSON chứa các object mô tả những phiên bản module có chứa lỗ hổng.
affected[].package
Trường affected[].package là một object JSON xác định module bị ảnh hưởng. Object này có hai trường bắt buộc:
- ecosystem: trường này luôn là “Go”
- name: đây là module path của Go
- Các package có thể import được trong thư viện chuẩn sẽ có name là stdlib.
- Lệnh go sẽ có name là toolchain.
affected[].ecosystem_specific
Trường affected[].ecosystem_specific là một object JSON chứa thông tin bổ sung về lỗ hổng, được các công cụ phát hiện lỗ hổng của Go sử dụng.
Hiện tại, ecosystem specific sẽ luôn là một object với một trường duy nhất, imports.
affected[].ecosystem_specific.imports
Trường affected[].ecosystem_specific.imports là một mảng JSON chứa các package và ký hiệu bị ảnh hưởng bởi lỗ hổng. Mỗi object trong mảng sẽ có hai trường sau:
- path: một chuỗi chứa import path của package chứa lỗ hổng
- symbols: một mảng chuỗi gồm tên các ký hiệu (hàm hoặc method) chứa lỗ hổng
- goos: một mảng chuỗi gồm các hệ điều hành thực thi nơi các ký hiệu xuất hiện, nếu biết
- goarch: một mảng chuỗi gồm các kiến trúc nơi các ký hiệu xuất hiện, nếu biết
database_specific
Trường database_specific chứa các trường tùy chỉnh riêng cho cơ sở dữ liệu lỗ hổng của Go.
database_specific.url
Trường database_specific.url là một chuỗi biểu diễn URL đầy đủ của report lỗ hổng trong Go, ví dụ “https://pkg.go.dev/vuln/GO-2023-1621”.
database_specific.review_status
Trường database_specific.review_status là một chuỗi biểu diễn trạng thái rà soát của report lỗ hổng. Nếu không có, report nên được coi là REVIEWED. Các giá trị có thể có là:
UNREVIEWED: Report được sinh tự động dựa trên một nguồn khác, chẳng hạn một CVE hoặc GHSA. Dữ liệu của nó có thể hạn chế và chưa được đội ngũ Go kiểm chứng.REVIEWED: Report bắt nguồn từ đội ngũ Go, hoặc được sinh ra dựa trên một nguồn bên ngoài. Một thành viên của đội ngũ Go đã rà soát report, và khi cần thiết, đã bổ sung thêm dữ liệu.
Để biết thông tin về các trường khác trong schema, hãy tham khảo đặc tả OSV.
Ghi chú về phiên bản
Bộ công cụ của chúng tôi cố gắng tự động ánh xạ các module và phiên bản trong những khuyến cáo nguồn sang module và phiên bản Go chính thức, theo đúng quy ước số phiên bản module của Go. Những công cụ như govulncheck được thiết kế để dựa vào các phiên bản chuẩn này nhằm xác định một dự án Go có bị ảnh hưởng bởi lỗ hổng trong một phụ thuộc hay không.
Trong một số trường hợp, chẳng hạn khi một dự án Go dùng lược đồ đánh phiên bản riêng, việc ánh xạ sang phiên bản Go chuẩn có thể thất bại. Khi điều đó xảy ra, report trong cơ sở dữ liệu lỗ hổng của Go có thể liệt kê một cách thận trọng tất cả phiên bản Go là bị ảnh hưởng. Điều này đảm bảo những công cụ như govulncheck không bỏ sót việc report lỗ hổng do khoảng phiên bản không nhận diện được (âm tính giả). Tuy nhiên, việc thận trọng liệt kê mọi phiên bản là bị ảnh hưởng có thể khiến các công cụ báo nhầm rằng một phiên bản đã được khắc phục của module vẫn chứa lỗ hổng (dương tính giả).
Nếu bạn cho rằng govulncheck đang report sai (hoặc bỏ sót) một lỗ hổng, vui lòng đề xuất chỉnh sửa cho report lỗ hổng đó và chúng tôi sẽ xem xét.
Ví dụ
Mọi lỗ hổng trong cơ sở dữ liệu lỗ hổng của Go đều dùng lược đồ OSV đã mô tả ở trên.
Xem các liên kết dưới đây để có ví dụ về những loại lỗ hổng khác nhau trong Go:
- Lỗ hổng trong thư viện chuẩn của Go (GO-2022-0191): JSON, HTML
- Lỗ hổng trong toolchain của Go (GO-2022-0189): JSON, HTML
- Lỗ hổng trong module Go (GO-2020-0015): JSON, HTML
Các report bị loại trừ
Các report trong cơ sở dữ liệu lỗ hổng của Go được thu thập từ nhiều nguồn khác nhau và được đội ngũ Bảo mật của Go tuyển chọn. Chúng tôi có thể gặp một khuyến cáo lỗ hổng (ví dụ một CVE hoặc GHSA) và chọn loại trừ nó vì nhiều lý do. Trong những trường hợp đó, một report tối giản sẽ được tạo trong kho x/vulndb, tại x/vulndb/data/excluded.
Report có thể bị loại trừ vì những lý do sau:
NOT_GO_CODE: Lỗ hổng không nằm trong package Go, nhưng nó được một nguồn khác đánh dấu là khuyến cáo bảo mật cho hệ sinh thái Go. Lỗ hổng này không thể ảnh hưởng tới bất kỳ package Go nào. (Ví dụ, một lỗ hổng trong thư viện C++.)NOT_IMPORTABLE: Lỗ hổng xuất hiện trong packagemain, một packageinternal/chỉ được packagemainimport, hoặc một vị trí nào đó không bao giờ có thể được module khác import.EFFECTIVELY_PRIVATE: Dù lỗ hổng xuất hiện trong một package Go có thể được module khác import, package đó không dành cho việc dùng từ bên ngoài và nhiều khả năng sẽ không bao giờ được import ngoài module nơi nó được định nghĩa.DEPENDENT_VULNERABILITY: Lỗ hổng này là tập con của một lỗ hổng khác trong cơ sở dữ liệu. Ví dụ, nếu package A chứa một lỗ hổng, package B phụ thuộc vào package A, và có các mã CVE riêng cho package A và B, chúng tôi có thể đánh dấu report cho B là lỗ hổng phụ thuộc, hoàn toàn được thay thế bởi report cho A.NOT_A_VULNERABILITY: Dù đã có một mã CVE hoặc GHSA được cấp, không có lỗ hổng nào được biết đến gắn với nó.WITHDRAWN: Lỗ hổng đã bị nguồn của nó rút lại.
Hiện tại, các report bị loại trừ không được phục vụ qua API vuln.go.dev. Tuy nhiên, nếu bạn có một trường hợp sử dụng cụ thể và việc truy cập được thông tin này qua API là hữu ích, hãy cho chúng tôi biết.