Gói thư viện không tồn tại: slopsquatting và cách dạy agent không cài bừa

Dành cho bất kỳ ai dùng AI để viết code hoặc giao việc cho AI agent, kể cả người mới. Không cần biết bảo mật. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu rõ để bỏ qua nếu bạn không cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể nào. Nguyên nhân sâu xa khiến AI bịa tên thư viện chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ.

---

Tóm tắt nhanh#

• Khi viết code, AI đôi khi gợi ý một thư viện nghe rất hợp lý nhưng không tồn tại. Một nghiên cứu lớn tại USENIX Security 2025 đo được tỷ lệ này trung bình ít nhất 5,2% với mô hình thương mại và 21,7% với mô hình mã nguồn mở, trên các thí nghiệm năm 2024.
• Nếu cùng một tên giả được gợi ý lặp lại, kẻ xấu có thể đăng ký trước tên đó trên kho thư viện công cộng như npm hay PyPI và để mã độc vào trong. Cách tấn công này được gọi là slopsquatting.
• Trong nghiên cứu trên, khi chạy lại 500 câu hỏi từng ra tên giả, khoảng 43% tên giả xuất hiện đủ cả 10 lần. Tức là tên bịa không hoàn toàn ngẫu nhiên, đủ để kẻ xấu đoán trước.
• Đã có thí nghiệm thật: gói rỗng huggingface-cli nhận hơn 30.000 lượt tải, và tên react-codeshift lan sang hơn 200 repo. Cả hai do nhà nghiên cứu đăng ký, không chứa mã độc.
• Rủi ro có thật nhưng chưa rõ lớn đến đâu: tôi chưa tìm thấy ghi nhận chắc chắn về một vụ slopsquatting gây thiệt hại lớn. Điều đáng lo hơn là agent có thể tự chạy lệnh cài mà không ai xem.
• Cách phòng không cần công cụ đắt tiền: khóa phiên bản bằng lockfile, nhìn qua gói mới trước khi cài, tắt script cài đặt, bắt agent xin duyệt và chạy trong môi trường cô lập.

---

Từ khó, nói dễ#

---

1. Hình dung trước: cô nhân viên và cửa hàng mạo danh#

Hình dung bạn hỏi một nhân viên bán hàng rất nhiệt tình: "Có ốp lưng nào hợp máy này không?" Cô ấy trả lời ngay: "Có món Zorbo Pro, bên em có bán." Thực ra không có món nào tên đó. Cô ấy không nói dối, chỉ là cô ấy giỏi nói những cái tên nghe hợp lý.

Giờ hình dung có một kẻ lừa đảo nhận ra cô ấy hay nhắc đúng cái tên ấy với rất nhiều khách. Hắn mở một cửa hàng ngay trước cửa, treo bảng "Zorbo Pro" và bán một món hàng độc hại. Lần sau cô ấy gợi ý, khách đi theo và vào đúng cửa hàng của hắn.

Đó là slopsquatting. Cô nhân viên là AI, "món hàng" là tên thư viện, cửa hàng là kho gói như npm, và lệnh npm install là bước chân vào cửa. Khác với việc gõ nhầm tên, ở đây người dùng không sai gì cả. Họ chỉ làm theo lời gợi ý.

Thuật ngữ này được cho là do Seth Larson, nhà phát triển bảo mật của Python Software Foundation, đặt vào tháng 4/2025, theo cách thuật lại của Wikipedia và của Andrew Nesbitt, người giúp nó lan rộng. Tôi chưa tìm được bài viết gốc của ông Larson để đối chiếu, nên coi đây là thông tin thuật lại, không phải trích nguyên văn.

Điều rút ra: nguy cơ không nằm ở chỗ AI sai, mà ở chỗ cái sai của AI có thể đoán trước được và có người sẵn sàng chiếm chỗ.

---

2. Hai thí nghiệm có thật và một sự cố dễ nhầm#

2.1 Gói rỗng huggingface-cli (Lasso Security, 2023 đến 2024)#

Bar Lanyado, nhà nghiên cứu của Lasso Security, thấy các mô hình AI cứ gợi ý lệnh cài một gói tên huggingface-cli trên PyPI. Gói đó không có thật, cách cài đúng là huggingface_hub[cli]. Ông đăng ký một gói rỗng dưới tên đó để xem có ai cài không.

Theo các báo thuật lại, gói nhận hơn 30.000 lượt tải trong khoảng ba tháng. Các nguồn ghi con số khác nhau, từ khoảng 15.000 đến 35.000, nên hãy coi đây là cỡ vài chục nghìn. The Register còn ghi rằng tên giả này xuất hiện trong hướng dẫn cài đặt của một kho mã nghiên cứu của Alibaba, và đã được sửa sau khi ông báo.

Cần thận trọng: lượt tải không chứng minh ai bị hại. Chưa rõ bao nhiêu lượt đến từ code do AI sinh ra, bao nhiêu từ người chép theo hướng dẫn, bao nhiêu từ máy quét tự động.

Điều rút ra: một cái tên bịa lặp lại đủ nhiều thì có người cài thật, và nó còn có thể chui vào tài liệu của người khác.

2.2 react-codeshift lan sang hơn 200 repo (Aikido Security, 2025 đến 2026)#

Theo bài của Aikido Security, một commit ngày 17/10/2025 vào một repo công khai thêm 47 "skill" (tệp hướng dẫn cho agent) do mô hình ngôn ngữ sinh ra. Ít nhất hai tệp trong đó chứa lệnh npx react-codeshift. Tên này có vẻ là sự pha trộn của hai gói thật là jscodeshift và react-codemod. Gói react-codeshift chưa từng tồn tại.

Các tệp đó bị chép và fork ra nhiều nơi. Theo Aikido, tháng 12/2025 có hơn 200 repo nhắc đến lệnh này, và đến ngày 14/1/2026, khi nhà nghiên cứu Charlie Eriksen đăng ký tên gói, con số là 237 trở lên. Một tìm kiếm mã trên GitHub khi đó cho khoảng 215 tệp khớp. Con số nên hiểu là "hơn 200", vì cách đếm khác nhau cho kết quả khác nhau. Ngay sau khi đăng ký, gói nhận khoảng 74 lượt tải trong ngày đầu, rồi mỗi ngày chỉ một đến bốn lượt. Tác giả cho rằng lượt tải rỉ rả này gợi ý có agent thật đang thử chạy lệnh. Đây là suy đoán của họ, không phải kết quả đã kiểm chứng. Gói được giữ làm chỗ trống an toàn, không chứa mã độc.

Điều rút ra: lỗi do AI bịa ra không đứng yên. Nó được chép, fork, dịch rồi trở thành "chuẩn" mà chính các agent khác lại đọc theo.

2.3 Sâu npm tháng 5/2026: nguy hiểm thật, nhưng không phải slopsquatting#

Nhóm nghiên cứu của Cloud Security Alliance (CSA) trong ghi chú ngày 17/5/2026 mô tả một đợt sâu npm gắn với nhóm TeamPCP: 373 phiên bản gói độc hại trên 169 gói npm và hai gói PyPI. Ghi chú nói rằng sâu này còn ghi cấu hình vào các tệp của công cụ lập trình AI và có phiên bản mang cả dấu provenance hợp lệ. Đây là ghi chú thứ cấp, thuật lại nguồn của người khác, nên hãy mở bản gốc trước khi trích dẫn. CSA cũng tự nói một số khẳng định "đầu tiên" thuộc về các nhà nghiên cứu mà họ dẫn.

Điểm cần nhớ: đây là chuyện gói thật bị chiếm quyền, không phải gói do AI bịa. Nó nằm ở đây vì hai lý do. Thứ nhất, nó cho thấy kho gói là mục tiêu thật và agent chạy lệnh cài là mắt xích dễ bị lợi dụng. Thứ hai, nó cho thấy provenance không phải bảo chứng tuyệt đối. Thói quen phòng thủ ở phần 6 hợp cho cả hai loại sự cố.

Điều rút ra: đừng chỉ nhìn tên "slopsquatting". Việc cần làm là kiểm soát cái gì được cài vào máy bạn, dù tên gói do AI bịa hay gói thật bị đầu độc.

---

3. Cơ chế từng bước#

Hình dung một dây chuyền bốn mắt xích. Cần nói trước: vì sao mô hình bịa tên gói thì chưa ai hiểu hết. Một cách nghĩ phổ biến là mô hình luôn cố viết ra tên trông giống tên thư viện thật, và tên thật thường ghép từ những từ quen như react, codemod, cli. Đây là cách hình dung, không phải kết luận đã chứng minh.

1. Bạn hỏi. Bạn (hoặc agent) cần thêm một chức năng, ví dụ đọc tệp CSV, và nhờ AI viết code kèm lệnh cài.
2. AI gợi ý một tên. Đôi khi tên đó không có trên kho gói. Theo nghiên cứu, chỉ khoảng 13,4% tên giả chỉ cách một tên thật một hai chữ cái, nên đây không chủ yếu là lỗi gõ sai.
3. Kẻ xấu đăng ký tên đó. Kho gói công cộng cho phép đăng ký tên còn trống rất nhanh. Nếu tên giả lặp lại, kẻ xấu có thể hỏi các mô hình phổ biến nhiều lần để xem tên nào hay xuất hiện và chiếm tên đó.
4. Lệnh cài chạy thành công. Lúc đầu lệnh cài báo lỗi "không tìm thấy", vô hại. Sau khi tên bị chiếm, cùng lệnh đó chạy được, và các script cài đặt có thể chạy ngay trên máy của người cài hoặc máy CI.

3.1 Phép tính để bạn tự kiểm lại (minh họa, có thể bỏ qua)#

Đây là ví dụ minh họa với số bịa cho dễ tính, dựa trên hai con số thật của nghiên cứu làm mốc: 5,2% (mô hình thương mại) và 43% (tên giả lặp đủ 10 lần). Giả sử một nhóm 10 dev, mỗi người nhờ AI gợi ý lệnh cài 5 lần mỗi ngày làm việc, trong 20 ngày làm việc.

devs, per_day, days = 10, 5, 20
suggestions = devs * per_day * days          # 1000
fake_rate = 0.052                            # mốc thấp của mô hình thương mại
repeat_rate = 0.43                           # tên giả lặp đủ 10 lần trong thử nghiệm
fake = suggestions * fake_rate               # 52
predictable = fake * repeat_rate             # 22.36
check_minutes = fake * 2                     # kiểm tra mỗi gói 2 phút
print(suggestions, round(fake), round(predictable), check_minutes, check_minutes / devs)
# 1000 52 22 104.0 10.4

Đọc kết quả: trong 1.000 lời gợi ý có khoảng 52 tên giả, trong đó cỡ 22 tên thuộc loại lặp lại, tức là loại kẻ xấu có thể đoán trước. Nếu một trong số đó bị chiếm và không ai kiểm, một lệnh npm install là đủ. Ngược lại, kiểm mỗi gói mới trong 2 phút tốn tổng cộng khoảng 104 phút một tháng cho cả nhóm, cỡ 10 phút mỗi người. Chi phí kiểm thấp hơn rất nhiều so với một lần cài nhầm.

Lưu ý: 43% đo trên 500 câu hỏi đã từng ra tên giả, không phải trên mọi câu hỏi, và 5,2% là trung bình theo từng tên gói gợi ý, không theo từng người dùng. Con số của nhóm bạn có thể khác nhiều, hãy xem đây là cách tính, không phải dự báo.

---

4. Chỗ nào trong công việc hằng ngày dễ hở#

Hình dung công trường: người thợ giỏi vẫn có thể lấy nhầm vật tư nếu không ai kiểm kho.

4.1 Minh họa: một buổi sáng với agent#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật. Tên gói trong ví dụ là bịa.

• 10:00. Một dev nhờ agent: "Gộp các tệp CSV trong thư mục này rồi làm sạch cột ngày."
• 10:03. Agent viết code dùng gói csv-tidy-helper-x và chạy lệnh cài. Agent đang ở chế độ tự duyệt nên lệnh chạy luôn.
• 10:04. Tên này chưa từng có trên kho, nhưng tuần trước ai đó đã đăng ký nó. Lệnh cài thành công, script cài đặt chạy.
• 11:30. Dev thấy code chạy ổn, mở PR. Lockfile thêm 14 dòng, không ai đọc.

Việc nên làm: bắt agent dừng ở lệnh cài và hỏi. Dev tra tên gói: ngày tạo là tuần trước, 3 lượt tải, không có kho mã nguồn. Dấu hiệu quá rõ để từ chối. Nếu lệnh cài đã chạy từ trong sandbox, thiệt hại cũng bị giới hạn. Phần 6 liệt kê các lớp bảo vệ này.

Minh họa này không thay cho bằng chứng. Bằng chứng là các nghiên cứu ở phần sau. Ngoài ra, nghiên cứu của Stanford (Perry và cộng sự, 2022) thấy người dùng trợ lý AI viết code kém an toàn hơn nhưng lại tin hơn rằng code của mình an toàn, nên việc không ai nhìn lại lệnh cài là có cơ sở để lo. Xem thêm bài Duyệt code do AI viết và bài Vì sao không nên tin AI tuyệt đối.

---

5. Số liệu từ nghiên cứu và vụ việc#

Đọc cho đúng: cả bảng cho thấy hai điều khác nhau. Có bằng chứng tốt rằng AI bịa tên gói, và rằng tên bịa có thể được đăng ký và có người cài. Chưa có bằng chứng tốt về việc điều này gây thiệt hại thật ở quy mô nào.

---

6. Thói quen áp dụng từ ngày mai#

Hình dung nhà bếp có quy trình nhập hàng: món mới phải có hóa đơn và người ký nhận, không phải ai muốn thì nhét vào kho.

6.1 Tám bước#

1. Khóa phiên bản bằng lockfile và dùng npm ci thay vì npm install trên CI và máy sạch. Theo tài liệu npm, npm ci cài đúng theo lockfile và báo lỗi nếu lockfile lệch với package.json.
2. Kiểm tra gói mới trước khi cài: ngày tạo, số lượt tải, kho mã nguồn có thật và khớp, người duy trì, lịch sử phiên bản. Gói tạo tuần trước mà có tên rất "đúng ý" là dấu hiệu cần dừng.
3. Tắt script cài đặt mặc định bằng --ignore-scripts hoặc ignore-scripts=true trong .npmrc. Chỉ bật cho gói bạn đã tin.
4. Dùng danh sách cho phép hoặc kho gương nội bộ (private registry mirror): chỉ những gói đã được duyệt mới cài được, tên lạ sẽ không tìm thấy.
5. Xem provenance bằng npm audit signatures khi gói có. Nhớ rằng nó cho biết nguồn gốc, không bảo đảm sạch.
6. Bắt người duyệt mọi lệnh cài của agent. Đừng bật chế độ tự duyệt cho lệnh cài hoặc lệnh chạy code lạ.
7. Chạy agent trong sandbox hoặc devcontainer, không đưa khóa thật, token deploy hay quyền ghi lên production vào đó.
8. Đọc khác biệt của lockfile trong mỗi PR: có gói mới nào không, tên gì, từ kho nào. Việc này nằm trong danh sách ở bài Duyệt code do AI viết.

6.2 Bốn lệnh nên nhớ#

# 1. Cài đúng theo lockfile, không chạy script cài đặt
npm ci --ignore-scripts

# 2. Nhìn gói trước khi cài: ngày tạo, người duy trì, kho mã nguồn
npm view some-package time.created time.modified maintainers repository.url
curl -s https://api.npmjs.org/downloads/point/last-week/some-package

# 3. Kiểm tra chữ ký và provenance của những gì đã cài
npm audit signatures

# 4. Sau thay đổi của agent: có dòng resolved mới nào trong lockfile không
git diff package-lock.json | grep '^+.*"resolved"'

Với Python, lệnh tương tự là pip install --require-hashes -r requirements.txt, nhưng cần lockfile có băm (hash) từng gói. Cú pháp các công cụ khác nhau, hãy xem tài liệu công cụ bạn dùng.

6.3 Mười câu hỏi trước khi cài#

1. Tên gói này có trên kho thật không, và tôi tra bằng trang kho hay bằng trí nhớ?
2. Gói tạo từ khi nào? Dưới vài tuần thì nghi ngờ.
3. Lượt tải mỗi tuần là bao nhiêu so với mức gói này đáng có?
4. Có kho mã nguồn công khai khớp với tên gói không?
5. Người duy trì là ai, có lịch sử không?
6. Gói có chạy script lúc cài không?
7. Có gói phổ biến hơn làm cùng việc không?
8. Lệnh cài này là của tôi, hay của agent chưa ai duyệt?
9. Nếu gói độc hại, máy này chứa gì nó có thể lấy?
10. Sau khi cài, lockfile thêm bao nhiêu dòng, và tôi đã đọc chưa?

---

7. Nhìn cân bằng: biết gì, chưa biết gì#

Khá chắc: các mô hình có bịa tên gói, tỷ lệ đo được ở mức vài phần trăm đến hơn hai mươi phần trăm trong thí nghiệm, tên giả có thể lặp lại, tên bịa có thể được đăng ký, và có người thật cài.

Chưa rõ:

• Tỷ lệ bịa của các mô hình và công cụ mới hơn. Nhiều công cụ giờ biết tra cứu trên mạng hoặc kiểm tra tên gói, có thể giảm tỷ lệ. Tôi chưa thấy số đo độc lập cho từng công cụ.
• Mức thiệt hại thực tế. Tôi chưa tìm thấy ghi nhận chắc chắn về một vụ slopsquatting gây thiệt hại lớn, nhưng việc chưa thấy không có nghĩa là chưa từng xảy ra.
• Các thí nghiệm của nhà nghiên cứu đăng ký gói vô hại. Người xấu thật sẽ không báo.

Đừng thổi phồng. Các sự cố lớn hơn trong chuỗi cung ứng, như sâu npm tháng 5/2026, đến từ gói thật bị chiếm. Nếu chỉ phòng slopsquatting thì bạn bỏ sót phần lớn rủi ro. Thói quen ở phần 6 hợp cho cả hai.

Đừng coi nhẹ. Chi phí phòng ngừa thấp (khoảng 10 phút mỗi người mỗi tháng trong ví dụ trên), còn một agent tự cài gói chưa ai xem có thể chạm vào khóa truy cập và mã nguồn. Bài OWASP Top 10 cho ứng dụng dùng AI đặt rủi ro chuỗi cung ứng vào bản đồ rộng hơn. Nếu agent của bạn gọi công cụ qua MCP, hãy đọc thêm MCP là gì, vì mỗi công cụ cũng là một thứ bạn đang cài vào.

---

8. Kết luận#

Một cái tên AI bịa ra tự nó vô hại, cho đến khi có người đăng ký nó và có máy nào đó tự cài. Phần lớn rủi ro nằm ở chỗ "không ai nhìn". Hãy cho lệnh cài một chốt kiểm: khóa phiên bản, tra gói mới, tắt script, bắt agent xin duyệt, và đọc lockfile.

---

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Một số con số được thuật lại khác nhau, và các ghi chú thứ cấp chỉ để tham khảo, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Spracklen và cộng sự, We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025)
• Lasso Security, AI Package Hallucinations và The Register (thí nghiệm huggingface-cli)
• Aikido Security, bài về react-codeshift và các lệnh npx bịa trong tệp skill (2026)
• Nguồn gốc thuật ngữ (thuật lại, chưa tìm thấy bài gốc): Wikipedia, Slopsquatting và Andrew Nesbitt, Slopsquatting meets dependency confusion
• Cloud Security Alliance, Mini Shai-Hulud: npm Worm Targets AI Developer Supply Chain (ghi chú thứ cấp, 17/5/2026)
• npm Docs, Generating provenance statements và lệnh npm ci
• Pearce và cộng sự, Asleep at the Keyboard? (2021) và Perry và cộng sự, Do Users Write More Insecure Code with AI Assistants? (Stanford, 2022)