Báo cáo lỗ hổng không còn là thứ đặc biệt nữa

• Trong việc bảo trì mã nguồn mở, issue và PR thông thường có thể được xử lý tùy chọn, nhưng trước đây báo cáo lỗ hổng là ngoại lệ cần phản hồi riêng để bảo vệ người dùng
• Tính ngoại lệ đó cung cấp hiểu biết khan hiếm và sự giữ bí mật để nhà nghiên cứu có thể sửa trước kẻ tấn công, và dự án đáp lại bằng cấu trúc gồm phản hồi nhanh, điều tra, chia sẻ tiến độ và ghi nhận công lao
• Đến năm 2026, cả người bảo trì lẫn kẻ tấn công đều có thể chạy LLM, nên nút thắt chuyển từ việc phát hiện vấn đề tiềm ẩn sang sàng lọc lỗ hổng thực sự
• Nhà nghiên cứu bên ngoài không có quan hệ tin cậy khó có thể đóng góp đáng kể cho việc sàng lọc, và tỷ lệ tín hiệu trên nhiễu của việc rà soát đầu ra LLM với việc kiểm tra hộp thư security@ trở nên tương tự nhau
• Thời gian của người bảo trì nên được dành nhiều hơn cho phân loại, vá nhanh và phòng ngừa, thay vì chỉ phản hồi báo cáo, đồng thời cũng cần cách chạy phân tích LLM trong CI

---

Vì sao báo cáo lỗ hổng từng là ngoại lệ

• Người bảo trì mã nguồn mở làm việc công khai thường xem issue, PR và phản hồi như những món quà, có thể chấp nhận, bỏ qua hoặc chỉ dùng một phần tùy nhu cầu
• Báo cáo lỗ hổng trước đây là một trường hợp đặc biệt nằm ngoài nguyên tắc đó
  • Thay vì công bố ngay, nhà nghiên cứu bảo mật chọn báo cáo riêng tư để dự án có thời gian sửa trước
  • Thông lệ chung là dự án xác nhận báo cáo nhanh chóng, điều tra, chia sẻ tiến độ với người báo cáo và cuối cùng ghi nhận công lao phát hiện
• Những kỳ vọng này xuất phát từ tiền đề rằng người báo cáo không phải là người đòi hỏi sửa bug hay triển khai tính năng, mà là người đang cung cấp dịch vụ cho dự án
  • Giá trị cốt lõi là hiểu biết và tính bảo mật giúp có thể phát hành bản sửa trước khi kẻ tấn công tung ra exploit
  • Bỏ qua báo cáo lỗ hổng bị xem như tín hiệu cho thấy dự án không quan tâm đến an toàn của người dùng

Những tiền đề sụp đổ vào năm 2026

• Đến năm 2026, những tiền đề từng khiến báo cáo lỗ hổng trở nên đặc biệt không còn dễ duy trì nữa
  • LLM làm tốt gần như mọi nhà nghiên cứu bảo mật và bất kỳ ai cũng có thể chạy chúng
  • Người bảo trì có thể dùng cùng công cụ đó, và kẻ tấn công cũng vậy
• Thứ đang thiếu không phải là khả năng tìm ra vấn đề tiềm ẩn, mà là công việc phân loại để xác định trong số đó cái nào là lỗ hổng thực sự
• Nhà nghiên cứu bên ngoài không có quan hệ tin cậy sẵn có khó có thể đóng góp có ý nghĩa cho quá trình phân loại này
  • Tỷ lệ tín hiệu trên nhiễu giữa việc xem đầu ra LLM và lướt qua hộp thư security@ gần như là như nhau
• Tầm quan trọng của việc giữ bí mật, embargo và điều phối cũng giảm đi so với trước
  • Kẻ tấn công có thể hỏi chính LLM của mình về lỗ hổng thay vì chờ các bài công bố công khai đầy đủ
  • Tuy vậy, kẻ tấn công nhiều khả năng cũng gặp cùng nút thắt phân loại như bên phòng thủ

Sự thay đổi trong ưu tiên của người bảo trì

• Có thể thời kỳ báo cáo lỗ hổng là thứ đặc biệt đã kết thúc
• Điều quan trọng hơn lúc này là phân loại, vá nhanh và phòng ngừa
• Cần tìm cách chạy phân tích LLM trong CI
• Quan điểm này không phải lập trường chính thức của đội Go Security, mà là ý kiến cá nhân của cựu trưởng nhóm Go Security
• Khi việc xử lý báo cáo lỗ hổng xung đột với việc thực thi Code of Conduct thì không có đáp án đúng duy nhất
  • Cần đánh giá dựa trên mức độ nghiêm trọng của hành vi, đó là vấn đề riêng tư hay ảnh hưởng đến cộng đồng, và nguồn lực của đội xử lý security@
• Thực hành công bố có một lịch sử phức tạp
  • Trước đây từng có trường hợp nhà nghiên cứu thiện chí bị đe dọa pháp lý hoặc bị truy tố
  • Trong thực tế mã nguồn mở năm 2026, không còn nhà nghiên cứu nào sợ bị truy tố vì báo cáo lỗ hổng, và các dự án cũng không nên ám chỉ truy tố như một phương án thay cho chính sách báo cáo được tài liệu hóa
• Việc curl tạm dừng kênh báo cáo lỗ hổng trong một tháng ban đầu có vẻ quá tay, nhưng để bảo vệ người dùng, không còn rõ liệu phản hồi báo cáo lỗ hổng có còn là cách dùng thời gian tốt nhất hay không

[GN⁺]

Ý kiến trên Lobste.rs

• Tôi vẫn cho rằng việc công khai lỗ hổng quá sớm giúp kẻ tấn công nhiều hơn rất nhiều so với bên phòng thủ. Theo trải nghiệm trực tiếp của tôi, ngay cả khi dùng các mô hình tiên tiến nhất thì tỷ lệ dương tính giả đôi khi vẫn gần 90%
  Nói thêm, tôi thấy có câu “việc bảo trì và phát triển bền vững các giao thức mật mã mã nguồn mở là yếu tố quan trọng để công nghệ blockchain được chấp nhận rộng rãi”, và thật ngạc nhiên là đến giờ vẫn còn người tin vào công nghệ blockchain

  • Tôi cũng bối rối không hiểu vì sao câu đó lại xuất hiện, nhưng rồi mới biết đó là thông điệp từ một trong các nhà tài trợ của Fillippo
    Ở thời điểm này, có lẽ đóng góp giá trị nhất mà công nghệ blockchain mang lại cho thế giới là tạo ra động lực tài chính rất mạnh để xây dựng các triển khai giao thức mật mã thực sự an toàn. Một phần trong số đó có thể cũng trở nên hữu ích cho mọi người khác
  • Tôi muốn hỏi dương tính giả ở đây nghĩa là gì. Có phải là mô hình khẳng định đã tìm thấy lỗ hổng, nhưng khi xác minh thì hóa ra không phải vấn đề thật không?
    Tôi cứ nghĩ đến lúc này thì việc tìm lỗ hổng và hiểu mã nói chung đã khá được xác lập là những việc LLM làm tốt, nên tôi tò mò thực tế có đúng vậy không. Sẽ rất hay nếu bạn có thể giải thích thêm về trải nghiệm trực tiếp của mình hoặc chỉ ra tài liệu tham khảo nào đáng xem. Tôi không dùng LLM nên khó cảm nhận được hiện giờ chúng đã đến mức nào, và thật lòng muốn biết liệu mình có nên thay đổi giả định hay không

• Các báo cáo lỗ hổng đặc biệt thì nên được đối xử như đặc biệt, và phía phòng thủ cần xây dựng cách xác minh tốt hơn cùng các mô hình đe dọa được công khai. Như vậy mọi người mới có thể đáp ứng và kiểm chứng được tiêu chuẩn cao hơn để một báo cáo được công nhận là xuất sắc

  • Rốt cuộc có lẽ sẽ đi đến kết luận như vậy. Báo cáo lỗ hổng nói chung không phải lúc nào cũng đặc biệt, nhưng một số báo cáo có mức độ nghiêm trọng cao hoặc độ tin cậy cao thì nên được xem là báo cáo lỗ hổng đặc biệt

• Tôi đồng ý rằng việc tìm ra vấn đề bảo mật đã dễ hơn và rào cản gia nhập cũng thấp hơn, nên danh sách thư bảo mật có lẽ ồn ào hơn trước. Dù vậy, tôi vẫn chắc chắn sẽ ưu tiên các báo cáo lỗi từ những công ty tư vấn bảo mật có uy tín như Trail of Bits hay Zellic
  Không chỉ vì tôi tin rằng họ sẽ không gửi các báo cáo cẩu thả, mà còn vì tôi cho rằng sự kết hợp giữa các nhà nghiên cứu bảo mật hàng đầu và LLM tốt hơn việc chỉ chạy LLM trong CI

  • Gần đây tôi đã làm việc với các nhà cung cấp như vậy, và báo cáo cẩu thả vẫn xuất hiện. Chỉ là chất lượng báo cáo nhìn chung cao hơn
    LLM, bất kể do ai điều khiển, vẫn có thể hiểu sai mô hình đe dọa và có thể làm biếng trong cách chứng minh một “khai thác”. Nếu nhà nghiên cứu bảo mật bỏ sót những sai lầm này thì cuối cùng chúng vẫn được chuyển đến những người bảo trì như chúng tôi. containerd đã nhận các báo cáo cẩu thả từ những nhà cung cấp như vậy, từ các công ty nghiên cứu LLM, từ các công ty mô hình nền tảng đã nổi tiếng, và cả từ J Random User trên Internet
    Một khó khăn khác mà Filippo chưa nói đủ ở đây là báo cáo trùng lặp. Nếu nhìn vào các advisories gần đây của containerd, bạn có thể thấy một vấn đề lớn khác trong khâu phân loại và phân bổ sự chú ý là trùng lặp. Ví dụ, chúng tôi đã ghi công cho 9 separate researchers/groups, trong đó có cả những nhóm có uy tín như đã nhắc ở trên. Điều này cho thấy (a) LLM, bất kể ai sử dụng, thường tìm ra cùng một vấn đề, và (b) một báo cáo đến từ người gửi đã quen biết cũng không nhất thiết là đặc biệt. Ngược lại, trường hợp này thực sự không có báo cáo trùng lặp nên chúng tôi chỉ ghi công cho một người, và người báo cáo đó cũng không phải người mà chúng tôi biết trước hay có quan hệ từ trước