Rủi ro dependency thật sự nằm ở đâu

Bản 2021 gọi hạng mục này là Vulnerable and Outdated Components, và câu trả lời gọn: chạy npm audit, cập nhật, xong. Bản 2025 đổi tên thành Software Supply Chain Failures và lên hạng ba, vì các vụ tấn công thật đã đi qua những cửa mà "cập nhật dependency" không chạm tới.

Bề mặt thật rộng hơn package.json rất nhiều:

Hai hàng giữa là hai hàng đáng chú ý nhất vì chúng chạy với quyền cao hơn code của bạn: một GitHub Action có quyền của workflow, tức là thường có token đọc/ghi repo và secret của môi trường. Một thư viện độc hại trong ứng dụng chỉ có quyền của tiến trình ứng dụng; một action độc hại trong CI có quyền deploy.

Và đây là điều quan trọng nhất của bài: "số CVE" gần như là một chỉ số vô nghĩa.

Một CVE chỉ là rủi ro nếu code của bạn gọi tới đường dẫn có lỗi. Ba yếu tố quyết định, và không yếu tố nào nằm trong điểm CVSS:

1. Có tiếp cận được không? Một lỗ hổng trong hàm parse XML của một thư viện bạn chỉ dùng để format ngày tháng là không tiếp cận được. Đây là reachability, và nó thay đổi mức rủi ro nhiều bậc.
2. Dữ liệu không tin được có tới đó không? Một lỗ hổng cần input do kẻ tấn công điều khiển là vô hại nếu input duy nhất là một file cấu hình bạn viết.
3. Nó chạy ở đâu? Một CVE trong một dependency chỉ dùng lúc build (devDependencies) không tồn tại ở production — nhưng nó tồn tại trong CI, nơi có secret.

Hệ quả thực dụng: một danh sách 200 CVE mà 190 cái không tiếp cận được là một danh sách sẽ bị bỏ qua hoàn toàn — cùng lý do với danh sách grep ở bài orm-escape-hatches. Việc đáng làm không phải giảm số CVE mà là biết cái nào tiếp cận được.