Mã do AI xây dựng có thực sự an toàn không? Hỏi & Đáp dành cho người xây dựng

Tôi nhận được một phiên bản nào đó của câu hỏi này trong hầu như mọi cuộc gọi onboarding, thường được diễn đạt cẩn thận, như thể người hỏi nửa mong đợi được thuyết phục là không cần lo lắng. Họ không nên bị thuyết phục như vậy. Bảo mật là một trong số ít lĩnh vực mà một mức độ hoang tưởng lành mạnh là hoàn toàn hợp lý, bất kể con người hay mô hình nào viết ra code. Dưới đây là những câu hỏi tôi thực sự nhận được, được trả lời trực tiếp nhất có thể.

Code do AI viết có kém an toàn hơn code do con người viết không?

Trung bình, và nếu không được kiểm soát, thì có — nhưng ở mức độ nhẹ. Một nghiên cứu của Stanford từ vài năm trước (Perry và cộng sự, thường được trích dẫn là nghiên cứu thực tế đầu tiên về vấn đề này) phát hiện các nhà phát triển sử dụng trợ lý code AI tạo ra code kém an toàn hơn so với nhóm đối chứng, và — đây mới là phần đáng lo hơn — họ tự đánh giá code của mình an toàn hơn thực tế. Sự tự tin tăng lên trong khi chất lượng giảm xuống. Các bản quét bảo mật code GenAI gần đây hơn của Veracode cũng đưa ra một con số cụ thể: khoảng 4 trên 10 mẫu code do AI tạo ra mà họ kiểm tra có chứa ít nhất một lỗ hổng có thể khai thác, thường là những thứ tầm thường như thiếu kiểm tra đầu vào hoặc cấu hình mặc định yếu. Không điều nào trong số này có nghĩa là code do AI viết vốn dĩ sẽ thất bại. Nó có nghĩa là code do AI viết chưa được rà soát mang cùng mức rủi ro như code của con người chưa được rà soát, và phần "chưa được rà soát" mới thực sự là nơi ẩn chứa nguy hiểm. Một mô hình viết nhanh mà không bao giờ được kiểm tra sẽ đưa ra cùng những lỗi mà một lập trình viên mới vào nghề mắc phải vào chiều thứ Sáu — chỉ là nhanh hơn, và nhiều hơn.

Điều gì xảy ra với API key và các thông tin bí mật của tôi?

Đây chính là điều thực sự khiến tôi mất ngủ, vì đây là loại lỗi vô hình cho đến khi nó không còn vô hình nữa. Cách nó xảy ra không hề kịch tính — không có chuyện máy chủ của ai đó bị xâm nhập theo kiểu phim hacker. Đó là một key bị dán vào một cuộc trò chuyện, được lặp lại vào một file được tạo ra, được commit, rồi âm thầm nằm ở dạng văn bản thô trong một repo sáu tháng sau, khi ai đó chạy công cụ quét bí mật ra vì tò mò. Trên nền tảng này, các thông tin bí mật không bao giờ xuất hiện trong mã nguồn được tạo ra — chúng được tiêm vào lúc runtime từ một kho lưu trữ đã mã hóa, được giới hạn theo tenant của bạn, và các agent xây dựng được chỉ dẫn tham chiếu chúng bằng tên, không bao giờ bằng giá trị thực. Nhưng nếu bạn đang xây dựng ở nơi khác, hoặc dán thông tin xác thực trực tiếp vào cửa sổ chat của bất kỳ công cụ nào, hãy giả định rằng văn bản đó giờ đã trở thành một phần của log liên quan đến huấn luyện ở đâu đó, trừ khi nhà cung cấp nói rõ điều ngược lại. Hãy xoay vòng (rotate) bất cứ thứ gì bạn từng gõ vào một ô chat, như một nguyên tắc, ngay trong ngày bạn hoàn tất kiểm thử.

Ai đó có thể hack trang web của tôi thông qua một prompt, kiểu tấn công prompt injection không?

Hai điều khác nhau thường bị gộp chung ở đây, và sự phân biệt này rất quan trọng. Prompt injection nhắm vào công cụ xây dựng — ai đó đánh lừa AI đang xây dựng ứng dụng của bạn để làm điều gì đó bạn không yêu cầu — là một rủi ro có thật, đã được nghiên cứu, và đó là lý do tại sao các agent xây dựng chạy với quyền công cụ được giới hạn phạm vi thay vì quyền truy cập shell toàn diện, và tại sao bất cứ điều gì chạm vào hệ thống file hoặc pipeline triển khai của bạn đều đi qua một nhật ký hành động rõ ràng mà bạn có thể kiểm tra sau đó. Prompt injection nhắm vào ứng dụng đã ra mắt của bạn là một vấn đề khác, chỉ áp dụng nếu chính ứng dụng của bạn nhúng một LLM lúc runtime — một chatbot hỗ trợ, một tính năng tìm kiếm AI, kiểu như vậy. Nếu có, hãy coi bất kỳ văn bản nào người dùng có thể gõ vào là đầu vào không đáng tin cậy đối với mô hình đó, giống như cách bạn coi nó là đầu vào không đáng tin cậy đối với một câu truy vấn SQL. Quy tắc thì cũ, phần mới chỉ là hệ thống nào đang phân tích chuỗi văn bản đó.

Công cụ xây dựng có tự kiểm tra lỗ hổng bảo mật trong code của chính nó trước khi triển khai không?

Các kiểm tra tự động bắt được những thứ nhàm chán, xuất hiện thường xuyên một cách đáng tin cậy: bí mật được viết cứng, thiếu xác thực trên một endpoint rõ ràng cần nó, SQL được xây dựng bằng cách ghép chuỗi thay vì tham số hóa, các dependency có CVE đã biết. Những gì chúng không bắt tốt là các lỗi logic nghiệp vụ — kiểu mà từng dòng code riêng lẻ đều ổn nhưng lỗ hổng nằm ở khoảng trống giữa hai tính năng mà không ai nghĩ đến việc kiểm tra cùng nhau. Một mã giảm giá có thể cộng dồn vô hạn với một khoản thưởng giới thiệu. Một luồng đặt lại mật khẩu tiết lộ liệu một email có tồn tại trong hệ thống hay không. Những thứ đó đòi hỏi một người hiểu ứng dụng dùng để làm gì, không chỉ code làm gì, và chưa có công cụ quét nào — dù là AI hay khác — có thể phát hiện chúng một cách đáng tin cậy. Việc rà soát tự động là một sàn tối thiểu, không phải một trần giới hạn.

Còn các gói bên thứ ba mà nó cài đặt thì sao — đó có phải là rủi ro chuỗi cung ứng không?

Có, và thành thật mà nói đó là một rủi ro thực tế lớn hơn cả chính code do AI viết. Hầu hết các ứng dụng có 80-95% là dependency tính theo số dòng; code mà một công cụ xây dựng viết ra chỉ là một lớp mỏng trên nền npm, PyPI, hoặc bất kỳ hệ sinh thái nào mà stack đó sử dụng. Một gói độc hại hoặc bị chiếm quyền có thể xâm hại bạn bất kể ai hoặc thứ gì viết ra lớp code kết nối xung quanh nó — xem các sự cố event-stream và colors.js để biết điều đó diễn ra như thế nào trong thực tế. Các biện pháp giảm thiểu thì nhàm chán nhưng hiệu quả: ghim phiên bản thay vì theo dõi bản mới nhất, ưu tiên các gói có lịch sử bảo trì thực sự thay vì những gói mới được phát hành tuần trước, và chạy kiểm toán dependency (`npm audit`, `pip-audit`, hoặc bất cứ thứ gì phù hợp với stack của bạn) như một thói quen thường trực, không phải một bước làm một lần trước khi ra mắt.

Ai chịu trách nhiệm nếu xảy ra vi phạm dữ liệu?

Bạn phải chịu trách nhiệm — về mặt pháp lý, gần như luôn luôn, nếu đó là ứng dụng của bạn và dữ liệu của khách hàng bạn. Điều này khiến những người cho rằng "AI đã viết nó" sẽ chuyển trách nhiệm sang đâu đó ngạc nhiên. Nó không hề, cũng giống như việc thuê một nhà thầu không chuyển trách nhiệm về vi phạm quy chuẩn xây dựng ra khỏi chủ sở hữu bất động sản. Các nền tảng chịu trách nhiệm về hạ tầng mà họ kiểm soát: cách các bí mật được lưu trữ, cách dữ liệu của tenant được cách ly, liệu bản thân lớp hosting có được vá lỗi hay không. Nhưng logic ứng dụng mà bạn đã đặc tả, dữ liệu mà bạn chọn thu thập, và các điều khoản mà bạn cung cấp cho người dùng của mình là của bạn. Nếu bạn đang xử lý bất cứ thứ gì nhạy cảm — chi tiết thanh toán, thông tin sức khỏe, bất cứ thứ gì thuộc GDPR hoặc CCPA — hãy đọc thỏa thuận xử lý dữ liệu thực tế của bất kỳ nền tảng nào bạn đang sử dụng thay vì giả định rằng "được AI xây dựng" bao hàm một lớp bảo vệ pháp lý bổ sung nào đó. Nó không hề.

Một nhà sáng lập từng nói với tôi, phần lớn là đùa, rằng cô ấy tin tưởng code của AI hơn code của chính mình vì "ít nhất nó không mệt mỏi lúc 2 giờ sáng." Có lẽ vậy. Nhưng con người mệt mỏi thường biết mình đang mệt mỏi. AI không hề biết nó vừa mắc lỗi, và nó sẽ nói với bạn rằng code đã hoàn thành với chính giọng điệu tự tin y hệt bất kể nó hoàn hảo hay đầy lỗ hổng. Sự tự tin không phải là một tín hiệu bảo mật, dù đến từ nguồn nào.

Tôi có nên trả tiền cho một cuộc kiểm toán bảo mật thực sự trước khi ra mắt không?

Nếu bạn đang nhận thanh toán, lưu trữ bất cứ thứ gì mà cơ quan quản lý sẽ gọi là PII, hoặc xây dựng cho một khách hàng doanh nghiệp mà đằng nào cũng sẽ yêu cầu báo cáo SOC 2 — thì có, và đừng để chi phí làm bạn từ bỏ ý định. Một cuộc kiểm toán tập trung cho một ứng dụng nhỏ tốn từ vài trăm đến vài nghìn đô la tùy phạm vi, rẻ hơn nhiều so với một lá thư thông báo vi phạm dữ liệu. Nếu bạn đang xây dựng một dự án cá nhân, một công cụ nội bộ, hoặc thứ gì đó không có dữ liệu người dùng thực sự nào đang gặp rủi ro, một cuộc kiểm toán trả phí là thừa thãi; hãy chạy lớp miễn phí và rẻ tiền thay vào đó — quét dependency, tự tay kiểm tra từng ranh giới xác thực (người dùng A có thể xem được đồ của người dùng B chỉ bằng cách đổi URL không?), và để một cặp mắt con người khác kiểm tra bất cứ thứ gì liên quan đến tiền hoặc mật khẩu.

Lỗi bảo mật phổ biến nhất mà mọi người mắc phải là gì, và nó xảy ra khi nào?

Không phải lúc ra mắt — mà là ba tháng sau, khi ứng dụng đang hoạt động và không ai còn để ý đến nó nữa. Đó là một route quản trị bị bỏ ngỏ không bảo vệ vì nó chỉ từng được kiểm tra bởi chính người đã xây dựng nó, đăng nhập bằng tài khoản của chính họ. Đó là một endpoint gỡ lỗi trả về toàn bộ stack trace ở môi trường production. Đó là một mật khẩu mặc định trên một cơ sở dữ liệu vốn chỉ dùng "để thử nghiệm" và không bao giờ được xoay vòng. Không điều nào trong số đó là kỳ lạ. Chúng tương đương với việc bảo mật khi để một chìa khóa dự phòng dưới thảm chùi chân vì bạn đang vội một lần và rồi quên mất nó ở đó. Giải pháp không phải là một công cụ tốt hơn, mà là một thói quen năm phút: mỗi tháng một lần, nhìn ứng dụng của bạn theo cách một kẻ tấn công sẽ nhìn trong năm phút trước khi bạn nhìn nó theo cách một người xây dựng đầy tự hào sẽ nhìn.