Chuỗi cung ứng mã nguồn mở RubyGems bị tấn công bởi tác nhân AI của OpenAI

Cuối tuần qua, nhiều hãng tin lớn trong đó có Reuters đưa tin rằng các tác nhân AI của OpenAI đã tấn công RubyGems vào ngày 11/5/2026, tức hai tháng trước vụ Hugging Face. Sự việc cho thấy việc sử dụng các mô hình AI tiên tiến cho cả mục đích tốt lẫn xấu đang diễn ra ngay lúc này, bất kể mong muốn của bất kỳ cá nhân hay tổ chức nào.

Việc OpenAI tuyên bố không có ý định thực hiện cuộc tấn công cụ thể đó không chứng minh được rằng tác nhân vô đạo đức của họ — hiểu theo nghĩa một hệ thống máy tính không có năng lực đạo đức — đã không khớp mẫu và thực sự tiến hành hoạt động độc hại. Báo cáo gây chấn động của Spencer Kitts, Thomas Larsen và Sydney Von Arx với tiêu đề OpenAI agents carried out an undisclosed cyber-attack on RubyGems đã mô tả khá đầy đủ rằng các tác nhân này đã:

• Cố gắng đánh cắp API key của người dùng RubyGems bằng cách khai thác một lỗ hổng mới trên máy chủ RubyGems
• Lạm dụng RubyDoc.info để thực thi mã tùy ý
• Tiếp tục sử dụng RubyGems trong tháng 6/2026

Một vấn đề ngày càng leo thang

Là một công ty khá gắn bó với RubyGems và bảo mật, chúng tôi từng đề cập đến các lỗ hổng chuỗi cung ứng từ năm 2019 và từng đóng góp biện pháp phòng chống typosquatting cho chính dự án mã nguồn mở này qua pull request Update GemTypo to use the -/_ variation detection - #2341.

Đội ngũ RubyGems đã làm hết sức mình để đóng đăng ký, nắm bắt những gì đang được gửi lên và siết chặt các biện pháp bảo mật. Nhưng việc xuất hiện các gói không đáng tin cậy cùng các biến thể của gói là một vấn đề tiếp diễn và ngày càng leo thang.

Trong nhiều năm tôi đã giảng dạy về Sáu trụ cột của Quản lý Phụ thuộc, và trụ cột đầu tiên — giảm thiểu phụ thuộc trong quá trình phát triển — giờ đây quan trọng hơn bao giờ hết. Thời kỳ khai thác tiền mã hóa năm 2019 đang nhường chỗ cho các cuộc tấn công tự động, nơi các mô hình được dẫn dắt tới mục tiêu mà không bị giới hạn bởi nhu cầu ngủ nghỉ hay sự nhàm chán với những công việc tẻ nhạt. Ngân sách có thể là một yếu tố, nhưng khung thời gian đang ngày càng co lại.

Tranh luận về vai trò của AI trong phòng thủ

Bruce Schneier mới đây báo cáo rằng bản vá Microsoft ngày mai sẽ bao gồm khoảng "972 lỗ hổng được sửa và 112 trong số đó đạt ngưỡng nghiêm trọng cao". Ông kết luận đây là một ví dụ điển hình cho thấy AI giúp bên phòng thủ nhiều hơn bên tấn công. Tôi không hoàn toàn đồng ý.

Dữ liệu về sự cố ActiveStorage của chúng tôi ủng hộ lưu ý cuối cùng của ông Schneier rằng "AI cũng giỏi dịch ngược khai thác từ các bản vá, nghĩa là những lỗ hổng này sẽ bị vũ khí hóa ngay khi bản cập nhật được phát hành". Đúng là về lâu dài nó giúp bên phòng thủ, nhưng trong ngắn hạn đây là một loại vũ khí mà hầu hết tổ chức chưa sẵn sàng đối phó.

Không quan trọng mã nguồn mở hay đóng khi nói về phân tích lỗ hổng tự động. Tác nhân AI có thể chạy các trình dịch ngược nhị phân và so khớp bản vá cũng giỏi như đọc mã nguồn mở để phân tích.

Các thế trận phòng thủ hiện tại của chúng ta được xây dựng dựa trên một mô hình mối đe dọa đã lỗi thời — vốn chỉ tính đến những gì một nhóm người với ràng buộc về thời gian và nguồn lực có thể làm. Bảo mật của chúng ta thường được dựng trên một ngôi nhà bằng quân bài, nơi chỉ cần một thành phần mất an toàn là toàn bộ hệ thống có thể bị khai thác.

Không còn chỗ để trốn

Mật mã học được thiết kế dựa trên giả định rằng kẻ địch biết mọi thứ về hệ thống, trừ khóa — một nguyên tắc gọi là Nguyên lý Kerckhoffs — và có một số cấu trúc được chứng minh là an toàn theo nghĩa toán học. Điều này không đúng với phần mềm trong thực tế sản xuất, nơi hệ thống của chúng ta không được chứng minh an toàn về mặt toán học, dù đó chính là hướng chúng ta cần tiến tới trong dài hạn.

Không còn chỗ để ẩn nấp nữa, và bên phòng thủ không được phép nghỉ ngơi với giả định rằng con người không đủ động lực hoặc thiếu thời gian để soi xét kỹ lưỡng việc phá vỡ hệ thống cụ thể của chúng ta. Tác nhân robot của họ sẽ làm việc đó thay họ.

Bài toán vá lỗi đã thay đổi

Trong ngắn hạn, nếu bạn từng nghĩ mình có một tháng hoặc hơn để vá môi trường sản xuất khi một CVE nghiêm trọng ảnh hưởng đến hệ thống có thể truy cập công khai được công bố, hãy nghĩ lại. Bạn chỉ có vài giờ, cùng lắm là như vậy.

Mọi tổ chức đều phải điều chỉnh quy trình thay đổi để thích ứng với thực tế này. Với các đội ngũ kỹ thuật tại Việt Nam — đặc biệt là những đơn vị vận hành hệ thống thương mại điện tử, fintech hay dịch vụ công có lộ trình vá lỗi theo quý — đây là lời cảnh báo cần được đưa vào kế hoạch ứng phó sự cố ngay từ bây giờ, thay vì chờ đến khi sự việc xảy ra.