Cập nhật thư viện phần mềm thế nào để vá lỗ hổng mà ít vỡ hệ thống?

Một công ty có website bán hàng viết bằng Next.js. Sáng thứ Hai, kho mã báo một thư viện đang dùng có lỗ hổng mức cao: sửa thì sợ vỡ trang thanh toán, để nguyên thì hở. Đây là tình huống minh họa, không phải ca thật.

Bài này dựa trên tài liệu của GitHub, npm, pnpm, OWASP, semver.org và Vercel, cùng các lần thử của Click Star, đối chiếu đến ngày 04/11/2026. Trang cve.org và NVD dùng JavaScript nên công cụ không đọc được, bài không dùng cả hai trang này.

Kết luận ngắn của Click Star: cập nhật nhỏ, đều, qua kiểm thử và xem thử thường an toàn hơn dồn một lần, nhưng bản vá tự động không thay được kiểm thử.

Điểm chính

• Trong dự án thử của Click Star, 9 thư viện khai báo trực tiếp kéo theo 397 gói (số tự đo).
• Theo GitHub, Dependabot gồm 3 phần: alerts báo lỗ hổng, security updates tạo bản vá, version updates giữ bản mới.
• Lockfile ghi đúng phiên bản đã cài. Theo npm, npm ci báo lỗi khi lockfile lệch package.json.
• Số phiên bản MAJOR.MINOR.PATCH là cam kết của tác giả, không phải bảo đảm. Nên kiểm thử cả bản PATCH.
• npm audit hữu ích nhưng nhiễu: trong lần thử, 1 cảnh báo gốc thành 16 mục, còn --omit=dev báo 0.
• Khung 5 bước của Click Star: nhánh riêng, đọc ghi chú, kiểm thử, xem thử preview, gộp và theo dõi.
• Bản MAJOR cần lịch riêng, và cập nhật quá nhanh cũng có rủi ro chuỗi cung ứng.

Vì sao một website kéo theo hàng trăm thư viện

Thư viện (dependency) là đoạn mã dựng sẵn của bên khác. Mỗi thư viện lại dùng thư viện khác, gọi là phụ thuộc gián tiếp (transitive dependency).

Click Star thử đo ngày 04/11/2026 bằng npm 11.12.1: với 3 thư viện next, react, react-dom, lệnh npm install --package-lock-only ghi 54 gói vào lockfile. Thêm 6 công cụ phát triển như TypeScript, ESLint thì tổng là 397 gói, số này đổi theo ngày giải phiên bản. Đây là 1 dự án thử, không đại diện chung.

Lỗ hổng đã biết đi vào hệ thống thế nào

Theo OWASP Top 10:2025, mục A03 (không ghi ngày, đọc 04/11/2026), thành phần chạy với cùng quyền của ứng dụng, nên lỗi ở 1 thành phần có thể gây hậu quả nghiêm trọng. Vá theo chu kỳ hằng tháng hoặc quý có thể để hệ thống hở không cần thiết trong nhiều ngày đến nhiều tháng trước khi vá.

Theo trang "GitHub Advisory database" (không ghi ngày, đọc 04/11/2026), kho thông báo của GitHub có thông báo lỗ hổng đã xét duyệt (từ nhiều nguồn, trong đó có National Vulnerability Database, NVD), thông báo chưa xét duyệt (đưa tự động từ NVD) và thông báo mã độc.

Dependabot không tạo cảnh báo lỗ hổng từ thông báo chưa xét duyệt. Cảnh báo mã độc là tính năng riêng, chỉ có khi được bật.

Lockfile làm gì và vì sao phải đưa vào kho mã

Lockfile ghi đúng phiên bản của từng gói đã cài, để mọi máy dựng ra cùng một bộ thư viện.

Theo trang package-lock.json của npm (bản 12.2.1, sửa lần cuối 04/10/2025, đọc 04/11/2026), tệp này nên được commit để mọi người, kể cả CI, cài đúng cùng một bộ gói. Theo trang npm ci cùng bản, lệnh này báo lỗi nếu lockfile lệch package.json.

Click Star thử ngày 04/11/2026: thêm tay left-pad vào package.json mà không cập nhật lockfile, npm ci dừng với lỗi "Missing: [email protected] from lock file".

Với pnpm, theo trang "pnpm install" (không ghi ngày, đọc 04/11/2026), --frozen-lockfile mặc định bật trong CI khi đã có lockfile. Lockfile cũng giữ nguyên lỗ hổng: nó không tự nâng phiên bản.

Số phiên bản MAJOR.MINOR.PATCH nói gì

Theo semver.org (Semantic Versioning 2.0.0, không ghi ngày, đọc 04/11/2026), MAJOR tăng khi thay đổi không tương thích ngược, MINOR tăng khi thêm tính năng tương thích ngược, PATCH tăng khi sửa lỗi tương thích ngược.

Trong package.json, theo trang "About semantic versioning" của npm (sửa lần cuối 23/10/2023), ~1.0.4 chỉ nhận bản PATCH, còn ^1.0.4 nhận cả MINOR.

Nhận định của Click Star: SemVer là cam kết của người viết thư viện, không phải bảo đảm, nên cả bản PATCH vẫn cần kiểm thử.

Dependabot: 3 chức năng khác nhau

Theo trang "Dependabot quickstart guide" (không ghi ngày, đọc 04/11/2026), Dependabot của GitHub gồm 3 chức năng, mỗi chức năng bật riêng.

• Alerts báo thư viện bạn dùng có lỗ hổng, theo trang "Dependabot alerts" của GitHub (không ghi ngày, đọc 04/11/2026).
• Security updates mở pull request (PR, đề xuất thay đổi) nâng lên phiên bản tối thiểu đã có bản vá, theo trang "Dependabot security updates".
• Version updates mở PR khi có bản mới dù chưa có lỗ hổng, và cần tệp dependabot.yml.

Tệp .github/dependabot.yml mẫu dưới đây hợp lệ khi đối chiếu với JSON Schema dependabot-2.0 của SchemaStore (cộng đồng duy trì, đọc 04/11/2026). Click Star chưa chạy nó trên kho GitHub thật.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3
    groups:
      patch-only:
        update-types:
          - "patch"

Theo trang "Dependabot options reference" (không ghi ngày, đọc 04/11/2026), cooldown là thời gian chờ sau khi bản mới ra, mặc định 3 ngày cho version updates và không áp cho security updates. Các con số 30, 7, 3 chỉ là ví dụ minh họa, không phải khuyến nghị chung.

Cũng theo trang này, mặc định mỗi phụ thuộc một PR, còn groups gộp vào 1 PR. Mẫu trên chỉ gộp bản PATCH; MINOR và MAJOR vẫn riêng từng gói để biết vỡ do đâu.

Theo trang "Dependabot version updates" của GitHub (không ghi ngày, đọc 04/11/2026), nếu không ai tương tác với PR của Dependabot, GitHub tạm dừng các cập nhật.

npm audit làm gì và vì sao báo cáo hay nhiễu

npm audit gửi danh sách phụ thuộc lên registry và nhận báo cáo lỗ hổng đã biết. Theo trang npm audit của npm (bản 12.2.1, sửa lần cuối 18/03/2026, đọc 04/11/2026), lệnh thoát mã khác 0 nếu thấy lỗ hổng, và --audit-level chỉ đổi ngưỡng gây lỗi, không lọc báo cáo.

Theo trang "About audit reports" của npm (sửa lần cuối 17/04/2024), critical cần xử lý ngay, high càng sớm càng tốt, moderate khi có thời gian, low tùy bạn. Theo trang npm audit ở trên, npm audit fix --force có thể cài cả bản SemVer MAJOR cho thư viện cấp trên cùng.

Lần thử 1 (dự án giả chỉ có lodash ghim đúng 4.17.15, npm 11.12.1, ngày 04/11/2026): npm audit báo mức high với 5 thông báo, thoát mã 1, và đề nghị --force. Khi khai ^4.17.15, npm audit fix nâng lên 4.18.1 không cần --force, rồi báo 0 lỗ hổng.

Lần thử 2, trên dự án 397 gói ở trên: npm audit báo 16 mục mức moderate, nhưng gốc chỉ là 1 thông báo về minimatch. Theo tài liệu npm, gói phụ thuộc vào gói lỗi cũng bị tính là "meta-vulnerability", nên 1 lỗi lan thành cả chuỗi.

Còn npm audit --omit=dev báo 0.

Nhận định của Click Star: hãy đọc báo cáo theo gốc và theo nhóm (chạy thật hay chỉ chạy lúc phát triển), không theo số dòng.

Quy trình cập nhật an toàn: 5 bước

Khung của Click Star, không lấy từ nguồn ngoài.

1. Nhận bản cập nhật trên nhánh riêng. Không sửa thẳng nhánh chính; mỗi PR một nhóm nhỏ để biết vỡ do đâu.
2. Đọc ghi chú phát hành và mức SemVer. Theo trang Dependabot version updates, hãy xem changelog và release notes trong phần tóm tắt của PR.
3. Chạy kiểm thử tự động. Dùng npm ci rồi chạy bộ kiểm thử trên mọi PR, kể cả PR của Dependabot.
4. Xem thử trên preview. Theo trang "Environments" của Vercel (không ghi ngày, đọc 04/11/2026), preview được tạo khi đẩy commit lên nhánh không phải production hoặc mở PR.
5. Gộp, theo dõi và giữ đường lùi. Gộp từng PR nhỏ, theo dõi lỗi sau triển khai, sẵn sàng hoàn tác (revert) đúng PR đó.

Cập nhật MAJOR và thư viện hết người bảo trì

Với bản MAJOR, theo trang "Configuring Dependabot version updates" của GitHub (không ghi ngày, đọc 04/11/2026), mục ignore dùng để chặn cập nhật của 1 thư viện, chờ sửa mã cho thay đổi phá vỡ, mà vẫn nhận bản vá bảo mật cho phiên bản đang dùng.

Nhưng trang "Dependabot options reference" ghi ignore cũng đổi cách Dependabot tạo PR cho security updates. Các trang này chưa khớp hẳn. Theo Click Star, chỉ chặn mức MAJOR qua update-types, để PATCH và MINOR có thể chứa bản vá vẫn tới.

Nhưng nếu bản vá chỉ nằm ở bản MAJOR, chặn MAJOR có thể chặn luôn PR vá, nên hãy kiểm tra PR vá lỗi vẫn xuất hiện. Hoãn cần có lịch, đừng để thành vĩnh viễn.

Thư viện hết bảo trì là rủi ro khác. OWASP nêu việc theo dõi thành phần không còn được bảo trì; nếu không vá được thì cân nhắc chuyển sang giải pháp thay thế.

Rủi ro chuỗi cung ứng: cập nhật quá nhanh cũng nguy

Theo OWASP, lỗi chuỗi cung ứng là sự cố khi dựng, phân phối hoặc cập nhật phần mềm, thường do mã của bên thứ ba bị sửa độc hại. Ví dụ OWASP nêu là Shai-Hulud năm 2025, sâu tự lây lan thành công đầu tiên trên npm, lan đến hơn 500 phiên bản gói trước khi npm chặn.

Click Star chỉ dẫn lại mô tả của OWASP, chưa đọc báo cáo gốc. Theo OWASP NPM Security Cheat Sheet (không ghi ngày, đọc 04/11/2026), nên chờ một thời gian cho bản mới lưu hành và cân nhắc ignore-scripts=true trong .npmrc.

Phần chờ này khớp với cooldown của Dependabot và min-release-age của npm. Nhận định của Click Star: bản vá lỗ hổng nên đến ngay, cập nhật định kỳ có thể chờ vài ngày, nên cần ngoại lệ có chủ đích.

Theo trang "Config" của npm (bản 12.2.1, sửa lần cuối 11/02/2026, đọc 04/11/2026), nếu min-release-age chặn bản vá mà npm audit fix muốn cài, npm giữ bản lỗi, cảnh báo và thoát mã khác 0.

Điều này có nghĩa gì với doanh nghiệp Việt Nam

Với doanh nghiệp thuê ngoài, theo Click Star, câu hỏi quản trị đáng quan tâm hơn: ai nhận cảnh báo, ai duyệt PR hằng tuần, hợp đồng bảo trì có ghi việc cập nhật không, kho mã có thuộc tài khoản của công ty không.

Đánh giá của Click Star. Cập nhật thư viện là bảo trì định kỳ, không phải dự án làm một lần. Cả hai thái cực đều rủi ro: không bao giờ cập nhật, hoặc tự động gộp mọi thứ khi chưa có kiểm thử đủ. Click Star ưu tiên PR nhỏ, gộp sau khi CI xanh và xem thử, còn MAJOR đi theo lịch riêng.

Click Star có dịch vụ thiết kế website và phần mềm theo yêu cầu, nên có lợi ích liên quan.

Việc nên làm: lộ trình 14 ngày

Đây là lộ trình tham khảo của Click Star, không lấy từ nguồn ngoài.

Ngày 1 đến 3: kiểm kê

• Liệt kê các kho mã, xác nhận mỗi kho có lockfile.
• Bật dependency graph và Dependabot alerts, ghi số cảnh báo theo mức.
• Chạy npm audit và npm audit --omit=dev, lưu kết quả làm mốc.

Ngày 4 đến 10: tự động hóa

• Thêm dependabot.yml với lịch hằng tuần, cooldown và groups.
• Chạy npm ci và kiểm thử trên mọi PR, kể cả của Dependabot.
• Bật preview cho PR, lập danh sách luồng phải thử tay.

Ngày 11 đến 14: chốt quy tắc

• Đặt thời hạn xử lý theo từng mức nghiêm trọng, tham khảo cột khuyến nghị của npm.
• Chỉ định người xem PR mỗi tuần và lịch cho cập nhật MAJOR.
• Rà soát hằng tháng các gói bị đánh dấu ngừng dùng (deprecated) hoặc không có bản vá.

Cách đo

Bộ chỉ số tham khảo của Click Star, không lấy từ nguồn ngoài:

• Số cảnh báo Dependabot đang mở, tách theo mức.
• Thời gian từ lúc có cảnh báo đến lúc gộp bản vá.
• Số PR chờ và tuổi của PR cũ nhất.

Những sai lầm thường gặp

1. Không commit lockfile, hoặc dùng npm install thay vì npm ci trong CI.
2. Chạy npm audit fix --force rồi triển khai ngay, dù lệnh có thể cài bản MAJOR.
3. Gộp tự động mọi PR khi chưa có đủ kiểm thử.
4. Để PR của Dependabot tồn đọng đến khi Dependabot tạm dừng.
5. Đọc báo cáo npm audit theo số dòng thay vì theo gốc và nhóm.
6. Ghim cứng mọi phiên bản rồi quên, nên bản vá không bao giờ tới.
7. Dồn nhiều bản MAJOR vào 1 PR lớn, nên vỡ là không biết do gói nào.

Điều chưa biết

Click Star chưa có số đo công khai về mức độ lỗi thời của phần mềm doanh nghiệp Việt Nam, cũng chưa tìm được nguồn đo mức tuân thủ SemVer ngoài thực tế.

Các lần thử chạy bằng npm 11.12.1, trong khi tài liệu đọc là bản 12.2.1, và kết quả npm audit cùng số gói đổi theo ngày. Tệp mẫu dependabot.yml chưa chạy trên kho thật. Click Star cũng chưa kiểm hành vi của ignore với PR bản vá bảo mật.