Bảo Mật NPM Dependencies: Hướng Dẫn Toàn Diện Bảo Vệ Chuỗi Cung Ứng cho Nhà Phát Triển API

TÓM TẮT

Các cuộc tấn công chuỗi cung ứng NPM đã tăng vọt lên hơn 3.000 gói độc hại chỉ riêng trong năm 2024, và vụ xâm nhập Axios tháng 3 năm 2026 đã chứng minh rằng ngay cả các gói nằm trong top 10 cũng không an toàn. Hướng dẫn này bao gồm mọi lớp phòng thủ mà nhà phát triển API cần: thực thi lockfile, chặn script postinstall, xác minh nguồn gốc, công cụ phân tích hành vi và các lựa chọn kiến trúc giúp thu hẹp bề mặt tấn công của bạn.

Giới thiệu

Cuộc tấn công chuỗi cung ứng Axios vào ngày 31 tháng 3 năm 2026 không phải là vụ xâm nhập npm đầu tiên. Và nó cũng sẽ không phải là cuối cùng. Nhưng với 83 triệu lượt tải xuống hàng tuần và một RAT (công cụ truy cập từ xa) đa nền tảng được triển khai thông qua một tài khoản bảo trì bị chiếm quyền kiểm soát, đó là tiếng chuông cảnh tỉnh lớn nhất mà hệ sinh thái JavaScript đã nhận được.

Đây là điều làm cho vụ việc này khác biệt so với lời khuyên thông thường “cập nhật các phần phụ thuộc của bạn”: cuộc tấn công Axios đã vượt qua mọi biện pháp phòng thủ truyền thống. Mã độc không nằm trong chính Axios. Nó được tiêm vào thông qua một phần phụ thuộc ảo đã kích hoạt hook postinstall. Lockfile không giúp ích gì nếu bạn chạy npm install trong thời gian cuộc tấn công diễn ra. Việc ghim phiên bản cũng không giúp ích nếu bạn chưa ghim.

Các nhà phát triển API đặc biệt dễ bị tổn thương. Các script kiểm thử, pipeline CI/CD, máy chủ giả lập và client HTTP của bạn đều kéo từ npm. Một gói bị xâm nhập duy nhất trong chuỗi công cụ của bạn có thể làm rò rỉ khóa API, thông tin đăng nhập cơ sở dữ liệu và token đám mây từ máy phát triển của bạn.

Hướng dẫn này bao gồm bảy lớp bảo vệ, từ vệ sinh lockfile cơ bản đến phân tích hành vi nâng cao.

Lớp 1: thực thi lockfile

Tại sao lockfile quan trọng

Lockfile ghi lại phiên bản chính xác của mọi gói và các phần phụ thuộc bắc cầu tại thời điểm cài đặt. Nếu không có lockfile, npm install sẽ phân giải phiên bản mới nhất phù hợp với phạm vi semver của bạn. Nếu package.json của bạn ghi "axios": "^1.14.0" và một phiên bản 1.14.1 độc hại tồn tại trên registry, bạn sẽ nhận được phiên bản độc hại đó.

Các quy tắc

Luôn commit lockfile của bạn. Dù là package-lock.json (npm), yarn.lock (Yarn), pnpm-lock.yaml (pnpm), hay bun.lock (Bun), nó đều thuộc về hệ thống kiểm soát phiên bản.

Sử dụng chế độ cài đặt đông lạnh (frozen installs) trong CI/CD. Không bao giờ chạy npm install trong các môi trường tự động. Hãy sử dụng lệnh tương đương với lockfile đông lạnh:

# npm
npm ci

# yarn
yarn install --frozen-lockfile

# pnpm
pnpm install --frozen-lockfile

# bun
bun install --frozen-lockfile

npm ci xóa node_modules và cài đặt nghiêm ngặt từ lockfile. Nếu lockfile không khớp với package.json, nó sẽ thất bại. Điều này ngăn chặn những bất ngờ trong quá trình phân giải.

Xem xét các thay đổi lockfile trong pull request. Khi một PR sửa đổi package-lock.json, hãy kiểm tra những gì đã thay đổi. Các phần phụ thuộc mới, tăng phiên bản và thay đổi URL registry đều cần được xem xét kỹ lưỡng. Các công cụ tự động như Socket.dev có thể gắn cờ các thay đổi lockfile đáng ngờ trong các đánh giá PR.

Khoảng trống của lockfile

Lockfile bảo vệ chống lại việc phân giải phiên bản không mong muốn, nhưng chúng không bảo vệ chống lại lần cài đặt đầu tiên. Nếu bạn khởi tạo một dự án hoặc thêm một phần phụ thuộc mới trong thời gian cuộc tấn công diễn ra, phiên bản độc hại sẽ bị khóa lại. Đây là lý do tại sao lockfile là Lớp 1, chứ không phải lớp duy nhất.

Lớp 2: vô hiệu hóa script postinstall

Vector tấn công chính

Cuộc tấn công Axios, cuộc tấn công ua-parser-js, cuộc tấn công event-stream, và hàng chục cuộc tấn công khác đều sử dụng cùng một cơ chế: một script postinstall chạy mã tùy ý trong quá trình npm install. Hook này thực thi trước khi mã ứng dụng của bạn chạy, trước khi bạn xem xét gói, và trước khi bất kỳ công cụ bảo mật thời gian chạy nào có thể can thiệp.

Chặn script trên toàn cầu

Thêm vào .npmrc của bạn:

ignore-scripts=true

Hoặc đặt nó qua CLI:

npm config set ignore-scripts true

Điều này ngăn chặn tất cả các script vòng đời (preinstall, install, postinstall, prepare) chạy trong quá trình cài đặt gói.

Xử lý các gói cần script

Một số gói yêu cầu script postinstall để biên dịch native (như bcrypt, sharp, hoặc sqlite3). Bạn có hai lựa chọn:

Tùy chọn 1: Chạy script chọn lọc sau khi cài đặt

npm ci --ignore-scripts
npm rebuild bcrypt sharp

Tùy chọn 2: Sử dụng danh sách cho phép (npm 10+)

Tạo một tệp .scriptsrc.json chỉ cho phép các gói đáng tin cậy chạy script:

{
  "allowScripts": {
    "bcrypt": true,
    "sharp": true
  }
}

Tùy chọn 3: Sử dụng các binary được biên dịch sẵn

Nhiều gói trước đây cần biên dịch native giờ đây đã cung cấp các binary được biên dịch sẵn. Ví dụ, sharp cung cấp các binary được biên dịch sẵn cho hầu hết các nền tảng, loại bỏ nhu cầu biên dịch postinstall. Kiểm tra các phần phụ thuộc của bạn; bạn có thể cần ít ngoại lệ script hơn bạn nghĩ.

Lưu ý về PackageGate

Vào tháng 1 năm 2026, các nhà nghiên cứu đã tiết lộ sáu lỗ hổng zero-day được gọi là “PackageGate” ảnh hưởng đến npm, pnpm, vlt và Bun. Một phát hiện: các phần phụ thuộc dựa trên Git có thể mang theo các tệp cấu hình cho phép thực thi mã ngay cả khi các script vòng đời bị vô hiệu hóa. Nếu package.json của bạn tham chiếu các URL Git cho các phần phụ thuộc, ignore-scripts một mình là không đủ. Hãy ghim các phần phụ thuộc đó vào các commit hash cụ thể và kiểm tra nội dung kho lưu trữ.

Lớp 3: ghim các phiên bản chính xác

Ngừng sử dụng các phạm vi semver

Hành vi mặc định của npm install --save thêm các gói với tiền tố dấu mũ:

{
  "axios": "^1.14.0"
}

Dấu ^ có nghĩa là “tương thích với 1.14.0,” và sẽ phân giải thành phiên bản 1.x.x mới nhất. Trong cuộc tấn công Axios, điều đó có nghĩa là phân giải thành 1.14.1.

Thay vào đó, hãy ghim các phiên bản chính xác:

{
  "axios": "1.14.0"
}

Cấu hình npm để lưu các phiên bản chính xác theo mặc định:

# .npmrc
save-exact=true
save-prefix=''

Sử dụng ghi đè cho các phần phụ thuộc bắc cầu

Các phần phụ thuộc trực tiếp của bạn có các phần phụ thuộc riêng. Nếu một phần phụ thuộc bắc cầu bị xâm phạm, việc ghim phần phụ thuộc trực tiếp của bạn sẽ không giúp ích gì. Sử dụng overrides để kiểm soát việc phân giải bắc cầu:

{
  "overrides": {
    "axios": "1.14.0",
    "plain-crypto-js": "npm:empty-npm-package@1.0.0"
  }
}

Đối với Yarn:

{
  "resolutions": {
    "axios": "1.14.0"
  }
}

Đối với pnpm:

{
  "pnpm": {
    "overrides": {
      "axios": "1.14.0"
    }
  }
}

Đánh đổi

Việc ghim chính xác có nghĩa là bạn sẽ không nhận được các bản cập nhật vá lỗi tự động. Bạn sẽ cần tự tay nâng cấp phiên bản, điều này tạo ra chi phí bảo trì. Sự đánh đổi này là có chủ đích: bạn chọn các bản cập nhật được kiểm soát thay vì tự động. Đối với các dự án nhạy cảm về bảo mật, sự đánh đổi này là đáng giá.

Lớp 4: xác minh nguồn gốc gói

Nguồn gốc có nghĩa là gì

Xác nhận nguồn gốc npm liên kết một gói đã xuất bản với mã nguồn và môi trường xây dựng của nó bằng cách sử dụng chữ ký Sigstore được ghi vào sổ cái minh bạch công khai. Khi một gói được xuất bản từ pipeline CI/CD với tính năng nguồn gốc được bật, gói đó bao gồm bằng chứng mật mã về:

• Kho lưu trữ nguồn nào đã được dùng để xây dựng nó
• Hệ thống CI/CD nào đã xây dựng nó
• Commit nào đã kích hoạt quá trình xây dựng

Cách kiểm tra nguồn gốc

npm audit signatures

Điều này xác minh rằng các gói đã cài đặt có các xác nhận nguồn gốc hợp lệ. Các gói được xuất bản thủ công từ máy của nhà phát triển sẽ không có nguồn gốc.

Các phiên bản Axios độc hại thiếu liên kết nguồn gốc OIDC và không có các commit GitHub tương ứng. Nếu kiểm tra nguồn gốc tự động là thực hành tiêu chuẩn, cuộc tấn công sẽ ngay lập tức gióng lên hồi chuông cảnh báo.

Bật nguồn gốc cho các gói của riêng bạn

Nếu bạn xuất bản các gói npm, hãy bật nguồn gốc trong CI/CD của bạn:

# Ví dụ GitHub Actions
- uses: actions/setup-node@v4
  with:
    node-version: 20
    registry-url: https://registry.npmjs.org
- run: npm publish --provenance
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Thêm vào .npmrc của bạn:

provenance=true

Hạn chế

Provenance là tùy chọn. Hầu hết các gói npm vẫn chưa có nó. Và provenance chỉ chứng minh nơi gói được xây dựng. Nó không chứng minh mã nguồn an toàn. Một pipeline CI/CD bị xâm nhập vẫn có thể xuất bản một gói độc hại với provenance hợp lệ.

Lớp 5: sử dụng công cụ phân tích hành vi

Ngoài việc quét lỗ hổng

Các công cụ truyền thống như npm audit và Snyk kiểm tra dựa trên cơ sở dữ liệu các lỗ hổng đã biết (CVEs). Chúng phát hiện các vấn đề đã được báo cáo nhưng bỏ sót các cuộc tấn công zero-day. Vụ xâm nhập Axios không có trong bất kỳ cơ sở dữ liệu CVE nào khi nó được xuất bản.

Các công cụ phân tích hành vi kiểm tra những gì các gói thực hiện, chứ không phải những gì đã được báo cáo về chúng.

Socket.dev

Socket phân tích hành vi của gói trong quá trình cài đặt và thời gian chạy. Nó gắn cờ:

• Các yêu cầu mạng trong quá trình cài đặt
• Truy cập hệ thống tệp bên ngoài thư mục gói
• Thực thi lệnh shell
• Thu thập biến môi trường
• Các mẫu mã bị che khuất

Khi tích hợp với GitHub, Socket sẽ bình luận trên các PR khi các phần phụ thuộc mới thể hiện hành vi đáng ngờ. Phần phụ thuộc plain-crypto-js của cuộc tấn công Axios đáng lẽ đã kích hoạt nhiều cảnh báo từ Socket: mã bị che khuất, yêu cầu mạng trong postinstall, và ghi vào hệ thống tệp bên ngoài thư mục gói.

# Cài đặt Socket CLI
npm install -g @socketsecurity/cli

# Quét dự án của bạn
socket scan

Snyk

Snyk cung cấp quản lý lỗ hổng với điểm rủi ro, dữ liệu mức độ trưởng thành khai thác và hướng dẫn khắc phục. Nó mạnh hơn đối với các lỗ hổng đã biết nhưng yếu hơn trong việc phát hiện hành vi zero-day.

# Cài đặt Snyk CLI
npm install -g snyk

# Kiểm thử dự án của bạn
snyk test

Tiếp cận theo lớp

Sử dụng cả hai. Socket phát hiện các bất thường về hành vi mà Snyk bỏ sót. Snyk phát hiện các lỗ hổng đã biết với ngữ cảnh phong phú hơn so với Socket cung cấp. Thêm npm audit làm cơ sở:

# Cơ sở
npm audit

# Phân tích hành vi
socket scan

# Quản lý lỗ hổng
snyk test

Chạy cả ba công cụ này trong CI/CD như các cổng kiểm soát. Bất kỳ phát hiện quan trọng nào cũng phải chặn quá trình xây dựng.

Lớp 6: giảm thiểu bề mặt phụ thuộc của bạn

Câu hỏi sâu sắc hơn

Mọi gói trong thư mục node_modules của bạn đều là một quyết định tin cậy. Cuộc tấn công Axios đã xâm phạm một gói có 83 triệu lượt tải xuống hàng tuần. Một dự án Node.js trung bình có hàng trăm phần phụ thuộc bắc cầu. Mỗi phần phụ thuộc đó là một vector tấn công tiềm năng.

Biện pháp phòng thủ hiệu quả nhất là có ít phần phụ thuộc hơn để bảo vệ.

Kiểm tra cây phụ thuộc của bạn

# Đếm tổng số phần phụ thuộc của bạn
npm ls --all | wc -l

# Kiểm tra các trùng lặp
npm ls --all | sort | uniq -c | sort -rn | head -20

Hãy tự hỏi những câu hỏi này cho mỗi phần phụ thuộc:

• Ngôn ngữ hoặc runtime có cung cấp tính năng này một cách native không? Node.js 18+ bao gồm fetch, crypto, URL, FormData, và nhiều tiện ích trước đây yêu cầu các gói.
• Phần phụ thuộc này có kéo theo hàng chục phần phụ thuộc bắc cầu không? Một gói duy nhất với 50 phần phụ thuộc con sẽ nhân bề mặt tấn công của bạn lên 50 lần.
• Bạn có thể vendor gói này không? Đối với các gói tiện ích nhỏ, việc sao chép mã nguồn vào dự án của bạn sẽ loại bỏ hoàn toàn rủi ro chuỗi cung ứng.

Các lựa chọn thay thế native cho các gói phổ biến

Đặc biệt đối với kiểm thử API

Các quy trình kiểm thử API thường phụ thuộc vào thư viện client HTTP, thư viện khẳng định, trình chạy kiểm thử và máy chủ giả lập. Mỗi phần phụ thuộc là một bề mặt tấn công.

Apidog thay thế toàn bộ stack bằng một nền tảng duy nhất:

• Client HTTP: Tích hợp sẵn, không cần phần phụ thuộc npm
• Khẳng định: Trình xây dựng kiểm thử trực quan với các khẳng định tích hợp sẵn
• Trình chạy kiểm thử: Các kịch bản kiểm thử tự động với tích hợp CI/CD qua Apidog CLI
• Máy chủ giả lập: Giả lập thông minh với phản hồi động, không cần Express hoặc các thư viện giả lập bên thứ ba
• Tài liệu: Tự động tạo từ các đặc tả API của bạn

Việc chuyển quy trình kiểm thử API của bạn vào Apidog giúp loại bỏ hàng chục phần phụ thuộc npm khỏi cơ sở hạ tầng kiểm thử của bạn. Ít phần phụ thuộc hơn có nghĩa là ít quyết định tin cậy hơn và ít vector tấn công hơn.

Dùng thử Apidog miễn phí để hợp nhất stack kiểm thử API của bạn.

Lớp 7: giám sát mạng và thời gian chạy

Chặn các tên miền độc hại đã biết

Sau bất kỳ cuộc tấn công chuỗi cung ứng nào, hãy chặn cơ sở hạ tầng điều khiển và chỉ huy ở cấp độ mạng:

# Thêm vào /etc/hosts
echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts

Đối với môi trường CI/CD, hãy hạn chế quyền truy cập mạng đi ra ngoài đối với các tên miền đã biết là tốt. Hầu hết các quy trình xây dựng chỉ cần quyền truy cập vào npm registry, máy chủ git của bạn và các mục tiêu triển khai của bạn. Mọi thứ khác nên bị chặn theo mặc định.

Sử dụng StepSecurity Harden-Runner cho CI/CD

Harden-Runner của StepSecurity giám sát các workflow GitHub Actions theo thời gian thực. Nó đã phát hiện Axios dropper liên hệ C2 trong vòng 1.1 giây sau khi npm install bắt đầu. Công cụ này cung cấp:

• Giám sát mạng đi ra ngoài cho GitHub Actions
• Theo dõi thực thi quy trình
• Giám sát tính toàn vẹn của tệp
• Cảnh báo tự động về hành vi bất thường

# GitHub Actions
- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # hoặc 'block' cho chế độ nghiêm ngặt

Giám sát quy trình thời gian chạy

Đối với máy phát triển, hãy xem xét các công cụ phát hiện và phản hồi điểm cuối (EDR) gắn cờ các quy trình con đáng ngờ được tạo ra bởi Node.js. RAT của Axios đã tạo ra osascript (macOS), cscript (Windows), và python3 (Linux) từ bên trong quy trình npm install. Các mẫu quy trình con này có thể phát hiện được.

Cấu hình .npmrc được khuyến nghị

Dưới đây là một tệp .npmrc được tăng cường bảo mật kết hợp các lớp ở trên:

# Ghim các phiên bản chính xác
save-exact=true
save-prefix=

# Vô hiệu hóa script vòng đời
ignore-scripts=true

# Bật nguồn gốc cho việc xuất bản
provenance=true

# Sử dụng registry chính thức
registry=https://registry.npmjs.org/

# Yêu cầu 2FA để xuất bản
auth-type=web

# Ngưỡng mức kiểm toán
audit-level=moderate

Commit tệp này vào kho lưu trữ của bạn để mọi thành viên trong nhóm đều sử dụng cùng một cài đặt bảo mật.

Ví dụ về pipeline bảo mật CI/CD

Dưới đây là một workflow GitHub Actions thực thi cả bảy lớp:

name: Secure Build
on: [push, pull_request]

jobs:
  security-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: step-security/harden-runner@v2
        with:
          egress-policy: audit

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      # Lớp 1+2: Lockfile đông lạnh, không script
      - run: npm ci --ignore-scripts

      # Lớp 3: Xác minh không có phiên bản bất ngờ
      - run: npm ls --all > deps.txt

      # Lớp 4: Kiểm tra nguồn gốc
      - run: npm audit signatures

      # Lớp 5: Phân tích hành vi
      - run: npx socket scan

      # Lớp 5: Quét lỗ hổng
      - run: npx snyk test

      # Lớp 1: Kiểm toán cơ bản
      - run: npm audit --audit-level=moderate

      # Chỉ xây dựng lại các phần phụ thuộc native được phép
      - run: npm rebuild sharp bcrypt

Điều gì sẽ đến tiếp theo cho bảo mật npm

Xác nhận nguồn gốc bắt buộc cho các gói phổ biến

npm đang thảo luận về việc yêu cầu xác nhận nguồn gốc cho các gói vượt quá một ngưỡng tải xuống nhất định. Điều này sẽ ngăn chặn việc xuất bản thủ công dựa trên token đã tạo điều kiện cho cuộc tấn công Axios.

Phê duyệt phát hành của hai người

Giống như các giao dịch tài chính yêu cầu ủy quyền kép, các gói có lượt tải xuống cao có thể yêu cầu người bảo trì thứ hai phê duyệt các bản phát hành. Một tài khoản bị xâm nhập duy nhất sẽ không đủ.

Phạm vi quyền thời gian chạy

Deno đã hạn chế những gì script có thể truy cập (mạng, hệ thống tệp, biến môi trường) trừ khi được cấp quyền rõ ràng. Node.js đang khám phá các mô hình quyền tương tự. Khi tính năng này được triển khai, các script postinstall sẽ cần quyền rõ ràng để thực hiện các yêu cầu mạng hoặc truy cập hệ thống tệp.

Sự hội tụ của trình quản lý gói

Mô hình cách ly nghiêm ngặt của pnpm (các gói chỉ có thể truy cập các phần phụ thuộc đã khai báo của chúng) ngăn chặn nhiều cuộc tấn công nhầm lẫn phần phụ thuộc. Khi npm áp dụng sự nghiêm ngặt tương tự, bề mặt tấn công sẽ thu hẹp lại.

Câu hỏi thường gặp

Tấn công chuỗi cung ứng trong npm là gì?

Tấn công chuỗi cung ứng trong npm nhắm mục tiêu vào chuỗi phụ thuộc phần mềm thay vì ứng dụng của bạn trực tiếp. Kẻ tấn công xâm nhập tài khoản người bảo trì gói, tiêm mã độc vào các gói phổ biến hoặc xuất bản các gói typosquat có tên tương tự. Khi bạn cài đặt hoặc cập nhật các phần phụ thuộc, mã độc sẽ thực thi trên máy của bạn hoặc trong pipeline CI/CD của bạn, đánh cắp thông tin đăng nhập, cài đặt backdoor hoặc lấy cắp dữ liệu.

npm audit có đủ để bảo vệ chống lại các cuộc tấn công chuỗi cung ứng không?

Không. npm audit kiểm tra dựa trên cơ sở dữ liệu các lỗ hổng đã biết (CVEs). Các cuộc tấn công zero-day như vụ xâm nhập Axios không có trong bất kỳ cơ sở dữ liệu CVE nào khi chúng xảy ra. Bạn cần các công cụ phân tích hành vi như Socket.dev kiểm tra những gì các gói thực hiện, chứ không phải những gì đã được báo cáo về chúng. Sử dụng npm audit làm cơ sở, chứ không phải biện pháp phòng thủ duy nhất của bạn.

Tôi có nên ngừng sử dụng npm hoàn toàn không?

Không. npm vẫn là hệ sinh thái gói lớn nhất, và hầu hết các gói đều an toàn. Mục tiêu là giảm thiểu rủi ro của bạn thông qua việc ghim phiên bản chính xác, thực thi lockfile, chặn script và giảm thiểu các phần phụ thuộc. Hãy xem xét liệu mỗi phần phụ thuộc có cần thiết không, và sử dụng các lựa chọn thay thế native khi có thể.

Apidog giúp giảm rủi ro chuỗi cung ứng npm như thế nào?

Apidog cung cấp client HTTP tích hợp sẵn, trình chạy kiểm thử, máy chủ giả lập và trình tạo tài liệu cho việc phát triển API. Điều này loại bỏ nhu cầu về các gói npm như Axios, node-fetch, Jest, Express (cho giả lập) và các phần phụ thuộc kiểm thử khác. Ít phần phụ thuộc npm hơn có nghĩa là ít vector tấn công hơn trong quy trình làm việc phát triển API của bạn.

Nguồn gốc gói trong npm là gì?

Nguồn gốc gói sử dụng Sigstore để liên kết mật mã một gói đã xuất bản với kho lưu trữ nguồn và môi trường xây dựng CI/CD của nó. Nó chứng minh nơi và cách một gói được xây dựng. Bạn có thể xác minh nguồn gốc bằng npm audit signatures. Các gói được xuất bản thủ công từ máy của nhà phát triển thiếu nguồn gốc, đây là một dấu hiệu đáng ngờ đối với các gói có lượt tải xuống cao.

Có bao nhiêu gói npm độc hại?

Snyk đã xác định hơn 3.000 gói npm độc hại vào năm 2024. Đến quý 4 năm 2025, Sonatype đã chặn 120.612 cuộc tấn công phần mềm độc hại trong một quý trên npm, PyPI và các registry khác. Con số này đang tăng lên. Hầu hết các gói độc hại là các typosquat có lượt tải xuống thấp, nhưng các vụ xâm nhập lớn như Axios chứng minh rằng các gói phổ biến cũng không miễn nhiễm.

Lỗ hổng PackageGate là gì?

PackageGate là một tập hợp sáu lỗ hổng zero-day được tiết lộ vào tháng 1 năm 2026 ảnh hưởng đến npm, pnpm, vlt và Bun. Một phát hiện cho thấy các phần phụ thuộc dựa trên Git có thể mang theo các tệp cấu hình cho phép thực thi mã ngay cả khi các script vòng đời bị vô hiệu hóa. Điều này có nghĩa là ignore-scripts một mình không đủ nếu các phần phụ thuộc của bạn tham chiếu các kho lưu trữ Git. Hãy ghim các phần phụ thuộc Git vào các commit hash cụ thể.

Những điểm chính cần ghi nhớ

• Thực thi lockfile là nền tảng của bạn, nhưng nó sẽ không bảo vệ chống lại lần cài đặt đầu tiên trong thời gian cuộc tấn công diễn ra
• Vô hiệu hóa script postinstall trên toàn cầu bằng ignore-scripts=true trong .npmrc
• Ghim các phiên bản chính xác với save-exact=true để ngăn chặn những bất ngờ từ phạm vi semver
• Xác minh nguồn gốc gói với npm audit signatures để phát hiện các tải lên thủ công
• Kết hợp Socket.dev (phân tích hành vi) với Snyk (lỗ hổng đã biết) và npm audit (cơ sở)
• Giảm số lượng phần phụ thuộc của bạn bằng cách sử dụng API native của Node.js và các nền tảng tích hợp như Apidog
• Giám sát lưu lượng mạng đi ra của CI/CD với StepSecurity Harden-Runner

Mỗi phần phụ thuộc là một quyết định tin cậy. Bạn càng có ít phần phụ thuộc, bề mặt tấn công của bạn càng nhỏ. Bạn càng áp dụng nhiều lớp xác minh, kẻ tấn công càng khó lọt qua. Hãy xây dựng hệ thống phòng thủ của bạn theo chiều sâu, chứ không phải đơn độc.