Comment by onion2k
7 hours ago
Isn't one fairly major problem with using lockfiles that there could be packages in the lockfile that aren't used in the application? If I run "npm i package" that doesn't tell you whether or not 'package' is actually used in the app.
For most things that unused dependency is just annoying but if your government has mandated that you use a specific package for something (e.g. cryptography) the lockfile isn't enough to give you confidence that the app is actually doing that. You'll still need to audit the application code.
You’re right that SBOMs cannot be used to attest that a library is correctly used. I’m not sure if that’s a common use-case of SBOMs though. I normally see people wanting SBOMs for security transparency (customer can see if you’re maintaining your dependencies), vulnerability management (customer can know what vulnerabilities lurk in the dependencies) and license compliance (they can know you didn’t use any dependencies with licenses that cause commercial issues).
Related to your point though is that just because a dependency is vulnerable doesn’t mean the software using it is affected too. It might not use the functionality that’s vulnerable. Which means a supplier needs to share their assessment of each dependency vulnerability.