Kiểm tra gói npm trước khi cài: npm audit chưa kiểm tra được mọi thứ

Trước khi cài một gói npm vào dự án, hãy đối chiếu tên gói và người có quyền phát hành, xem provenance nếu có, tải đúng tarball để đọc script, rồi tạo lockfile trong bản sao dự án mà không chạy script. Quy trình này giúp bạn phát hiện tên giả, nguồn phát hành đáng ngờ và mã có thể chạy ngay trong lúc cài.

Tài liệu audit của npm mô tả việc gửi thông tin cây phụ thuộc tới registry để tìm lỗ hổng đã biết và nêu rằng lệnh không kiểm tra riêng peerDependencies. Vì thế, một báo cáo không có cảnh báo chưa cho biết script cài đặt hoặc mã của gói mới có đáng tin hay không. Hãy dùng audit sau các bước kiểm tra trước khi cho phép gói chạy mã.

Đối chiếu tên gói và quyền phát hành

Lấy tên gói từ tài liệu chính thức của dự án định sử dụng, gồm cả phần scope trong dạng @to-chuc/ten-goi. Kiểm tra từng ký tự trước khi sao chép lệnh cài: dấu gạch nối, chữ đảo vị trí hoặc một scope khác sẽ dẫn đến một gói khác. Nếu tài liệu của dự án trỏ tới một phiên bản cụ thể, hãy giữ nguyên phiên bản ấy trong các bước tiếp theo.

Dùng npm view TEN_GOI@PHIEN_BAN để đọc metadata trên registry mà chưa cài gói. Xem name, version, repository, maintainers, scripts, dependencies và dist; sau đó chạy npm owner ls TEN_GOI để xem các tài khoản hiện có quyền sửa gói và phát hành phiên bản mới. Đối chiếu những tài khoản này với kênh chính thức của dự án. Danh sách chủ sở hữu hiện tại không chứng minh ai đã phát hành một phiên bản cũ, còn trường repository là thông tin do phía phát hành khai báo.

Nếu tên gói chỉ xuất hiện trong một bài đăng hoặc kết quả tìm kiếm, hãy tìm đường dẫn cài đặt từ website hay kho mã mà dự án công bố. Với gói quen thuộc, một phiên bản mới vẫn cần được xem riêng: kiểm tra metadata của phiên bản này rồi cài theo thẻ latest có thể đưa một tarball khác vào dự án. Khi không xác định được quan hệ giữa tên gói, tài khoản có quyền phát hành và dự án thật, hãy dừng trước bước cài.

Xem provenance theo đúng phiên bản

Trên trang của phiên bản có provenance, hướng dẫn provenance của npm chỉ cách mở dấu xác minh để xem môi trường build, workflow, commit nguồn và bản ghi minh bạch. Hãy đối chiếu repository cùng commit được ghi ở đó với phiên bản bạn định tải. Nếu commit hoặc repository liên kết không còn được tìm thấy, npm hiển thị cảnh báo rằng provenance ấy không còn xác lập được.

Provenance cho biết đường đi từ nguồn và quy trình build tới bản phát hành; nó không đánh giá mã có hành vi độc hại hay không. Một gói không có provenance cũng chưa đủ để kết luận là độc hại, nên quyết định vẫn cần dựa vào danh tính, tarball và cây phụ thuộc. Sau khi đã tải và cài các phụ thuộc trong môi trường cô lập, npm audit signatures có thể kiểm tra chữ ký registry và provenance attestation; lỗi xác minh là lý do để điều tra trước khi sử dụng gói.

Đọc tarball và script trước khi chạy mã

Trong thư mục tạm, chạy npm pack TEN_GOI@PHIEN_BAN --ignore-scripts để lấy tarball của đúng phiên bản. Tên viết hoa ở đây là chỗ cần thay bằng tên và phiên bản thật; cờ --ignore-scripts giữ các script trong package.json không chạy khi thực hiện lệnh. Dùng tar -tzf TEN_TEP.tgz để liệt kê nội dung, rồi tar -xOf TEN_TEP.tgz package/package.json để đọc manifest trực tiếp từ gói đã tải.

Trong mục scripts, chú ý preinstall, install và postinstall, sau đó mở mọi tệp mà các lệnh này gọi tới. Những script đó có thể chạy trong quá trình cài, trước khi ứng dụng import hay gọi API của thư viện. Lệnh tải thêm mã từ mạng, gọi shell, đọc biến môi trường hoặc tìm tệp chứa thông tin đăng nhập cần có lời giải thích phù hợp với chức năng gói. Một script build hợp lệ vẫn cần được đọc; một lệnh ngắn chuyển sang tệp bị làm rối mã hoặc địa chỉ mạng không liên quan là tín hiệu nên dừng.

Đừng thay việc đọc tarball bằng việc chỉ xem README hoặc repository. Tarball là nội dung sẽ được đưa vào dự án, trong khi cây nguồn bạn mở có thể ở commit hoặc nhánh khác. Nếu cần giải nén để xem sâu hơn, dùng thư mục hay container dùng một lần và chỉ đọc tệp, không thực thi chúng. Kiểm tra cả tên và script của các gói phụ thuộc xuất hiện sau đó trong lockfile: đọc gói trực tiếp chưa bao phủ mã của toàn bộ cây.

Tạo lockfile mà không cài vào dự án chính

Trong bản sao sạch của dự án, chạy npm install TEN_GOI@PHIEN_BAN --package-lock-only --ignore-scripts --save-exact. Tài liệu npm install giải thích rằng --package-lock-only chỉ cập nhật lockfile thay vì tải và cài phụ thuộc vào node_modules, --ignore-scripts chặn script trong package.json, còn --save-exact ghi phiên bản chính xác vào package.json. Bản sao cho phép xem thay đổi trước khi đưa ứng viên vào dự án đang làm việc.

So sánh package.json và package-lock.json trước và sau lệnh: phiên bản trực tiếp đã được ghi đúng chưa, những phụ thuộc gián tiếp nào vừa xuất hiện, trường resolved trỏ tới registry hay nguồn nào, và trường integrity có mặt hay không. Lockfile cố định các phiên bản đã giải quyết để lần cài sau dùng lại cùng cây phù hợp; nó không chứng nhận mã trong tarball là an toàn. Nếu có tên lạ hoặc nguồn tải ngoài dự kiến, quay lại kiểm tra danh tính và nội dung của phụ thuộc đó.

Dùng audit rồi thử trong môi trường cô lập

Khi đã có lockfile, chạy npm audit trên bản sao dự án để xem advisory áp dụng cho cây phụ thuộc vừa giải quyết. Đọc tên gói, phiên bản bị ảnh hưởng và đường phụ thuộc trong từng cảnh báo. Đừng dùng npm audit fix làm bước thăm dò ban đầu: lệnh sửa có thể thay đổi các phiên bản đã giải quyết và thực hiện một lượt cài đặt, làm mất trạng thái bạn vừa kiểm tra.

Nếu gói vẫn cần được thử, hãy cài trong môi trường cô lập với --ignore-scripts trước và xem lại các script đã bị chặn. Chỉ cho chạy script thật sự cần thiết sau khi hiểu mã mà nó gọi; môi trường thử không nên chứa khóa truy cập hay dữ liệu dự án thật. Kết quả audit sạch chỉ trả lời câu hỏi về lỗ hổng đã được ghi nhận trong cây phụ thuộc, còn quyết định đưa gói vào dự án phải tính cả danh tính bản phát hành, nội dung tarball và mã sẽ chạy lúc cài.

Đọc thêm:

• Linear hay Jira: công cụ nhanh hơn có thể thua khi quy trình cần kiểm soát
• Gridsight gọi 26 triệu USD: mở thêm công suất mà chưa cần xây lưới mới
• Bản vá PaperCut đầu tiên bị vượt qua: quản trị viên cần cài Release 2