Nghiên cứu mới đây cho thấy các mô hình AI tạo mã hiện đại thường xuyên sinh ra mã không an toàn, khiến các ứng dụng được tạo bởi AI tạo mã này dễ bị ảnh hưởng bởi các cuộc tấn công từ chối dịch vụ (DoS), lộ bí mật được mã hóa cứng và các lỗi ủy quyền.
Việc áp dụng nhanh chóng các trợ lý lập trình AI đã thay đổi đáng kể quá trình phát triển phần mềm. Điều này cho phép các nhà phát triển tạo ra các ứng dụng sẵn sàng sản xuất chỉ trong vài phút thay vì vài ngày.
Tuy nhiên, khi các tổ chức ngày càng phụ thuộc vào mã do AI tạo ra, một câu hỏi mới đã nảy sinh: Các hệ thống này đang đưa vào những loại rủi ro bảo mật nào?
Nghiên cứu Chuyên sâu về Mã nguồn do AI tạo ra
Một nghiên cứu mới từ nhóm nghiên cứu tại Xint.io đã phân tích 28 ứng dụng được mã hóa bằng AI, trải rộng qua nhiều quy trình phát triển, mô hình AI và môi trường lập trình.
Mục tiêu là xác định các lớp lỗ hổng bảo mật nào xuất hiện thường xuyên nhất và cách những lỗ hổng này thay đổi khi ứng dụng trở nên phức tạp hơn.
Sau khi xác thực các phát hiện thông qua xác minh mã nguồn và kiểm thử thời gian chạy, các nhà nghiên cứu đã xác định được 434 lỗ hổng bảo mật đã được xác minh.
Nghiên cứu cung cấp một cái nhìn chi tiết về các điểm yếu bảo mật cụ thể thường xuất hiện trong phần mềm được tạo bởi AI.
Các Kịch bản Phát triển Ứng dụng được Đánh giá
Nghiên cứu đã đánh giá ba quy trình phát triển có sự hỗ trợ của AI phổ biến, phản ánh các kịch bản trong thế giới thực:
- Ứng dụng được tạo ra từ các đặc tả chi tiết.
- Ứng dụng mới (Greenfield) được tạo từ các yêu cầu tối thiểu theo phương pháp “xây dựng cái này”.
- Một ứng dụng sản xuất mà AI được yêu cầu hiện đại hóa và tăng cường bảo mật.
Các Lỗ hổng Phổ biến trong Mã nguồn AI
Các phát hiện cho thấy các mô hình ngôn ngữ lớn hàng đầu hiện nay liên tục tạo ra các điểm yếu liên quan đến khả năng phục hồi hoạt động, xác thực, các lỗi IDOR (Insecure Direct Object Reference) phức tạp và các bí mật được mã hóa cứng.
Các loại lỗ hổng bảo mật thay đổi khi các ứng dụng được tạo trở nên lớn hơn và phức tạp hơn.
Giảm thiểu Lỗ hổng Kế thừa
Điều đáng chú ý là các lỗ hổng injection (như SQL Injection, XSS) và các lỗi kiểm soát truy cập cơ bản kiểu IDOR/BOLA (Broken Object Level Authorization) chỉ xuất hiện rất ít.
Điều này cho thấy các phòng thí nghiệm AI đã cải thiện đáng kể trong lĩnh vực cụ thể này.
Giả thuyết ban đầu là mã do AI tạo ra sẽ lặp lại nhiều lỗi lập trình kinh điển của ngành, như SQL injection, cross-site scripting (XSS) và các truy vấn cơ sở dữ liệu không an toàn.
Các mô hình AI được đào tạo trên lượng lớn mã dễ bị injection, vì vậy việc chúng tái tạo các lỗ hổng này là điều tự nhiên.
Tuy nhiên, nghiên cứu đã tìm thấy điều ngược lại.
Các mô hình hiện đại thường mặc định sử dụng các framework an toàn, các truy vấn cơ sở dữ liệu được tham số hóa, các công cụ ánh xạ đối tượng-quan hệ (ORM) và cơ chế làm sạch đầu vào.
Điều này làm giảm đáng kể tần suất của nhiều lỗ hổng injection. Tương tự, các kiểm tra ủy quyền đơn giản — như ngăn chặn một người dùng chỉnh sửa dữ liệu của người dùng khác — đã được triển khai đúng cách trong hầu hết các ứng dụng nhỏ hơn.
Mã AI không lặp lại các lỗ hổng của quá khứ, điều này cho thấy các phòng thí nghiệm tiên phong đã giải quyết thành công vấn đề này.
Mối đe dọa DoS và Quản lý Tài nguyên
Danh mục lớn nhất của các phát hiện đã được xác minh liên quan đến các điểm yếu về cạn kiệt tài nguyên và từ chối dịch vụ (DoS), chiếm 93 trong số 434 lỗ hổng được xác thực (21%).
Các ví dụ điển hình bao gồm:
- Thiếu giới hạn tốc độ (rate limiting).
- Phân trang không giới hạn (unbounded pagination).
- Các hoạt động chặn đồng bộ (synchronous blocking operations).
- Quản lý tài nguyên kém.
Các điểm yếu này thường cho phép ứng dụng hoạt động bình thường trong quá trình kiểm thử nhưng tạo ra rủi ro bảo mật vận hành đáng kể khi triển khai.
Chúng có thể dẫn đến chi phí máy chủ tăng vọt, hoặc khiến máy chủ bị kẻ tấn công đánh sập.
Chúng xuất hiện trong hầu hết mọi dự án được phân tích, nhưng kẻ tấn công thường phải đáp ứng các điều kiện nhất định để khai thác chúng. Các khía cạnh về hiệu suất và hiệu quả hiếm khi được đề cập trong các yêu cầu (prompts) hoặc mã ví dụ được sử dụng để đào tạo các mô hình AI.
Do đó, các mô hình tối ưu hóa để tạo ra chức năng hoạt động thay vì phần mềm tiếp tục hoạt động an toàn dưới khối lượng công việc nặng hoặc độc hại.
Rò rỉ Bí mật Nhạy cảm: Một Vấn đề Nghiêm trọng
Mặc dù các điểm yếu từ chối dịch vụ là lỗ hổng phổ biến nhất nói chung, bức tranh đã thay đổi khi chúng ta chỉ cô lập các phát hiện có mức độ nghiêm trọng Critical.
Trong số 23 lỗ hổng nghiêm trọng được xác định trong các ứng dụng mới được tạo, gần một nửa liên quan đến các bí mật ứng dụng được mã hóa cứng hoặc dễ đoán.
Các bí mật này bao gồm khóa mã hóa mặc định, khóa ký JWT và thông tin đăng nhập được nhúng.
Chúng chiếm 11 phát hiện quan trọng, khiến việc lộ bí mật trở thành loại lỗ hổng bảo mật nghiêm trọng phổ biến nhất.
Những điểm yếu này có thể bắt nguồn từ các mẫu mã hóa phổ biến trong dữ liệu đào tạo công khai.
Nhiều hướng dẫn, kho lưu trữ mẫu và ứng dụng khởi động nhanh bao gồm các bí mật giữ chỗ (placeholder secrets) được thiết kế để thay thế trước khi triển khai.
Vì những giá trị này hiếm khi ngăn phần mềm hoạt động đúng cách, các mô hình AI thường sao chép chúng mà không thay đổi. Những giá trị mặc định này có thể cho phép kẻ tấn công giả mạo token xác thực, chiếm quyền điều khiển phiên hoặc thậm chí toàn bộ ứng dụng, dẫn đến một cuộc tấn công mạng quy mô lớn.
Báo cáo cũng xác định các trường hợp nghiêm trọng về lộ chế độ gỡ lỗi (debug-mode exposure) và thực thi mã từ xa (Remote Code Execution) liên quan đến dependency. Điều này cho thấy các cấu hình phát triển vẫn là một lĩnh vực mà phần mềm do AI tạo ra cần được xem xét cẩn thận.
Lỗi Quyền truy cập và IDOR: Thách thức với Ứng dụng Phức tạp
Một trong những phát hiện đáng chú ý của nghiên cứu là kích thước ứng dụng ảnh hưởng đến các loại lỗ hổng bảo mật mà AI đưa vào.
Các ứng dụng Greenfield nhỏ hơn nói chung ít gặp lỗi ủy quyền hơn. Thay vào đó, chúng bị chi phối bởi các kiểm soát hoạt động bị thiếu như giới hạn tốc độ và quản lý tài nguyên.
Tuy nhiên, khi độ phức tạp của ứng dụng tăng lên, lỗ hổng chủ yếu chuyển sang các lỗi ủy quyền và các lỗi IDOR không an toàn.
Trong ứng dụng sản xuất lớn hơn được phân tích trong nghiên cứu, các vấn đề ủy quyền chiếm 66 trong số 238 phát hiện đã xác minh (28%), so với chỉ 22 trong số 196 phát hiện (11%) trong các ứng dụng nhỏ hơn được tạo ra.
Chúng tôi tin rằng các mô hình AI xử lý tốt các kiểm tra quyền sở hữu đơn giản vì logic cần thiết được cục bộ hóa.
Tuy nhiên, các mô hình quyền chi tiết đòi hỏi khả năng lập luận trên hàng trăm điểm cuối, nhiều vai trò người dùng và trạng thái ứng dụng thay đổi.
Khi phần mềm phát triển, việc duy trì nhất quán các mối quan hệ đó trở nên khó khăn hơn đáng kể đối với các hệ thống AI hiện tại.
Kết quả là phần mềm thực thi đúng quyền trong các kịch bản đơn giản trong khi âm thầm giới thiệu các cơ hội leo thang đặc quyền trong các quy trình làm việc phức tạp hơn.
Phương pháp và Giới hạn Nghiên cứu
Để cô lập các mẫu lỗ hổng bảo mật, nhóm nghiên cứu đã đánh giá ba quy trình phát triển có sự hỗ trợ của AI phổ biến:
- Các ứng dụng được tạo từ các đặc tả chi tiết.
- Các ứng dụng Greenfield được tạo từ các yêu cầu tối thiểu bằng cách sử dụng phương pháp “build this”.
- Một ứng dụng sản xuất mà AI được yêu cầu hiện đại hóa và tăng cường bảo mật.
Các ứng dụng Greenfield được tạo bằng nhiều mô hình từ Anthropic và OpenAI, trong khi kịch bản sản xuất liên quan đến việc di chuyển một hệ thống quản lý nội dung PHP đã trưởng thành sang Laravel và React.
Mỗi ứng dụng trải qua phân tích mã nguồn tự động và phân tích thời gian chạy, sau đó là xác thực thủ công.
Quy trình bắt đầu với 8.827 phát hiện thô, được giảm thông qua loại bỏ trùng lặp tự động xuống còn 513 phát hiện riêng biệt.
Các nhà nghiên cứu sau đó đã xác minh khoảng 85% số phát hiện đó dựa trên bằng chứng nguồn, xác nhận 434 lỗ hổng để đưa vào phân tích.
Các phát hiện không thể xác minh đã bị loại trừ.
Các giới hạn của báo cáo là kích thước mẫu tương đối nhỏ trên mỗi mô hình và việc thiếu một cơ sở phần mềm do con người viết.
Kết quả nên được hiểu là các quan sát so sánh chứ không phải là xếp hạng mô hình có ý nghĩa thống kê.
Xu hướng Cải thiện và Thách thức Mới
Mặc dù ghi nhận hàng trăm lỗ hổng bảo mật, nghiên cứu này cung cấp bằng chứng cho thấy các hệ thống mã hóa AI đang cải thiện trong một số lĩnh vực quan trọng.
So với những kỳ vọng dựa trên các thế hệ công cụ tạo mã trước đây, nghiên cứu đã tìm thấy ít SQL injection, cross-site scripting và các lỗi ủy quyền đơn giản hơn đáng kể so với dự kiến.
Các mô hình ngày càng áp dụng các giá trị mặc định an toàn như các câu lệnh được chuẩn bị (prepared statements) và làm sạch đầu vào tích hợp sẵn mà không cần yêu cầu rõ ràng.
Sự tiến hóa đó cho thấy các nhà phát triển mô hình nền tảng đã giảm thành công một số lớp lỗ hổng bảo mật đã tồn tại lâu dài.
Đồng thời, nghiên cứu chỉ ra rằng phần mềm do AI tạo mã đang giới thiệu các loại rủi ro bảo mật khác nhau.
Những rủi ro này ngày càng trở nên quan trọng khi các tổ chức mở rộng phát triển có sự hỗ trợ của AI.
Giả thuyết là những lỗ hổng này phản ánh các động lực mà các mô hình AI hiện tại được đào tạo.
Các mô hình ngôn ngữ chủ yếu tối ưu hóa để tạo ra mã biên dịch, vượt qua các kiểm thử cơ bản và đáp ứng các yêu cầu chức năng.
Các biện pháp bảo vệ hoạt động — bao gồm giới hạn tốc độ, hạn ngạch tài nguyên, quản lý thời gian chờ và logic ủy quyền phức tạp — vượt ra ngoài phạm vi này.
Chúng thường không được bao gồm như các yêu cầu chức năng rõ ràng khi yêu cầu các mô hình tạo mã.
Báo cáo của chúng tôi không chứng minh giả thuyết này, nhưng nó phù hợp với các quan sát chung của chúng tôi trên kỹ thuật phần mềm có sự hỗ trợ của AI.
Các mô hình thường tối ưu hóa cho “happy path” (kịch bản thành công) trong khi bỏ qua các điều kiện ngoại lệ, các kịch bản lạm dụng thời gian chạy và khả năng phục hồi hoạt động lâu dài.
Khuyến nghị Nâng cao An ninh cho Mã nguồn AI
Các phát hiện cho thấy các tổ chức nên điều chỉnh quy trình đánh giá bảo mật để tính đến các đặc điểm riêng biệt của mã do AI tạo mã.
Không nên chỉ dựa vào các danh sách kiểm tra mã hóa an toàn truyền thống.
Các Lĩnh vực Ưu tiên trong Đánh giá Bảo mật
Thay vì tập trung vào các lỗ hổng injection, các nhà đánh giá bảo mật nên ưu tiên:
- Giới hạn tốc độ và tiêu thụ tài nguyên.
- Thông tin đăng nhập được mã hóa cứng và các bí mật ứng dụng.
- Logic ủy quyền chi tiết (fine-grained authorization logic).
- Hành vi thời gian chạy dưới tải (runtime behavior under load).
- Thực thi quyền cấp đối tượng (object-level permission enforcement).
- Đánh giá cấu hình debug và các dependency.
Kiểm thử Mã nguồn và Kiểm thử Thời gian Chạy
Chúng tôi cũng khuyến nghị xác thực các ứng dụng do AI tạo ra bằng cả phân tích mã nguồn và kiểm thử thời gian chạy.
Nhiều lỗ hổng bảo mật chỉ trở nên rõ ràng khi ứng dụng thực thi trong điều kiện hoạt động thực tế.
Tích hợp vào Quy trình Phát triển Phần mềm
Đối với các nhóm bảo mật sản phẩm, phát triển có sự hỗ trợ của AI cũng có thể yêu cầu giới thiệu các kiểm soát mới vào vòng đời phát triển phần mềm.
Các kiểm soát này bao gồm phát hiện bí mật tự động, kiểm thử ủy quyền, đánh giá mã dựa trên chính sách và kiểm thử bảo mật ứng dụng liên tục trước khi triển khai.
Thay vì loại bỏ việc đánh giá mã an toàn, AI dường như đang thay đổi nơi các nhà đánh giá nên tập trung sự chú ý của họ. Khi các nhóm phần mềm tạo ra nhiều mã hơn so với khả năng kiểm tra thủ công của con người, các quy trình bảo mật có thể sẽ cần phải phát triển song song với chính quá trình phát triển có sự hỗ trợ của AI.
