lint lockfiles for improved security and trust policies
Lockfiles are used as trusted whitelist of resources manifest to fetch packages from. However, keeping track of the changes introduced to lockfiles is not an easy task as they are designed to be consumed by machines 🤖.
What happens when someone creates a Pull Request and sneaks a malicious resource package that replaces a real library? 😱
Exactly! Lint your lockfiles to ensure they adhere to pre-defined security policies and mitigate this vector of attack.
Why is this important? read: Why npm lockfiles can be a security blindspot for injecting malicious modules
Easily invoked with npx on any project and lint it:
npx lockfile-lint --path yarn.lock --allowed-hosts npm yarn --validate-httpsTo lint the npm-shrinkwrap.json file, add the --type npm flag:
npx lockfile-lint --path npm-shrinkwrap.json --type npm --allowed-hosts npm yarn --validate-httpsIf you get no results, congratulations, the file passes!
If lockfile-lint detects exceptions to the policies it will report them:
Refer to lockfile-lint for more details on the CLI usage.
You can use lockfile-lint as a standalone CLI tool, or as an API library using the following npm packages:
- lockfile-lint - a CLI tool that can be easily integrated as a pre-commit hook or part of a CI/build
- lockfile-lint-api - a library providing a programmatic API
Please be advised of the following security disclaimers that are outside of the control of a lockfile linter:
When you whitelist all hosts from npmjs, yarnpkg, github or other registries you implicitly convey that you trust all the packages originating from these sources. As such, a malicious package can exist in a registry source that you whitelist. Direct dependencies that you should add to a project should be well vetted before adding such as using a tool like npq.
- Secure Nodejs Guidelines section on Lockfile Attack
- pnpm's lockfile injection #4361
- yarn's lockfile injection #4136
lockfile-lint © Liran Tal, Released under the Apache-2.0 License.