Bên trong Cơ sở dữ liệu tư vấn và điều gì xảy ra khi khối lượng lỗ hổng phá vỡ kỷ lục
Vào tháng 5 năm 2026, Cơ sở dữ liệu tư vấn GitHub đã xuất bản 1.560 lời khuyên được đánh giá—gấp hơn năm lần sản lượng hàng tháng thông thường của chúng tôi và là mức cao nhất trong lịch sử.
Và nó vẫn không đủ để theo kịp.
Trong vài tháng qua, hệ sinh thái dễ bị tổn thương đã thay đổi một cách cơ bản. Đầu vào từ các báo cáo lỗ hổng riêng tư, tư vấn kho lưu trữ và yêu cầu CVE đã tăng lên đồng thời, đẩy toàn bộ hệ thống lên quy mô hoạt động mới.
Blog này được xây dựng dựa trên cuộc thảo luận đang diễn ra của cộng đồng GitHub, theo dõi bản chất ngày càng phát triển của báo cáo lỗ hổng bảo mật, cũng như sự phát triển lộ trình của Cơ sở dữ liệu tư vấn và PVR. Chủ đề định kỳ trong chủ đề đó là tác động xuôi dòng của những thay đổi nền tảng đối với việc quản lý tư vấn và chất lượng dữ liệu. Điều này phù hợp với sự thay đổi rộng rãi hơn của GitHub hướng tới việc nhấn mạnh chất lượng và trách nhiệm chung trong việc báo cáo lỗ hổng bảo mật, từ đó trực tiếp định hình cách quản lý và duy trì dữ liệu tư vấn.
TL;DR
Thời gian xem xét các tư vấn mới lâu hơn vì số lượng và mức độ phức tạp của lỗ hổng đã tăng lên đáng kể. Chất lượng tư vấn không thay đổi: các tư vấn được xem xét vẫn được con người xác thực và các cảnh báo hiện có tiếp tục hoạt động bình thường. Nếu bạn muốn trợ giúp, hãy tập trung vào ba điều: gửi dữ liệu về lỗ hổng bảo mật hoàn chỉnh, phối hợp chặt chẽ với các nhà bảo trì và nhà nghiên cứu, đồng thời chỉ yêu cầu CVE khi có ý định xuất bản rõ ràng.
Ghi lại đầu ra và đầu vào chưa từng có
Tháng Năm không phải là sự tăng đột biến một lần. Từ tháng 3 đến tháng 5, chúng tôi phải đưa ra hơn 6.000 quyết định tư vấn mỗi tháng. Điều này bao gồm việc cập nhật các tư vấn hiện có, xuất bản các tư vấn mới và xem xét các tư vấn gửi đến và vượt quá mọi mức cao nhất trong ba tháng trước đó.
Đồng thời, dòng vốn vào tăng tốc trên mọi nguồn:
• Báo cáo về lỗ hổng bảo mật riêng tư trên nền tảng đã tăng từ ~550/tuần trong tháng 1 lên hơn 3.000/tuần trong hầu hết tháng 5.
• Tư vấn về kho lưu trữ tăng từ ~650/tuần lên hơn 5.000/tuần.
• Yêu cầu GitHub CNA CVE đã đạt gần 4.000 chỉ trong tháng 5, gần gấp 10 lần so với cùng kỳ năm ngoái.
• Chương trình CVE đã xuất bản hơn 30.000 CVE vào năm 2026.
• Tổng cộng hơn 1,7 triệu kho lưu trữ đã cho phép báo cáo lỗ hổng bảo mật riêng tư.
Đây không phải là sự đột biến cục bộ. Nó phản ánh sự thay đổi cấu trúc trên hệ sinh thái tiết lộ lỗ hổng bảo mật.
tác động
Kể từ giữa tháng 4, do sự gia tăng đột biến này, chúng tôi đã không liên tục đạt được các mục tiêu nội bộ về xuất bản. Thời gian xử lý lúc đầu kéo dài đến khoảng một tuần, sau đó lên nhiều tuần để có được một lượt chia sẻ có ý nghĩa. Thời gian xuất bản dài hơn có thể làm tăng thời gian hiển thị. Chúng tôi rất coi trọng điều đó và tính kịp thời là một phần cốt lõi của giá trị mà cơ sở dữ liệu này mang lại.
Những gì vẫn đang hoạt động
Đường ống dữ liệu và cơ sở hạ tầng xuất bản của chúng tôi đã tiếp tục hoạt động trong giai đoạn này. Quá trình nhập đang diễn ra, tính toàn vẹn của dữ liệu vẫn nguyên vẹn và các tư vấn được công bố đều chính xác. Các tư vấn đạt trạng thái được đánh giá ngày nay đều đáp ứng tiêu chuẩn chất lượng như trước đây.
Chất lượng nhiệm vụ CVE vẫn tốt. Tỷ lệ phân công của chúng tôi đã giữ ở mức từ 91–94% trong toàn bộ đợt tăng đột biến, phù hợp hoặc tốt hơn các tiêu chuẩn lịch sử và cho thấy rằng chưa có sự suy giảm rõ ràng nào về số lượng yêu cầu mà chúng tôi nhận được.
Vấn đề là thông lượng. Hệ thống xác nhận, làm phong phú và xuất bản dữ liệu tư vấn đang hoạt động; nó hiện đang hoạt động vượt quá khối lượng và độ phức tạp mà nó được thiết kế để xử lý.
Công việc không đồng đều
Không phải mọi tư vấn bảo mật đều yêu cầu mức độ nỗ lực như nhau. Một số được gửi đến với định dạng rõ ràng: chi tiết tư vấn nêu rõ tên gói bị ảnh hưởng và hệ sinh thái liên quan của nó, phạm vi phiên bản được ghi lại và bản sửa lỗi được gắn thẻ. Người phụ trách có thể xác nhận và xuất bản những thông tin này trong vòng chưa đầy vài phút.
Nhưng tỷ lệ tư vấn sắp tới ngày càng tăng đòi hỏi phải điều tra nhiều hơn:
• Phân biệt gói hàng. Chi tiết tư vấn có nội dung “foo”, nhưng đó là foo trên npm, python-foo trên PyPI hay foo không liên quan trên Maven? Khi dữ liệu ngược dòng không chỉ định hệ sinh thái, người phụ trách của chúng tôi sẽ tìm ra điều đó.
• Xây dựng lại phạm vi phiên bản. Nhiều tư vấn bảo mật được đưa ra mà không có phạm vi phiên bản bị ảnh hưởng hoặc có phạm vi không khớp với lịch sử phát hành thực tế. Người quản lý theo dõi các cam kết, nhật ký thay đổi và thẻ để xác định những gì thực sự bị ảnh hưởng.
• Tư vấn đa hệ sinh thái. Một số dự án gửi gói đến nhiều cơ quan đăng ký, chẳng hạn như thư viện có cả triển khai .NET (NuGet) và triển khai JavaScript (npm) có cùng chức năng, trong đó lỗ hổng trong logic chia sẻ ảnh hưởng đến cả hai. Điều này yêu cầu xác minh độc lập trên nhiều nguồn dữ liệu.
• Xung đột dữ liệu ngược dòng. Khi bản ghi CVE, lời khuyên của người bảo trì và lịch sử cam kết không thống nhất được về những gì bị ảnh hưởng thì ai đó phải xác định sự thật.
Trong lịch sử, những lời khuyên đơn giản hơn chiếm ưu thế và những lời khuyên khó hơn có thể được tiếp thu. Khi khối lượng tăng lên, hàng đợi sẽ lấp đầy cả hai và những hàng phức tạp sẽ mất nhiều thời gian hơn, tạo ra hiệu ứng gộp. Sự kết hợp bây giờ quan trọng hơn nhiều. Đây không chỉ là việc làm thêm; nó phức tạp hơn đáng kể.
"Đã xem xét" thực sự có nghĩa là gì
Một tư vấn được xem xét lại không chỉ đơn giản là một bản ghi được xuất bản lại; đó là kết quả của việc xác minh.
• Lập bản đồ các lỗ hổng cho gói hệ sinh thái chính xác
• Xác thực các phiên bản bị ảnh hưởng và đã sửa lỗi dựa trên lịch sử phát hành
• Xác nhận độ chính xác ngược dòng
• Kiểm tra sự trùng lặp và nhất quán
• Xác thực việc phân loại và cho điểm
Đây là điều cho phép các công cụ tiếp theo dựa vào dữ liệu mà không cần xác thực bổ sung.
Việc xuất bản nhanh hơn bằng cách bỏ qua quá trình xác minh sẽ làm tăng số lượng báo cáo sai trên quy mô lớn, điều này có thể tạo ra nhiều rủi ro hơn là sự chậm trễ.
Một sự thay đổi hệ sinh thái rộng lớn hơn
Xu hướng này vượt ra ngoài GitHub.
Số lượng lỗ hổng được báo cáo và công bố tiếp tục tăng nhanh và các tổ chức trên toàn hệ sinh thái đang thích ứng với sự thay đổi đó.
Hệ thống đang hoạt động như thiết kế. Nhiều lỗ hổng đang được báo cáo, tiết lộ và theo dõi hơn bao giờ hết. Điều đó tạo ra áp lực ở hạ lưu, bao gồm cả trong quá trình giám tuyển tư vấn.
Những gì chúng tôi đang làm bây giờ
• Cải thiện chất lượng và thông lượng đóng góp của cộng đồng. Đóng góp của cộng đồng là một phần quan trọng trong cách chúng tôi cải thiện Cơ sở dữ liệu tư vấn và mỗi đóng góp đều được xem xét theo tiêu chuẩn xác thực giống như bất kỳ tư vấn nào khác. Chúng tôi đã tăng cường phân loại và ưu tiên để các bài gửi chất lượng cao được xác định sớm hơn, được xem xét nhất quán hơn và được chuyển qua hàng đợi nhanh hơn. Điều này giúp chúng tôi đáp ứng khối lượng hiện tại đồng thời củng cố mục tiêu chính của chúng tôi là duy trì bộ dữ liệu đáng tin cậy, chất lượng cao.
• Mở rộng quy mô hệ thống đằng sau việc giám tuyển. Chúng tôi đã tăng cường các khía cạnh về năng lực của hệ thống quản lý phụ trợ để xử lý thông lượng ổn định cao hơn và chúng tôi đang tiếp tục hiện đại hóa cơ sở hạ tầng dữ liệu hỗ trợ phân tích và quản lý hàng đợi.
• Xây dựng các công cụ nghiên cứu có sự hỗ trợ của AI. Chúng tôi đã phát triển và triển khai công cụ hỗ trợ AI cho người phụ trách trong giai đoạn nghiên cứu đánh giá tư vấn. Người quản lý vẫn đưa ra mọi quyết định, nhưng nghiên cứu thường lệ có thể được hoàn thành nhanh hơn để có được tư vấn chất lượng cao hơn.
• Mở rộng tự động hóa ở những nơi hữu ích nhất. Chúng tôi đã cải thiện khả năng tự động hóa để trích xuất thêm dữ liệu từ thông tin CVE ngược dòng và để xử lý cách các đóng góp của cộng đồng tương tác với các tư vấn đã được xem xét. Công việc đó làm giảm thời gian cho mỗi quyết định mà không làm giảm tiêu chuẩn chất lượng.
• Đầu tư vào tài liệu và đào tạo. Chúng tôi đã mở rộng đáng kể tài liệu hoạt động của mình. Điều này cho phép chúng tôi giúp các thành viên mới trong nhóm phát triển nhanh hơn và cải thiện tính nhất quán trong toàn nhóm.
Những gì chúng tôi đang xây dựng tiếp theo
Để hỗ trợ quy mô mới này, chúng tôi đang đầu tư vào:
• Giảm thời gian tư vấn cho những trường hợp phổ biến nhất. Một phần đáng kể của các tư vấn sắp tới yêu cầu nghiên cứu tuân theo các mẫu có thể dự đoán được, chẳng hạn như xác định gói chính xác, xác nhận phạm vi phiên bản và kiểm tra cách khắc phục. Chúng tôi đang đầu tư vào công cụ giúp đẩy nhanh các mô hình này, để người quản lý có thể dành thời gian cho những trường hợp thực sự mơ hồ đòi hỏi sự phán xét của con người.
• Làm cho việc ưu tiên đánh giá dựa trên rủi ro trở nên thông minh hơn. Chúng tôi đang khám phá các tín hiệu rủi ro bổ sung để ưu tiên, chẳng hạn như việc sử dụng gói, bằng chứng về việc khai thác tích cực và tác động đến hệ sinh thái để đảm bảo những lời khuyên quan trọng nhất sẽ đến tay người dùng trước tiên.
• Cải thiện vòng phản hồi với các nguồn dữ liệu ngược dòng. Một phần đáng kể thời gian quản lý được dành để sửa dữ liệu ngược dòng không đầy đủ hoặc không chính xác. Chúng tôi đang đầu tư vào việc tích hợp chặt chẽ hơn với các nguồn mà chúng tôi sử dụng, đặc biệt là thông qua việc xác thực dữ liệu Tư vấn bảo mật GitHub và Báo cáo lỗ hổng bảo mật riêng tư trong kho lưu trữ tăng cường, để các vấn đề về chất lượng dữ liệu được giải quyết gần với nguồn gốc hơn là trong hàng đợi xem xét của chúng tôi.
• Tiếp tục minh bạch. Chúng tôi sẽ chia sẻ thông tin cập nhật về tiến trình của mình khi chúng tôi đạt được điều đó. Nếu mọi thứ được cải thiện, chúng tôi sẽ cho bạn biết. Nếu chúng tôi gặp phải những thử thách mới, chúng tôi cũng sẽ chia sẻ điều đó.
Điều này có ý nghĩa gì với bạn
• Người dùng Dependabot: Các cảnh báo hiện tại không bị ảnh hưởng. Các tư vấn mới có thể mất nhiều thời gian hơn để kích hoạt, ưu tiên các vấn đề quan trọng.
• Người tiêu dùng API và thức ăn chăn nuôi: Dữ liệu được đánh giá vẫn chính xác; những lời khuyên chưa được xem xét có thể nhìn thấy nhưng chưa được xác thực.
• Người bảo trì: Các tư vấn về kho lưu trữ tiếp tục được đưa vào cơ sở dữ liệu toàn cầu; ưu tiên dựa trên một số yếu tố, bao gồm tác động và mức độ nghiêm trọng của dự án.
Bạn có thể giúp bằng cách nào
Bao gồm dữ liệu đầy đủ trong các báo cáo về lỗ hổng. Việc cung cấp phạm vi phiên bản bị ảnh hưởng, nguyên nhân cốt lõi và các bước sao chép rõ ràng sẽ tạo ra sự khác biệt trực tiếp về cách xem xét tư vấn nhanh chóng và chính xác. Khi dữ liệu này hoàn tất, quá trình quản lý có thể mất vài phút. Nếu không, người quản lý phải xây dựng lại các chi tiết còn thiếu từ mã nguồn, lịch sử phát hành và các tín hiệu ngược dòng xung đột. Ở quy mô này, những khoảng trống đó sẽ tăng lên nhanh chóng. Dữ liệu ngược dòng chất lượng cao là một trong những cách hiệu quả nhất để cải thiện cả tốc độ và độ chính xác trên toàn hệ sinh thái.
Bao gồm các chi tiết tư vấn phù hợp. Hướng dẫn thực hành tốt nhất của chúng tôi bao gồm phân loại hệ sinh thái, tên gói và định dạng phạm vi phiên bản, nhưng một số chi tiết bổ sung sẽ tạo ra sự khác biệt trực tiếp về cách xem xét và xuất bản các tư vấn nhanh chóng và chính xác lên Cơ sở dữ liệu tư vấn GitHub.
• Sử dụng tên gói giống như tên xuất hiện trong sổ đăng ký. Tên gói tư vấn phải khớp với sổ đăng ký, không phải tên kho lưu trữ hoặc tên dự án. Các hệ thống hạ nguồn dựa vào mã nhận dạng đăng ký để khớp với lời khuyên cho các phần phụ thuộc bị ảnh hưởng. Nếu tên không chính xác hoặc bị thiếu, cảnh báo sẽ không được tạo một cách đáng tin cậy và người dùng bị ảnh hưởng có thể không bao giờ được thông báo. Việc sử dụng tên đăng ký đảm bảo tư vấn có thể được liên kết, lập chỉ mục và phân phối chính xác.
• Liệt kê tất cả các gói bị ảnh hưởng. Một số lỗ hổng ảnh hưởng đến nhiều gói trong một dự án. Mỗi gói bị ảnh hưởng phải được liệt kê riêng với hệ sinh thái, tên gói và phạm vi phiên bản riêng. Các tư vấn được sử dụng ở cấp độ gói, vì vậy việc thiếu một gói có nghĩa là thiếu những người dùng phụ thuộc vào gói đó. Việc bao gồm tất cả các gói bị ảnh hưởng đã biết sẽ cải thiện phạm vi phủ sóng và đảm bảo cảnh báo đến được với toàn bộ người dùng bị ảnh hưởng.
• Cung cấp chuỗi vectơ CVSS hoàn chỉnh. Cơ sở dữ liệu tư vấn GitHub hỗ trợ CVSS 3.1 và 4.0. Nhãn mức độ nghiêm trọng như “Cao” là một bản tóm tắt nhanh nhưng chuỗi vectơ CVSS hoàn chỉnh bao gồm một tập hợp các thuộc tính phong phú hơn, chẳng hạn như độ phức tạp của cuộc tấn công, các đặc quyền bắt buộc và tương tác của người dùng, mô tả lỗ hổng chi tiết hơn. Thông tin có cấu trúc này cho phép xác thực mức độ nghiêm trọng, diễn giải một cách nhất quán và được sử dụng bởi các công cụ hạ nguồn để ưu tiên hóa và tự động hóa. Nếu không có nó, việc chấm điểm sẽ kém chính xác hơn và khó so sánh giữa các lời khuyên. Nếu bạn bao gồm điểm, hãy sử dụng máy tính chính thức và bao gồm vectơ đầy đủ.
• Bao gồm phân loại CWE có liên quan. CWE xác định điểm yếu tiềm ẩn đằng sau lỗ hổng bảo mật, chẳng hạn như tập lệnh chéo trang, chèn SQL hoặc giải tuần tự hóa dữ liệu không đáng tin cậy. Không giống như mô tả tường thuật, CWE cung cấp cho các nhóm bảo mật và công cụ tiếp theo một cách được tiêu chuẩn hóa để hiểu loại vấn đề mà họ đang giải quyết. Điều đó quan trọng vì dữ liệu CWE có thể được sử dụng để phân loại, lọc, ưu tiên và so sánh các lỗ hổng trên các tập dữ liệu lớn. Nó giúp các tổ chức nhóm các vấn đề liên quan, áp dụng chính sách hoặc quy tắc báo cáo và hiểu các mẫu lỗ hổng ảnh hưởng đến phần mềm của họ. CWE càng cụ thể thì lời khuyên càng hữu ích cho người tiêu dùng ở hạ nguồn.
Để biết thêm hướng dẫn, hãy xem các phương pháp hay nhất để viết lời khuyên bảo mật rõ ràng, đầy đủ.
Hãy có chủ ý khi yêu cầu CVE. Yêu cầu ID CVE báo hiệu rằng lỗ hổng sẽ được tiết lộ và theo dõi công khai. Khi các yêu cầu được đưa ra mà không có kế hoạch xuất bản, nó có thể làm mất thời gian và sự chú ý khỏi những lời khuyên đang tích cực hướng tới việc phát hành. Việc điều chỉnh các yêu cầu CVE với mục đích xuất bản rõ ràng giúp đảm bảo rằng nỗ lực được tập trung vào nơi nó có tác động tức thời nhất và giúp hệ thống luôn phản hồi nhanh chóng cho mọi người.
Phối hợp chặt chẽ với người bảo trì và các nhà nghiên cứu khác. Dữ liệu tư vấn chất lượng cao phụ thuộc vào bối cảnh được chia sẻ. Việc căn chỉnh các gói, phạm vi phiên bản và bản sửa lỗi bị ảnh hưởng giúp giảm sự mơ hồ và thông tin xung đột giữa các nguồn. Ở quy mô này, những khoảng cách nhỏ trong việc phối hợp có thể trở thành những mâu thuẫn lớn ở hạ lưu.
Cải thiện chất lượng tư vấn bằng cách đóng góp các yêu cầu kéo vào Cơ sở dữ liệu tư vấn. Mọi sửa đổi đối với phạm vi phiên bản, ánh xạ gói hoặc bản sửa lỗi đều cải thiện độ chính xác mà các nhà phát triển dựa vào.
Nhận biết quy mô của sự thay đổi hệ sinh thái này và tham gia vào nó. Sự gia tăng báo cáo về lỗ hổng phản ánh sự tiến bộ thực sự. Nhiều vấn đề đang được phát hiện, khắc phục và tiết lộ hơn bao giờ hết. Việc duy trì chất lượng ở quy mô này phụ thuộc vào các nhà nghiên cứu, người bảo trì, người tiêu dùng và nhà sản xuất dữ liệu cùng làm việc để hướng tới cùng một mục tiêu.
Bức tranh lớn hơn
Hai năm trước, cơ sở dữ liệu đã xuất bản ~270 lời khuyên mỗi tháng.
Vào tháng 5 năm 2026, nó đã xuất bản hơn 1.500 quyết định trong khi xử lý hàng nghìn quyết định bổ sung trên toàn hệ thống.
Điều này phản ánh một sự thay đổi rộng lớn hơn:
• Nhiều kho lưu trữ hơn đang cho phép tiết lộ có trách nhiệm.
• Nhiều nhà nghiên cứu đang báo cáo các lỗ hổng.
• Nhiều nhà bảo trì đang xuất bản các bản sửa lỗi và lời khuyên.
• Hệ sinh thái dễ bị tổn thương đang mở rộng theo hướng minh bạch hơn.
Sự tăng trưởng đó tạo ra áp lực lên các hệ thống như của chúng ta. Nhưng nó cũng đại diện cho sự tiến bộ có ý nghĩa.
Mọi lời khuyên đều cải thiện khả năng hiển thị. Mỗi cảnh báo đều làm giảm rủi ro.
Chúng tôi đang mở rộng quy mô để đáp ứng thực tế đó và chúng tôi sẽ tiếp tục chia sẻ tiến trình như chúng tôi đã làm.
Bài đăng Bên trong cơ sở dữ liệu tư vấn và điều gì sẽ xảy ra khi số lượng lỗ hổng bị phá vỡ kỷ lục xuất hiện đầu tiên trên Blog GitHub.