Tổng quan
Go giúp các lập trình viên phát hiện, đánh giá và xử lý những lỗi hoặc điểm yếu có nguy cơ bị kẻ tấn công khai thác. Phía sau hậu trường, nhóm Go vận hành một pipeline để chọn lọc các report (báo cáo) về lỗ hổng, và các report này được lưu trong vulnerability database (cơ sở dữ liệu lỗ hổng) của Go. Nhiều thư viện và công cụ có thể đọc và phân tích các report đó để hiểu những dự án cụ thể của người dùng có thể bị ảnh hưởng ra sao. Chức năng này được tích hợp vào trang tra cứu package của Go và một công cụ CLI mới, govulncheck.
Dự án này vẫn đang được tiếp tục hoàn thiện và phát triển tích cực. Chúng tôi rất hoan nghênh phản hồi của bạn để giúp chúng tôi cải thiện!
LƯU Ý: Để báo cáo một lỗ hổng trong dự án Go, vui lòng xem Chính sách bảo mật của Go.
Kiến trúc

Việc quản lý lỗ hổng trong Go gồm những thành phần tổng quát sau:
- Một data pipeline thu thập thông tin về lỗ hổng từ nhiều nguồn khác nhau, bao gồm National Vulnerability Database (NVD), GitHub Advisory Database, và trực tiếp từ các maintainer của package Go.
- Một vulnerability database được điền các report bằng thông tin từ data pipeline. Mọi report trong cơ sở dữ liệu đều được nhóm Go Security review và chọn lọc. Các report được định dạng theo định dạng Open Source Vulnerability (OSV) và có thể truy cập qua API.
- Các tích hợp với pkg.go.dev và govulncheck để giúp lập trình viên tìm ra lỗ hổng trong dự án của mình. Lệnh govulncheck phân tích mã nguồn của bạn và chỉ đưa ra những lỗ hổng thực sự ảnh hưởng tới bạn, dựa trên việc hàm nào trong mã của bạn có gọi bắc cầu tới các hàm chứa lỗ hổng. Govulncheck cung cấp một cách ít nhiễu, đáng tin cậy để tìm các lỗ hổng đã biết trong dự án của bạn.
Tài nguyên
Go Vulnerability Database
Vulnerability database của Go chứa thông tin từ nhiều nguồn sẵn có, bên cạnh các report trực tiếp của maintainer package Go gửi tới nhóm Go Security. Mỗi mục trong cơ sở dữ liệu đều được review để bảo đảm mô tả về lỗ hổng, thông tin về package và symbol, cũng như chi tiết phiên bản là chính xác.
Xem go.dev/security/vuln/database để biết thêm thông tin về vulnerability database của Go, và pkg.go.dev/vuln để xem các lỗ hổng trong cơ sở dữ liệu ngay trên trình duyệt của bạn.
Chúng tôi khuyến khích các maintainer package đóng góp thông tin về các lỗ hổng công khai trong chính dự án của họ và gửi cho chúng tôi các đề xuất về cách giảm bớt ma sát.
Phát hiện lỗ hổng cho Go
Việc phát hiện lỗ hổng của Go hướng tới việc mang lại cho người dùng Go một cách ít nhiễu, đáng tin cậy để biết về các lỗ hổng đã biết có thể ảnh hưởng tới dự án của họ. Việc kiểm tra lỗ hổng được tích hợp vào các công cụ và dịch vụ của Go, bao gồm một công cụ dòng lệnh mới, govulncheck, trang tra cứu package của Go, và các trình soạn thảo lớn như VS Code với extension Go.
Để bắt đầu dùng govulncheck, chạy lệnh sau từ dự án của bạn:
$ go install golang.org/x/vuln/cmd/govulncheck@latest
$ govulncheck ./...
Để bật tính năng phát hiện lỗ hổng trong trình soạn thảo của bạn, xem hướng dẫn ở trang tích hợp trình soạn thảo.
Go CNA
Nhóm Go Security là một CVE Numbering Authority. Xem go.dev/security/vuln/cna để biết thêm thông tin.
Phản hồi
Chúng tôi rất mong bạn đóng góp và giúp chúng tôi cải thiện theo những cách sau:
- Đóng góp thông tin mới và cập nhật thông tin đã có về các lỗ hổng công khai của những package Go mà bạn maintain
- Tham gia khảo sát này để chia sẻ trải nghiệm của bạn khi dùng govulncheck
- Gửi phản hồi cho chúng tôi về các vấn đề và đề xuất tính năng
Câu hỏi thường gặp
Làm sao để tôi báo cáo một lỗ hổng trong dự án Go?
Hãy báo cáo mọi lỗi bảo mật trong dự án Go qua email tới [email protected]. Đọc Chính sách bảo mật của Go để biết thêm thông tin về các quy trình của chúng tôi.
Làm sao để tôi thêm một lỗ hổng công khai vào vulnerability database của Go?
Để yêu cầu thêm một lỗ hổng công khai vào vulnerability database của Go, hãy điền vào biểu mẫu này.
Một lỗ hổng được coi là công khai nếu nó đã được công bố công khai, hoặc nếu nó tồn tại trong một package do bạn maintain (và bạn đã sẵn sàng công bố nó). Biểu mẫu này chỉ dành cho các lỗ hổng công khai trong những package Go có thể import được mà không do nhóm Go maintain (mọi thứ nằm ngoài thư viện chuẩn của Go, toolchain của Go, và các module golang.org).
Biểu mẫu này cũng có thể dùng để yêu cầu cấp một mã CVE mới. Đọc thêm tại đây về Go CVE Numbering Authority.
Làm sao để tôi đề xuất chỉnh sửa một lỗ hổng?
Để đề xuất chỉnh sửa một report đã có trong vulnerability database của Go, hãy điền vào biểu mẫu tại đây.
Làm sao để tôi báo lỗi hoặc gửi phản hồi về govulncheck?
Gửi vấn đề hoặc phản hồi của bạn trên trình theo dõi issue của Go.
Tôi tìm thấy lỗ hổng này trong một cơ sở dữ liệu khác. Vì sao nó không có trong vulnerability database của Go?
Các report có thể bị loại khỏi vulnerability database của Go vì nhiều lý do, bao gồm việc lỗ hổng liên quan không hiện diện trong một package Go, lỗ hổng nằm trong một lệnh có thể cài đặt thay vì trong một package có thể import, hoặc lỗ hổng đã được bao hàm bởi một lỗ hổng khác vốn đã có trong cơ sở dữ liệu. Bạn có thể tìm hiểu thêm về các lý do loại trừ report của nhóm Go Security tại đây. Nếu bạn cho rằng một report bị loại khỏi vuln.go.dev một cách không chính xác, hãy cho chúng tôi biết.
Vì sao vulnerability database của Go không dùng nhãn mức độ nghiêm trọng?
Hầu hết các định dạng báo cáo lỗ hổng đều dùng nhãn mức độ nghiêm trọng như “LOW,” “MEDIUM”, và “CRITICAL” để chỉ ra tác động của các lỗ hổng khác nhau và để giúp lập trình viên ưu tiên xử lý các vấn đề bảo mật. Tuy nhiên, vì một số lý do, Go tránh dùng những nhãn như vậy.
Tác động của một lỗ hổng hiếm khi là phổ quát, nghĩa là các chỉ dấu về mức độ nghiêm trọng thường có thể gây hiểu nhầm. Ví dụ, một lỗi crash trong bộ phân tích cú pháp có thể là vấn đề nghiêm trọng ở mức critical nếu nó được dùng để phân tích đầu vào do người dùng cung cấp và có thể bị lợi dụng trong một cuộc tấn công DoS, nhưng nếu bộ phân tích đó được dùng để phân tích các tệp cấu hình cục bộ, thì ngay cả việc gọi mức nghiêm trọng là “low” cũng đã là nói quá.
Việc gán nhãn mức độ nghiêm trọng cũng tất yếu mang tính chủ quan. Điều này đúng ngay cả với chương trình CVE, vốn đưa ra một công thức để phân tách các khía cạnh liên quan của một lỗ hổng, chẳng hạn vector tấn công, độ phức tạp, và khả năng khai thác. Tuy nhiên, tất cả những thứ đó đều đòi hỏi đánh giá chủ quan.
Chúng tôi tin rằng những mô tả tốt về lỗ hổng hữu ích hơn các chỉ dấu mức độ nghiêm trọng. Một mô tả tốt có thể phân tách rõ vấn đề là gì, nó có thể bị kích hoạt ra sao, và người dùng nên cân nhắc những gì khi xác định tác động lên phần mềm của chính họ.
Cứ thoải mái gửi issue nếu bạn muốn chia sẻ suy nghĩ của mình với chúng tôi về chủ đề này.