AI đang biến chuỗi cung ứng phần mềm thành một mặt trận an ninh. Công nghệ này đồng thời tăng tốc viết mã, lựa chọn phần phụ thuộc và khai thác lỗ hổng. Doanh nghiệp vì thế cần kiểm soát nguồn gốc thành phần và con đường đưa chúng vào hệ thống. Chỉ quét phần mềm sau khi mã đã được tạo không còn đủ.
Quincy Castro, Giám đốc an toàn thông tin của Chainguard, mô tả sự thay đổi này: “Con người định hướng điều họ muốn hoàn thành, nhưng họ phần nào bị tách khỏi quá trình thực hiện công việc.” Tác tử AI có thể tự chọn thư viện và gói phần mềm. Vì vậy, tổ chức có thể không nhìn thấy những quyết định ảnh hưởng trực tiếp đến độ an toàn của sản phẩm.
Theo bài viết gốc của The New Stack, GitHub xử lý khoảng một tỷ lượt ghi nhận mã trong năm 2025. Đến tháng 4 năm 2026, nền tảng xử lý khoảng 275 triệu lượt mỗi tuần. Số liệu này do Giám đốc vận hành GitHub Kyle Daigle cung cấp. Mức sử dụng GitHub Actions cũng tăng nhanh. Con số tăng từ 500 triệu phút tính toán mỗi tuần năm 2023 lên 2,1 tỷ phút trong một phần của một tuần năm 2026.
Castro cho rằng cách phần mềm được tạo ra đã thay đổi rõ rệt. Ông nói rằng trong năm qua, có lẽ không kỹ sư nào tại Chainguard tự mình viết trọn một dòng mã. Viết mã hoàn toàn thủ công lúc này giống như trang trí bản thảo bằng tay trong lúc máy in đã hoạt động hết công suất.
AI mở rộng phạm vi phát triển phần mềm
Sự thay đổi không chỉ nằm ở năng suất của lập trình viên chuyên nghiệp. Các nhóm nhân sự, tài chính và phân tích kinh doanh từng phải chờ bộ phận kỹ thuật. Nay họ có thể tự xây dựng một phần công cụ cần thiết. Điều đó làm tăng lượng phần mềm do người ngoài nhóm kỹ thuật truyền thống tạo ra. AI còn có thể tự quyết định thư viện hoặc gói phần mềm được đưa vào sản phẩm.
Với doanh nghiệp Việt Nam đang thử nghiệm tác tử AI viết mã, điểm cần chú ý không chỉ là tốc độ tạo phần mềm. Tổ chức còn phải biết tác tử đã lấy thành phần nào, lấy từ đâu và đưa thành phần đó vào môi trường bằng cách nào.
Khi tác tử tự chọn phần phụ thuộc
Khi tác tử AI đảm nhiệm phần lớn việc viết mã, quyền chọn thư viện và gói phần mềm không còn nằm hoàn toàn ở lập trình viên. Người giao việc có thể không quan sát được hệ thống đưa ra lựa chọn nào. Vì vậy, nguồn gốc và cách đưa phần phụ thuộc vào ứng dụng trở thành vấn đề bảo mật trực tiếp.
An toàn phần mềm từ lâu đã dựa trên thực tế rằng con người không thể kiểm tra mọi dòng mã. Dù vậy, lập trình viên vẫn trực tiếp đưa ra những quyết định quan trọng, gồm việc chọn thư viện và gói phần mềm cho ứng dụng. Tác tử AI làm tăng khoảng cách giữa người đặt mục tiêu và quá trình thực hiện.
“Con người định hướng điều họ muốn hoàn thành, nhưng họ phần nào bị tách khỏi quá trình thực hiện công việc”, Castro nói. AI lúc này có thể quyết định phần phụ thuộc nào được đưa vào ứng dụng và cách hoàn thành nhiệm vụ.
Kiểm soát nội dung tác tử đưa vào ứng dụng
Bên tấn công cũng đang dùng chính năng lực đó. Castro nhận thấy ba vấn đề xuất hiện đồng thời. Mô hình tiên phong có thể tìm ra lỗ hổng chưa từng được biết đến. Tác tử hỗ trợ khai thác những lỗ hổng tổ chức chưa sửa. Các chiến dịch kéo dài còn nhắm vào hệ sinh thái mã nguồn mở.
Trước đây, phát hiện có mức nghiêm trọng trung bình hoặc thấp thường nằm xa vị trí ưu tiên trong hàng chờ khắc phục. Claude Mythos Preview của Anthropic và GPT-5.6-Cyber của OpenAI có năng lực an ninh mạng tiên tiến. Các mô hình này có thể xem xét nhiều phát hiện cùng lúc. Sau đó, chúng nối những điểm yếu tưởng như nhỏ thành một đường tấn công khả thi.
Castro mô tả yêu cầu mà kẻ tấn công có thể giao cho AI theo cách trực diện: từ một loạt điểm yếu trung bình và thấp, hãy tìm đường giành quyền quản trị miền hoặc quyền cao nhất trên hệ thống. AI đặc biệt giỏi việc ghép các mắt xích đó.
Tốc độ khai thác và thứ tự ưu tiên
Theo báo cáo M-Trends của Mandiant, chỉ số mean time-to-exploit đã giảm từ mức trung bình 63 ngày trong giai đoạn 2018 đến 2019 xuống mức ước tính âm 7 ngày vào năm 2025. Hoạt động khai thác vì thế có thể bắt đầu trước khi đội phòng thủ có bản vá.
Khả năng kết hợp nhiều điểm yếu ít nghiêm trọng khiến hàng chờ dựa chủ yếu vào điểm CVSS phản ánh kém chính xác hơn những gì kẻ tấn công có thể làm. Việc dùng bối cảnh để ưu tiên lỗ hổng trở nên quan trọng hơn một danh sách chỉ sắp xếp theo điểm số.
Mã nguồn mở trở thành đường tấn công
Ứng dụng hiện đại phụ thuộc nhiều vào mã nguồn mở. Vì vậy, hạ tầng xây dựng và phân phối các thành phần này trở thành mục tiêu có sức lan truyền lớn. Một thành phần đáng tin cậy bị xâm nhập có thể đưa mã độc vào nhiều hệ thống phía dưới. Nguy cơ tăng khi quy trình tích hợp và triển khai thiếu kiểm soát.
Castro dẫn chiến dịch TeamPCP, trong đó các dự án được sử dụng rộng rãi, gồm Trivy của Aqua Security, đã bị xâm nhập. Mã độc được đẩy vào thành phần đáng tin cậy rồi tiếp tục đi xuống những hệ thống sử dụng thành phần đó.
Tấn công chuỗi cung ứng từng chủ yếu gắn với các nhóm tinh vi được nhà nước hậu thuẫn. Những nhóm này sẵn sàng dành nhiều thời gian để thâm nhập đúng vị trí. Rào cản đó đang thấp dần. Theo Castro, đây là hướng dễ thực hiện hơn nhiều người từng nghĩ nếu bên tấn công không ngại gây chú ý. Một lần xâm nhập thành công có thể kéo theo nhiều vụ khác và mở quyền truy cập sang nhiều nơi.
Kiểm soát đường phân phối mã nguồn mở
Quy trình phát triển có thể làm rủi ro lớn hơn. Castro cho biết nhiều tổ chức vẫn có ít biện pháp kiểm soát quanh quy trình tích hợp và triển khai liên tục. Trong khi đó, lập trình viên thường lấy thành phần từ nguồn bên ngoài để hoàn thành công việc. Công cụ viết mã tự động tiếp tục mở rộng phạm vi rủi ro của thói quen này.
Castro ví cách một số tổ chức sử dụng mã nguồn mở với việc cắm một thiết bị lưu trữ không rõ nguồn gốc vào hệ thống sản xuất. Vấn đề không nằm ở mã nguồn mở, mà ở việc tin vào đường phân phối khi chưa xác minh đầy đủ thứ được đưa vào hệ thống.
Khi lượng mã do AI tạo ra tăng nhanh, khâu xác minh không thể chỉ là một bước thủ công cuối quy trình. Khả năng kiểm chứng cần được tích hợp vào dây chuyền phát triển để theo kịp quy mô tự động hóa.
Phòng ngừa phải đi trước phát hiện
Quét và xử lý cảnh báo sau khi phần mềm đã xuất hiện không còn đủ khi sản lượng mã tăng và tác tử tự đưa ra nhiều quyết định nền tảng. Doanh nghiệp cần kiểm soát thành phần nào được phép đi vào môi trường, xác minh nguồn gốc của chúng và buộc mọi chủ thể sử dụng con đường đã phê duyệt.
Mô hình quản lý lỗ hổng quen thuộc thường bắt đầu bằng quét, tạo cảnh báo, đánh giá mức nghiêm trọng rồi giao người khắc phục. Cách làm này khó duy trì khi sản lượng phần mềm tăng mạnh, tác tử AI tự đưa ra nhiều quyết định hơn và bên tấn công có thể hành động trước khi bản vá xuất hiện.
Castro cho rằng doanh nghiệp nên tập trung vào những gì được phép đi vào môi trường phát triển. Họ không nên chờ phần mềm xuất hiện rồi mới tìm vấn đề. Mục tiêu là tạo ra một chuỗi đáng tin cậy từ lúc hình thành mã đến khi triển khai. Cách này giảm nhu cầu chạy theo cảnh báo và cố chứng minh một thành phần không có rủi ro.
Xác minh thành phần trước khi sử dụng
Đó là tư duy đứng sau cách Chainguard xử lý bộ chứa, thư viện và các sản phẩm mã nguồn mở khác. Công ty không chấp nhận nguyên trạng gói phần mềm từ hệ sinh thái công cộng rồi mới quét. Chainguard xây dựng sản phẩm từ mã nguồn đã được xác minh và có thể dùng để xây dựng. Công ty cũng cung cấp thông tin về nguồn gốc và quá trình tạo sản phẩm.
Thành phần đáng tin cậy mới chỉ là một lớp bảo vệ. Theo Castro, việc đưa phần mềm an toàn vào môi trường không có nhiều ý nghĩa nếu tổ chức thiếu biện pháp kỹ thuật buộc mọi người chỉ được lấy thành phần qua con đường đã phê duyệt.
Nhóm kỹ thuật, an toàn thông tin và vận hành hệ thống cần kiểm soát nguồn cung cấp phần mềm. Yêu cầu này áp dụng dù thành phần do con người hay tác tử AI lựa chọn. Tổ chức cũng phải biết phần mềm được xây dựng như thế nào. Cùng một bộ quy tắc cần áp dụng cho mọi chủ thể đưa mã vào dây chuyền.
Bảo vệ mã nguồn mở ở tốc độ của AI
Bảo vệ mã nguồn mở ở tốc độ của AI đòi hỏi quy trình chuyển phát hiện thành bản sửa. Quy trình đó cũng phải phân phối bản sửa về gần nguồn phát sinh. Chỉ tìm thêm lỗ hổng sẽ làm tăng số báo cáo mà nhà duy trì phải xử lý. Trong lúc đó, các thành phần chưa sửa vẫn tiếp tục lưu chuyển trong chuỗi cung ứng.
Mô hình tiên phong có thể tìm thấy những lỗ hổng từng bị bỏ sót. Chúng còn kết hợp các lỗi mức thấp thành đường tấn công hoạt động được. Một doanh nghiệp có thể gia cố quy trình nội bộ. Tuy nhiên, phần mềm của họ vẫn phụ thuộc vào hệ sinh thái mã nguồn mở. Hệ sinh thái đó không được xây dựng để tiếp nhận phát hiện lỗ hổng ở tốc độ và quy mô hiện nay.
Chuyển phát hiện thành bản sửa
Đây là một phần lý do Chainguard thành lập liên minh ngành Athena. Liên minh chuyển các phát hiện từ chương trình AI tiên phong thành bản sửa kỹ thuật. Theo số liệu Chainguard công bố, tính đến tháng 7, Athena đã xử lý hơn 40.000 lỗ hổng. Trong đó, 42% được xếp mức nghiêm trọng hoặc cao. Có 86% lỗ hổng có thể tiếp cận qua mạng, nghĩa là bên tấn công có thể truy cập và kích hoạt chúng từ mạng.
Với Castro, tìm thêm lỗi chưa phải phần quan trọng nhất vì AI đã làm việc đó rất tốt. Vẫn phải có người sửa lỗi. Athena tiếp nhận vấn đề, tự động tạo bản sửa rồi phân phối lại. Bản sửa cũng có thể được gửi ngược về dự án mã nguồn mở. Việc này giúp nhà duy trì xử lý lượng báo cáo lỗ hổng do AI tạo ra ngày càng lớn.
Điều chỉnh cách tổ chức phòng thủ
Sự thay đổi lớn hơn nằm ở cách ngành phần mềm tổ chức khâu phòng thủ. Lập trình viên sẽ không ngừng dùng tác tử viết mã chỉ vì chúng tạo thêm rủi ro. Doanh nghiệp cũng sẽ không bỏ mã nguồn mở chỉ vì bên tấn công nhắm vào nó. Gắn thêm nhiều công cụ quét vào một quy trình đang tăng tốc không giải quyết được gốc rễ.
Hướng xử lý là loại bỏ rủi ro trước khi phần mềm đến tay lập trình viên hoặc tác tử. Doanh nghiệp cần bắt đầu bằng thành phần có thể tin cậy. Họ phải kiểm soát con đường đưa thành phần vào môi trường và sửa điểm yếu gần nguồn phát sinh. Tranh luận về việc AI làm thay đổi hoạt động rà soát mã cũng cần bao quát nguồn gốc thành phần và quyền lựa chọn của tác tử.
AI đã làm giảm mạnh chi phí tạo phần mềm và đang làm điều tương tự với chi phí tấn công. Bảo mật phải theo kịp tốc độ đó mà không buộc đội phát triển quay lại cách làm thủ công.
Hãy tiếp tục theo dõi Sine để cập nhật cách các đội kỹ thuật và bảo mật thích ứng khi AI tham gia sâu hơn vào chuỗi cung ứng phần mềm.
