Safe and Secure Consumption of Open Source Libraries

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.

Example Policy

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.