Tính không xác định: Thách thức lớn trong việc vá lỗi CVE và giải pháp từ Nix

Tính không xác định: Thách thức lớn trong việc vá lỗi CVE và giải pháp từ Nix

Kỷ nguyên của trí tuệ nhân tạo đang thay đổi hoàn toàn bối cảnh bảo mật phần mềm. Ngay cả trước khi các mô hình như Claude Mythos ra đời, đã có những dấu hiệu rõ ràng cho thấy làn sóng lỗ hổng CVE (Common Vulnerabilities and Exposures) tiếp theo sẽ được tìm ra bởi AI. Big Sleep đã phát hiện một lỗ hổng zero-day trong SQLite, Microsoft Copilot tìm thấy hơn 20 CVE trong các bộ tải khởi động (bootloaders), và DARPA đã tung ra AIxCC để khuyến khích việc phát hiện CVE bằng AI.

Mối đe dọa từ các lỗ hổng CVE gia tăng

Với sự xuất hiện của các mô hình AI hiện đại, chúng ta rút ra hai kết luận quan trọng: tốc độ phát hiện CVE sẽ tăng nhanh chóng khi các mô hình AI cải thiện, và chúng ta sẽ phát hiện ra nhiều CVE đã tồn tại qua nhiều phiên bản mà các nhà nghiên cứu đã bỏ sót trong hàng thập kỷ.

Trong số các loại hình lỗ hổng này, lỗ hổng trong các gói phần mềm (package CVEs) thuộc nhóm khó xử lý nhất. Hầu hết các tổ chức không có một danh sách kê khai (manifest) cập nhật cho mọi gói trong hệ thống của mình. Các trình quản lý gói ở cấp hệ thống như dnf, apt, zypper, hay các công cụ toolchain như pip, npm, cargo thường giải quyết các phiên bản gói khác nhau tùy thuộc vào nền tảng, môi trường và thời điểm. Để tự tin rằng một phụ thuộc bị lỗi không đang được sử dụng, các tổ chức phải quét thủ công toàn bộ ngăn xếp của mình. Kết hợp với số lượng CVE ngày càng tăng, vấn đề này nhanh chóng trở nên không thể quản lý.

Sự bùng nổ của các CVE này là lý do khiến các nhà phát triển cần áp dụng một hệ thống ghi chép (system of record) cho các gói đã cài đặt. Đó là lý do Flox được xây dựng: một hệ thống mã nguồn mở giúp các nhóm nền tảng và trải nghiệm phát triển (devEx) quản lý tập trung các môi trường từ phát triển đến sản xuất. Flox hoạt động dựa trên Nix, một trình quản lý gói khai báo (declarative) với đồ thị phụ thuộc có thể xác thực bằng mật mã học. Cùng nhau, Flox và Nix đảo ngược mô hình truyền thống: Thay vì phát hiện các gói bị lỗi thông qua các lần quét sau sự cố, mọi phụ thuộc đều có thể xác minh tại thời điểm xây dựng (build time) và có thể được theo dõi bởi hệ thống ghi chép của Flox.

Vấn đề của tính không xác định

Với các trình quản lý gói truyền thống, việc phân loại CVE tỷ lệ thuận với số lượng tạo phẩm (artifacts), hình ảnh, máy chủ hoặc môi trường runtime bạn chạy. Nếu bạn có n lần triển khai, bạn thường cần phân tích từng cái một, vì không có cách nào đáng tin cậy để chứng minh hai môi trường chứa chính xác cùng một tập hợp các phụ thuộc.

Sự khác biệt giữa tính không xác định và xác định

Về mặt ký hiệu Big O, đây là công việc O(n), và hầu hết trong số đó là thừa thãi.

Có một số nguồn phổ biến gây ra tính không xác định. Đối với một số trình quản lý gói (ví dụ: apt hoặc dnf), cùng một lệnh cài đặt có thể tạo ra các kết quả khác nhau dựa trên môi trường nó chạy, mirror nào được kéo dữ liệu, những gì được lưu trong bộ nhớ đệm và thời điểm lưu. Hậu quả là không có bản ghi có thể truy vấn được của đồ thị phụ thuộc trên toàn bộ ngăn xếp.

Vậy còn các tệp khóa (lockfiles) thì sao? Các lockfile thông dụng như Cargo.lock hay package-lock.json rất hữu ích vì chúng giảm thiểu sự trôi dạt của bộ giải quyết (resolver) trong một hệ sinh thái gói. Tuy nhiên, lockfile không phải là mô tả khai báo, xác định của toàn bộ môi trường runtime: tức là hình ảnh cơ sở, thư viện gốc, công cụ, chứng chỉ, biến môi trường và các phụ thuộc chuyển tiếp tạo nên môi trường mà ứng dụng chạy.

Khi một lỗ hổng gói được công bố, các tổ chức thường phải tìm kiếm trên các dịch vụ, hình ảnh, máy chủ và môi trường runtime để xác định mức độ tiếp xúc của họ. Gói bị lỗi có thể không phải là thứ mà bất kỳ ai (hoặc bất kỳ thứ gì) cố tình cài đặt; thường xuyên, nó là một phụ thuộc chuyển tiếp được đưa vào bởi một gói khác, hình ảnh cơ sở hoặc thư viện hệ thống. Đây là logic cốt lõi đằng sau lớp tấn công chuỗi cung ứng phụ thuộc chuyển tiếp mà chúng ta đã thấy.

Nix và Flox: Chuyển từ O(n) sang O(u)

Nix thay đổi những gì bạn phân tích. Mọi môi trường Nix hoặc Flox đều giải quyết thành tập hợp hoàn chỉnh và chuyển tiếp của các gói và đầu vào xây dựng được sử dụng để tạo ra nó. Trong ngôn ngữ của Nix, điều này được gọi là "closure". Các closure được định địa chỉ theo đầu vào (input-addressed), vì vậy nếu hai môi trường giải quyết cùng một đường dẫn lưu trữ Nix, chúng có thể được coi là cùng một đơn vị cho việc phân loại CVE; bạn không cần kiểm tra cả hai một cách độc lập để chứng minh rằng các tập hợp phụ thuộc của chúng khớp nhau.

Điều này biến việc phân loại thành một bài toán khử trùng lặp. Nếu n môi trường của bạn chỉ chia sẻ u tập hợp phụ thuộc riêng biệt, công việc tốn kém (như kiểm tra gói nào bị ảnh hưởng hoặc xác thực bản vá) sẽ chạy một lần cho mỗi tập hợp phụ thuộc thay vì một lần cho mỗi môi trường. Ví dụ, nếu 500 môi trường thu gọn lại thành 50 tập hợp phụ thuộc duy nhất, thì công việc phân loại không còn là "quét 500 thứ", mà tương đương với:

• Ánh xạ mỗi môi trường tới tập hợp phụ thuộc của nó.
• Nhóm các môi trường có cùng tập hợp phụ thuộc.
• Phân tích từng tập hợp phụ thuộc duy nhất một lần.
• Tái sử dụng kết quả cho mọi môi trường trong nhóm đó.

Trong ký hiệu Big O, việc phân tích tốn kém chuyển từ O(n) trên 500 môi trường sang O(u) trên 50 tập hợp phụ thuộc duy nhất.

Cơ chế hoạt động của Nix

Hơn nữa, với Nix và Flox, bằng chứng mà các nhóm cần để giải quyết hai câu hỏi tốn kém nhất về gói-CVE đã được ghi lại trong một tệp khóa và hiện thực hóa trong môi trường đã giải quyết. Để xác định các môi trường bị ảnh hưởng, các nhóm truy vấn xem các lockfile, closure hoặc SBOM nào chứa gói bị ảnh hưởng, sau đó ánh xạ các bản ghi đó trở lại các môi trường sử dụng chúng. Để xác nhận việc khắc phục, họ so sánh đồ thị thay thế và xác nhận rằng gói bị lỗi không còn tồn tại.

Tại sao Nix lại xác định?

Nix đạt được tính xác định bằng cách đảo ngược mô hình quy ước mà chúng ta sử dụng để xây dựng, đóng gói và tiêu thụ phần mềm. Hầu hết các trình quản lý gói cài đặt các tạo phẩm được xây dựng sẵn vào một ngữ cảnh hệ thống toàn cầu có thể thay đổi (mutable), sao cho môi trường cuối cùng — ngữ cảnh mà tạo phẩm chạy — được xác định bởi trạng thái của các kho lưu trữ thượng nguồn, trạng thái của máy chủ và tất cả các đầu vào xung quanh khác.

Nix đi theo hướng ngược lại: nó xây dựng các gói từ các đầu vào được khai báo và lưu trữ chúng vào các đường dẫn lưu trữ bất biến (immutable). Nếu một thay thế nhị phân được xây dựng sẵn được sử dụng từ bộ nhớ đệm, nó vẫn tương ứng với một đường dẫn lưu trữ Nix đã băm. Đó là chìa khóa: Nix không coi các tệp nhị phân đã tải xuống là các gói tùy ý; nó coi chúng là đầu ra của các công thức xây dựng đã biết với các đầu vào được khai báo.

Mô hình này làm cho đồ thị phụ thuộc có thể truy vấn được. Đầu ra xây dựng của Nix nằm trong các đường dẫn lưu trữ bất biến, và mỗi đầu ra nhúng đồ thị phụ thuộc chuyển tiếp hoàn chỉnh của nó: gói, các phụ thuộc của nó và các phụ thuộc của những phụ thuộc đó. Môi trường kết quả có thể được kiểm tra, khử trùng lặp và tái sử dụng cho việc phân loại CVE, chuyển đơn vị phân tích từ "Cái gì đang được cài đặt trên máy chủ hoặc hình ảnh này?" sang "Những đồ thị phụ thuộc đã giải quyết nào chứa các gói bị lỗi?".

Kỷ nguyên mới của bảo mật

Chúng ta hy vọng bài viết này mang lại cái nhìn sâu sắc về lý do tại sao chúng tôi dành nhiều năm đóng góp cho vũ trụ Nix. Mong muốn của chúng tôi là tạo ra một trường hợp thuyết phục cho việc quản lý gói xác định và một hệ thống ghi chép trước làn sóng thủy triều CVE sắp tới. Trong một kỷ nguyên tự động hóa không ngừng nghỉ, chúng tôi tin rằng bảo mật tốt sẽ quan trọng hơn bao giờ hết.

Nix là một trình quản lý gói rất khác so với các dự án phổ biến như dnf, apt, brew, v.v. Lý do chính là sự khác biệt về giá trị. Hầu hết các trình quản lý gói ưu tiên sự tiện lợi và thời gian xây dựng nhanh. Nix ưu tiên tính hermeticism (sự cô lập), và tính hermeticism khá tốn kém. Mọi thứ đều được xây dựng trong sự cô lập; ngay cả với các bản sao được lưu trong bộ nhớ đệm, điều đó có nghĩa là thời gian xây dựng dài hơn và nhiều dung lượng đĩa hơn.

Tuy nhiên, ngày nay chúng ta sống trong một kỷ nguyên khác. Dung lượng đĩa không khan hiếm như trước, và chúng ta có băng thông Internet dồi dào. Khi so sánh với nhu cầu của các hệ thống AI, yêu cầu tài nguyên của Nix khá khiêm tốn. Con lắc có thể chuyển từ việc ưu tiên thời gian xây dựng hiệu quả sang việc ưu tiên thời gian khắc phục hiệu quả, đặc biệt là khi các tác nhân AI làm tăng khối lượng CVE.

Trong tương lai, việc sửa chữa CVE sẽ đơn giản như việc định vị phụ thuộc trong manifest.lock, điều chỉnh manifest.toml và khóa lại (re-locking), xây dựng lại, sau đó triển khai lại cho bất kỳ môi trường nào bị ảnh hưởng. Vì quá trình xây dựng hoàn toàn xác định: nếu nó hoạt động cục bộ, nó sẽ hoạt động trong môi trường sản xuất.