DEV Community

Cover image for Safe and Secure Consumption of Open Source Libraries
Abhisek Datta
Abhisek Datta

Posted on

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

brew tap safedep/tap
brew install safedep/tap/vet
Enter fullscreen mode Exit fullscreen mode
  • Scan your project source code for vulnerabilities and other risks
vet scan -D /path/to/source
Enter fullscreen mode Exit fullscreen mode

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.

vet Default Scan Result

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
Enter fullscreen mode Exit fullscreen mode

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)'
Enter fullscreen mode Exit fullscreen mode

Find vulnerable dependencies

  • Identify libraries that are unmaintained
vet scan -D /path/to/source --filter 'scorecard.scores.Maintained == 0'
Enter fullscreen mode Exit fullscreen mode

Find unmaintained dependencies

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")'
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode
  • Exporting risky libraries as SARIF report
vet scan -D /path/to/source --filter 'vulns.critical.exists(p, true)' --report-sarif report.sarif
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)