Open Source software is the foundation of modern software projects. Any software written today consists of 70-90% of open source code in form of libraries and other components. These open source libraries often comes with security risks and introduce technical debt over time in consumer software projects. These risks include
Vulnerability
Malware
Unmaintained / unpopular projects
License
In this post, we will look at how we can use vet, an open source tool for vetting open source libraries before use by software consumers.
Full Disclosure: I am the creator of vet. You can follow the GitHub project at https://github.com/safedep/vet
TL;DR
Note: Examples in this post are created by using vet to scan https://github.com/safedep/demo-client-java which is a Java app with intentionally older version of libraries
Install vet by following documentation on installation
If you are using homebrew, you can install it easily
brew install safedep/tap/vet
Scan your project source code for vulnerabilities and other risks
The default configuration should scan your package manifest (e.g. package-lock.json, gradle.lockfile, pom.xml) and identify the most risky open source libraries that your software depends on. Upgrading these libraries usually reduce the risk of vulnerabilities.
Instead of scanning entire source directory, you can scan specific package manifests as well. This is useful for monorepo or to avoid noise of vet picking up documentation or test data related sub-modules
Filters
Like most other security tools, vet by default uses an opinionated approach to identifying “risk” which may not be suitable for all consumers. The filters feature of vet allows consumers to identify the risky OSS libraries that they care about.
Identify only libraries that has a critical vulnerability
Identify libraries that are unmaintained
Scorecard checks are based on OpenSSF Scorecard Project
Find libraries with a specific license
For a full list of filtering capabilities, refer to the documentation
Reporting
Mitigation, fixing, response or integration with other tools requires additional information which can be obtained using various supported reporting format.
Common use-cases include
Exporting risky libraries as CSV report
Exporting risky libraries as SARIF report
Policy as Code
The filters can be combined together into YAML document to achieve policy as code capability with vet. It can be used to build a guard rail in CI/CD against introducing risky OSS libraries.
Policy violations will trigger a non-zero exit code in vet with error such as
This is useful for CI integration where the build step is failed based on exit code. Refer to policy as code documentation for more details.
Conclusion
Consuming OSS libraries require security vetting. vet project goal is to make the process of OSS library vetting easy and automated while providing the necessary controls and customization for wider adoption.
vet is a community driven project and welcomes community participation and contribution. Report bugs or ask for new feature using GitHub issue and join us on community Discord.