"Dependency cooldowns" biến bạn thành kẻ trục lợi: Tại sao chúng không phải là giải pháp bảo mật tối ưu?

"Dependency cooldowns" (thời gian chờ phụ thuộc) đang bất ngờ trở thành một xu hướng nổi bật trong giới công nghệ. Chúng nhanh chóng được khuyến nghị rộng rãi và dường như sắp được đưa vào danh sách các "thực hành tốt nhất tiêu chuẩn" của ngành. Hy vọng đằng sau phương pháp này là: bằng cách chờ đợi N ngày sau khi phát hành trước khi áp dụng một phiên bản mới — thay vì cập nhật ngay lập tức — bất kỳ mã độc nào được chèn lén sẽ được người khác phát hiện ra và bản phát hành có vấn đề sẽ bị "gỡ bỏ".

Nhà trong tuyết

Về mặt lý thuyết, đây dường như là một cách tiếp cận hiệu quả vì hầu hết các cuộc tấn công chuỗi cung ứng thực sự được phát hiện trong vài ngày. Tuy nhiên, mặc dù "dependency cooldowns" mang lại lợi ích khiêm tốn cho cá nhân áp dụng chúng, chúng lại đặt ra gánh nặng lớn lên những người khác. Hơn nữa, phương pháp này không giải quyết được vấn đề cốt lõi: việc xuất bản và phân phối là hai hoạt động khác nhau và không có lý do gì chúng phải bị ràng buộc chặt chẽ với nhau.

Sự yếu kém của hành động cá nhân

Thẳng thắn mà nói, "dependency cooldowns" hoạt động dựa trên việc kẻ trục lợi (free-rider) trên nỗi đau và sự tổn thất của người khác. Nguyên tắc cơ bản trong kế hoạch này là hy vọng rằng những người khác — những người không đủ thông minh để cấu hình thời gian chờ — sẽ đóng vai trò là những người thử nghiệm beta (beta testers) bất đắc dĩ và không công cho các gói phần mềm mới phát hành. Nếu có vấn đề, những người kém may mắn đó sẽ bị tấn công, mọi người nhận ra họ bị hack, và gói phần mềm/tệp thực thi có vấn đề sẽ bị gỡ bỏ trước khi ngưỡng thời gian chờ của những người áp dụng cooldown được đạt tới.

Ngay cả khi cách này có hiệu quả với cá nhân, tôi cho rằng không thể duy trì nó như một hệ thống hợp lý hoặc đạo đức cho toàn bộ hệ sinh thái.

Một vấn đề khác là "dependency cooldowns" yêu cầu nhiều nhóm người khác nhau phải thực hiện công việc. Hiện tại Python có nhiều trình quản lý gói (bao nhiêu rồi nhỉ? 8?). Tất cả đều phải triển khai tính năng cooldown. Và mọi dự án từng được tạo ra đều phải cấu hình thời gian chờ — điều này thường không dễ dàng hay rõ ràng, vì các trình quản lý gói thường chọn những cách hoàn toàn khác nhau để thực hiện điều đó.

Thực tế, ngay cả những người áp dụng cooldown cũng chịu thiệt. Rất dễ dàng vô tình lách qua thời gian chờ mà bạn đã khôn ngoan cấu hình trong tệp dự án của mình. Trong Python, một lệnh pip install litellm cá nhân đơn bên ngoài cấu hình dự án gần đây đã khiến người dùng bị tấn công. Vì vậy, cách tiếp cận cooldown thực sự không hoàn toàn, cũng không đặc biệt an toàn.

Tại một thời điểm nào đó, có thể thông qua việc sử dụng LLM hoặc cách sao chép-dán truyền thống — vì đó là cách phần lớn cấu hình dự án được tạo ra — một "cooldown" có trách nhiệm sẽ trở thành mặc định trên thực tế. Và, để nói theo Greenspun, bất kỳ "dependency cooldown" nào đủ phổ biến sẽ trở thành một bản triển khai hàng đợi tải lên (upload queue) đặc thù, được quy định không chính thức, đầy lỗ hổng và chậm chạp.

Hàng đợi tải lên — Lợi ích của hành động tập trung

Sự thay thế rõ ràng là thay vì mọi người cấu hình thời gian chờ — lặp đi lặp lại, nhiều lần — trong các trình quản lý gói và dự án khác nhau, chúng ta chỉ cần làm điều đó một lần, duy nhất, tại máy chủ phụ thuộc trung tâm. Một "hàng đợi tải lên". Buộc các gói mới phải chờ một khoảng thời gian sau khi được xuất bản trước khi chúng được phân phối.

(Tôi dùng từ "xuất bản" ở đây để chỉ việc gửi bản phát hành (tarball, whl, gem, v.v.) đến chỉ mục trung tâm (npm, pypi, rubygems). Ngược lại, "Phân phối" là khi chỉ mục trung tâm bắt đầu phục vụ bản phát hành đó cho công chúng).

Trong khoảng thời gian sau khi xuất bản nhưng trước khi phân phối, bạn có thể chạy các công cụ lint nội bộ, cung cấp gói cho các trình quét bảo mật tự động hóa bên ngoài (tên thương hiệu của họ nên được hiển thị nổi bật nếu họ tìm thấy gì đó), hiển thị diff công khai của các thay đổi trong gói đã xây dựng và thậm chí cung cấp các bản phát hành đang trong hàng đợi cho những người thử nghiệm beta tự nguyện, rõ ràng để dùng thử.

Hàng đợi tải lên có tiền lệ. Dự án Debian sử dụng một hàng đợi tải lên. Các gói được tải lên kho lưu trữ và sau đó đối mặt với thời gian chờ tối thiểu là 2-10 ngày trước khi lọt vào bản phân phối "testing". Hàng đợi tải lên tách biệt việc xuất bản gói và phân phối gói.

Xuất bản là tạo một gói và đăng nó lên kho lưu trữ. Phân phối là khi gói được cung cấp cho công chúng. Không có lý do đặc biệt nào hai hoạt động này cần phải xảy ra cùng một lúc — nó chỉ là một tai nạn lịch sử của cách các chỉ mục gói đặc thù cho từng ngôn ngữ phát triển.

Hàng đợi tải lên đạt được cùng mục tiêu với "dependency cooldowns", nhưng không có bất kỳ vấn đề nào. Hàng đợi tải lên giải quyết vấn đề kẻ trục lợi: không còn những người gặp khó khăn về cấu hình bị dùng làm chuột bạch miễn phí cho những người áp dụng cooldown. Các trình quản lý gói không cần triển khai bất cứ thứ gì. Các dự án không cần thêm một tùy chọn cấu hình nữa. Các công cụ lint bảo mật không cần cảnh báo về nó. Và ngay cả khi vô tình cài đặt một gói lẻ trên máy tính xách tay của nhà phát triển mà không có cấu hình, bạn vẫn được bảo vệ.

Loại bỏ yếu tố bất ngờ

Hàng đợi tải lên có một lợi ích đáng kể khác. Trong phần lớn các cuộc tấn công chuỗi cung ứng, không chỉ các mã độc được chèn vào là trái phép — toàn bộ bản phát hành là trái phép. Việc buộc các gói đã xuất bản phải "ngồi chờ" trong vài ngày làm giảm đáng kể quyền lực của thông tin đăng ký phát hành. Điều đó quan trọng vì làm cho một thứ gì đó ít quyền lực hơn là một điều tốt thứ hai sau khi bảo mật nó tốt hơn.

Việc buộc các bản phát hành đã xuất bản phải ngồi chờ trong vài ngày trước khi phân phối cũng loại bỏ yếu tố bất ngờ hoàn toàn không cần thiết khi một bản phát hành mới xuất hiện. Nó cung cấp cho người dùng thông báo trước rằng một bản phát hành mới sắp tới và kiến thức trước chính xác khi nào nó sẽ có sẵn.

Và không chỉ người dùng cần kiến thức trước. Khoảng thời gian trong hàng đợi tải lên cũng là thời điểm tốt để thông báo cho những người bảo trì (maintainers), đảm bảo rằng họ thực sự biết về bản phát hành sắp tới. "Thông báo: Bản phát hành 2.4.1 đã nhập hàng đợi tải lên" sẽ là lời gọi cần thiết để ngăn chặn cuộc tấn công chuỗi cung ứng được triển khai trong nhiều trường hợp.

Điều này áp dụng gấp đôi cho AI

Ít người nói điều này một cách rõ ràng nhưng, LLM có nghĩa là markdown hiện nay là một định dạng tệp thực thi. Điều đó thú vị hay đáng sợ (hoặc cả hai!) có lẽ phụ thuộc vào sở thích cá nhân. Nhưng đó là một sự thật đơn giản; và sau cùng đó là cách Agent Skills hoạt động: bạn tải xuống một số tệp markdown, và bây giờ LLM của bạn có một phụ thuộc bên thứ ba mới.

Cuộc tấn công chuỗi cung ứng lớn đầu tiên trên LLM chắc chắn chỉ là vấn đề thời gian — ai đó chèn lệnh "Bỏ qua điều đó!" (Disregard that!) của họ vào một số tệp markdown phổ biến.

Tôi đã suy nghĩ về vấn đề này cho một dự án phụ của mình là một hệ thống bộ nhớ công cộng cho các tác nhân AI gọi là "Soapstones". Đó là nơi cho chúng (nghĩa là các tác nhân AI) ghi lại cách làm mọi việc; như tìm kiếm bài đăng HN, lấy thời tiết hiện tại, tra cứu tỷ giá hối đoái, v.v. Soapstones thực chất là một trình quản lý gói cho các tệp markdown. Và, vì nó là như vậy, vấn đề tấn công chuỗi cung ứng tồn tại.

Thực tế nó áp dụng gấp đôi. Không chỉ mọi người có thể làm độc các tệp markdown bằng các lệnh "Bỏ qua điều đó!" mà LLM có thể foolishly tải lên thông tin bí mật cho hệ thống — chẳng hạn như khóa API của chúng.

Và giải pháp ở đây, cũng vậy, là một hàng đợi tải lên. Thực tế là một hàng đợi tải lên kép. Người kiểm duyệt xem xét từng lần tải lên để tìm các cuộc tấn công chuỗi cung ứng. Và chủ sở hữu của các tác nhân xem xét từng lần tải lên để đảm bảo họ cũng chấp nhận nó.

Tôi nghĩ hàng đợi tải lên là lựa chọn hợp lý duy nhất ở đây — tôi không thể chỉ yêu cầu LLM "hãy cẩn thận khi tải xuống thứ mới được tải lên" — điều đó sẽ là điên rồ.

Tài chính có phải vấn đề? Rõ ràng là không

Một phản bác có thể xảy ra là "ai sẽ trả tiền cho việc này?". Đầu tiên, không rõ rằng cần nguồn vốn khổng lồ. Dự án Debian đã duy trì một hàng đợi tải lên trong nhiều thập kỷ và có một đội ngũ bảo mật who đẩy nhanh các ngoại lệ vì lý do bảo mật.

Thứ hai, không rõ ràng rằng mọi chỉ mục gói quan trọng thực sự thiếu tiền mặt. NPM, Inc là một khởi nghiệp được rót vốn mạo hiểm và hiện là công ty con thuộc sở hữu hoàn toàn của Microsoft. Python Software Foundation, người vận hành PyPI, đã có một danh sách dài các nhà tài trợ doanh nghiệp, nhiều người trong số họ sẽ được hưởng lợi từ một hàng đợi tải lên. Và PSF thậm chí gần đây đã nhận được 1,5 triệu đô la từ Anthropic cho, trong số những thứ khác: bảo mật chuỗi cung ứng.

Nhưng một lựa chọn khác là cung cấp các đánh giá bảo mật đẩy nhanh cho các dự án thương mại như một dịch vụ trả phí.

Các thực thể thương mại thường vội vã muốn đưa ra phiên bản mới càng sớm càng tốt — để sửa một số lỗi (không phải bảo mật) đang ảnh hưởng đến khách hàng, để đưa ra một thông báo lớn hoặc chỉ để đẩy nhanh một việc loại bỏ quan trọng phía máy chủ. Chỉ cần tính phí họ cho đánh giá đẩy nhanh như một dịch vụ trả phí.

Đánh giá đẩy nhanh sẽ không phải là một lựa chọn không tham gia quy trình. Nó không có nghĩa là bản phát hành được phân phối ngay lập tức ngay khi công ty nhấn "xuất bản" ở phía họ — tất cả các thứ tự tự động vẫn nên chạy đến hoàn thành. Thay vào đó, một kiểm tra thủ công đơn giản có nghĩa là thời gian thực tế trên đồng hồ có thể được giảm đáng kể cho một bản phát hành cụ thể.

Các chỉ mục gói đã cần các đội ngũ phản hồi bảo mật: gỡ bỏ các bản phát hành, duy trì các lệnh cấm, xử lý việc đánh lừa tên miền (typosquatting) và điều phối các lỗ hổng 0-day. Tính phí cho các dự án thương mại cho đánh giá đẩy nhanh là một cách tốt để tài trợ chéo cho việc đó. Sự khẩn cấp của doanh nghiệp trợ cấp cho bộ máy bảo mật phục vụ toàn bộ hệ sinh thái.

Hợp lý về mặt cá nhân, điên rồ về mặt tập thể

"Dependency cooldowns" là một trong những thứ phục vụ bạn khá tốt khi bạn tự làm nó. Và chúng ta đều làm điều đó ở một mức độ nào đó. Đối với một số thứ, tôi không muốn là người đầu tiên nâng cấp: hộp set-top TV gia đình là hạ tầng quan trọng sứ mệnh trong hộ gia đình của tôi.

Nhưng về mặt chất lượng, việc biến các phản hồi cá nhân, chủ quan cho từng tình huống nâng cấp thành hóa thạch thành các thực hành tốt nhất của cộng đồng là hoàn toàn khác biệt. Tôi không muốn bảo mật của mình phụ thuộc vào việc người khác bị hack trước.