npm publish-time malware scanning and dual-use metadata for code-obfuscation tools

What happened on 28 July

On 28 July 2026 (UTC), the GitHub Changelog announced publish-time malware scanning for npm: new packages are scanned before they become installable and are then published normally, held for manual review or blocked. Availability typically takes about five minutes, sometimes 15 minutes or more under load or for large packages, and GitHub said this is not a guaranteed service level. The same day npm published a Dual-Use Content Policy (the page says it was last updated on 28 July 2026). It lists penetration-testing tools, security research utilities and code-obfuscation tools as examples of content that automated scanning may mistake for malware. Maintainers declare such content with a contentPolicy field in package.json and a plain-text DISCLOSURE file at the package root explaining the legitimate purpose. The declaration must persist in later versions and does not guarantee publication. Also that day, GitHub said Dependabot malware alerts now import advisories from the OpenSSF malicious-packages repository, covering ecosystems including npm and PyPI.

What it means for developers protecting their own apps

The change touches two kinds of teams. If you publish a JavaScript obfuscator or a protection SDK, or distribute protected code inside npm packages, npm's own policy now says such capabilities can look like malware to scanners. Declaring them also constrains how you publish: the path must enforce two-factor authentication. The changelog and the current policy page differ on trusted publishing (OIDC). The policy page says OIDC may only stage a dual-use package, not publish it directly, so treat the policy page as authoritative. If you only consume npm dependencies to build Electron or Node apps, publish-time scanning is an extra supply-chain gate, but it blocks only what it can detect. Lockfiles, dependency review and build isolation remain your job. Keep the boundaries clear: malware scanning protects whoever installs a package. It does nothing to stop your app logic from being read or copied. Conversely, obfuscated third-party dependencies are harder for you to review yourself.

Checks you can run

First, inventory the npm packages you maintain: do any ship obfuscated code, a protection runtime or other security-relevant capabilities? Compare them against the policy text to decide whether a contentPolicy declaration and DISCLOSURE file apply, remembering that the declaration cannot be removed later. Second, review your release pipeline. Steps that install or smoke-test a package right after publishing need to tolerate a delay of several minutes. For dual-use packages, confirm that the publishing method meets the two-factor requirement, and switch to staged publishing if needed. Third, enable Dependabot malware alerts in repositories that consume npm dependencies, pin lockfiles in builds, and look into any obfuscated code that appears in your dependency tree, confirming where it comes from and whether you need it. Finally, describe your protection measures accurately in your own release notes, and do not present registry scanning as protection for your app.

Your checklist

• Check whether your own npm packages count as dual-use content
• Let release pipelines tolerate scan delays and meet the 2FA rules
• Enable Dependabot malware alerts and review obfuscated dependencies