Implementing security and licensing policies with Tidelift

 The Tidelift Subscription can help you avoid introducing security and licensing problems into your open source dependencies. We partner with upstream open source project maintainers, asking them to clean up licensing information and verify that vulnerabilities are real. Once we have those details, our subscribers can configure policies to act on the data.

Most subscribers choose to block their pull requests or continuous integration builds when problems are found. In this post I'll give you a tour of how that works.

Scanning your package manifests

Step 1: figure out which dependencies you're using. Tidelift parses package manager files for you (Gemfile, pom.xml, package.json and so forth).

GitHub.com

If you host your code on GitHub.com, it's as simple as installing our GitHub app.

For each commit, we'll then extract your package manager files and run a scan.

Via the API

If you don't use GitHub.com or would rather not install the app, we have an API that allows you to upload package manager files yourself.

Using curl, you'd add something like this to your continuous integration scripts to upload a Gemfile and Gemfile.lock:

  curl -X POST -F "files[]=@Gemfile.lock" -F "files[]=@Gemfile" -H "Authorization: Bearer repository/example-api-key" https://api.tidelift.com/subscriber/team-name/repo-name/manifest/upload

Scan history

Once you're regularly scanning your commits, you'll see a scan history in the Tidelift dashboard, like this:

Identifying issues

For each scan, we identify a list of concerns about your dependencies. Among these are security concerns—"this dependency is vulnerable"—and licensing concerns—"you've disallowed this dependency's license."

Choosing your policy

Your policy defines the issues that will block a pull request or feature branch from being merged.

Block CI builds

Tidelift applies your policy to issues it finds, and you can use this to fail your continuous integration builds.

After submitting your package manifests in the build, a CI script can check on scan status with another curl command that looks like this:

curl -H "Authorization: Bearer repository/example-api-key" https://api.tidelift.com/subscriber/team-name/repo-name/revision/status

This API call returns a JSON object, with a status field indicating "success" or "failure." On failure, the build should fail.

GitHub pull request block

Tidelift's GitHub app can set a status on pull requests based on the same criteria—"did you introduce any issues prohibited by your policy?"

Feature branches are only blocked on regression

Tidelift treats scans of your default branch (master) differently from scans of a feature branch or pull request. Pull requests are only blocked when they introduce new issues compared to master.

Think about a scenario where several developers have a pull request outstanding, when a security vulnerability comes out. Tidelift will find the vulnerability on all the pull requests and also on master. Typically, teams don't want every developer to fix the vulnerability as part of their unrelated pull request; instead, they want to create a new pull request specifically to fix the vulnerability.

Tidelift therefore treats the vulnerability as a blocking issue only for the master scan.

However, if a pull request modifies dependencies and in the process adds a new vulnerability compared to master, Tidelift blocks that pull request.

This creates a ratchet effect—pull requests aren't allowed to make anything worse! 

Keeping it simple

We do some hard work behind the scenes, where maintainers help us curate accurate security and licensing data. 

With that done, Tidelift customers set it and forget it—we'll block only those commits that need to be blocked.