Nguy hiểm ở chỗ một package độc chạy code với toàn quyền của máy cài nó — máy dev có SSH key, token git, biến môi trường; runner CI có secret deploy. Đây là lý do các vụ tấn công chuỗi cung ứng có sức lan rộng hơn nhiều so với lỗ hổng trong chính ứng dụng.
Các đường vào:
- Typosquatting: tên gần giống (crossenv thay cross-env), hoặc lợi dụng khác biệt dấu gạch nối.
- Chiếm tài khoản maintainer rồi phát hành version độc dưới tên package hợp pháp — không có lỗi chính tả nào để phát hiện.
- Dependency confusion: package nội bộ trùng tên với package public; trình cài chọn nhầm bản public có version cao hơn.
- Postinstall script: code chạy ngay lúc install, trước cả khi ai đó đọc source.
Chặn theo lớp:
- Lockfile là bắt buộc và CI cài bằng --frozen-lockfile. Không có lockfile thì một bản patch độc tự động vào build.
- Tắt lifecycle script mặc định. pnpm v10 trở đi không chạy postinstall của dependency trừ khi được khai báo cho phép (onlyBuiltDependencies) — giữ nguyên chế độ này và duyệt từng ngoại lệ.
- Cooldown cho version mới: cấu hình Renovate chờ vài ngày trước khi nâng, phần lớn version độc bị gỡ trong khoảng đó.
- Registry nội bộ / scope riêng cho package nội bộ, cấu hình để không bao giờ rơi ngược về public registry.
- Review kỹ khi thêm dependency mới: số lượng maintainer, tần suất phát hành, số dependency con. Đây là bước con người, không tự động hoá được.
Quan trọng nhất là chấp nhận một thực tế: pnpm audit chỉ biết những lỗ hổng đã được công bố. Package độc mới phát hành không nằm trong cơ sở dữ liệu đó — phòng thủ phải dựa vào việc hạn chế quyền thực thi lúc cài, chứ không phải quét sau khi cài.