<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=420236&amp;fmt=gif">

Are your open source dependencies safe and secure?

We've been talking to engineering leads over the last year to learn to learn how they use open source, and how they vet it to manage risks.

You're using a lot of open source. It's free, but nothing is really free. When you pay for software, you insist on certain assurances: around security practices, licensing, support, and more. There are good reasons you want these—and with open source, for most packages, there's literally no way to obtain them. And there’s a cost to that your team bears every day.

Most software teams are adopting new open source packages every day, with individual developers making the calls informally. Developers need to work this way to get their jobs done—there are too many packages involved in modern development to talk to a committee about every one.

Security risks can get embarrassing quickly. You might have seen the story at Equifax: a developer failed to track the latest version of Struts, lost millions of users' records, and his CEO threw him under the bus in front of Congress. But Internet-facing exploits aren't the only risk; in the recent hack of event-stream, which had been downloaded over 100m times and was used by some of the largest corporations, developer workstations were targeted by a trojan. This can happen with any package you depend on.

Licensing risks are a long shot, but the stakes are high. It's harder to learn from others' failures here because the incidents tend to stay secret… but we know of an entire product which had to be rewritten because it inadvertently used a package with a problematic license… and if your company might be acquired, IP audits are a standard part of acquisition diligence.

 time

“In all cases I want to reduce risk. The whole point of OSS is to accelerate. If I start to lose velocity I’m losing the value of using open source”

 
The everyday risks relate to maintenance. It's a myth that most open source packages are adequately maintained. Most are under-maintained; some see no maintenance whatsoever; and turnover is high. The lack of maintenance resources leads to bugs, obviously, but also to a lack of support for older versions, and a need for tech teams to undertake expensive porting efforts to switch packages or switch major versions. If you submit pull requests to upstream projects, your most likely response will be… crickets.
 
Most companies tell us they don't even know what open source packages they use. Across all the teams and repositories and languages in a large company, how would you even start cataloging your dependencies? That's the first step to track applicable security, licensing, and maintenance risks, but this step alone is a bunch of work. The few companies that have tried to solve this in-house have discovered how hard it is; LinkedIn blogged about their project, which has a whole team working on it.

This is a big problem but it's decidedly non-core. It makes total sense to outsource it, rather than putting a team on it.

Two bad ways to manage open source dependencies

1 Scanning tools make more work for you

You can buy tools to generate long lists of legal and security concerns. We've spoken with hundreds of companies who bought these, and frequently… the list of concerns is just sitting there. Nobody has time to slog through countless false positives and maybe-you-should-investigate-this warnings related to the thousands of open source projects.

A cynic might say these tools are a way for security and legal teams to blame engineering… you knew about the big list of warnings! Why didn't you fix them all?

Of course, even if you worked through all the security and legal warnings, it would do nothing for general maintenance and bug-fixing of the libraries you depend on.

 tools

"Existing tools are helpful for guiding conversations, but don't get to the heart of the problem"

Wiggle-line

"I need to get maximum time for senior engineers on senior things, not babysitting PRs"

2 Bureaucracy fails while making everyone sad

You can adopt a vetting or approval processes for every new package. This fails in two ways:

  • Developers circumvent them, because individually approving thousands of packages isn't realistic and it’s inhumane.
  • Vetting a package at a point in time isn't enough; maintainers disappear constantly, licenses change, and APIs break.

 


What if someone stood behind open source packages?

When you buy software as SaaS or from a vendor, it's the vendor's problem to fix licensing issues, keep the code maintained, and tell you when and how to patch security vulnerabilities.

What if open source worked like that?

  • When someone at your company runs a security or licensing scanner, you could take that long list of warnings and send them to someone else to resolve.
  • When legal asks for a list of packages with their licenses, you could forward that email to someone else to handle.
  • When there's a security vulnerability, someone would tell you about it quickly and give you a new package that's actually practical to upgrade to.
  • When there's a new version, it would come with clear guidance on what's changed, why to upgrade, and whether it's likely to break your code.
  • And most importantly… packages would keep improving all the time, in response to customer feedback.
In short, what if you could have the flexibility of open source with the assurances of vendor-provided code?

Maybe you could move fast and not break things.

It'd be great to choose any open source you need from Maven Central, npm, Rubygems, PyPI, or wherever, and have someone take care of it.

Instead of buying a scanner tool to tell you all the stuff you need to fix in your open source dependencies, what if you could buy… open source dependencies that don't need fixing?

You probably see where this is going. That's the product we've built. 


Let us take care of your dependencies for you

It's called the Tidelift Subscription. Here's how it works, from the perspective of your software team:

  • Keep us informed on what software you're using (we give you simple tools to do this by adding a hook to your CI system).
  • We'll be your dependencies vendor, keeping your libraries in line—any open source packages you choose from the major package repositories.

Please don't buy (or, ugh, build) tools that create more busywork and bureaucracy for your team around open source packages. Instead, for a fraction of one developer's salary, hire Tidelift to do this for you. Outsource this non-core task!

Ready to learn more? 

Overview-1

request a demo

We're paying maintainers to fix problems at the root

How do we do it? We've set up software and business processes to manage all open source packages, at scale, for our subscribers. The two key elements:

  • We support upstream projects directly. We've created a business relationship with the maintainers of the packages you use. Through direct funding, education, and tools we bring upstream projects up to uniform standards our subscribers would like to see, and we can work with maintainers to address new problems that arise.
  • We have a solutions-as-a-service mindset. Our goal isn't to tell you about problems; it's to fix them before you see them. We're about root-cause fixes, not band-aids late in the software lifecycle.

 Here's exactly what happens when you subscribe to Tidelift.

  • We give you the tools to continuously catalog your open source dependencies. You can give your service access to your repositories on GitHub.com, or you can call our APIs from any CI job you already have to upload your dependency manifest files.
  • We go to work ensuring your dependencies have proactive maintenance. For every dependency, if we don't already have a maintainer on the hook, we'll get to work finding someone. We'll always prefer to work with and support upstream projects directly—so they stick around, and you aren't left to maintain those projects yourself.
  • We run scans for security, licensing, and maintenance issues… and then we start knocking the issues out for you. You can look at these if you want. But you don't have to; we'll work on them anyway.

Repositories

  • We'll give you a way to measure your open source dependencies' health. And that measure will improve even if your team spends zero time on it. You can do even better if you use the information we provide to curate what you're using, but we're working for you either way.

shorthand-svgHere's how your job gets easier with the Tidelift Subscription

done_1If you already subscribe to another open source problem-discovery service, send us the complaints it has about your dependencies. We'd be happy to bring you solutions instead of bringing you more problems.

done_1Next time legal asks for a list of packages with their licenses, download them as CSV from your Tidelift Subscription dashboard. We'll actually have correct license information for all of your packages—and if we don't, you can make it our problem.

done_1Next time there's a security vulnerability in one of your dependencies, we'll give you a new package that's actually practical to upgrade to. If it's necessary to fork an old version of the package and backport a fix—we'll maintain that for you.

done_1When there's a new version of a package you use, we'll tell you whether and when to update to it. Maybe it's compatible, maybe it isn't—maybe it fixes something important and maybe it doesn't—we'll give you that guidance.

Managing your open source dependencies can be a solved problem. Your job is to tell us what you use, and our job is to keep it in good shape. We can keep track of thousands of dependencies both better and at lower cost than someone on your team could.

Ready to see how the Tidelift Subscription would look with your codebase?

request a demo