[Bug?]: Poor SCA behavior out of the box

[mcandre]

Self-service

• [ ] I'd be willing to implement a fix

Describe the bug

Yarn's SCA implementation is ornery to use, resulting in an ecosystem that is insecure by default compared to plain NPM.

To reproduce

npm install a package with known CVE's, such as found in the Snyk Vulnerability Database.

Then yarn install the same dependency managed in a yarn.lock file.

Then try yarn audit, which was quietly dropped years ago in some post-v1 update, but dozens of Google results continue to reference.

Then try yarn npm audit, which happily remarks no security vulnerabilities found.

Then try yarn npm audit --all, which likewise reports no security vulnerabilities.

Finally, try yarn npm audit --all --recursive, which is unintuitive, and shouldn't be required when the yarn.lock is in the same directory, the current working directory, as the package.json file that declares the vulnerable dependency.

That's quite a lot for people to remember, so even producing a reliable security report ends up being difficult rather than automatic.

Environment

$ yarn dlx -q envinfo --preset jest

System: OS: macOS 15.0 CPU: (10) arm64 Apple M1 Pro Binaries: Node: 20.17.0 - /private/var/folders/xc/s20l07yj76x8m3h20lmy5jlc0000gn/T/xfs-c0ae5a0b/node Yarn: 4.5.0 - /private/var/folders/xc/s20l07yj76x8m3h20lmy5jlc0000gn/T/xfs-c0ae5a0b/yarn npm: 10.8.2 - ~/.asdf/plugins/nodejs/shims/npm

Additional context

npm correctly targets the nearest package.json file as the source of truth and automatically reporting any vulnerabilities in dependencies written there, whereas yarn often fails to see package.json or yarn.lock right there in the current directory.