Nhóm của bạn muốn phát hành thư viện JavaScript đầu tiên từ pipeline tự động của họ. Ai tạo gói, ai kiểm tra nội dung của nó và khi nào danh tính của pipeline được xác thực? Cả hai thay đổi npm được công bố vào ngày 2 tháng 10 năm 2026 làm cho chuỗi này trở nên quan trọng hơn. Một gói sẵn sàng để được xem xét và một cấu hình tin cậy hợp lệ là hai trạng thái khác nhau.
Gói đầu tiên thêm một bước vào quá trình khởi chạy
Bài viết của chúng tôi ngày 1 tháng 10 về các bước và quyền cho phép xuất bản npm mô tả việc phân chia quyền; bài viết này xem xét các gói mới và chu trình xác nhận tin cậy được công bố vào ngày 2 tháng 10.
Hãy lấy một thư viện giả tưởng, dành riêng cho kịch bản của chúng ta. Kho lưu trữ của nó chứa mã nguồn dành cho các ứng dụng khác. Quy trình xử lý chuẩn bị tệp đóng gói này, nhưng một người nào đó phải có thể xem xét nó trước khi một phiên bản có thể sử dụng được được phân phối. Vấn đề không chỉ là «tự động hóa có thể phát hành không?» mà còn phải biết nó có thể chuẩn bị gì và ai quyết định việc cung cấp nó.
Ngày 2 tháng 10, npm đã thông báo khả năng tạo một gói mới với npm stage publish, từ một phiên cục bộ hoặc một token chi tiết, bao gồm cả một token chỉ giới hạn cho việc chuẩn bị. Phiên bản được gửi sẽ đi vào hàng đợi xem xét và phải được một người duy trì phê duyệt trước khi có thể cài đặt. Cấu hình gói và việc xuất bản đáng tin cậy sau đó có thể được sắp xếp. Thông báo về các gói mới.
Staged publishing là cách xuất bản đang chờ phê duyệt này. Trusted publishing là cơ chế riêng: cho phép một môi trường tự động có danh tính xác định thao tác trên gói. Vì vậy, bạn có thể có tệp đóng gói đang chờ và cấu hình tin cậy chưa được xác thực, hoặc cấu hình tin cậy hợp lệ với tệp đóng gói chưa được phê duyệt. Bài viết xem xét các trạng thái này, thay vì gộp toàn bộ quá trình vào một nút « xuất bản ».
Việc thay đổi trong 48 giờ liên quan đến sự tin tưởng chưa được xác nhận
Thông báo khác vào ngày 2 tháng 10 liên quan đến các cấu hình xuất bản đáng tin cậy chưa được xác thực. Chúng hết hạn 48 giờ sau khi được tạo. Một lần xuất bản thành công đầu tiên sẽ xác thực chúng và loại bỏ chúng khỏi thời hạn này. Thay đổi danh tính của kho mã nguồn hoặc dự án yêu cầu một mối quan hệ tin cậy mới; một thay đổi thông thường không làm bộ đếm trở về không. Các cấu hình đã hết hạn vẫn có thể nhìn thấy và cần được tạo lại để mở một cửa sổ mới. Thông báo npm về thời hạn hết hạn.
Cùng một thông báo nêu rõ việc từ chối các token xuất phát từ các sự kiện GitHub Actions issue_comment, ngoài hạn chế đã được áp dụng đối với pull_request_target. Một trình kích hoạt quy trình làm việc mô tả tình huống trong đó pipeline bắt đầu. Ở đây, một ngữ cảnh bị từ chối không trở nên được cho phép vì tệp đóng gói của nó đã được phê duyệt. Hạn chế bối cảnh xuất bản.
Đừng biến 48 giờ thành tuổi thọ của tất cả bí mật của bạn hay thành thời hạn phổ quát để phê duyệt phát hành một phiên bản. Cửa sổ này liên quan đến một trạng thái cụ thể của cấu hình. Kịch bản chính xác xác nhận sự tin cậy phải được thấy trong quy trình của bạn: chỉ sự hiện diện của một tệp đóng gói đang chờ không đủ để chứng minh nó.
Vẽ lộ trình trước khi khởi chạy tự động hóa
Viết một tờ thông tin với tên gói, người chịu trách nhiệm, kho dự kiến và phiên bản khởi đầu. Thêm thành phần tạo ra tệp lưu trữ, người kiểm tra và người có thể phê duyệt phát hành nó. Một người có thể đảm nhận nhiều vai trò, nhưng những quyết định này phải vẫn có thể nhận dạng được.
Tài liệu npm tham khảo vào ngày 6 tháng 10 mô tả một phiên bản chờ 0.0.0-stage được tạo ra khi một gói chưa tồn tại. Chỗ giữ này là công khai; phiên bản đã gửi và nội dung của nó vẫn đang chờ phê duyệt. Việc chuẩn bị vì vậy có tác động trực quan lên sổ đăng ký trước khi phân phối tệp đóng gói thực tế của bạn. Tài liệu cũng chỉ ra npm CLI 11.15.0 hoặc mới hơn và Node 22.14.0 hoặc mới hơn. Tài liệu xuất bản theo giai đoạn.
Đối với thư viện giả tưởng của chúng tôi, bước kiểm tra đầu tiên là so sánh tệp đóng gói với những gì đáng lẽ phải được giao. Kiểm tra các tệp được bao gồm, các phụ thuộc và các kịch bản có thể chạy khi cài đặt. Thực hiện điều này trong một môi trường cách ly phù hợp với dự án của bạn. Việc một tệp đóng gói đến từ một pipeline đã biết không có nghĩa là nội dung của nó tương ứng với yêu cầu.
Sau đó, hãy ghi chép lại quá trình chuyển đổi giữa chuẩn bị và phê duyệt phát hành. Người phê duyệt phải biết tài liệu lưu trữ nào đã được xem xét và phiên bản nào nó tương ứng. Việc chứng minh đã đọc lại một tệp khác, ngay cả khi có tên gần giống, không phải là bằng chứng cho hiện vật này. Việc theo dõi của bạn có thể sử dụng dấu vân tay của tệp trong các bản ghi riêng tư, mà không làm rối thông điệp gửi đến người dùng.
Theo dõi cả hai chu trình sống
Bảng dưới đây là một phương pháp theo dõi được đề xuất, dựa trên các trạng thái tin cậy đã được công bố. Nó không mô tả một giao diện npm bị bịa đặt.
| Tình trạng niềm tin | Ý nghĩa cần kiểm tra | Hành động của đội |
|---|---|---|
| Chưa được xác nhận | Lần xuất bản đầu tiên thành công vẫn chưa được ghi nhận | Chuẩn bị xác nhận trong cửa sổ dự kiến |
| Đã được xác nhận | Quan sát việc xuất bản đầu tiên thành công | Giám sát danh tính và quyền hạn |
| Hết hạn | Cửa sổ xác nhận đã hoàn tất | Tạo lại mối quan hệ sau khi xem xét lý do |
| Danh tính đã thay đổi | Kho mã nguồn hoặc dự án khác | Xem xét và thiết lập mối quan hệ mới |
Bên cạnh đó, giữ một hồ sơ theo dõi độc lập của lưu trữ: được chuẩn bị, xem xét, phê duyệt rồi phân phối. Sự hết hạn của một sự tin cậy không chứng minh rằng một phiên bản đã bị rút lại. Việc phê duyệt một lưu trữ không chứng minh rằng một quy trình khác được phép. Bằng cách tách riêng những trạng thái này, bạn có thể xác định người chịu trách nhiệm đúng khi một hoạt động thất bại.
Đối với cơ chế nhận dạng, giải thích cho đội ngũ ý nghĩa của OpenID Connect, thường được viết tắt là OIDC: pipeline trình bày một bằng chứng liên quan đến bối cảnh thực thi của nó, thay vì chỉ là một bí mật cố định được sao chép khắp nơi. Quyết định hữu ích vẫn là nhận dạng thực sự được chấp nhận. Một nhãn OIDC trong cấu hình không thay thế cho việc xem xét kho, quy trình làm việc và trình kích hoạt.
Thêm một cảnh báo vận hành phù hợp với việc ra mắt: ai nhận thấy một cấu hình vẫn chưa được xác nhận, ngày tạo được ghi lại ở đâu và ai quyết định tạo lại? Đừng tự động tạo lại các mối quan hệ mà không hiểu lý do tại sao chúng hết hạn. Một khó khăn trong việc phối hợp giữa chuẩn bị, đánh giá và ra mắt nếu không sẽ có thể không được nhìn thấy.
Kiểm tra từ chối với một mô hình cục bộ
Trước bất kỳ hành động nào trên một sổ đăng ký, bạn có thể xây dựng một mô phỏng cục bộ của các trạng thái. Nó nhận một cấu hình giả tưởng, một ngày tạo và một kết quả xuất bản giả tưởng. Nó tính toán xem mối quan hệ chưa được xác thực, đã xác thực hay hết hạn theo mô hình thông báo của bạn. Lịch trình là các mục nhập kiểm tra, không phải là các quan sát về npm.
Chuẩn bị bốn trường hợp: quan hệ không được xác thực trong cửa sổ, quan hệ không được xác thực sau khi hết hạn, quan hệ được xác thực và danh tính bị thay đổi. Đối với mỗi trường hợp, chỉ ra sự chuyển tiếp mong đợi và quyết định mà một người chịu trách nhiệm sẽ phải đưa ra. Mô phỏng này kiểm tra sự hiểu biết và quy trình của bạn; nó không tự đủ để đánh giá hành vi của sổ đăng ký.
Thêm các từ chối liên quan đến lưu trữ: nội dung vắng mặt, phiên bản được xem xét khác với phiên bản đề xuất, thiếu sự phê duyệt. Cũng thêm bối cảnh thực thi bị cấm. Thông điệp nhận được phải chỉ ra chiều nào đang gặp vấn đề, mà không hiển thị bằng chứng nhận dạng hoặc bí mật. Phản hồi thích hợp đối với một tệp đóng gói chưa được xem xét không phải là điều chỉnh độ tin cậy của quy trình.
Đối với một thử nghiệm sau này được phép trên một registry, trước tiên hãy kiểm tra không gian tên, chủ sở hữu và các hiệu ứng tạo công khai. Các lệnh được trích dẫn trong bài này nhằm xác định các cơ chế; không có gói nào được tạo ra và không có lệnh chuẩn bị, xuất bản hay phê duyệt phát hành nào đã được thực hiện để tạo ra nội dung này.
Dự kiến một sự phục hồi dễ hiểu
Nếu cửa sổ hết hạn, hãy bắt đầu bằng dòng thời gian: mối quan hệ được tạo khi nào, sự kiện nào cần xác nhận nó và quan sát nào còn thiếu? Kiểm tra xem liệu quy trình xử lý có thực sự đạt đến bước xuất bản, liệu danh tính của nó có khớp và bối cảnh có được phép không. Việc tái tạo được thực hiện sau khi kiểm tra này, cùng với người chịu trách nhiệm khởi chạy.
Nếu lưu trữ vẫn đang chờ xử lý, hãy kiểm tra phía việc xem xét và phê duyệt. Đừng ép buộc việc xuất bản trực tiếp chỉ để mở khóa lịch trình. Quy trình phải chỉ rõ ai có thể quyết định từ bỏ một phiên bản, chỉnh sửa lưu trữ hoặc tiếp tục chuỗi. Bạn sẽ giữ được tính hữu ích của việc phân chia vai trò.
Đối với gói đầu tiên của bạn, hãy ghi nhớ năm tiêu chí: tệp đóng gói đã được kiểm tra, danh tính được xem xét, việc xác thực thực sự được quan sát, quyền phê duyệt phát hành được cấp và quy trình hết hạn được ghi chép. Bảng này không đo lường bất kỳ lợi ích an ninh tổng thể nào; nó đưa ra các quyết định cụ thể để kiểm tra. Khi thiếu một tiêu chí, hãy hoàn thành việc chuẩn bị tương ứng trước khi mở rộng quy trình sản xuất sang các phiên bản tiếp theo.
Việc triển khai trở nên dễ giải thích hơn khi mọi người biết phân biệt giữa « gói được tạo », « nội dung được phê duyệt » và « niềm tin được xác thực ». Các thông báo ngày 2 tháng 10 thay đổi các phần này, nhưng quy tắc của nhóm bạn vẫn giữ được trình tự. Trước tiên hãy thử đi qua nó với dữ liệu giả và các từ chối dự kiến: sau đó bạn sẽ biết nên thu thập bằng chứng gì trong một thử nghiệm thực sự được phép.
Nguồn và ngày kiểm tra
Nguồn mở ngày 6 tháng 10 năm 2026 : hết hạn của lòng tin, tạo một gói mới trong môi trường kiểm thử và tài liệu npm. Cả hai thông báo đều có từ ngày 2 tháng 10; tài liệu sống cung cấp bối cảnh. Kịch bản và mô phỏng được đề xuất, không có ấn phẩm thực sự hay kết quả được tuyên bố.