Trail of Bits chỉ trích báo cáo AI của 1Password là gây hiểu lầm, công bố bộ kiểm chứng mới

Báo cáo FLAWED của 1Password, được công bố vào ngày 6 tháng 8 năm 2026, mang đến cho những người làm công tác bảo mật một cái nhìn sai lệch về việc vá lỗi bằng AI. Tiêu đề báo cáo cho rằng các mô hình chỉ tạo ra các bản sửa lỗi sạch (clean fixes) trong 26% trường hợp. Con số đó bao gồm cả các thử nghiệm cố tình hướng dẫn các tác nhân (agents) áp dụng bản sửa lỗi sai, cùng với các thử nghiệm mà trong đó các tác nhân không thể biên dịch hoặc kiểm thử các bản vá của chúng.

Báo cáo này gây rủi ro khiến những người làm bảo mật trở nên kém hiệu quả hơn bằng cách ngăn cản họ sử dụng công nghệ có thể giúp họ khắc phục nhiều lỗ hổng hơn. Các nhóm tin tưởng hoàn toàn vào tiêu đề của báo cáo có thể bỏ qua các lỗ hổng có khả năng sửa chữa được.

Chúng tôi muốn công việc của mình giúp các chuyên gia bảo mật khắc phục được nhiều lỗ hổng hơn. Bài viết này chia sẻ dữ liệu thực tế về chất lượng bản vá của con người và tác nhân từ các dự án tư vấn của chúng tôi và chương trình Patch the Planet. Chúng tôi cũng đang phát hành hai kỹ năng cho tác nhân: post-patch-validation (xác thực sau bản vá) để giúp các tác nhân kiểm thử các bản sửa lỗi, và review-walkthrough (hướng dẫn đánh giá) để giúp các kỹ sư rà soát chúng.

Cách thử nghiệm tạo ra một tiêu đề gây hiểu lầm

Quá trình đánh giá của chúng tôi đối với mã nguồn và dữ liệu của 1Password đã tìm ra bốn lựa chọn khiến tỷ lệ sửa lỗi sạch 26% trở thành một hướng dẫn sai lệch cho công việc vá lỗi thông thường.

Tiêu đề của 1Password cũng che khuất một kết quả hữu ích trong chính dữ liệu của họ. Chúng tôi đã phân tích lại các bản vá và ghi lại kết quả kiểm thử được công bố cùng với nghiên cứu, giữ lại các thử nghiệm mà ở đó các tác nhân có thể chạy mã và không bị hướng dẫn áp dụng bản sửa lỗi sai. Trong các thử nghiệm đó, 2.634 trên 3.067 bản vá được tạo ra bởi các mô hình của 1Password (86%) đã chặn được lỗ hổng khai thác được cung cấp. Chúng tôi đã loại trừ các lượt chạy mà nghiên cứu phân loại là đã tham khảo bản sửa lỗi từ phía thượng nguồn (upstream). Việc chặn lỗ hổng đó không khẳng định một bản sửa lỗi hoàn chỉnh, nhưng những kết quả này cho thấy khả năng vá lỗi hữu ích trong các điều kiện làm việc hợp lý mà tiêu đề báo cáo đã không truyền tải được.

Các hướng dẫn và cách chấm điểm đã đưa ra thêm những vấn đề khác, một vài trong số đó cũng đã được Davi Ottenheimer nêu bật:

Các lỗi chấm điểm có thể phạt nhầm các bản sửa lỗi hợp lệ và để lọt các bản vá lỗi yếu kém. Kết hợp với mẫu được chọn lọc thủ công và các hướng dẫn cố tình sai lệch, báo cáo này không còn cơ sở đáng tin cậy cho tiêu đề của nó. Những người làm bảo mật không nên coi tỷ lệ trong tiêu đề của 1Password là thước đo nghiêm túc về khả năng vá lỗi của AI.

Các nhà phát triển thực hiện sai một trong tám bản sửa lỗi trong điều kiện lý tưởng

Việc hiểu về các thất bại của tác nhân cũng đòi hỏi phải hiểu tần suất các nhà phát triển gửi các bản sửa lỗi không hoàn chỉnh. Công việc tư vấn bảo mật của chúng tôi cung cấp một hồ sơ chi tiết về cách các nhà phát triển sửa chữa các lỗ hổng trong phần mềm của chính họ. Chúng tôi cung cấp cho khách hàng các báo cáo lỗ hổng chi tiết, sau đó thực hiện "đánh giá bản sửa lỗi" (fix review) để kiểm tra xem các bản vá được đề xuất của họ có giải quyết triệt để các vấn đề hay không.

Hồ sơ của chúng tôi kết nối từng lỗ hổng với bản sửa lỗi đầu tiên mà nhà phát triển đề xuất và đánh giá của chúng tôi về việc liệu nó có hiệu quả hay không. Chúng lưu giữ các nỗ lực không thành công mà các nhà phát triển sửa đổi trước khi một vấn đề được coi là đã giải quyết xong.

Chúng tôi đã xem xét các bản sửa lỗi đầu tiên được gửi cho 2.265 lỗ hổng trên 236 đánh giá bảo mật của Trail of Bits từ năm 2024 đến 2026. Các nhà phát triển duy trì phần mềm bị ảnh hưởng, có các báo cáo chi tiết từ các kỹ sư của chúng tôi và biết rằng chúng tôi sẽ xem xét các bản vá của họ. Ngay cả trong những điều kiện thuận lợi đó, 283 bản sửa lỗi đầu tiên đã không giải quyết triệt để vấn đề được báo cáo: chiếm 12,5%, hay một trong tám trường hợp.

Tính đến nhiều bản sửa lỗi từ cùng một đánh giá, khoảng tin cậy 95% là từ 10,5% đến 14,5%. Đôi khi chúng tôi chỉ ra sai sót trong bản vá của khách hàng trong một cuộc trò chuyện không chính thức, và họ sửa lại trước khi thực hiện đánh giá bản sửa lỗi chính thức. Những thất bại sớm đó có thể không bao giờ xuất hiện trong hồ sơ đánh giá, vì vậy dữ liệu của chúng tôi có thể đánh giá thấp các nỗ lực đầu tiên thất bại. Chúng tôi cũng loại trừ các trường hợp mà hồ sơ hiện có không xác định được liệu bản sửa lỗi có hiệu quả hay không. Một sự so sánh trực tiếp với các tác nhân sẽ đòi hỏi các nhiệm vụ và điều kiện làm việc tương đương.

Điều gì đã xảy ra với các bản vá của chúng tôi trong các dự án thực tế

Thông qua Patch the Planet, sáng kiến chung của chúng tôi với OpenAI, Trail of Bits đã đồng tác giả hàng trăm bản vá cho các dự án mã nguồn mở được sử dụng rộng rãi. Các tác nhân đã viết các bản vá với sự chỉ đạo của các kỹ sư và kiểm tra kết quả. Sau đó, những người duy trì dự án (maintainers) quyết định hợp nhất (merge), sửa đổi hoặc từ chối từng bản gửi.

Cách những người duy trì đánh giá các bản vá của Patch the Planet

Chúng tôi đã kiểm tra lịch sử đánh giá công khai của mọi bản gửi Patch the Planet trong tập dữ liệu của mình mà những người duy trì đã hợp nhất hoặc đóng lại trước ngày 14 tháng 9 năm 2026: 186 yêu cầu kéo (pull requests). Điểm chuẩn của 1Password đã sử dụng sáu lỗ hổng được chọn vì các bản sửa lỗi của chúng rất phức tạp.

Những người duy trì đã hợp nhất 126 trong số 186 yêu cầu kéo của chúng tôi, tỷ lệ chấp nhận là 67,7%. Trong 91 trên 126 yêu cầu kéo đó (72,2%), những người duy trì đã chấp nhận bản sửa lỗi bảo mật mà chúng tôi đề xuất ban đầu.

Bảng 1: Các thay đổi được yêu cầu bởi những người duy trì đối với 126 yêu cầu kéo Patch the Planet đã được hợp nhất. Các sửa đổi liên quan đến bảo mật bao gồm việc sửa chữa một bản sửa lỗi được đề xuất và mở rộng phạm vi bảo mật của nó.

Việc người duy trì chấp nhận không khẳng định rằng mọi bản vá đều chính xác.

Những người duy trì đã đóng 60 bản gửi còn lại mà không hợp nhất chúng. Hầu hết bị thay thế bởi các công việc khác hoặc bị từ chối vì lý do chính sách, quy trình, phạm vi hoặc bảo trì. Bốn bản bị từ chối rõ ràng vì lý do kỹ thuật.

Bảng 2: Các lý do những người duy trì đóng 60 yêu cầu kéo Patch the Planet mà không hợp nhất

Một trong những bản gửi bị đóng đó là bản vá freenginx của chúng tôi.

Một người duy trì và một tác nhân đã tạo ra cùng một lỗi treo (crash) trên freenginx

Nghiên cứu tình huống của 1Password xem xét một bản sửa lỗi Patch the Planet cho một lỗi an toàn bộ nhớ trong mô-đun Perl nhúng của freenginx. Một tác nhân đã viết bản vá của chúng tôi dưới sự chỉ đạo của một kỹ sư Trail of Bits. Nó để hở một đường dẫn mã dễ bị tổn thương và tạo ra một lỗi treo mới trong quá trình dọn dẹp yêu cầu (request cleanup). Lời chỉ trích của bài báo về bản vá của chúng tôi là chính xác.

Người duy trì đã đóng yêu cầu kéo của chúng tôi và cam kết một bản sửa lỗi riêng biệt. Bản sửa lỗi đó bao phủ tất cả ba đường dẫn mã dễ bị tổn thương nhưng lại tạo ra cùng một lỗi treo trong quá trình dọn dẹp. Bài báo cũng ghi lại lỗi hồi quy (regression) của người duy trì.

Cả hai tác giả đều gặp phải cùng một cái bẫy. Lỗi ban đầu cho phép Perl hủy một callback trước khi freenginx sử dụng nó.

Cả hai bản sửa lỗi đều giữ cho callback tồn tại để freenginx có thể sử dụng sau đó. Nhưng nếu yêu cầu hết thời gian chờ (timeout) trước, freenginx sẽ làm cho yêu cầu không thể sử dụng được và sau đó giải phóng callback. Việc giải phóng nó có thể chạy mã Perl vẫn cố gắng sử dụng yêu cầu, làm treo worker. Cả hai tác giả đều bỏ lỡ một vấn đề mà bản sửa lỗi của họ có thể gây ra sau đó, trong quá trình dọn dẹp. Việc phát hiện ra nó đòi hỏi phải nhìn xa hơn lỗi ban đầu để xem điều gì đã xảy ra khi một yêu cầu kết thúc sớm.

Hai tác giả, một con người và một tác nhân, làm việc riêng biệt, đã mắc cùng một sai lầm trên cùng một lỗi. Những độc giả đang quyết định xem có nên sử dụng các tác nhân hay không cần biết cách các thất bại của chúng so sánh với các nhà phát triển con người như thế nào. Việc xác định cái nào đáng tin cậy hơn đòi hỏi phải đo lường cả hai trong các điều kiện tương đương.

Chúng tôi đã kiểm tra những gì xảy ra sau khi các bản vá của chúng tôi được hợp nhất

Chúng tôi đã kiểm tra khoảng 33.500 lần cam kết (commits) tiếp theo trong các dự án Patch the Planet. Khi một lần cam kết sau đó thay đổi một tệp mà bản vá của chúng tôi đã sửa đổi, chúng tôi đã điều tra xem liệu nó có khắc phục được vấn đề mà bản vá của chúng tôi đã tạo ra hay không. Đối với mỗi lỗi hồi quy bị nghi ngờ, một tác nhân đã cố gắng chứng minh tác động của nó bằng một bằng chứng khái niệm (proof of concept). Các tác nhân khác và các kỹ sư của chúng tôi sau đó đã thách thức các phát hiện này.

Quá trình đánh giá đã tìm thấy ít nhất mười lỗi chức năng; bốn lỗi tự động hóa xây dựng, kiểm thử hoặc phát hành; và một lỗi hiệu năng. Nó không tìm thấy lỗ hổng bảo mật nào có thể khai thác được. Hai ví dụ minh họa các vấn đề chúng tôi đã xác định:

Chúng tôi đang mở rộng cuộc điều tra này cho mọi bản vá mà chúng tôi đã viết, bao gồm cả các bản vá có sự đóng góp của người duy trì. Các phát hiện sẽ giúp chúng tôi thêm các bước kiểm tra để bắt được những thất bại này trước khi chúng tôi gửi các bản vá trong tương lai.

Các kỹ năng của tác nhân cho các bản vá bảo mật tốt hơn

Chúng tôi đang phát hành hai kỹ năng cho tác nhân cùng với bài viết này: post-patch-validation để giúp các tác nhân kiểm thử các bản sửa lỗi bảo mật, và review-walkthrough để giúp các kỹ sư đánh giá các thay đổi mã nguồn.

Post-patch-validation là một kỹ năng mới mà chúng tôi đã viết để giúp các tác nhân bắt được các bản sửa lỗi không hoàn chỉnh và lỗi hồi quy trước khi gửi bản vá để đánh giá. Nó đã không được sử dụng trong công việc Patch the Planet được mô tả ở trên.

Kỹ năng này bắt đầu với một báo cáo lỗ hổng và mã nguồn trước và sau khi vá. Nó hướng dẫn tác nhân thực hiện bốn nhiệm vụ:

Các bước kiểm tra thất bại cung cấp cho tác nhân các vấn đề cụ thể để điều tra và sửa chữa trước khi gửi bản vá của nó. Kỹ năng này lưu lại các kiểm thử và kết quả để những người duy trì có thể thấy những gì đã được kiểm tra.

Để thử nghiệm post-patch-validation, hãy cài đặt kỹ năng và cung cấp cho tác nhân của bạn báo cáo lỗ hổng cùng với các phiên bản dễ bị tổn thương và đã được vá: