npm 发布时恶意软件扫描与双重用途元数据

As part of our ongoing supply-chain security work, npm is introducing automatic scanning of packages at publish time . This changelog covers what publishers can expect and a new metadata requirement for dual-use content. Newly published packages will be automatically scanned before they become available for install. Depending on the results, a package may be published as normal, held for manual review, or blocked. This introduces a short delay between publishing and availability, typically around five minutes. It may take longer, up to 15 minutes or more, at peak times or depending on a package’s content and size. These times reflect current typical behavior and may change as scanning evolves; they aren’t a service guarantee. For most publishes, no action is required beyond allowing for this brief delay. If you have automation that assumes a package is installable immediately after publishing, update it to tolerate a short availability delay. While scanning is pending, the npm dist-tag command continues to work. Other operations that depend on the published version, such as npm deprecate and npm unpublish , will not work until the package becomes available. If a package is blocked, the publisher may receive a notification with the option to appeal. Depending on the severity and confidence of a finding, further action may be taken on the associated maintainer account(s), consistent with our existing policies. npm blocks the malware we can detect and we are continuously working to improve detection coverage and reduce scan time. For what is and isn’t permitted on the registry, see the npm Acceptable Use Policies . Some legitimate packages have security-relevant capabilities that can resemble malware to automated scanning (dual-use content). We are introducing a contentPolicy field in package.json for maintainers to declare this content. Maintainers declaring dual-use content must also include a DISCLOSURE file in the package’s root directory, containing only text content. This file is free-form and should describe both the dual-use functionality and its intended legitimate use. Our Trust & Safety team uses it when reviewing dual-use packages. Declaring this metadata may trigger additional automated scanning suited to dual-use content when needed. It does not automatically grant publication, and our Trust & Safety team may review dual-use packages on a case-by-case basis. 2FA-enforced publishing: Packages declaring dual-use content must be published through a method that enforces two-factor authentication (e.g., trusted publishing (OIDC), an interactive session with two-factor authentication, or staged publishing). Staged publishing is 2FA-enforced through its staging and promotion step, so granular access tokens with bypass-2FA may still be used to publish to staging . Publishing a dual-use package directly (unstaged) with a token that bypasses two-factor authentication is not permitted. Persistent declaration: Once a package is published with dual-use metadata, the declaration must persist. New versions cannot remove the contentPolicy field or the DISCLOSURE file; publishes that drop them will be rejected.