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 tap safedep/tap
brew install safedep/tap/vet
- Scan your project source code for vulnerabilities and other risks
vet scan -D /path/to/source
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
vet scan --lockfiles gradle.lockfile --lockfiles ui/package-lock.json
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
vet scan -D /path/to/source --filter 'vulns.critical.exists(p, true)'
- Identify libraries that are unmaintained
vet scan -D /path/to/source --filter 'scorecard.scores.Maintained == 0'
Scorecard checks are based on OpenSSF Scorecard Project
- Find libraries with a specific license
vet scan -D /path/to/source --filter 'licenses.exists(p, p == "MIT")'
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
vet scan -D /path/to/source --filter 'vulns.critical.exists(p, true)' --report-csv report.csv
- Exporting risky libraries as SARIF report
vet scan -D /path/to/source --filter 'vulns.critical.exists(p, true)' --report-sarif report.sarif
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.
vet scan -D /path/to/source --filter-suite policy.yml --filter-fail
Policy violations will trigger a non-zero exit code in vet
with error such as
scan failed due to error: CEL Filter Suite analyzer raised an event to fail with: failed due to filter suite match on demo-client-java/gradle.lockfile
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.
Top comments (0)