Đánh giá "cam kết" của các gói npm: Rủi ro an ninh khi Zod có gần 1 tỷ lượt tải nhưng chỉ có một người duy trì

Tấn công chuỗi cung ứng (supply chain attacks) không còn là một mối đe dọa mới lạ. Tuy nhiên, có một mô hình trong dữ liệu mà hiếm khi được chỉ ra trực tiếp: các gói npm được tải xuống nhiều nhất thường lại được bảo trì bởi một người duy nhất.

Lượng tải xuống khổng lồ cộng với một người bảo trì duy nhất có nghĩa là chỉ cần một thông tin xác thực bị đánh cắp là đủ để gây ra một vụ vỡ lỗ ảnh hưởng đến hàng triệu bản dựng (build).

Tại sao tôi xây dựng hệ thống chấm điểm cam kết cho npm

Tôi đã xây dựng Proof of Commitment — một máy chủ MCP cung cấp các tín hiệu tin cậy hành vi cho các tác nhân AI. Luận điểm của tôi là: các tín hiệu hành vi khó bị làm giả hơn nhiều so với các tuyên bố (như file README, số lượng sao, đánh giá_review). Tuần trước, tôi đã tung ra bộ chấm điểm cam kết cho các kho lưu trữ GitHub. Và tuần này là: các gói npm.

Mô hình chấm điểm này xem xét 5 khía cạnh:

• Độ bền vững (Longevity) (25 điểm) — gói package đã tồn tại bao lâu
• Động lượng tải xuống (Download momentum) (25 điểm) — khối lượng gần đây + xu hướng (tăng ổn định/giảm)
• Tính nhất quán khi phát hành (Release consistency) (20 điểm) — số lượng phiên bản + tính mới của lần publish gần nhất
• Chiều sâu đội ngũ bảo trì (Maintainer depth) (15 điểm) — số lượng người bảo trì hiện tại
• Sự hậu thuẫn từ GitHub (GitHub backing) (15 điểm) — nếu liên kết với repo, sẽ lấy điểm cam kết từ GitHub

Không tính số sao. Không đánh giá chất lượng README. Chỉ tập trung vào hành vi theo thời gian.

Dữ liệu thực tế

Dưới đây là trạng thái hiện tại của 9 gói package tạo nên lõi của hầu hết các ứng dụng JS/TS ngày nay:

Package	Score	Age	Weekly downloads	Maintainers	Versions
express	97/100	15.3 năm	87 triệu	5	317
openai	93/100	5.7 năm	111 triệu	17	354
@anthropic-ai/sdk	86/100	3.2 năm	86 triệu	14	148
langchain	84/100	3.1 năm	15 triệu	8	419
@langchain/core	84/100	2.4 năm	24 triệu	13	314
@modelcontextprotocol/sdk	75/100	1.4 năm	208 triệu	6	78
node-fetch	77/100	11.2 năm	889 triệu	5	96
zod	79/100	6.1 năm	974 triệu	1	860
axios	74/100	11.6 năm	672 triệu	1	132

(Điểm số tính đến ngày 5/4/2026. Lượt tải là tổng hàng tuần từ sổ ký npm.)

Vấn đề của Zod và Axios

Hãy nhìn vào con số ấn tượng mà cũng đầy đáng sợ này:

• Zod: 974 triệu lượt tải xuống mỗi tuần. 1 người bảo trì.
• Axios: 672 triệu lượt tải xuống mỗi tuần. 1 người bảo trì.

Hãy suy nghĩ về ý nghĩa của nó. Mọi pipeline CI chạy lệnh npm install và có zod hoặc axios trong cây phụ thuộc đều chỉ cách một cuộc tấn công chuỗi cung ứng ảnh hưởng đến gần một tỷ sự kiện tải xuống mỗi tuần... chỉ bằng một token npm bị xâm phạm.

Đây không phải là suy đoán. Chiến dịch TeamPCP (tháng 3/2026) đã theo đúng mô hình này: đánh cắp token CI → phát hành phiên bản độc hại → đợi lệnh npm install lan truyền. Cuộc tấn công chuỗi cung ứng LiteLLM thành công cũng vì một token duy nhất kiểm soát một gói có hàng triệu phụ thuộc ngược.

Bề mặt tấn công tỷ lệ thuận với số lượng tải xuống. Bề mặt phòng thủ tỷ lệ thuận với số lượng người bảo trì. Cả Zod và Axios đều đang ở mức tỷ lệ tấn công-phòng thủ tối đa.

Lưu ý: Zod có một repo GitHub rất năng động — 860 phiên bản được phát hành trong 6 năm, có commit hàng tuần. Colin Mcdonnell rõ ràng là rất tận tâm. Vấn đề ở đây không phải là chất lượng cá nhân — mà là rủi ro hạ tầng. Một người nghĩa là chỉ cần một email lừa đảo (phishing), một thông tin xác thực bị đánh cắp, hoặc một lần kiệt sức (burnout).

@modelcontextprotocol/sdk: Trẻ nhưng khổng lồ

SDK MCP đạt 75/100 — điểm bị kéo xuống chủ yếu do tuổi đời trẻ (1.4 năm, chỉ đạt 8 điểm độ bền vững so với tối đa 25). Nhưng 208 triệu lượt tải hàng tuần trong 17 tháng là tốc độ chấp nhận extraordinarily phi thường. Việc có 6 người bảo trì là một tín hiệu sức khỏe tốt.

Mối lo ngại ở đây khác nhau: việc chấp nhận nhanh chóng một gói trẻ tạo ra các mục tiêu có giá trị cao cho các cuộc tấn công giả mạo tên gói (typosquatting) và nhầm lẫn phụ thuộc (dependency confusion). Các tên như modelcontextprotocol-sdk, @model-context-protocol/sdk, mcp-sdk — bất kỳ cái nào trong số này đều có thể là một cái bẫy đang chờ một lỗi copy-paste.

Cách sử dụng trong quy trình làm việc của bạn

Thêm máy chủ MCP vào cấu hình AI của bạn (không cần cài đặt):

{
  "mcpServers": {
    "proof-of-commitment": {
      "type": "streamable-http",
      "url": "https://poc-backend.amdal-dev.workers.dev/mcp"
    }
  }
}

Sau đó, hãy yêu cầu AI của bạn:

• "Kiểm tra điểm cam kết cho zod"
• "Chấm điểm các gói này trước khi tôi thêm vào làm phụ thuộc: @ai-sdk/openai, ai, @vercel/ai"
• "Gói nào trong số này có rủi ro chuỗi cung ứng cao nhất: axios, node-fetch, got?"

AI của bạn giờ đây có thể chạy thẩm định hành vi trên bất kỳ gói npm nào trước khi nó chạm vào file package.json của bạn.

Điểm số không bắt được điều gì

Điểm số cao không có nghĩa là gói đó an toàn. Express với 97/100 vẫn từng có các lỗ hổng CVE. Những gì điểm số đo lường là cam kết hành vi — bằng chứng rằng những người thật đã đầu tư thời gian thật trong một khoảng thời gian thật.

Những gì nó không thể đo lường được:

• Liệu người bảo trì có tái sử dụng mật khẩu hay không
• Liệu token CI có được phân quyền đúng cách hay không
• Liệu pipeline phát hành có bắt buộc MFA hay không

Để làm được điều đó, bạn cần các xác thực nguồn gốc (npm provenance, Sigstore) — đó là một lớp riêng biệt. Điểm cam kết cho bạn biết bao nhiêu "cơ hội" được đặt vào cuộc. Thực tiễn bảo mật cho bạn biết liệu "cơ hội" đó có được bảo vệ hay không.

Bối cảnh thị trường bảo mật chuỗi cung ứng

Chiến dịch TeamPCP vào tháng 3/2026 đã nhắm vào các gói thông qua token CI bị đánh cắp và các phiên bản độc hại được chuẩn bị từ trước. Mô hình tấn công: phát hành phiên bản sạch để thiết lập lịch sử → đợi → phát hành phiên bản độc hại. Hành vi này không thể phát hiện được bằng bất kỳ kỳ kiểm tra số lượng tải xuống đơn điểm nào.

Nhưng phân tích xu hướng hành vi có thể bắt được nó: nếu một gói đột nhiên hiển thị một mô hình publish bất thường sau nhiều tháng nhất quán, đó là một tín hiệu. Sự đảo ngược xu hướng tải xuống theo sau một sự kiện publish là một tín hiệu khác.

Đây là phiên bản chấm điểm cam kết mà tôi đang hướng tới: không chỉ là hồ sơ tĩnh, mà là phát hiện bất thường thời gian. Một gói đã có bản phát hành hàng tháng nhất quán trong 4 năm và sau đó đột nhiên xuất bản 3 phiên bản trong một ngày đang không hoạt động bình thường.

---

Tham khảo: GitHub: https://github.com/piiiico/proof-of-commitment Landing: https://getcommit.dev