2.000 ứng dụng Vibe-Coding bị lộ cho thấy giới hạn của các hệ thống bảo mật hiện nay

Shadow AI từng có nghĩa là nhân viên dán những nội dung không nên vào ChatGPT. Giờ đây, nó mang một ý nghĩa lớn hơn: nhân viên xây dựng toàn bộ ứng dụng bằng AI, kết nối chúng vào các hệ thống sản xuất và xuất bản chúng công khai trên internet mà không có sự tham gia của bộ phận Bảo mật hay IT. Sản phẩm tạo ra đã chuyển từ một câu lệnh thành một sản phẩm hoàn chỉnh. Và bề mặt rủi ro cũng dịch chuyển theo đó. Trong báo cáo The Shadow Builders, Red Access đã xác định được hơn 380.000 tài sản web có thể truy cập công khai trên các nền tảng vibe-coding hàng đầu.
Rủi ro từ Shadow AI và Vibe-coding

Shadow AI từng có nghĩa là nhân viên dán những nội dung không nên vào ChatGPT. Giờ đây, nó mang một ý nghĩa lớn hơn: nhân viên xây dựng toàn bộ ứng dụng bằng AI, kết nối chúng vào các hệ thống sản xuất (production) và xuất bản chúng công khai trên internet mà không có sự tham gia của bộ phận Bảo mật hay IT.

Sản phẩm tạo ra đã chuyển từ một câu lệnh (prompt) thành một sản phẩm hoàn chỉnh. Và bề mặt rủi ro cũng dịch chuyển theo đó.

Trong báo cáo The Shadow Builders, một cuộc điều tra cấp danh mục mới được Axios, WIRED và VentureBeat đưa tin vào tháng 5, Red Access đã xác định được hơn 380.000 tài sản web có thể truy cập công khai trên các nền tảng vibe-coding hàng đầu.

Khoảng 5.000 tài sản trong số đó có vẻ thuộc về doanh nghiệp. Hơn 2.000 tài sản chứa dữ liệu nhạy cảm của công ty, dữ liệu vận hành hoặc dữ liệu cá nhân - nằm công khai trên web, được triển khai mà không có các biện pháp kiểm soát truy cập cơ bản, thường cấp quyền admin mặc định cho bất kỳ ai truy cập URL. Hiện trạng này diễn ra trên cả sáu châu lục, ở mọi ngành nghề được khảo sát và không cần đến bất kỳ kỹ thuật exploit nào.

Bên trong các tổ chức, họ vẫn vượt qua các kỳ kiểm toán (audits) trong khi những lỗ hổng này vẫn đang tồn tại.

Shadow AI mới không phải về câu lệnh. Đó là về sản phẩm.

Vibe coding - một không gian rộng lớn của các nền tảng phát triển dựa trên AI, nơi bất kỳ ai cũng có thể xây dựng một ứng dụng hoạt động được bằng cách mô tả những gì họ muốn - đã rút ngắn quy trình vốn tốn hàng tháng trời của các đội ngũ kỹ thuật xuống thành thứ mà một người không chuyên về lập trình có thể hoàn thành trước giờ ăn trưa.

Một quản lý marketing xây dựng trình theo dõi chiến dịch và kết nối nó với công cụ BI nơi chứa các con số thực tế. Một quản lý vận hành xây dựng biểu mẫu tiếp nhận nhà cung cấp và kết nối nó với hệ thống ticketing. Một nhóm tài chính xây dựng bảng điều khiển chuẩn bị cho cuộc họp hội đồng quản trị và kéo dữ liệu hóa đơn vào đó trước thứ Sáu. Những ứng dụng đó được kết nối với các hệ thống sản xuất đã được phê duyệt - CRM, ERP, công cụ ticketing, nền tảng BI - và thường xuyên được xuất bản lên internet công cộng, với bất kỳ quyền kiểm soát truy cập nào mà người xây dựng thiết lập. Thường là không có gì.

Những người làm việc này không có ý đồ xấu. Họ là những nhân viên có năng lực, đang giải quyết các vấn đề thực tế nhanh hơn mức tổ chức của họ có thể đáp ứng, làm chính xác những gì các nền tảng đó khuyến khích. Các nền tảng cũng không phải là kẻ xấu - họ đang cung cấp những gì người dùng yêu cầu. Điều không theo kịp chính là các rào chắn (guardrails), cả về kỹ thuật lẫn hành vi, quản lý những gì xảy ra sau khi ứng dụng được xây dựng.

Đây không phải là Shadow IT theo nghĩa cũ. Shadow IT cũ có giới hạn: khi một nhóm mua tài khoản Trello bằng thẻ công ty mà không báo cho ai, dữ liệu nằm bên trong một nhà cung cấp SaaS không được phê duyệt, nhưng ít nhất định danh, nhật ký kiểm tra (audit logs) và bề mặt quản trị vẫn tồn tại. Shadow Builders đảo ngược điều đó. Ứng dụng được xây dựng tùy chỉnh, dữ liệu được tải lên tùy chỉnh, các tích hợp là kết nối trực tiếp đến các hệ thống hồ sơ sản xuất, và thành phẩm thường được xuất bản trên internet công cộng. Nền tảng bên dưới có thể được kiểm toán; nhưng ứng dụng được xây dựng trên đó thì không. Chỉ có người xây dựng, nền tảng và URL. Còn IT? Hầu như không có mặt.

Tại sao các hệ thống bảo mật hiện đại vẫn bỏ sót điều này

Phản xạ của một CISO khi đọc những con số trên là kiểm tra lại hệ thống bảo mật (stack). EDR đang chạy. DLP đã được cấu hình. CASB đã có bản quyền. Firewall và SSE đã sẵn sàng. Một số tổ chức còn bổ sung trình duyệt doanh nghiệp. Mỗi công cụ đó đều đang làm đúng chức năng được thiết kế. Nhưng danh mục rủi ro mới này lại nằm ở những khoảng trống giữa chúng.

EDR nhìn thấy tiến trình trình duyệt, chứ không thấy việc xây dựng bên trong đó. Đối với một agent ở thiết bị đầu cuối, một Shadow Builder sử dụng nền tảng vibe-coding trông giống như hoạt động trình duyệt bình thường, không độc hại - cùng một dạng dữ liệu đo từ xa (telemetry) như khi ai đó đọc tin tức. Ngay cả khi EDR hiện đại hoặc trình duyệt doanh nghiệp có thể nhìn sâu hơn, nó cũng chỉ làm được điều đó trên các thiết bị thuộc sở hữu của tổ chức và bên trong các trình duyệt mà tổ chức quản lý. Laptop cá nhân, máy tính của nhà thầu, thiết bị BYOD và các tab trình duyệt cá nhân về định nghĩa là vô hình.

DLP giám sát các kênh được liệt kê. Nó có thể gắn cờ một người dùng dán dữ liệu được quản lý vào một cuộc trò chuyện AI đã biết. Nó không thể thấy một ứng dụng vibe-coded kết nối theo lập trình với một công cụ BI đã được phê duyệt qua API, di chuyển dữ liệu từ đám mây sang đám mây, hoàn toàn bỏ qua thiết bị đầu cuối.

CASB được xây dựng cho Shadow IT - cho các nhà cung cấp SaaS với các định danh có thể khám phá được. Nó không dễ dàng phân biệt được vô số các ứng dụng tùy chỉnh được lưu trữ trên các subdomain của nền tảng vibe-coding với chính bản thân nền tảng đó. Toàn bộ các ứng dụng này thường được ghi nhận như một nhà cung cấp SaaS đã được phê duyệt duy nhất.

Firewall và SSE nhìn thấy lưu lượng truy cập đến domain của nền tảng nhưng thiếu ngữ cảnh "ứng dụng như một đối tượng kinh doanh". Và hầu hết các triển khai SASE/SSE đều chỉ là một phần - ngay cả những triển khai hoàn thiện vẫn để lại vấn đề thiết bị không được quản lý chưa có lời giải.

Không có công cụ nào trong số này thất bại. Chỉ là danh mục rủi ro này nằm xuyên suốt các khoảng hở mà kiến trúc hiện tại để lại giữa các lớp, tạo ra những mảnh tín hiệu rời rạc không bao giờ tập hợp thành một bức tranh duy nhất có thể quản trị được.

Nơi thực sự cần khả năng hiển thị (visibility)

Từ đầu đến cuối, vibe coding là một sự kiện phiên web (web-session event). Việc xây dựng là một sự kiện trình duyệt. Việc cấp quyền OAuth kết nối ứng dụng mới với hệ thống doanh nghiệp là một sự kiện trình duyệt. Dữ liệu mà ứng dụng xoay quanh di chuyển qua phiên làm việc. Việc triển khai là một sự kiện trình duyệt - hành động xuất bản biến bản dựng thành một ứng dụng trực tiếp tại một URL công khai là một cú nhấp chuột bên trong cùng một tab nơi mọi thứ khác đã diễn ra.

Mọi bước đều xảy ra ở lớp phiên (session layer). Không phải bên cạnh nó. Mà là bên trong nó.

Do đó, một biện pháp kiểm soát được đặt tại lớp phiên sẽ thấy được toàn bộ lộ trình xây dựng - chứ không phải một mảnh nhỏ. Nền tảng được sử dụng. Các hệ thống doanh nghiệp được kết nối, và thông qua cơ chế nào. Dữ liệu đang di chuyển ra vào. Sự kiện xuất bản đưa ứng dụng lên internet công cộng. Tất cả đều có thể quy trách nhiệm cho một người cụ thể và một phiên bản ứng dụng cụ thể, bất kể trình duyệt nào được sử dụng hay lộ trình mạng nào mà lưu lượng truy cập đi qua. Và quan trọng nhất, bất kể thiết bị đó là laptop do công ty cấp hay máy cá nhân của nhà thầu.

Những việc cần làm ngay trong tuần này

Bốn bước triển khai. Không bước nào yêu cầu phải mua sắm công nghệ ngay lập tức.

  1. Bắt đầu với việc khám phá (discovery): Hỏi trực tiếp nhân viên xem họ đã xây dựng những gì. Hầu hết Shadow Builders đang làm những công việc hữu ích và không giấu giếm điều gì; cách đặt vấn đề rất quan trọng. Một thông báo toàn công ty - "Nếu bạn đã xây dựng một công cụ bằng nền tảng phát triển AI, vui lòng cho chúng tôi biết. Chúng tôi không kiểm tra kỷ luật. Chúng tôi đang thống kê tài sản" - sẽ hiệu quả hơn trong lần đầu tiên so với một bản ghi nhớ chính sách hoặc triển khai công cụ.
  2. Sau đó là lập bản đồ: Đối với mỗi ứng dụng được phát hiện, hãy ghi lại nó được kết nối với hệ thống doanh nghiệp nào, bằng cách nào (OAuth, API key, tải lên thủ công - các dấu vết kiểm tra khác nhau) và liệu nó có thể truy cập công khai hay không. Khả năng tiếp cận công khai là tín hiệu quan trọng nhất cần xử lý trong ngắn hạn.
  3. Thiết lập một lộ trình được phê duyệt: Cung cấp cho các Shadow Builders một nơi để báo cáo. Chỉ tên các nền tảng được phê duyệt, xác định các danh mục dữ liệu được chấp nhận và thiết lập tiêu chuẩn xác thực tối thiểu. Cách này ít gây trở ngại hơn so với việc họ không báo cáo gì với bạn.
  4. Chấp nhận thực tế: Công việc này không phải là kiểm kê một lần. Các ứng dụng vibe-coded liên tục được tạo ra; bức tranh bạn xây dựng tháng này sẽ không còn đầy đủ vào tháng sau. Tư thế bảo mật trưởng thành là khám phá liên tục ở lớp mà hoạt động thực sự diễn ra.

Danh mục này sẽ tiếp tục phát triển. Các nền tảng sẽ tiếp tục điều chỉnh các cài đặt mặc định. Không có sự thích nghi nào là kết thúc. Sự phơi nhiễm này hiện đang tồn tại ở hầu hết các doanh nghiệp.

Red Access là nền tảng bảo mật lớp phiên, không cần agent, được xây dựng chính xác cho việc này - cung cấp khả năng hiển thị và quản trị cấp độ SSE ngay tại phiên làm việc, trên mọi trình duyệt, mọi thiết bị, bao gồm cả những thiết bị không được quản lý. Có thể triển khai trong vài giờ. Yêu cầu kiểm tra miễn phí.