Project Zero bỏ chính sách 90+30, chuyển sang tiết lộ sau 30 ngày

Nhóm nghiên cứu bảo mật Google Project Zero vừa công bố chính sách tiết lộ lỗ hổng mới mang tên "Full X", theo đó thời gian các nhà sản xuất được phép sửa lỗi sẽ bị rút ngắn theo lộ trình. Nhóm cho biết sự phát triển của AI và mô hình ngôn ngữ lớn (LLM) đã khiến kẻ tấn công tìm và khai thác lỗ hổng nhanh hơn rất nhiều, nên mốc thời gian cũ không còn phù hợp.

Từ "90 + 30" sang "Full X"

Từ năm 2021, Project Zero áp dụng chính sách tiết lộ "90 + 30": nhà sản xuất có tối đa 90 ngày để khắc phục lỗ hổng, cộng thêm 30 ngày "soak time" để triển khai bản vá. Mục tiêu là thúc đẩy vá lỗi nhanh hơn đồng thời cho nhà sản xuất thời gian đưa bản vá đến người dùng.

Theo chính sách mới, lỗ hổng sẽ được công bố sau X ngày kể từ khi báo cáo cho nhà sản xuất. Lộ trình cụ thể:

• Từ hôm nay: chính sách "Full 90", tiết lộ sau 90 ngày.
• Ngày 2/2/2027: chuyển sang "Full 60", tiết lộ sau 60 ngày.
• Ngày 3/1/2028: chuyển sang "Full 30", tiết lộ sau 30 ngày.

Project Zero cũng loại bỏ phần lớn các "trường hợp đặc biệt", bao gồm thời gian ân hạn (grace period) và chính sách biến thể (variant policy). Chỉ còn ba ngoại lệ: lỗ hổng đang bị khai thác thực tế (ITW) sẽ xử lý theo chính sách tiết lộ lỗ hổng ứng dụng của Google; lỗ hổng đã được bên khác công khai thì Project Zero có thể công bố chi tiết theo quyết định của mình; và trường hợp nhà sản xuất yêu cầu công khai.

Vì sao rút ngắn dần thay vì đột ngột?

Project Zero cho biết đã lấy ý kiến từ những nhà sản xuất mà nhóm báo cáo nhiều lỗ hổng nhất. Lo ngại chung là nếu đổi chính sách ngay lập tức, lỗ hổng chưa được vá có thể lọt vào tay kẻ tấn công trong lúc nhà sản xuất còn đang cải thiện quy trình và công nghệ khắc phục.

Hai lo ngại tinh tế hơn cũng được nêu ra: một chính sách quá cứng rắn sẽ khiến các lỗi báo cáo theo chính sách mới được ưu tiên sửa trước, kể cả khi chúng ít nghiêm trọng hơn các lỗ hổng khác; và nếu áp đặt ngay một thời hạn mà nhiều nhà sản xuất chưa đủ năng lực đáp ứng, họ có thể chấp nhận việc không sửa nổi lỗi kịp hạn và bỏ luôn nỗ lực.

Nhóm kỳ vọng lộ trình "khó nhưng thực tế" này sẽ giúp nhà sản xuất cải thiện toàn diện quy trình và hạ tầng khắc phục lỗ hổng.

Mức độ nghiêm trọng không còn là căn cứ quyết định

Project Zero chỉ báo cáo các lỗ hổng có mức độ nghiêm trọng đáng kể và tác động bảo mật đã được chứng minh. Tuy vậy, nhóm cho rằng mức độ nghiêm trọng (severity) không phải thước đo hiệu quả để quyết định việc tiết lộ, đặc biệt trong bối cảnh hiện nay: nó không làm thay đổi khả năng lỗ hổng bị kẻ tấn công phát hiện, chỉ phản ánh tác động lên người dùng.

Khi nhà sản xuất dùng mức độ nghiêm trọng để sắp xếp thứ tự sửa lỗi, họ đang quyết định mức rủi ro chấp nhận cho người dùng. Việc chấp nhận rủi ro với các lỗi ít nghiêm trọng như lỗi con trỏ null không thể khai thác hay rò rỉ thông tin nhỏ là hợp lý trong nhiều tình huống, nhưng điều đó không có nghĩa lỗ hổng không còn trong tầm với của kẻ tấn công.

Nhóm cũng nhấn mạnh Project Zero tự đặt tiêu chuẩn cao về khả năng tái hiện, tính dễ đọc, khả năng tiếp cận và tác động bảo mật của lỗ hổng được báo cáo. Chính sách mới giả định các báo cáo đạt chất lượng này, và việc nhà sản xuất đối xử khác với những báo cáo chất lượng thấp là điều hợp lý.

Còn phần cứng và việc kiểm tra đã vá hay chưa?

Project Zero khuyến khích mọi nhà sản xuất tính đến cách ứng phó khi một lỗ hổng nghiêm trọng sắp bị tiết lộ, kể cả các chiến lược không dùng bản vá, vì không có gì bảo đảm phía phòng thủ sẽ tìm ra lỗi đầu tiên. Nhóm cho biết đã từng hiếm hoi tạo ngoại lệ, như với Spectre và Meltdown, và sẽ tiếp tục làm vậy trong tương lai.

Về câu hỏi liệu nhóm có kiểm tra lỗi đã được sửa hay chưa, Project Zero thừa nhận đây là vấn đề khó và chưa thực sự được giải quyết, nhất là với mã không được phát hành trực tiếp cho người dùng và không công khai. Việc phải trao đổi nhiều lần với nhà sản xuất cho mỗi báo cáo để thống nhất một lỗ hổng đã được sửa hay chưa là chuyện thường gặp, và còn phức tạp hơn khi nhiều nhà sản xuất thử nghiệm các chiến lược khắc phục không dùng bản vá như tạm vô hiệu hóa các nhánh mã.

Theo chính sách mới, việc lỗi đã được sửa hay chưa sẽ không còn là điểm quyết định. Nhóm vẫn theo dõi và thông báo nếu lỗi chưa được xử lý, nhưng nhờ đó có thể chia sẻ chi tiết kỹ thuật về cách người dùng được bảo vệ mà không phải đưa ra phán quyết nhị phân gây hệ lụy cho nhà sản xuất.

Góc nhìn

Với các kỹ sư và doanh nghiệp phần mềm tại Việt Nam, thay đổi này là một lời nhắc rằng thời gian "vùng an toàn" sau khi nhận báo cáo lỗ hổng đang ngắn lại theo từng năm. Khi mô hình LLM giúp việc dịch ngược bản vá và khai thác lỗ hổng nhanh hơn, khoảng thời gian từ lúc phát hành bản vá đến lúc người dùng cập nhật — patch gap — trở thành rủi ro thực sự chứ không chỉ là chi tiết vận hành.

Điều này đặt yêu cầu rõ ràng hơn với quy trình nội bộ: theo dõi và cập nhật các thành phần phụ thuộc sớm hơn, giảm thời gian từ khi có bản vá đến khi triển khai, và chuẩn bị sẵn các phương án giảm thiểu không dùng bản vá như tắt tạm chức năng bị ảnh hưởng. Một kế hoạch khắc phục lỗ hổng có mốc thời gian cụ thể sẽ giúp doanh nghiệp chủ động hơn thay vì chạy theo hạn tiết lộ.