Cộng đồng JavaScript đang đứng trước ngã tư đường sau cuộc tấn công được gọi là lớn nhất trong lịch sử tấn công chuỗi cung ứng. Trong khi sự hoảng loạn ban đầu đã lắng xuống và các nhà phát triển đã hoàn tất việc bảo mật hệ thống của họ, một cuộc tranh luận gay gắt đã nổ ra về việc liệu hệ sinh thái cuối cùng sẽ giải quyết những lỗ hổng bảo mật cơ bản hay tiếp tục theo cách làm việc như thường lệ.
Cuộc tấn công đã làm bùng phát lại những chỉ trích lâu nay về cách tiếp cận quản lý phụ thuộc của JavaScript , với nhiều người chỉ ra những cây phụ thuộc rộng lớn của các thư viện siêu nhỏ đã trở thành đặc trưng của hệ sinh thái npm . Tuy nhiên, phản ứng của cộng đồng cho thấy sự chia rẽ sâu sắc về cả bản chất của các vấn đề và các giải pháp tiềm năng.
Cuộc tranh luận về phụ thuộc siêu nhỏ cho thấy tiến bộ và sự dai dẳng
Một trong những vấn đề được thảo luận nhiều nhất tập trung vào các phụ thuộc siêu nhỏ như gói left-pad khét tiếng. Những người chỉ trích cho rằng việc JavaScript dựa vào các thư viện nhỏ, đơn mục đích tạo ra các bề mặt tấn công không cần thiết. Tuy nhiên, một số nhà phát triển chỉ ra rằng lời chỉ trích này ngày càng lỗi thời. Chức năng mà left-pad cung cấp đã là một phần của thư viện chuẩn JavaScript trong gần một thập kỷ thông qua String.padStart(), và xu hướng hiện tại ủng hộ mạnh mẽ zero dependencies như một điểm marketing trong phát triển frontend.
Bất chấp tiến bộ này, việc chuyển đổi khỏi các gói siêu nhỏ vẫn chưa hoàn thành. Một số nhà phát triển báo cáo gặp phải những kẻ xấu cố ý chèn thư viện của riêng họ làm phụ thuộc để thổi phồng số lượt tải xuống nhằm mục đích tài chính. Điều này cho thấy rằng trong khi cộng đồng nhận ra vấn đề, các vấn đề hệ thống vẫn tồn tại trong cách các gói được duy trì và phân phối.
Quy mô làm cho các giải pháp truyền thống trở nên không khả thi
Khi thảo luận về các bản sửa lỗi tiềm năng, nhiều người chỉ ra các bản phân phối Linux như một mô hình cho quản lý gói bảo mật. Các hệ thống này sử dụng các bộ sưu tập được tuyển chọn, người duy trì gói và quy trình xem xét nghiêm ngặt. Tuy nhiên, sự khác biệt về quy mô đặt ra những thách thức to lớn. Debian , một trong những ví dụ thành công nhất, quản lý khoảng 20.000 gói với khoảng 1.000 tình nguyện viên - tỷ lệ 20:1.
Áp dụng mô hình này cho 3 triệu gói của npm sẽ cần 150.000 tình nguyện viên, thậm chí nếu chỉ 100.000 gói được coi là đáng duy trì, nỗ lực vẫn cần 5.000 tình nguyện viên tận tụy. Việc tìm ra nhiều người có trình độ sẵn sàng làm việc miễn phí như vậy có vẻ không thực tế, đặc biệt khi bản thân Debian đã đạt tối đa khoảng 1.000 người đóng góp mặc dù là nền tảng cho một số phần mềm được sử dụng nhiều nhất trên thế giới.
So sánh quy mô: Các bản phân phối Linux so với npm
- Debian: ~20.000 gói được quản lý bởi ~1.000 tình nguyện viên (tỷ lệ 20:1)
- npm: 3 triệu gói sẽ cần 150.000 tình nguyện viên với cùng tỷ lệ
- Tập hợp con thực tế: Ngay cả 100.000 gói "đáng giá" cũng sẽ cần 5.000 tình nguyện viên
- Năng lực hiện tại của Debian: Đã đạt tối đa ~1.000 người đóng góp mặc dù được sử dụng trên toàn cầu
Các bản sửa lỗi kỹ thuật xuất hiện nhưng bỏ lỡ vấn đề gốc rễ
Cộng đồng đã bắt đầu triển khai các giải pháp kỹ thuật để làm chậm các cuộc tấn công. Các trình quản lý gói như pnpm và Yarn đang giới thiệu các yêu cầu về tuổi phát hành tối thiểu, buộc phải trì hoãn trước khi có thể cài đặt các phiên bản gói mới. Mặc dù điều này có thể bắt được một số bản cập nhật độc hại, nó tạo ra các vấn đề mới khi các bản vá bảo mật khẩn cấp cần được triển khai ngay lập tức.
Một số nhà phát triển đề xuất sử dụng hệ thống AI để tự động quét các gói tìm mã độc hại. Tuy nhiên, cách tiếp cận này đối mặt với sự hoài nghi từ các nhà phát triển có ý thức bảo mật, những người lo lắng rằng việc quét tự động có thể tạo ra sự tự tin sai lầm trong khi những kẻ tấn công tinh vi phát triển các kỹ thuật che giấu được thiết kế đặc biệt để đánh lừa hệ thống AI .
Về cơ bản, bản sửa lỗi không phải là kỹ thuật; nó là xã hội / cấu trúc. Các công ty hoặc tự chịu trách nhiệm về việc phê duyệt các phụ thuộc mà họ sử dụng, hoặc yêu cầu các kho lưu trữ chịu trách nhiệm phê duyệt các phụ thuộc, hoặc tiếp tục làm những gì chúng ta đã làm.
Các Giải Pháp Kỹ Thuật Hiện Đang Được Triển Khai
- pnpm: Cài đặt mới cho thời gian phát hành tối thiểu của gói
- Yarn: Các tùy chọn cấu hình npmMinimumReleaseAge và npmMinimumReleaseAgeExclude
- Hạn chế: Các bản vá bảo mật khẩn cấp yêu cầu loại trừ hoàn toàn khỏi yêu cầu về thời gian phát hành
- Các nền tảng thay thế: JSR.io với các mô hình tin cậy khác nhau, Deno Standard Library
Các hệ sinh thái thay thế cung cấp lối thoát có hạn
Một số nhà phát triển đang khám phá các lựa chọn thay thế như runtime JavaScript của Deno và registry gói JSR , nhấn mạnh các cách tiếp cận khác nhau đối với quản lý phụ thuộc và bảo mật. Tuy nhiên, ngay cả những lựa chọn thay thế này cũng đối mặt với thách thức khi chúng ngày càng hỗ trợ các gói npm để duy trì khả năng tương thích, có khả năng tái giới thiệu những lỗ hổng tương tự mà chúng nhằm tránh.
Cuộc thảo luận tiết lộ một căng thẳng cơ bản trong phát triển phần mềm hiện đại. Sự tiện lợi và tốc độ của các hệ thống quản lý phụ thuộc hiện tại đã cho phép đổi mới và phát triển nhanh chóng, nhưng với cái giá của bảo mật và ổn định. Hầu hết những người tham gia dường như cam chịu với các cải tiến từng bước thay vì những thay đổi cách mạng.
Cuộc tranh luận cuối cùng phản ánh những câu hỏi rộng lớn hơn về cách ngành công nghiệp phần mềm cân bằng tốc độ đổi mới với trách nhiệm bảo mật. Trong khi các giải pháp kỹ thuật tiếp tục xuất hiện, các động lực xã hội và kinh tế cơ bản đã tạo ra những vấn đề này phần lớn vẫn không thay đổi. Như một nhà quan sát lưu ý, mô hình khủng hoảng và phản ứng tối thiểu này đã lặp lại trong nhiều thập kỷ qua nhiều hệ sinh thái lập trình, cho thấy rằng cải cách có ý nghĩa có thể đòi hỏi nhiều hơn chỉ đổi mới kỹ thuật.