关于`npm audit signatures`额外安全防护能力的技术问询

HTTPS与package-lock校验和的局限性 #

HTTPS仅能保障你和npm registry之间的传输链路不被篡改，但如果registry本身出现问题——比如官方源的合法包被恶意替换，或者你误配置了第三方恶意源——HTTPS无法识别这类场景下的包篡改。

而package-lock.json里的校验和，只是验证你后续安装的包和首次拉取的包一致。如果首次拉取的就是被篡改的恶意包，校验和只会确保你重复安装的还是同一个恶意包，根本没法判断这个包是不是官方/作者发布的原版。

npm audit signatures 能防范的攻击 #

这个命令通过npm官方公钥验证包的签名，核心是确保你安装的包是经过npm官方认证的合法版本，能覆盖以下场景：

• 官方registry被入侵，攻击者替换了合法包的内容，但拿不到npm的签名私钥，此时签名验证会直接失败
• 误配置了恶意第三方源，对方伪造了同名同版本的包，但无法生成npm认可的签名，会被检测出来
• 部分供应链攻击中，攻击者试图绕过正常发布流程上传篡改包，但通不过npm的签名校验（但如果是作者npm账号被盗，攻击者用合法账号发布的恶意包，npm还是会给它签名，这种情况就需要作者签名来防护）

作者签名的差异 #

npm的签名是registry层面的验证，只确认包是通过合法流程进入registry的，但如果作者的npm账号被盗，攻击者用被盗账号发布恶意包，npm依然会为其签名，npm audit signatures检测不出这类问题。

而如果是作者自行对包签名（比如用GPG），验证的是包确实来自作者本人——就算npm账号被盗，攻击者拿不到作者的签名私钥，发布的恶意包也过不了作者签名的验证。这种签名能防护账号被盗后的恶意发布场景，比registry层面的签名多了一层身份验证。

内容的提问来源于stack exchange，提问作者Johannes Ewald