Một dependency "bẩn" và cú ngã của startup 10 tỷ đô

40 phút nhiễm mã độc trong thư viện open-source, hàng terabyte dữ liệu bay màu. Supply chain của bạn có đang an toàn?

40 phút — ngắn hơn một tập Netflix

40 phút. Đủ lâu để nấu nồi phở. Ngắn hơn một tập phim Netflix. Và cũng vừa đủ để một thư viện open-source bị cài mã độc, credential bị hút sạch, rồi từ đó domino vào hệ thống của một startup được định giá 10 tỷ đô la.

Đó không phải kịch bản phim. Đó là chuyện thật vừa xảy ra với Mercor — công ty chuyên cung cấp dữ liệu huấn luyện AI cho các ông lớn như Meta và OpenAI. Câu chuyện này không chỉ là tin bảo mật đọc rồi lướt; nó là case study sống động nhất mình từng thấy về cái giá của việc tin tưởng supply chain một cách mù quáng.

Khoan — chuyện phức tạp hơn "bị hack" nhiều

Nếu bạn chỉ đọc tiêu đề "startup bị data breach", bạn sẽ nghĩ: ừ, lại SQL injection hay phishing gì đó. Nhưng không.

Mercor dùng LiteLLM — một thư viện proxy open-source cực phổ biến, được tải hàng triệu lần mỗi ngày — để giao tiếp với các LLM API. Trong vòng 40 phút, phiên bản LiteLLM trên registry bị cài mã độc dạng credential harvesting — nó âm thầm "hút" mọi thông tin đăng nhập đi qua.

Tưởng tượng thế này: bạn đang nấu phở cho cả nhà hàng, nguyên liệu đặt từ nhà cung cấp quen mỗi ngày. Một hôm, lô nước mắm giao đến bị ai đó pha thêm chất lạ — chỉ trong 40 phút trước khi nhà cung cấp phát hiện và thu hồi. Nhưng 40 phút đó, bạn đã nêm vào mấy chục nồi phở rồi.

Credential bị đánh cắp từ LiteLLM được dùng để truy cập thêm nhiều hệ thống khác, rồi lại thu thêm credential — hiệu ứng domino. Kết quả: một nhóm hacker tuyên bố thu được 4 terabyte dữ liệu từ Mercor, bao gồm hồ sơ ứng viên, thông tin cá nhân, dữ liệu khách hàng, mã nguồn, và API keys.

Đáng chú ý: Mercor xử lý những bí mật thương mại lớn nhất của các công ty AI — bộ dữ liệu huấn luyện tùy chỉnh, quy trình dạy model. Quan trọng đến mức dù Meta đã chi 14,3 tỷ đô cho đối thủ Scale AI, họ vẫn song song làm việc với Mercor. Vậy mà giờ đây, Meta đã tạm dừng hợp đồng vô thời hạn.

Soi lại bếp nhà mình

Trước khi nghĩ "chuyện của startup Mỹ, xa lắm", hãy mở file requirements.txt hay package.json của project đang chạy production và đếm thử: bao nhiêu dependency? Bao nhiêu trong số đó bạn thực sự đọc changelog trước khi update?

Kịch bản 1: Giả sử team bạn 5 người, đang build một hệ thống RAG nội bộ dùng LangChain. Phía dưới LangChain là hàng chục sub-dependency. Một trong những package con đó bị compromise trong vài chục phút. CI/CD của bạn tự động pull latest mỗi lần build. Sáng hôm sau, credential database nội bộ đã nằm ở đâu đó bạn không kiểm soát.

Kịch bản 2: Team bạn self-host LLM qua Ollama, phía trước có một lớp proxy để load balance giữa các model. Proxy chạy bản latest, không pin version. Đúng ngày demo cho sếp, bản latest bị inject mã độc. Không chỉ credential mà cả prompt data — có thể chứa thông tin nhạy cảm của khách hàng — đều bị lộ.

Hai kịch bản này không phải viễn tưởng. Đây chính xác là pattern đã xảy ra với Mercor.

Chiều nay, thử làm ngay 4 việc này

Bạn không cần đợi bị breach mới hành động:

1. Pin version — đừng bao giờ tin latest

# Thay vì
pip install litellm
# Hãy
pip install litellm==1.57.2

Lockfile (poetry.lock, package-lock.json) là bạn thân nhất của bạn. Commit nó vào repo, đừng để trong .gitignore.

2. Audit dependency ngay lập tức

# Python
pip-audit

# Node.js
npm audit

# Đa ngôn ngữ — dùng Trivy (open-source của Aqua Security)
trivy fs --scanners vuln .

3. Bật hash verification

Với pip, dùng --require-hashes trong requirements. Mỗi lần install, pip verify hash của package — nếu ai đó thay đổi nội dung mà giữ nguyên version number, pip chặn ngay.

4. Tách credential ra khỏi code flow

API key không nên đi qua proxy dưới dạng plaintext nếu có thể tránh. Dùng secret manager (HashiCorp Vault, AWS Secrets Manager, hoặc đơn giản là .env + .gitignore) thay vì hardcode trong config.

Cái bẫy mà team nào cũng dễ sa chân

Sai lầm phổ biến nhất mình thấy: "Package này mấy chục ngàn star trên GitHub, chắc an toàn."

Plot twist: LiteLLM cũng là project phổ biến, cộng đồng lớn, maintain tích cực. Vấn đề không nằm ở chất lượng code của project, mà ở supply chain — cái pipeline từ lúc maintainer push code đến lúc bạn pip install. Một mắt xích bị compromise ở registry, ở CI/CD của chính project, hay ở một contributor bị chiếm tài khoản — là đủ.

Giống như bạn có thể tin tưởng đầu bếp nhà hàng 5 sao, nhưng nếu ai đó đánh tráo nguyên liệu trên đường vận chuyển từ chợ về bếp, thì tay nghề đầu bếp không cứu được món ăn.

Bẫy thứ hai: chỉ audit dependency lúc setup project rồi quên luôn. Supply chain attack không nhắm vào version cũ — nó nhắm vào lần update tiếp theo của bạn. Việc audit phải lặp lại, lý tưởng là tích hợp vào CI pipeline.

Bài học từ cú ngã 10 tỷ đô

Câu chuyện Mercor không có nghĩa open-source nguy hiểm. Nói thẳng ra thì: chính nhờ cộng đồng open-source mà mã độc trong LiteLLM bị phát hiện chỉ sau 40 phút. Nếu đây là phần mềm closed-source, có khi vài tháng sau mới biết.

Vấn đề thật sự là cách chúng ta tiêu thụ open-source. Bạn có quyền dùng miễn phí, nhưng trách nhiệm bảo mật thì không ai tặng kèm. Đối với các team đang xây dựng hệ thống AI — đặc biệt những hệ thống xử lý dữ liệu nhạy cảm — supply chain security không phải "nice to have", mà là bắt buộc.

Như mình đã chia sẻ trong các bài về RAG và self-host model trước đây: càng tự chủ hạ tầng, càng phải tự chủ bảo mật. Không có ngoại lệ.

Mỗi dependency bạn thêm vào project là một cánh cửa mở thêm — hãy chắc chắn bạn biết ai đang cầm chìa khóa.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng