BrassCoders đã phát hiện các thông tin bí mật được mã hóa cứng (hard-coded secrets) trong hai trên số mười lăm kịch bản Python do AI tạo ra mà họ đã kiểm tra, cho thấy rủi ro cụ thể đối với các nhà phát triển thường sao chép và dán mã trực tiếp từ kết quả của các mô hình ngôn ngữ lớn. Những phát hiện này cho thấy chỉ một khóa hoặc mật khẩu đặt sai chỗ cũng có thể biến một đoạn mã hữu ích thành một vụ rò rỉ thông tin xác thực trên các môi trường quản lý phiên bản và môi trường thực tế (production).

Kết quả kiểm tra cho thấy

Kịch bản đầu tiên, token_check.py, được tạo ra từ một câu lệnh (prompt) yêu cầu một hàm để ký các mã thông báo phiên (session tokens) và bao gồm một "ví dụ có thể sử dụng được". Để làm cho mã có thể chạy được, mô hình đã chèn trực tiếp một khóa ký HMAC vào tệp nguồn.

  • Vấn đề: Khóa bí mật nằm ngay trong mã nguồn.
  • Rủi ro: Bất kỳ ai có quyền đọc kho lưu trữ (repository) đều có thể thấy khóa, và bất kỳ quy trình triển khai nào lấy tệp này đều sẽ kế thừa bí mật đó.
  • Hệ quả: Kẻ tấn công nếu có được khóa có thể giả mạo các mã thông báo phiên hợp lệ, vượt qua các bước kiểm tra xác thực.

Kịch bản thứ hai, email_sender.py, trả lời yêu cầu về một hàm gửi email qua SMTP. Mô hình một lần nữa cung cấp một mật khẩu cụ thể để ví dụ có thể hoạt động ngay lập tức.

  • Vấn đề: Mật khẩu xuất hiện dưới dạng một chuỗi văn bản thuần túy trong lời gọi hàm.
  • Rủi ro: Việc thay đổi mật khẩu đòi hỏi phải thay đổi mã nguồn và triển khai lại, đồng thời thông tin xác thực sẽ lan truyền đến mọi môi trường có sử dụng tệp này.
  • Hệ quả: Mật khẩu có thể bị thu thập từ hệ thống quản lý phiên bản, nhật ký (logs) hoặc các gói đã biên dịch, giúp kẻ tấn công có quyền truy cập trái phép vào máy chủ thư điện tử.

Tại sao AI lại đưa ra các thông tin bí mật

Các mô hình ngôn ngữ lớn tạo ra văn bản bằng cách hoàn thiện câu lệnh (prompt). Khi người dùng yêu cầu một "ví dụ có thể sử dụng được", mô hình sẽ hiểu đó là "mã có thể chạy mà không cần thiết lập thêm". Do đó, nó sẽ điền các giá trị còn thiếu—như khóa API, mật khẩu, mã thông báo—bằng các giá trị giữ chỗ (placeholders) trông có vẻ hợp lý. Mô hình không có nhận thức về các thực hành tốt nhất trong quản lý bí mật trừ khi câu lệnh đề cập đến chúng một cách rõ ràng.

Một phân tích gần đây của Veracode về mã do AI tạo ra cho thấy 45% các đoạn mã chứa ít nhất một lỗ hổng nằm trong danh sách OWASP Top 10, trong đó việc lộ thông tin xác thực chiếm một tỷ trọng đáng kể. Thống kê này nhấn mạnh rằng vấn đề không chỉ nằm ở một vài trường hợp cá biệt; nó là một tác dụng phụ mang tính hệ thống từ cách các mô hình này được huấn luyện và nhận câu lệnh.

Các bước giảm thiểu mà nhà phát triển có thể thực hiện ngay

Cách phòng thủ đơn giản nhất là giữ cho bất kỳ bí mật nào nằm ngoài tệp mã nguồn. Biến môi trường (environment variables) là phương pháp phổ biến nhất và không phụ thuộc vào ngôn ngữ lập trình:

# token_check.py – secure version
import os
import hmac
import hashlib

SECRET_KEY = os.environ["HMAC_SECRET_KEY"]

def sign_token(data: bytes) -> str:
    return hmac.new(SECRET_KEY.encode(), data, hashlib.sha256).hexdigest()

# email_sender.py – secure version
import os
import smtplib

smtp_password = os.environ["SMTP_PASSWORD"]
server = smtplib.SMTP("smtp.example.com", 587)
server.starttls()
server.login("noreply@example.com", smtp_password)

Việc sử dụng os.environ sẽ lấy giá trị từ môi trường thực thi, giúp giữ bí mật tránh khỏi hệ thống quản lý phiên bản và cho phép thay đổi (rotation) mà không cần chạm vào các tệp nguồn. Mô hình tương tự cũng hoạt động với các tệp cấu hình được loại trừ khỏi các lần commit, các dịch vụ quản lý bí mật, hoặc các bí mật được điều phối bởi container.

Các biện pháp bảo vệ bổ sung

  • Kiểm tra mã nguồn (Code reviews) để gắn cờ các chuỗi văn bản khớp với các mẫu bí mật phổ biến (ví dụ: các chuỗi ký tự chữ và số dài).
  • Các công cụ phân tích tĩnh (Static analysis tools) được tinh chỉnh để phát hiện các thông tin xác thực mã hóa cứng trong các tệp mới được thêm vào.
  • Kỹ thuật đặt câu lệnh (Prompt engineering): yêu cầu mô hình một cách rõ ràng là "sử dụng biến môi trường cho tất cả các bí mật" hoặc "bỏ qua các thông tin xác thực thật".
  • Kiểm tra lỗi (Linting) sau khi tạo: chạy một kịch bản nhanh để tìm kiếm các giá trị văn bản đáng ngờ trước khi sao chép mã vào dự án.

Quan điểm ngược lại: Điều này có nghĩa là mã do AI tạo ra không an toàn?

Sự hiện diện của các thông tin bí mật được mã hóa cứng không có nghĩa là mã do AI tạo ra luôn luôn không an toàn. Trong nhiều trường hợp, mô hình tạo ra logic sạch sẽ, có cấu trúc tốt giúp đẩy nhanh quá trình phát triển. Rủi ro chỉ phát sinh khi các nhà phát triển coi kết quả đầu ra là đã sẵn sàng để triển khai thực tế (production-ready) mà không qua kiểm tra bảo mật. Hãy coi AI như một trợ lý soạn thảo, chứ không phải là sự thay thế cho các quy trình bảo mật đã được thiết lập.

Những điều cần theo dõi tiếp theo

  • Cập nhật về công cụ: Các nền tảng AI đang bắt đầu tích hợp các bộ lọc an toàn để thay thế các bí mật bằng các giá trị giữ chỗ. Việc theo dõi những thay đổi này có thể giúp giảm thiểu rủi ro lộ lọt thông tin.
  • Sự thay đổi về chính sách: Các tổ chức có thể chính thức hóa các hướng dẫn về lập trình có sự hỗ trợ của AI, bắt buộc kiểm tra quản lý bí mật như một phần của quy trình CI (tích hợp liên tục).
  • Các mô hình cộng đồng: Khi các nhà phát triển chia sẻ nhiều hơn các "câu lệnh bảo mật", các mẫu thực hành tốt nhất có thể trở thành kết quả đầu ra mặc định cho các tác vụ phổ biến như ký mã thông báo hoặc gửi email.

Bài học rút ra: AI có thể tạo ra mã nguồn hoạt động được chỉ trong vài giây, nhưng nếu các nhà phát triển không thực hiện kỷ luật quản lý thông tin bảo mật, sự tiện lợi này sẽ đi kèm với một cái giá tiềm ẩn—các thông tin xác thực bị lộ có thể làm tổn hại đến toàn bộ hệ thống. Hãy coi mọi đoạn mã là bản nháp, loại bỏ bất kỳ thông tin bảo mật trực tiếp nào, và đưa chúng vào thông qua các biến môi trường hoặc một kho lưu trữ chuyên dụng trước khi commit.