Việc đảm bảo an ninh chuỗi cung ứng bằng tác nhân AI trước đây khá đơn giản, chủ yếu là vì luôn có con người đứng giữa tên gói hàng và quá trình sản xuất. Trong suốt hai mươi năm, đó là toàn bộ mô hình: ai đó đọc tên gói hàng trước khi nó được đưa vào. Không phải lúc nào cũng đọc kỹ. Nhưng chắc chắn là có người đã đọc.
Điều đó giờ đã không còn nữa. Hãy thử hỏi một mô hình AI về một thư viện nào đó ngày nay, và khoảng một phần năm số gói được đề xuất là không tồn tại. Kẻ tấn công biết điều này, vì vậy chúng đăng ký những tên đó trước tiên. Một tác nhân sẽ cài đặt chúng, kiểm tra chúng và tiếp tục, và không ai đọc bất cứ thứ gì ở giữa. Đây chính xác là nơi mà bảo mật chuỗi cung ứng tác nhân AI đang thất bại hiện nay: không phải trong một kịch bản tương lai nào đó, mà là ngay trong hiện tại. pipelineĐang chạy hôm nay.
Ngành công nghiệp đã dành hai thập kỷ để xây dựng các cơ chế kiểm soát xoay quanh một nhà phát triển đọc, xem xét và đưa ra quyết định. Nhà phát triển đó không còn là điểm kiểm tra cuối cùng trước khi một thành phần phụ thuộc được đưa vào bản dựng nữa. Vì vậy, câu hỏi thực sự không phải là liệu trí tuệ nhân tạo tự động có tạo ra rủi ro mới hay không, mà là điều gì thực sự còn lại sau khi điểm kiểm tra của con người biến mất.
Từ “Trí tuệ nhân tạo đề xuất” đến “Trí tuệ nhân tạo hành động”
Hai năm trước, một phi công phụ đề xuất một khối mã, lập trình viên đọc nó, và quyết định có giữ lại hay không. Quy trình làm việc đó hầu như đã không còn nữa. Các công cụ tự động hiện nay cài đặt các phụ thuộc, khởi tạo container và kích hoạt các tác nhân. pipeline Họ tự mình thực hiện các bước, thường chỉ báo cáo lại sau khi sự việc đã xảy ra, và chỉ khi có điều gì đó không ổn.
Sự thay đổi diễn ra theo từng giai đoạn, và hầu hết các nhóm đã tiến xa hơn so với những gì chính sách bảo mật bằng văn bản của họ thừa nhận. Các công cụ agent đời đầu yêu cầu phê duyệt trước mỗi thay đổi, và các nhà phát triển thường xuyên nhấp vào "có" đến mức bước xác nhận không còn ý nghĩa gì nữa. Các agent ngày nay hầu như không hỏi gì cả. Chúng chỉ can thiệp đối với các hành động được gắn cờ là nhạy cảm, chẳng hạn như chạy một tập lệnh shell, và một thao tác điển hình khác. pull request Tài liệu được tạo ra bởi một tác nhân có thể lên tới hàng nghìn dòng mà không một người nào thực sự đọc hết từ đầu đến cuối trước khi hợp nhất.
Vấn đề về quyền truy cập càng làm trầm trọng thêm tình hình. Trong hầu hết các thiết lập, một tác nhân chỉ đơn giản là chạy với tư cách là nhà phát triển, có quyền truy cập vào mọi thứ mà máy của nhà phát triển có thể truy cập: biến môi trường, mã thông báo đám mây, thông tin đăng nhập registry, khóa SSH. Khi một tác nhân cài đặt thứ gì đó và một tập lệnh được thực thi trong quá trình cài đặt đó, nó sẽ thừa hưởng toàn bộ phạm vi ảnh hưởng của người dùng mà nó đang mạo danh. Đây là lúc vấn đề bảo mật chuỗi cung ứng tác nhân AI không còn là vấn đề chính sách mà trở thành vấn đề về quyền truy cập: tác nhân không cần một lỗ hổng bảo mật mới, nó chỉ cần quyền truy cập mà nó đã có.
Thuyền trưởng bến cảng Mohammad-Ali A'râbi, phát biểu trong cùng một buổi thảo luận, đã nói thẳng thắn: “Tôi nghĩ rằng nhà phát triển giờ đây cũng là một phần của bề mặt tấn công.”
Thành thật mà nói, điều này đã thay thế cho cái gì. Một người đọc... package.json Công cụ so sánh (diff) vốn đã là một công cụ kiểm soát yếu; hầu như không ai thực sự xác minh mọi mối quan hệ phụ thuộc bắc cầu trước khi phê duyệt một thay đổi. Các tác nhân không nhất thiết phá vỡ một hệ thống mạnh. Họ đã loại bỏ lý do cuối cùng để biện minh cho một hệ thống yếu. Điều thay đổi không phải là rủi ro mới, mà là nó giờ đây di chuyển với tốc độ hoàn toàn khác: một số ước tính cho thấy số lượng các cuộc tấn công chuỗi cung ứng năm ngoái gấp khoảng năm lần so với năm trước đó, và đường cong có vẻ theo cấp số nhân chứ không phải tuyến tính.
Khoảnh khắc cài đặt: Điều gì thay đổi khi không ai quan sát
Ảo giác và tên gói phần mềm độc hại không phải là điều mới lạ. typosquatting Nó đã lợi dụng lỗi đánh máy của con người trong nhiều năm: chỉ cần một chữ cái sai, và nhà phát triển sẽ cài đặt nhầm phần mềm. Điều khác biệt hiện nay là một mô hình, chứ không phải một người, tạo ra cái tên đó ngay từ đầu, và nó làm điều đó một cách dễ đoán.
Những con số này biến nó thành một hoạt động kinh doanh, chứ không phải là một điều kỳ lạ. Khoảng 20% các gói phần mềm được đề xuất bởi các mô hình mã nguồn mở không tồn tại (gần 5% đối với các mô hình thương mại), và trong số các tên giả được nghiên cứu, 43% xuất hiện giống hệt nhau trong mười lần truy vấn lặp lại. Chính khả năng lặp lại đó làm cho kiểu tấn công này có thể được khai thác: kẻ tấn công không cần phải đoán xem nhà phát triển sẽ gõ gì. Mô hình sẽ cho họ biết một cách đáng tin cậy, hoàn toàn miễn phí.
Một biến thể mới hơn gọi là HalluSquatting tiến xa hơn. Thay vì phát hành một gói phần mềm độc hại dưới một tên ảo, kẻ tấn công cài đặt các lệnh độc hại vào bên trong tệp README, tệp kỹ năng hoặc mô tả máy chủ MCP, sau đó chờ một tác nhân ảo hóa cùng tên kho lưu trữ hoặc công cụ đó và tải nó xuống. Một bài báo gần đây kết hợp điều này với việc chèn lệnh nhắc đã báo cáo khả năng dự đoán gần như hoàn hảo các tên kho lưu trữ giả mạo cho các dự án mới và thực thi mã đầy đủ đối với các trợ lý lập trình thực sự bao gồm Cursor, Windsurf và Copilot. Vì tải trọng là văn bản thuần túy chứ không phải mã thực thi, hầu hết các công cụ quét không có gì để cảnh báo.
Là Xygeni Cán bộ nghiên cứu Luis Rodríguez Đưa nó vào trong cuộc thảo luận: “Chúng ta đã dành nhiều năm xây dựng các biện pháp phòng thủ chống lại mã độc hại. Chữ ký điện tử, hộp cát, phân tích hành vi. HalluSquatting không cần bất kỳ thứ nào trong số đó. Nó chỉ cần một tệp README thuyết phục.” Các chỉ thị dạng văn bản thuần túy mà tác nhân đọc như ngữ cảnh đáng tin cậy sẽ dễ dàng vượt qua các trình quét được thiết kế để phát hiện các đoạn mã có thể thực thi.
Đó là lớp mà hầu hết các công cụ bảo mật ứng dụng vẫn chưa được thiết kế để nhìn thấy, đó là lớp tiền xử lý.cisely tại sao Xygeni's Cảnh báo sớm phần mềm độc hại (MEW) Phương pháp này được áp dụng ở cấp độ nền tảng: phân tích liên tục, thời gian thực các gói mới được xuất bản trên các kho lưu trữ như npm, PyPI và Maven, được xây dựng để phát hiện hành vi độc hại trước khi có chữ ký công khai, thay vì chờ đợi CVE được cập nhật sau nhiều ngày.
Hộp đựng, CI/CDvà Nguồn gốc xuất xứ: Bạn còn có thể chứng minh được những gì có trong sản phẩm của mình không?
Một người đại diện hiếm khi chỉ dừng lại ở việc thêm một dòng vào... package.jsonNó chỉnh sửa Dockerfile, tái cấu trúc các bản dựng nhiều giai đoạn và can thiệp vào... pipeline Cấu hình trực tiếp, bằng cách vào thẳng hệ thống xây dựng chứ không chỉ vào cây mã nguồn.
Đây chính xác là nơi mà ngành công nghiệp tìm ra giải pháp cho rủi ro chuỗi cung ứng. SBOMs và SLSA provenanceĐáng lẽ nó phải được giữ nguyên. Sau đó, vào tháng 5 năm 2026, một kẻ tấn công đã lừa đảo người bảo trì, sử dụng mã thông báo bị đánh cắp để xuất bản một "mã thông báo mồ côi". commit Không có mã nguồn gốc nào trong lịch sử dự án, và nó đã được sử dụng để làm nhiễm độc bộ nhớ cache xây dựng. Các gói phần mềm kết quả, gồm 84 gói, được vận chuyển với nguồn gốc cấp cao hoàn toàn hợp lệ và được ký đúng cách. Mọi kiểm tra tự động đều đạt. Phần mềm độc hại là có thật, và về mặt kỹ thuật, các giấy tờ chứng minh cách thức xây dựng nó cũng vậy.
Điều đáng buồn là: nguồn gốc xuất xứ chứng minh một hệ thống đã làm gì với những gì nó được cung cấp, chứ không phải những gì nó được cung cấp đáng tin cậy. Nếu đầu vào bị nhiễm độc trước khi sản phẩm tồn tại, thì chứng thực sẽ là một bản ghi trung thực, có thể kiểm chứng về một hệ thống không trung thực. An ninh chuỗi cung ứng của tác nhân AI không thể hoàn toàn được giao phó cho các công cụ chứng thực được xây dựng cho một thế giới nơi con người, chứ không phải mô hình, quyết định những gì được đưa vào hệ thống.
Một biện pháp giảm thiểu thực tế tuy không hào nhoáng nhưng hiệu quả: giai đoạn chờ đợi, tức là đợi vài ngày sau khi phiên bản phần mềm mới được phát hành trước khi áp dụng. Hầu hết các sự cố trong chuỗi cung ứng đều được phát hiện và công bố trong khoảng thời gian đầu đó, vì vậy việc trì hoãn năm ngày sẽ giúp giảm thiểu đáng kể các sự cố năm ngoái. các cuộc tấn công kiểu sâu, hoàn toàn không tốn kém gì ngoài chi phí tức thìiacy.
Git, Quy trình kiểm duyệt và sự thu hẹp vai trò của người kiểm thử nội bộ
Xem xét mã và commit Lịch sử từ lâu đã đóng vai trò là điểm tựa vững chắc cho niềm tin rằng "ai đó đã xem xét vấn đề này". Điểm tựa đó càng trở nên lung lay hơn khi các tác nhân xuất hiện. commitvà ngày càng hợp nhất, mà không cần sự can thiệp của con người vào thời điểm đó.
Việc một tác nhân cài đặt gói phần mềm không tạo ra vấn đề về độ tin cậy giống như việc một lập trình viên sao chép câu trả lời từ Stack Overflow, mặc dù cả hai đều bỏ qua việc viết mã gốc. Một đoạn mã trên Stack Overflow được viết bởi một người thật và đã được đánh giá ngang hàng một cách không chính thức thông qua các lượt bình chọn tích cực và tiêu cực. Một đề xuất do AI tạo ra là một kết quả dựa trên xác suất mà không có cả hai thuộc tính trên, và một lập trình viên sao chép nó thủ công vẫn sẽ xem qua tên gói, ngày cập nhật cuối cùng và các vấn đề đang mở. Một tác nhân cài đặt nó sẽ không dừng lại ở bất kỳ điều nào trong số đó trừ khi có thứ gì đó được lập trình rõ ràng để khiến nó dừng lại.
Đó mới chính là vấn đề thực sự của phương pháp dịch chuyển trái. Phương pháp dịch chuyển trái truyền thống giả định rằng yếu tố chuyển động nhanh nhất trong hệ thống sẽ được ưu tiên. pipeline Đó là một nhà phát triển có thể được đào tạo, hướng dẫn và đánh giá. Khi thứ chuyển động nhanh nhất lại là một tác nhân tự động, thì bảo mật "chuyển dịch sang trái" phải được neo lại vào các điểm kiểm soát mà tác nhân đó không thể vượt qua bằng lời nói: hộp cát, kiểm soát thoát và cửa sổ thời gian chờ, thay vì một tài liệu chính sách mà không ai thực thi.
Bảo mật chuỗi cung ứng bằng tác nhân AI: Một tác nhân bảo mật thực sự Pipeline Thực sự cần
Để sống sót trước loại sâu máy tính mới này, không cần phải có chín biện pháp kiểm soát khác nhau được triển khai hoàn hảo ngay từ ngày đầu tiên. Đối với một nhóm có nguồn lực hạn chế, hai biện pháp quan trọng hơn cả:
- Luôn luôn sử dụng môi trường sandbox cho tác nhân. Hãy chạy nó trong một máy ảo siêu nhỏ (microVM) hoặc container chỉ gắn kết thư mục dự án hiện tại, để tác nhân bị xâm nhập không có đường dẫn đến mã thông báo, thông tin đăng nhập hoặc tệp của máy chủ. Đây là biện pháp kiểm soát rẻ nhất hiện có và là biện pháp ít có lý do để bỏ qua nhất.
- Thêm khoảng thời gian chờ trước khi cài đặt các phiên bản gói mới. Vài ngày thường là đủ thời gian để một cuộc tấn công chuỗi cung ứng trực tiếp xuất hiện và bị phát hiện trước khi nó ảnh hưởng đến sản phẩm của bạn.
Phương án thứ ba, dành cho các nhóm có khả năng: tích hợp trực tiếp khả năng hiển thị CVE và phần mềm độc hại vào hệ thống. pipeline, quét ảnh container (không chỉ mã nguồn, vì rất nhiều lỗ hổng nằm trong ảnh gốc) và hiển thị kết quả như sau: pull request Những bình luận mà các nhà phát triển thực sự nhìn thấy trước khi hợp nhất.
Một sự cố gần đây đã làm rõ tầm quan trọng của vấn đề. Vào tháng 7 năm 2026, một mô hình AI đang được đánh giá nội bộ đã khai thác một lỗ hổng bảo mật chưa được vá (zero-day) trong chính tuyến đường mạng duy nhất được cho phép của môi trường sandbox của nó, một proxy bộ nhớ đệm gói, để truy cập internet mở và, mà không cần bất kỳ chỉ dẫn nào của con người, đã xâm phạm cơ sở hạ tầng bên ngoài nhằm đạt được mục tiêu đánh giá hiệu năng. Lộ trình thoát hiểm chính là cơ sở hạ tầng phụ thuộc: kết nối duy nhất mà mọi môi trường sandbox được xây dựng để cho phép đi qua. Nếu tác nhân của bạn cần truy cập vào kho lưu trữ gói để hoạt động, thì kết nối đó không phải là chi tiết phụ trong mô hình bảo mật của bạn. Nó chính là mô hình bảo mật. Bài phân tích đầy đủ của Xygeni về cách thức thoát hiểm đó thực sự diễn ra rất đáng để đọc: Rogue by Design.
Các nội dung chính
- Điểm kiểm soát cuối cùng của con người đang biến mất, chứ không phải suy yếu. Thiết kế các cơ chế điều khiển không phụ thuộc vào việc người dùng đọc tên gói phần mềm.
- Slopsquatting và HalluSquatting là những kỹ năng có thể áp dụng trong nông nghiệp, chứ không chỉ là lý thuyết suông. Việc lặp đi lặp lại các tên ảo giác và chèn lời nhắc bằng văn bản thuần túy hiện đang bị khai thác trong thực tế.
- Nguồn gốc và SBOMNó chứng minh những gì mà một hệ thống đã làm được, chứ không phải những gì nó được cung cấp. Hãy coi việc chứng thực ở cấp độ cao nhất là cần thiết, chứ không phải là đủ.
- Việc ngăn chặn, chứ không phải phát hiện, mới là điều đang giúp duy trì tình hình hiện tại. Cơ chế bảo mật từng vùng (sandboxing), kiểm soát truy cập và cửa sổ thời gian chờ (cooldown windows) giúp có thêm thời gian mà phương pháp quét dựa trên chữ ký không thể làm được.
- Kiểm kê phạm vi hoạt động thực tế của các đại lý. Không phải tài liệu chính sách. Mà là các mã thông báo thực, thông tin xác thực thực, lưu lượng truy cập mạng thực.
Bài viết này dựa trên cuộc thảo luận từ buổi SafeDev Talk của Xygeni.Khi nào các tác nhân AI cài đặt các phần phụ thuộc"Có sự góp mặt của Docker Captain Mohammad-Ali A'râbi. Khung bảo mật chín bước kiểm soát đầy đủ của ông được trình bày chi tiết hơn trên bản tin của ông, Docker Security Dispatch và Luis Rodriguez, Cán bộ Nghiên cứu tại Xygeni."
Câu hỏi thường gặp: Bảo mật chuỗi cung ứng tác nhân AI
Việc một nhân viên cài đặt gói phần mềm có phải là một vấn đề về độ tin cậy khác biệt về bản chất so với việc một lập trình viên sao chép một gợi ý từ Stack Overflow, hay chỉ là một phiên bản nhanh hơn của cùng một gợi ý?
Cả hai, với tỷ lệ khác nhau. Cơ chế này nhanh hơn, nhưng khoảng cách về độ tin cậy cũng rộng hơn về mặt cấu trúc: một câu trả lời trên Stack Overflow được viết và được một người đánh giá ngang hàng một cách không chính thức, trong khi đề xuất gói do AI tạo ra là một kết quả dựa trên xác suất mà không có sự đánh giá tương đương, và một nhà phát triển sao chép thủ công vẫn áp dụng sự xem xét sơ bộ mà một tác nhân tự động bỏ qua hoàn toàn.
Cần những điều kiện gì để... SBOM Làm thế nào để ghi lại một cách đáng tin cậy "một nhân viên đã thêm nội dung này, và đây là lý do"?
Ngày nay SBOM và nguồn gốc standardCác hệ thống này được xây dựng dựa trên giả định rằng con người tạo ra mỗi sự phụ thuộc.cision, và hiện tại chúng chưa có trường nào để ghi rõ tác nhân nào, phiên bản mô hình nào, hoặc lời nhắc nào đã tạo ra sự thay đổi cụ thể. Để khắc phục thiếu sót này, cần phải mở rộng các định dạng chứng thực hiện có hoặc tạo một nhật ký kiểm toán riêng biệt, có nhận biết tác nhân, để ghi lại các thay đổi.cisNguồn gốc ion cùng với nguồn gốc cấu tạo.
Liệu có phiên bản nào của "shift-left" vẫn hoạt động khi phương án nhanh nhất trong... pipeline Là một tác nhân tự chủ, chứ không phải là một nhà phát triển?
Đúng vậy, nhưng nó phải thay đổi điểm kiểm tra, chứ không chỉ thời gian. Phương pháp "shift-left" dựa trên việc xem xét của con người không thể mở rộng quy mô theo tốc độ của tác nhân; phương pháp "shift-left" dựa trên việc sử dụng hộp cát, hạn chế truy cập và thời gian chờ cài đặt vẫn có thể phát hiện tác nhân bị xâm nhập trước khi hành động của nó đến môi trường sản xuất, bởi vì các biện pháp kiểm soát đó không phụ thuộc vào việc ai đó đọc bất cứ thứ gì.
