GitHub mở rộng cơ sở dữ liệu cảnh báo mã độc từ npm sang OpenSSF

Các cảnh báo phần mềm độc hại (malware) trên GitHub không còn chỉ dừng lại ở npm. Dưới đây là cách chúng tôi tích hợp dữ liệu về các gói phần mềm độc hại từ OpenSSF vào Advisory Database, và lý do tại sao chúng tôi xây dựng đường ống (pipeline) này với tâm thế cảnh giác cao độ.

Ngày 6 tháng 8 năm 2026

5 phút đọc

Một gói phần mềm bị xâm nhập có thể đánh cắp thông tin xác thực ngay khi bạn cài đặt nó, và cho đến gần đây, GitHub chỉ có thể gắn cờ các gói này trong npm. Nhưng điều đó đã thay đổi. Đây là câu chuyện về cách đội ngũ kỹ thuật chuỗi cung ứng đứng sau Dependabot mở rộng các cảnh báo phần mềm độc hại ra tám hệ sinh thái bằng cách xây dựng dựa trên dữ liệu về các gói phần mềm độc hại được chia sẻ từ OpenSSF.

Tình hình hiện tại như sau: đầu năm nay, Dependabot đã bắt đầu gắn cờ phần mềm độc hại trong các phụ thuộc (dependencies) npm của bạn. Tin tuyệt vời nếu bạn là người viết JavaScript. Giờ đây, chúng tôi đang mang chức năng tương tự đó đến với PyPI.

Chúng tôi đã nâng cấp GitHub Advisory Database để tiếp nhận các báo cáo phần mềm độc hại từ kho lưu trữ malicious-packages của OpenSSF, đồng nghĩa với việc các cảnh báo phần mềm độc hại và các thông báo Dependabot dựa trên đó sẽ bao phủ tất cả tám hệ sinh thái gói phần mềm chính: npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io và PHP Composer. Tôi là người dẫn dắt đội ngũ Dependabot trong tổ chức bảo mật chuỗi cung ứng của GitHub, và trong bài viết này, tôi sẽ cho bạn thấy cách đường ống này hoạt động.

Từ một hệ sinh thái lên tám hệ sinh thái

Advisory Database đã nhập dữ liệu lỗ hổng từ các nguồn bên ngoài trong nhiều năm. RubySec cho gems, RustSec cho crates, PyPA cho Python. Mỗi nguồn là một trình nhập (importer) đọc một kho lưu trữ cảnh báo công khai và ánh xạ các bản ghi vào cơ sở dữ liệu của chúng tôi. Phần mềm độc hại là trường hợp ngoại lệ: nó đi qua một con đường nội bộ riêng biệt, chỉ dành cho npm, được xây dựng dựa trên khả năng phát hiện các gói npm độc hại của chính GitHub.

Việc mở rộng khả năng phát hiện hiện có từ một lên tám hệ sinh thái được hỗ trợ sẽ tiêu tốn của chúng tôi nhiều năm. Trong khi đó, OpenSSF đã giải quyết vấn đề tổng hợp dữ liệu cho tất cả mọi người. Kho lưu trữ malicious-packages của họ ra mắt vào năm 2023, với hơn 15.000 báo cáo ở định dạng OSV. Kể từ đó, nó phát triển mỗi ngày, được cung cấp bởi các đóng góp từ cộng đồng và các nguồn phát hiện tự động trên toàn ngành: typosquatting (tên gói gây nhầm lẫn), các gói gây nhầm lẫn phụ thuộc, chiếm đoạt tài khoản, các tệp nhị phân độc hại được xây dựng sẵn. Nó công khai, có cấu trúc và bao phủ bất kỳ hệ sinh thái nào mà lược đồ OSV hỗ trợ.

Vì vậy, thiết kế gần như tự hoàn thiện. Thay vì xây dựng tám hệ thống phát hiện riêng biệt, chúng tôi đã xây dựng một trình nhập duy nhất.

Trình nhập (The importer)

Chúng tôi tái sử dụng cùng một mô hình mà các trình nhập dựa trên kho lưu trữ của chúng tôi đã tuân theo để duyệt qua cây tệp của kho lưu trữ nguồn, chọn các tệp đã thay đổi kể từ lần chạy cuối cùng và xử lý từng tệp một. Trình nhập OpenSSF mới đọc mọi bản ghi OSV và xác thực các trường, kiểu dữ liệu và định dạng bắt buộc so với lược đồ trước khi bất kỳ dữ liệu nào chạm đến cơ sở dữ liệu. Một bản ghi không vượt qua được xác thực này sẽ bị từ chối và ghi nhật ký. Nó không bao giờ được vá lỗi âm thầm rồi cho qua, bởi vì một cảnh báo phần mềm độc hại "gần như hợp lệ" chính là thứ sẽ gây rắc rối cho bạn sáu tháng sau đó.

Các bản ghi hợp lệ được chuẩn hóa thành các mục tin (feed entries): nguồn, định danh, ID CVE (nếu có), bản ghi gốc hoàn chỉnh được lưu dưới dạng ảnh chụp nhanh (snapshot), và tập hợp con đã ánh xạ mà đường ống xuất bản của chúng tôi sử dụng.

Việc chuẩn hóa nghe có vẻ nhàm chán cho đến khi bạn thực sự tiếp cận dữ liệu. Các chuỗi hệ sinh thái thượng nguồn không phải lúc nào cũng khớp với chúng tôi (kho lưu trữ ghi PyPI, cơ sở dữ liệu của chúng tôi ghi pip). Các bản ghi OSV liệt kê các phiên bản bị ảnh hưởng dưới dạng các giá trị rời rạc trong khi chúng tôi tư duy theo phạm vi, và một số bản ghi không nêu tên phiên bản nào có thể sử dụng được. Trường chi tiết thường xuyên bị trống, và khi nhiều nguồn báo cáo cùng một gói, các mô tả của chúng được gộp thành một khối. Các báo cáo cũng có thể bị rút lại: kho lưu trữ giữ một thư mục osv/withdrawn riêng cho các cảnh báo hóa ra là sai, vì vậy trình nhập phải xử lý trường hợp một gói bị gắn cờ vào thứ Hai nhưng lại bị bác bỏ vào thứ Tư.

Sau đó là vấn đề khử trùng lặp (dedup), và đây là một vấn đề thú vị. Bản thân GitHub cũng là một người đóng góp cho kho lưu trữ OpenSSF; các cảnh báo phần mềm độc hại npm của chính chúng tôi cũng chảy ngược lên đó. Nếu nhập kho lưu trữ một cách ngây thơ, chúng tôi sẽ nhập lại dữ liệu của chính mình trong một vòng lặp. Giải pháp nằm ở siêu dữ liệu nguồn gốc của OSV: mọi mục trong malicious-packages đều ghi lại nguồn gốc của báo cáo, và bất kỳ thứ gì được gắn thẻ ghsa-malware đều bắt đầu từ chúng tôi. Trình nhập sẽ loại bỏ những mục đó trước khi một mục tin được tạo ra.

Khi chúng tôi xác thực với dữ liệu thực tế, hơn một nửa số báo cáo npm mới đổ vào kho lưu trữ mỗi tháng đều bắt nguồn từ các cảnh báo của chính chúng tôi và bị bỏ qua như những vòng lặp, vì vậy những gì trình nhập thu thập được là những thứ mà chúng tôi thực sự chưa biết tới.

Quy trình tiếp nhận cảnh báo và các biện pháp phòng ngừa bảo mật mà chúng tôi đang thực hiện

Một câu hỏi chiếm ưu thế trong quá trình đánh giá bảo mật của chúng tôi: điều gì sẽ xảy ra nếu dữ liệu thượng nguồn bị lỗi?

Các cảnh báo phần mềm độc hại được tự động xuất bản. Không có con người nào đọc từng cảnh báo trước khi nó được đưa ra, và đó là điều có chủ đích. Khi một gói đang đánh cắp thông tin xác thực ngay lúc này, một hàng đợi đánh giá kéo dài hàng ngày là một món quà cho kẻ tấn công. Sự khác biệt có chủ đích ở đây là các cảnh báo tự động xuất bản này giờ đây có thể tạo ra các thông báo Dependabot. Các cảnh báo chưa được xem xét của chúng tôi trước đây đã được xuất bản tự động, nhưng đây là lần đầu tiên một cảnh báo tự động xuất bản có thể kích hoạt thông báo, và cần phải làm rõ lý do tại sao.

Đồng nghiệp của tôi, Madison Ficorilli, gần đây đã viết về ý nghĩa thực sự của từ "đã xem xét" (reviewed) đối với các cảnh báo về lỗ hổng bảo mật: các chuyên gia kiểm duyệt xác minh ánh xạ gói, phạm vi phiên bản và mức độ nghiêm trọng trước khi bất kỳ thứ gì được phát hành. Sự khắt khe đó xứng đáng với độ trễ khi câu hỏi đặt ra là phiên bản nào của thư viện bị lỗ hổng. Phần mềm độc hại là một vấn đề khác. Báo cáo gần như mang tính nhị phân (gói này độc hại), và thời gian quan trọng hơn sự tinh tế. Thiết kế này giả định rằng nguồn cấp dữ liệu thượng nguồn có thể một ngày nào đó chứa dữ liệu xấu: một báo cáo sai gắn cờ một gói hợp lệ, được sử dụng rộng rãi là phần mềm độc hại, một bản ghi có tên gói sai, hoặc cả một loạt báo cáo được xuất bản từ một nguồn bị xâm nhập.

Vì vậy, chúng tôi đã xây dựng một đường ống tiếp nhận linh hoạt với ba lớp bảo vệ cho chính ngày đó. Đây là cách chúng hoạt động.

Điều này có ý nghĩa gì với bạn

Dependabot và GitHub giờ đây sẽ thông báo cho bạn nếu bạn sử dụng một phụ thuộc độc hại trên hầu hết các hệ sinh thái gói phần mềm.

Các thông báo phần mềm độc hại là tùy chọn: hãy bật chúng trong cài đặt bảo mật của kho lưu trữ, tổ chức hoặc doanh nghiệp của bạn. Dependabot sẽ đối chiếu các phụ thuộc của bạn với các cảnh báo phần mềm độc hại trong Advisory Database, bao gồm cả việc quét ngược lại các cảnh báo hiện có, bắt đầu ngay từ thời điểm bạn bật tính năng này.

Thẻ:

Viết bởi

Ankit là Giám đốc Kỹ thuật cấp cao tại GitHub, nơi anh dẫn dắt đội ngũ Dependabot trong tổ chức Bảo mật Chuỗi cung ứng. Dependabot giám sát hơn 30 triệu kho lưu trữ trên hơn 34 hệ sinh thái gói phần mềm, điều này khiến anh luôn giữ sự cảnh giác cần thiết về các cuộc tấn công chuỗi cung ứng.

Bài viết liên quan

Chúng tôi cũng có bản tin (newsletter)

Khám phá các mẹo, hướng dẫn kỹ thuật và các phương pháp hay nhất trong bản tin hai tuần một lần dành riêng cho các nhà phát triển.

Địa chỉ email của bạn