<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.



What if you had an all-in-one solution to manage open source packages?

What if you could have the flexibility of open source with the assurances of vendor-provided code? It'd be great to choose any open source you need from Maven Central, npm, Rubygems, PyPI, or wherever, and manage it all in one place. What if you could easily set up continuous tracking of your dependencies, and then have a straightforward list of issues to be aware of—all in one place?

That'd be great, but you'd still have to fix those issues. What if you could also get some proactive assurances that the list of issues will go down in the future—that your dependencies in particular won't have so many security, licensing, and maintenance problems to worry about? You'd have significantly more peace-of-mind around your open source stack.

That's the product we've built.

It's called the Tidelift Subscription. Here's how it works:

  • 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 tell you about issues with that software you need to be aware of.
  • We'll send part of your subscription dollars straight to the upstream maintainers behind your software—paying them to support professional security, licensing, and maintenance assurances.

Ready to learn more?

 

Overview-2

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 for our subscribers to manage all their open source packages, at scale 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. This reduces the number of new issues you encounter.
  • We have comprehensive tools for you to track which packages you use and any issues associated with those packages.

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 show you what you need to address. Our all-in-one tool keeps it simple and shows only the highest-priority problems.
  • We'll give you a way to measure your open source dependencies' health. So you can track the value of working on open source problems and choosing better-maintained packages.

Analysis - from PR

Dependencies export selection

We're offering all the tools you need to get your open source dependencies under control, backed by the maintainers that wrote the code in the first place.

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

request a demo