Tại sao Dependabot áp dụng cơ chế chờ 3 ngày trước khi cập nhật phiên bản?

Một khoảng thời gian chờ mặc định mới kéo dài ba ngày sẽ trì hoãn các yêu cầu kéo (pull request) cập nhật phiên bản, giúp các nhà bảo trì và chuyên gia bảo mật có thời gian xử lý các vấn đề phát hiện được trong bản phát hành trước khi nó xâm nhập vào mã nguồn của bạn.

Ngày 23 tháng 7 năm 2026

4 phút

Vào tháng 9 năm 2025, một kẻ tấn công đã lừa đảo lấy thông tin đăng nhập của một nhà bảo trì npm và xuất bản các phiên bản chứa mã độc của chalk, debug cùng khoảng hơn một chục gói khác, vốn được tải xuống tổng cộng hơn 2 tỷ lần mỗi tuần. Đoạn mã này đã tự động ghi đè các địa chỉ ví tiền điện tử bên trong bất kỳ ứng dụng trình duyệt nào tải nó. Các phiên bản bị nhiễm độc này đã tồn tại khoảng hai giờ trước khi cộng đồng phát hiện và npm gỡ bỏ chúng.

Hai giờ là thời gian phản ứng nhanh. Tuy nhiên, đó cũng là khoảng thời gian quá đủ để một công cụ cập nhật tự động nhận diện phiên bản mới, mở một yêu cầu kéo và đưa nó đến trước đội ngũ của bạn, vì các công cụ cập nhật phiên bản được thiết kế để lấy bản phát hành mới nhất ngay khi nó vừa xuất hiện.

Mô hình đó là nguyên nhân đằng sau một tỷ lệ ngày càng tăng các cuộc tấn công chuỗi cung ứng. Mã độc "đi nhờ" trên một bản phát hành hoàn toàn mới, được xuất bản lên một kho lưu trữ công cộng và bị kéo vào các quy trình xây dựng (build pipelines) chỉ trong vài phút, trước khi con người hoặc trình quét kịp xem xét nó.

Một khoảng thời gian chờ sẽ thay đổi bài toán đó. Việc đợi vài ngày trước khi áp dụng một bản phát hành mới sẽ tạo điều kiện cho các nhà bảo trì, chuyên gia bảo mật và các trình quét tự động có thời gian phát hiện phiên bản độc hại và gỡ bỏ nó trước khi nó kịp tiếp cận các yêu cầu kéo của bạn.

Đối với các bản cập nhật phiên bản không liên quan đến bảo mật, Dependabot hiện sẽ đợi ít nhất ba ngày sau khi bản phát hành được công bố trước khi mở yêu cầu kéo. Tuy nhiên, tùy chọn cấu hình cooldown trong dependabot.yml vẫn kiểm soát hành vi này, vì vậy bạn có thể chọn một tham số thời gian chờ khác phù hợp với dự án của mình.

Các nghiên cứu điển hình và dữ liệu từ GitHub Advisory Database

Khi kẻ tấn công xâm nhập vào một gói phổ biến, phiên bản bị nhiễm độc thường có vòng đời ngắn. Nó được xuất bản, lan truyền qua bất kỳ nơi nào cài đặt nó, và bị bắt giữ, thường là trong vòng vài giờ. Ví dụ trước đó chỉ tồn tại trong hai giờ. Các gói được sử dụng rộng rãi khác cũng đi theo quỹ đạo tương tự, với các bản dựng bị xâm nhập của Solana web3.js, Axios và ua-parser-js đều bị phát hiện trong vòng vài giờ sau khi xuất bản.

Tổng quát hơn, GitHub nhìn thấy mô hình này trực tiếp thông qua GitHub Advisory Database, nơi lưu trữ các thông báo bảo mật mã nguồn mở trên khắp các hệ sinh thái. Trong năm kết thúc vào tháng 5 năm 2026, cơ sở dữ liệu này đã công bố hơn 6.500 thông báo về phần mềm độc hại trên npm, tăng từ khoảng 6.200 của năm trước đó, tương đương với khoảng 18 gói npm độc hại mới được lập danh mục mỗi ngày. Khoảng thời gian chờ giúp bạn tránh khỏi "cửa sổ" nguy hiểm đó và cho phép bản phát hành được xem xét kỹ lưỡng hơn trước khi nó đến tay bạn.

Tại sao lại là ba ngày?

Phần mềm độc hại được xuất bản nhắm vào các gói phổ biến thường bị phát hiện rất nhanh. Một cuộc đánh giá 21 sự cố chuỗi cung ứng được báo cáo rộng rãi từ năm 2018 đến 2026 cho thấy cùng một mô hình: các phiên bản độc hại của axios, Solana web3.js, ua-parser-js và Ledger Connect Kit đều bị gỡ bỏ trong vòng vài giờ sau khi xuất bản, và một khoảng thời gian chờ có thể đã lọc bỏ phần lớn các bản phát hành tồn tại ngắn hạn này trước khi bất kỳ ai kịp cài đặt chúng.

Ba ngày là mức mặc định cân bằng giữa hai mục tiêu: nó giúp bạn vượt qua khoảng thời gian mà hầu hết các cuộc tấn công này tồn tại, và nó không giữ các phụ thuộc của bạn lại lâu hơn mức cần thiết.

Các thành viên khác trong cộng đồng cũng đã chọn khoảng thời gian chờ ba ngày (mặc dù một số nơi chọn lâu hơn), vì vậy hành vi mặc định này giúp Dependabot duy trì tính nhất quán khi các nhà phát triển chuyển đổi giữa các công cụ.

Bạn luôn có thể thiết lập khoảng thời gian dài hơn hoặc ngắn hơn với tùy chọn cấu hình cooldown của Dependabot.

Phòng thủ theo chiều sâu

Khoảng thời gian chờ được xây dựng cho một mô hình cụ thể: một phiên bản độc hại được phát hành, lan truyền và bị phát hiện nhanh chóng. Nó ít có tác dụng đối với các cuộc tấn công có kế hoạch dài hơi hơn, bao gồm các cửa sau (backdoor) được cài cắm trong các bản phát hành và để ở trạng thái ngủ, sự phá hoại từ chính nhà bảo trì, hoặc hệ thống xây dựng bị xâm nhập. Mục đích của thiết lập mặc định này là loại bỏ một con đường tấn công phổ biến và nhạy cảm về thời gian, chứ không phải để thay thế cho các lớp phòng thủ còn lại của bạn.

Vì khoảng thời gian chờ chỉ giải quyết các trường hợp diễn ra nhanh chóng, nó nên là một lớp trong số nhiều lớp bảo mật. Một số bước bổ sung cần thực hiện bao gồm ghim các phụ thuộc bằng lockfiles, vô hiệu hóa các tập lệnh cài đặt trong CI nếu có thể, giới hạn phạm vi các token trong quy trình xây dựng của bạn và xem xét các bản cập nhật trước khi hợp nhất (merge).

Nếu bạn muốn tùy chỉnh thời gian trì hoãn cho các gói nội bộ có độ tin cậy cao so với các kho lưu trữ công cộng, hãy xem tài liệu về cách cấu hình Dependabot. Hoặc xem tài liệu tham khảo về các tùy chọn cấu hình Dependabot để biết đầy đủ các tham số cooldown.

Hướng đi tiếp theo

Đây là một bước trong số nhiều bước chúng tôi đang thực hiện để củng cố chuỗi cung ứng phần mềm cho tất cả những ai xây dựng trên GitHub. Tính năng này được bật theo mặc định, vì vậy bạn không cần phải thay đổi bất cứ điều gì để kích hoạt nó. Bạn cũng có thể điều chỉnh nó để phù hợp với quy trình làm việc của mình.

Hãy cho chúng tôi biết hiệu quả của nó trong các cuộc thảo luận cộng đồng Dependabot.

Tác giả

Carlin là Giám đốc Sản phẩm tại GitHub, làm việc trong bộ phận GitHub Advanced Security, tập trung vào Dependabot. Nền tảng của cô về kỹ thuật phần mềm và khoa học dữ liệu đã định hình cách tiếp cận dựa trên dữ liệu trong quản lý sản phẩm. Cô sống tại Washington cùng bạn đời và chú chó Cookie, dành thời gian rảnh để đạp xe và chơi các trò chơi board game cạnh tranh.

Bài viết liên quan

Cách GitHub trao cho mỗi kho lưu trữ một chủ sở hữu bền vững

GitHub từng có hơn 14.000 kho lưu trữ. Ít hơn một nửa trong số đó có quyền sở hữu rõ ràng. Đây là cách chúng tôi đã trao cho mỗi kho lưu trữ đang hoạt động một chủ sở hữu được xác thực trong vòng chưa đầy 45 ngày, lưu trữ phần còn lại và biến quyền sở hữu thành nền tảng cho mọi thứ theo sau.

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

Khám phá các mẹo, hướng dẫn kỹ thuật và các phương pháp tốt 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