OpenAI Biến Một Đợt Chạy Nước Rút Bảo Mật 250 Người Thành Nhà Máy Phòng Thủ AI Liên Tục

OpenAI cho biết họ đã huy động hơn 250 nhân viên để tìm và khắc phục lỗ hổng trên hàng trăm hệ thống, sử dụng Codex và các mô hình an ninh mạng chuyên biệt để hỗ trợ phát hiện, phân loại, khắc phục và xác minh. Công ty hiện đã công bố kiến trúc và quy trình vận hành hình thành từ đợt chạy nước rút bảo mật nội bộ đó, gọi hệ thống kết quả là “Defense Factory.”

Thông tin công bố này bao gồm các kết quả vận hành cụ thể bất thường. OpenAI cho biết các nhóm đã xử lý xong 53 vấn đề khẩn cấp hoặc ưu tiên cao trong ngày đầu tiên của đợt chạy nước rút, đạt tỷ lệ chấp nhận 90.6% khi chuyển các phát hiện đến chủ sở hữu, phân loại 37% phát hiện là trùng lặp, và giảm tỷ lệ dương tính giả xuống 0.81% sau khi xác thực động.

Các con số này mô tả một chương trình phòng thủ nội bộ, không phải một vụ xâm nhập bên ngoài đã được công bố. OpenAI chưa xác định các dịch vụ bị ảnh hưởng, chưa công bố tổng số hoặc phân bố mức độ nghiêm trọng của các lỗ hổng, cũng như chưa cung cấp mẫu số và khoảng thời gian đo lường cho mọi tỷ lệ được báo cáo. Vì vậy, các kết quả của họ không thể được tái lập độc lập chỉ từ tài liệu đã công bố. Thay vào đó, tầm quan trọng của thông tin này nằm ở mô hình vận hành: công việc bảo mật đang được tổ chức lại thành một quy trình tác tử thường trực thay vì chuỗi quét định kỳ và bàn giao thủ công.

1. Đợt Chạy Nước Rút Bảo Mật Bao Phủ Hơn 100 Mảng Dịch Vụ

OpenAI mô tả nỗ lực ban đầu là một “code red” nội bộ, quy tụ các tổ chức Security, Applied và Research của họ. Hơn 250 người đã tham gia, và công việc bao phủ hơn 100 mảng dịch vụ gồm hàng trăm hệ thống.

Đợt chạy nước rút bắt đầu trước khi OpenAI có bản đồ đầy đủ về các hệ thống đó. Codex hỗ trợ lập danh mục tài sản trong khi các nhóm nhập các phát hiện bảo mật sẵn có vào một backlog dùng chung. Dữ liệu về quyền sở hữu dịch vụ, cấu hình triển khai, hồ sơ đám mây, mã nguồn và các endpoint công khai được kết nối dần để các tác tử có thể xác định nhóm nào nên nhận từng phát hiện.

OpenAI báo cáo rằng quy trình này tạo ra tỷ lệ chấp nhận quyền sở hữu là 90.6%. Người đánh giá vẫn tiếp tục xử lý các trường hợp mơ hồ, trong khi các bản sửa lỗi khẩn cấp được thực hiện trước khi danh mục hoàn chỉnh. Cách tiếp cận song song đó cho phép các nhóm xử lý xong 53 vấn đề khẩn cấp hoặc ưu tiên cao ngay trong ngày đầu tiên.

Các tác tử cũng đánh giá các phát hiện theo một khung phân loại mức độ nghiêm trọng. OpenAI cho biết các phân loại ban đầu thiếu nhất quán và nhạy cảm với chỉ dẫn cung cấp cho mô hình. Công ty đã phản hồi bằng cách quản lý phiên bản cho prompt và khung phân loại, bổ sung các đánh giá có thể lặp lại, ghi lại mức ưu tiên và lập luận dự kiến của người đánh giá, đồng thời duy trì các đợt kiểm tra ngẫu nhiên bởi con người.

Loại bỏ trùng lặp trở thành một cổng kiểm soát rõ ràng khác. OpenAI tạm thời dừng định tuyến tự động cho đến khi quy trình này được cải thiện, rồi cuối cùng xác định rằng 37% các phát hiện họ kiểm tra là trùng lặp. Điều này quan trọng vì một hệ thống tác tử chỉ tạo thêm báo cáo có thể gia tăng gánh nặng cho kỹ sư bảo mật mà không làm giảm rủi ro.

Xác thực động được dùng để tách các lỗ hổng có thể tái hiện khỏi nhiễu của phân tích tĩnh. Các tác tử nhận được phiên bản có thể chạy của các dịch vụ được chọn và cố gắng tái hiện vấn đề nghi ngờ trong môi trường được kiểm soát. OpenAI báo cáo tỷ lệ dương tính giả là 0.81% sau giai đoạn này, dù không công bố quy mô hoặc thành phần của mẫu đã được xác thực.

2. Defense Factory Sử Dụng Vòng Lặp Tác Tử Gồm Năm Giai Đoạn

Defense Factory không được trình bày như một mô hình đơn lẻ hay trình quét lỗ hổng. Đây là một kiến trúc tham chiếu kết nối các hệ thống kiểm soát mã nguồn hiện có, trình quét bảo mật, trình theo dõi vấn đề, môi trường phát triển, ngữ cảnh đặc thù của công ty và các tác tử AI.

Quy trình của nó có năm giai đoạn lặp lại: kiểm kê, phát hiện, xác thực động, phân công quyền sở hữu và khắc phục đã được xác minh.

Các tác tử kiểm kê đối chiếu tài nguyên đám mây, cấu hình triển khai, mã nguồn, endpoint công khai và hồ sơ quyền sở hữu dịch vụ. Các tác tử phát hiện sau đó kết hợp danh mục đó với mô hình đe dọa, chính sách bảo mật, mã nguồn và các phát hiện được nhập từ những công cụ như Snyk hoặc Wiz. Đầu ra vẫn là một tập các lỗ hổng tiềm năng thay vì danh sách lỗi đã được xác nhận.

Trong quá trình xác thực động, các tác tử kiểm tra mã liên quan và cố gắng tái hiện từng ứng viên trong một ứng dụng có thể chạy. Đặc tả của OpenAI cho biết chỉ truy vết tĩnh là chưa đủ: một lỗ hổng đã được xác thực phải bao gồm bằng chứng tái hiện. Các phát hiện bị bác bỏ và chưa thể kết luận vẫn được gắn với hồ sơ, trong khi việc tạo một vấn đề trong trình theo dõi cần có phê duyệt.

Các tác tử quyền sở hữu kết nối phát hiện đã được xác thực với danh mục tài sản, tệp code-owner, lịch sử commit, truyền thông nội bộ và trình theo dõi vấn đề. OpenAI phân biệt giữa phân công và xác nhận, ngăn việc một ticket được định tuyến tự động bị coi là công việc đã được chấp nhận.

Ở giai đoạn cuối, Codex chuẩn bị một bản vá và kiểm tra hành vi của nó trong môi trường có thể tái lập. Sau khi được con người đánh giá và triển khai có ủy quyền, một bước kiểm tra riêng biệt sẽ kiểm thử lại bản sửa lỗi trên môi trường production. Một pull request đã hợp nhất hoặc ticket đã được di chuyển không được coi là bằng chứng khắc phục; việc xác minh thất bại hoặc chưa thể kết luận sẽ giữ vấn đề ở trạng thái mở.

Các tệp SECURITY.md dùng chung mang kiến thức đặc thù của hệ thống qua các chu kỳ. Mỗi lượt có thể tái sử dụng ánh xạ, thông tin quyền sở hữu, bằng chứng điều tra và các kiểm tra xác minh trước đó thay vì phải tái dựng ngữ cảnh đó. Công ty cho biết các thay đổi có hệ quả vẫn được con người đánh giá và các bản sửa lỗi đã triển khai được xác minh độc lập.

3. Cô Lập Và Kiểm Soát Truy Cập Là Một Phần Của Ranh Giới Bảo Mật

Kiến trúc của OpenAI tách control plane khỏi data plane. Control plane quản lý điều phối khối lượng công việc, thực thi chính sách và truy cập vào thông tin xác thực. Data plane cung cấp các môi trường phát triển cô lập, nơi tác tử có thể chạy ứng dụng, tái hiện lỗ hổng và kiểm thử bản vá.

Các môi trường này được thiết kế để tồn tại tạm thời: mỗi lần chạy bắt đầu từ một môi trường mới và trạng thái của nó bị loại bỏ sau đó. Điều này giảm rủi ro một cuộc điều tra làm nhiễm bẩn cuộc điều tra khác và giúp việc xác thực lặp lại đáng tin cậy hơn.

Kiến trúc cũng đặt kiểm soát mã nguồn, lưu trữ bí mật, registry artifact và endpoint mô hình bên trong mạng riêng của tổ chức. Danh mục tài sản và cơ sở dữ liệu phát hiện lưu giữ trạng thái quy trình, trong khi giám sát máy chủ, bảo mật hạ tầng và hệ thống kiểm toán tác tử giám sát hoạt động trên toàn bộ pipeline.

OpenAI cho biết họ đã tăng quyền tự chủ theo từng bước. Họ bắt đầu với các lô nhỏ và đánh giá của con người, sau đó loại bỏ các bước thủ công lặp lại khi kết quả trở nên đáng tin cậy hơn. Các quyền được cấp cho một tác tử được giữ tách biệt khỏi khối lượng công việc phân tích mà tác tử đó có thể thực hiện.

Sự phân biệt này đặc biệt quan trọng trong quá trình khắc phục. OpenAI cho biết các tác tử đã tạo mọi bản vá trong đợt chạy nước rút, mô tả việc khắc phục là “100% Codex-based,” nhưng con người vẫn chịu trách nhiệm đánh giá các thay đổi có hệ quả và triển khai có ủy quyền. Tỷ lệ bản sửa lỗi bị hoàn tác được báo cáo là 0.53%, dù công ty chưa công bố số lượng bản vá thô mà tỷ lệ đó đại diện.

Các bước kiểm tra tiếp theo cũng phát hiện khoảng cách giữa việc bản sửa lỗi được hợp nhất và việc nó đến được mọi hệ thống đã triển khai. OpenAI mở rộng xác minh sau triển khai nhưng ban đầu vẫn tắt tính năng tự động mở lại vấn đề trong khi họ xác định cách phân biệt giữa khắc phục thất bại và độ trễ triển khai thông thường.

4. Kết Quả Có Thể Chuyển Giao Là Pipeline Xác Thực, Không Phải Số Lượng Nhân Sự

Tuyên bố trọng tâm của OpenAI là bên phòng thủ có thể sử dụng mã riêng tư, ngữ cảnh triển khai, hồ sơ quyền sở hữu và các mô hình frontier mạnh hơn trước khi kẻ tấn công có được quyền truy cập tương đương. Defense Factory của họ được thiết kế để biến lợi thế đó thành các chu kỳ ngắn hơn giữa phát hiện và khắc phục đã được xác minh.

Cloudflare đã mô tả riêng một harness lỗ hổng đa tác tử tương đương. Pipeline của họ dùng các tác tử riêng biệt cho trinh sát, săn tìm, xác thực đối nghịch, loại bỏ trùng lặp, truy vết phụ thuộc và chuẩn bị bản vá. Hệ thống yêu cầu sự phê duyệt của con người trước khi một bản sửa lỗi được tạo có thể đến production và coi các bài kiểm thử có thể tái hiện là một cổng kiểm soát thay vì tin vào đánh giá bằng văn bản của mô hình.

Việc triển khai độc lập đó củng cố mô hình quy trình nền tảng, đồng thời cho thấy chi phí của nó. Cloudflare cho biết các lượt quét lớn có thể mất hàng giờ, cần các nhóm từ 50 đến 200 worker, và chuyển nút thắt vận hành từ việc tìm lỗi sang đánh giá và triển khai bản sửa lỗi an toàn. Hoạt động tác tử liên tục không loại bỏ nhu cầu về chủ sở hữu ứng dụng, môi trường kiểm thử đáng tin cậy, kỹ thuật phát hành hay phán đoán bảo mật.

Với các tổ chức cân nhắc thiết kế của OpenAI, thay đổi cụ thể nhất nằm ở quy trình. Các phát hiện tiềm năng phải được loại bỏ trùng lặp và tái hiện trước khi đến tay kỹ sư; quyền sở hữu phải gắn với hồ sơ vận hành hiện tại; bản vá phải vượt qua kiểm tra hồi quy; và việc khắc phục phải được xác minh sau triển khai. Không có các cổng này, việc bổ sung tác tử có nguy cơ chỉ tăng tốc sản xuất báo cáo thay vì giảm lỗ hổng.

Quyền truy cập vào các mô hình nền tảng cũng không đồng đều. Kiến trúc được OpenAI công bố nêu tên các mô hình đa dụng gồm Astra, Sol, Terra và Luna, cùng với các mô hình bảo mật Daybreak Blue và Daybreak Red. Các khả năng an ninh mạng cởi mở hơn được cung cấp qua Daybreak cho những bên phòng thủ đã xác minh, với quy trình xác minh danh tính mạnh hơn, kiểm soát phạm vi, giám sát và giám sát quản trị.

Do đó, tài liệu được công bố là một kiến trúc tham chiếu và nghiên cứu tình huống nội bộ, không phải bằng chứng rằng bất kỳ tổ chức nào cũng có thể tái tạo ngay kết quả của OpenAI. OpenAI đã cung cấp các chỉ số hiệu suất và chi tiết quy trình, nhưng chưa đủ dữ liệu ở cấp độ lỗ hổng để so sánh hệ thống của họ với các chương trình bảo mật thông thường hoặc đánh giá độc lập mức độ bao phủ phát hiện.

Câu hỏi thường gặp

OpenAI có đang phản ứng trước một vụ xâm nhập bên ngoài đã được xác nhận không?

Không. OpenAI mô tả công việc này là một đợt chạy nước rút bảo mật nội bộ và không nói rằng thông báo về Defense Factory liên quan đến một vụ xâm nhập bên ngoài mới.

Defense Factory làm gì?

Nó kết nối kiểm kê tài sản, phát hiện lỗ hổng, xác thực khi chạy, định tuyến quyền sở hữu, tạo bản vá và xác minh sau triển khai trong một quy trình lặp lại có sự hỗ trợ của tác tử.

Các tác tử AI có triển khai bản sửa lỗi mà không cần phê duyệt của con người không?

OpenAI cho biết Codex đã tạo các bản vá, nhưng các thay đổi có hệ quả vẫn phải chịu sự đánh giá của con người và ủy quyền triển khai. Sau đó, các bản sửa lỗi production được kiểm thử lại độc lập.

OpenAI đã tìm thấy bao nhiêu lỗ hổng?

OpenAI chưa công bố tổng số. Họ báo cáo đã xử lý xong 53 vấn đề khẩn cấp hoặc ưu tiên cao trong ngày đầu tiên, nhưng không tiết lộ số lượng đầy đủ hoặc phân bố mức độ nghiêm trọng của các phát hiện.

Tổ chức nào cũng có thể sử dụng các mô hình an ninh mạng tương tự không?

Không tự động. OpenAI hướng các bên phòng thủ được ủy quyền đăng ký qua Daybreak, nơi quyền truy cập vào các công cụ an ninh mạng có năng lực hoặc cởi mở hơn phụ thuộc vào xác minh, kiểm soát phạm vi và giám sát quản trị.

Tham khảo nguồn

• Bài đăng gốc của OpenAI trên X
• OpenAI: Defense Factory
• OpenAI: Daybreak
• OpenAI: Trusted Access for the Next Era of Cyber Defense
• Cloudflare: Xây dựng Vulnerability Harness của riêng bạn