Kỷ nguyên chất lượng phần mềm hay kỷ nguyên của những kẻ vùi đầu trong cát?

Con người vốn viết mã bảo mật kém, và các lập trình viên GNOME cũng không phải ngoại lệ. GNOME chủ yếu được viết bằng những ngôn ngữ lập trình không an toàn, nơi chỉ một sai sót nhỏ cũng có thể gây hậu quả nghiêm trọng cho người dùng — và chúng ta mắc những sai sót đó liên tục. Dù cố gắng đến đâu, các lập trình viên GNOME vẫn sẽ thất bại trong việc viết mã bảo mật khi dùng những ngôn ngữ không an toàn như C, C++ hay Vala: ngay cả những người dày dạn kinh nghiệm cũng khó làm đúng.

Đó là quan điểm trong các bài phát biểu của tôi tại GUADEC 2024 và 2025. Khi ấy, tôi cho rằng thất bại là điều không thể tránh khỏi, và chắc chắn không tin một AI nào có thể làm tốt hơn con người. Nhưng bối cảnh năm nay đã hoàn toàn khác. AI tiến bộ vượt bậc và mang đến giải pháp như một cây đũa thần: chúng ta chỉ cần yêu cầu mô hình ngôn ngữ tìm lỗ hổng trong phần mềm, và chúng làm việc này khá tốt.

Không còn cách nào khác vào năm 2026

Theo tác giả, không còn chút hy vọng nào để duy trì chất lượng phần mềm trong năm 2026 nếu không dùng AI để quét lỗ hổng. Bất kỳ ai phản đối đều là thiếu nghiêm túc và ảo tưởng. Khối lượng lỗi khổng lồ được tìm thấy trong những dự án được bảo trì tốt nhất như GLib và fwupd đã nói lên tất cả. Không quét dự án của mình là đối xử bất công với người dùng.

Nếu chúng ta không tự tìm ra lỗ hổng bằng cách quét dự án, kẻ tấn công chắc chắn sẽ tìm ra. Cơ sở người dùng Linux đã tăng đến mức đủ đông để trở thành mục tiêu đáng nhắm tới.

Trong khi đó, AI cũng khiến việc xây dựng mã khai thác trở nên dễ dàng hơn bao giờ hết — điều trước đây gần như không tưởng.

Nhiều người nói rằng hầu hết báo cáo lỗi do AI tạo ra đều là "rác". Điều đó đúng trong phần lớn năm 2025, nhưng đến năm 2026 thì chất lượng báo cáo lỗ hổng do AI tạo đã cải thiện rõ rệt. Không phải không còn báo cáo tồi, nhưng nhìn chung phần lớn hiện nay khá tốt. Daniel Stenberg cũng ghi nhận xu hướng tương tự với dự án curl.

Những tác động không mong muốn

Dù vậy, báo cáo lỗ hổng do AI tạo vẫn gây ra nhiều hệ lụy khó chịu cho các nhà bảo trì GNOME:

• Chúng thường dài dòng, chi tiết một cách không cần thiết
• Thường phóng đại mức độ nghiêm trọng hoặc đưa ra những tuyên bố sai lệch, không liên quan
• Đôi khi không chính xác, thậm chí bịa đặt dữ liệu như stack trace giả
• Khi số lượng báo cáo đủ lớn, chúng có thể nhấn chìm các tình nguyện viên bảo trì

Ngay cả khi một báo cáo tốt và tránh được mọi vấn đề trên, việc xem xét cũng là công việc thêm cho những người vốn đã quá tải.

Một số nhà bảo trì GNOME đã áp dụng chính sách cấm nội dung do AI tạo trong báo cáo lỗi. Tác giả phản đối mạnh mẽ: ngày nay đại đa số báo cáo lỗ hổng đều do AI tạo, nên dự án nào cấm nội dung AI thì cũng gần như cấm luôn mọi báo cáo lỗ hổng.

Đề xuất của tác giả:

• Các nhà bảo trì GNOME nên sửa lại chính sách để cho phép báo cáo lỗ hổng do AI tạo
• Dự án nào tiếp tục cấm loại báo cáo này thì không còn phù hợp làm phụ thuộc của GNOME
• Không dung thứ báo cáo tồi, nhưng không nên loại trừ chỉ vì dùng AI

Có nên yêu cầu con người viết lại báo cáo?

Lập luận phổ biến nhất chống lại việc chấp nhận báo cáo do AI tạo là con người nên đọc, hiểu và viết lại toàn bộ. Nhưng việc báo cáo lỗ hổng là một dịch vụ công, không phải nghĩa vụ. Nếu đòi hỏi thêm công sức, nhiều người sẽ bỏ dự án mà đi, hoặc công bố lỗ hổng ở nơi khác thay vì trên issue tracker của bạn.

Việc viết lại cũng không thể mở rộng quy mô. Giả sử bạn dùng AI tìm được 100 lỗi bảo mật trong một dự án GNOME — bạn có thực sự bỏ ra hàng tháng trời để viết lại từng báo cáo trước khi gửi lên? Chỉ riêng việc xác minh, gửi báo cáo và tạo merge request đã là rất nhiều công việc.

Làn sóng CVE ập đến GNOME

Xu hướng cấp CVE cho GNOME phản ánh rõ làn sóng báo cáo lỗ hổng hiện nay:

Năm	CVE của GNOME	Không tính GIMP, Gegl, libxml2, libxslt
2021	21	14
2022	146	6
2023	134	20
2024	372	82
2025	97	49
2026 (đến 30/09)	141	74

Chỉ trong vài năm, GNOME đang phải xử lý số lượng CVE nhiều gấp cả chục lần so với ba năm trước. AI không phải nguyên nhân duy nhất, nhưng là nguyên nhân chính.

WebKitGTK cũng có xu hướng tương tự, với sự gia tăng lớn trong năm 2026 hoàn toàn đến từ phân tích AI đối với Skia và ANGLE — những thư viện được WebKit đóng gói sẵn.

Chương trình bug bounty của GNOME: mở rồi đóng

Chương trình bug bounty của GNOME trên nền tảng YesWeHack được tài trợ bởi chương trình Sovereign Tech Resilience của Cơ quan Công nghệ Chủ quyền Đức. Ban đầu chỉ nhận báo cáo cho GLib, glib-networking và libsoup để tránh quá tải, nhưng cuối cùng lại bị nhấn chìm bởi làn sóng báo cáo do AI tạo.

Năm	Báo cáo gửi vào	Báo cáo được chấp nhận
2024	26	14
2025	150	33
2026	122	24
Tổng	298	71

Con số của năm 2026 chỉ phản ánh chưa đầy hai tháng, cho thấy chương trình không còn khả thi. Tổng cộng chương trình đã trao 183.900 euro tiền thưởng cho 71 lỗ hổng: 45 trong libsoup, 23 trong GLib và 3 trong glib-networking. Mức thưởng dao động từ 500 euro đến 7.500 euro, trung bình khoảng 2.663 euro.

Điều đáng chú ý là các chương trình bug bounty là ngoại lệ đối với quy tắc "hầu hết báo cáo AI đều tốt". Khi có động lực tài chính, người ta sẵn sàng gửi báo cáo tồi. Nhiều báo cáo được chấp nhận thực chất cũng không tốt lắm, phải qua nhiều vòng chỉnh sửa.

Bài học rút ra:

• Đóng chương trình vì tìm ra quá nhiều lỗ hổng là kết quả không mấy dễ chịu, nhưng vẫn là thành công một phần khi phát hiện nhiều lỗi trong libsoup và GLib
• Phần lớn lỗi trong GLib là tràn số nguyên dẫn đến tràn bộ đệm — tác giả giờ sợ tràn số nguyên hơn bất cứ thứ gì
• Có thể phát hiện hầu hết vấn đề này bằng cách điều chỉnh cờ biên dịch như -Wconversion, -Wint-conversion và -Wsign-compare
• Muốn mở lại bug bounty thì phải giới hạn phạm vi cho các dự án tự quét lỗ hổng bằng AI, và có lẽ chỉ trả tiền cho khai thác thực sự hoạt động

Red Hat quét GLib bằng AI

Red Hat đã ký hợp đồng với AISLE Research để thực hiện quét lỗ hổng bằng AI cho nhiều dự án GNOME. GLib là dự án bị ảnh hưởng nặng nhất, chiếm hơn 40% tổng số phát hiện — điều tác giả không ngờ tới.

Red Hat tuyên bố tìm thấy 118 lỗ hổng trong GLib. Tuy nhiên, do cách chạy quét, một số là bản trùng lặp chưa được loại bỏ hết. Đáng chú ý, 46 trong số đó thực chất là lỗi trong gobject-introspection, chủ yếu ở phần hỗ trợ typelib. Vì typelib kiểm soát cách chương trình gọi thư viện và buộc phải được tin cậy hoàn toàn, tất cả đều được tính là dương tính giả — tạo ra tỷ lệ sai 40%.

Dù vậy, tác giả khá hài lòng với kết quả: gần như toàn bộ báo cáo đều chất lượng cao, và các dương tính giả chủ yếu do một hiểu lầm cụ thể, có thể coi như báo cáo lỗi phi bảo mật hữu ích.

Việc các nhà cung cấp Linux chủ động tìm lỗ hổng thay vì chờ nhà nghiên cứu báo cáo là điều hiếm thấy. Đây là một thử nghiệm thành công.

Con người vẫn hữu ích

Bên cạnh bug bounty, chương trình Sovereign Tech Resilience còn tài trợ một cuộc kiểm toán bảo mật do Codean Labs thực hiện, mang lại nhiều phát hiện quan trọng ở nhiều dự án GNOME, đặc biệt là Flatpak và xdg-desktop-portal với các phát hiện nghiêm trọng.

Hầu hết vấn đề này có thể phát hiện bằng quét AI, nhưng tác giả không chắc AI có thể tìm ra những phát hiện quan trọng nhất, như hai lỗ hổng thoát sandbox Flatpak. Vì vậy, không nên chỉ dựa vào AI.

Tác giả cũng không đánh giá cao việc phải tương tác với robot thay vì con người. Thật dễ nhận ra khi bình luận trên issue tracker hay review mã được viết bởi AI. Đừng đăng bình luận do AI tạo lên issue tracker hay merge request như thể đó là ý kiến của bạn — bạn không lừa được ai đâu.

Giữ đúng tầm nhìn

Có nên hoảng loạn trước số lượng lớn lỗ hổng mới được phát hiện không? Không cần thiết. Lỗi bảo mật cũng chỉ là lỗi, và chúng không nhất thiết quan trọng hơn các lỗi khác. Các mối đe dọa an ninh mạng lớn nhất với người dùng thực ra là lừa đảo và trojan, còn lỗi bảo mật phần mềm chỉ đứng thứ ba.

Tuy nhiên, không nên xem nhẹ vấn đề bảo mật. Cách đây hai năm, tác giả từng cho rằng các lỗ hổng an toàn bộ nhớ đang trở nên ít đe dọa hơn — nhận định đó đã không còn đúng khi AI giúp việc tạo mã khai thác trở nên dễ dàng hơn nhiều.

Các nhà bảo trì tình nguyện không nên cảm thấy có nghĩa vụ sửa mọi lỗi bảo mật hay coi chúng ưu tiên hơn báo cáo lỗi khác. Điều tác giả yêu cầu chỉ là đừng cấm báo cáo lỗi, chứ không phải tự mình giải quyết mọi vấn đề.

Về Rust

Ngay cả dự án viết bằng ngôn ngữ an toàn bộ nhớ như Rust cũng vẫn cần cho phép báo cáo lỗ hổng do AI tạo. Rust thực sự loại bỏ phần lớn vấn đề an toàn bộ nhớ (trừ các khối unsafe), và bạn có thể kỳ vọng dự án Rust có ít lỗ hổng hơn khoảng một bậc độ lớn so với dự án C, C++ hay Vala tương đương.

Nhưng không phải mọi lỗ hổng đều là vấn đề an toàn bộ nhớ. Hơn nữa, việc dùng Cargo để tải phụ thuộc làm tăng đáng kể rủi ro bảo mật chuỗi cung ứng. Tác giả cho rằng rủi ro đóng gói một phụ thuộc bị cài trojan có thể lớn hơn lợi ích từ việc loại bỏ lỗi an toàn bộ nhớ. Vì mã Rust của GNOME phụ thuộc nặng vào Cargo, tác giả khuyến nghị không nên dùng Rust để viết phần mềm GNOME.

Lời kết

Cuộc tranh luận về báo cáo lỗ hổng do AI tạo vẫn còn nhiều điều đáng bàn. Với các dự án mã nguồn mở như GNOME — nơi các tình nguyện viên vừa phải bảo trì mã vừa phải xử lý làn sóng báo cáo ngày càng lớn — việc tìm ra cách cân bằng giữa chất lượng, bảo mật và nguồn lực hạn chế sẽ là thách thức định hình cả một thế hệ phần mềm tự do.