Nearly all application developers rely heavily on open source code, yet most organizations don’t have a strategy to keep that code secure and well maintained.
What if you could just pay a team of experts to do this for you, like you pay your cloud provider for compute and storage?
Tidelift is partnering with creators and maintainers of a vast array of community-led open source projects to make that possible.
We call it managed open source.
The best solutions are comprehensive solutions, and we’ve reached a major milestone with the Tidelift Subscription now providing assurances for over 1,000 of the most popular community-led open source projects. That means we’re paying the maintainers of each of those projects to ensure their packages meet uniform commercial standards.
Apache Struts, Joda-Time, Vue, Babel, Material-UI, Gulp, Mongoose, Nokogiri, and hundreds of other community-led projects that are pivotal to commercial application development are now part of the Tidelift Subscription.
And there are more on the way—with over 4,000 projects immediately eligible for income across the JavaScript, Python, PHP, Ruby, Java, and .NET ecosystems. (If you’re an open source maintainer, learn about partnering with Tidelift.)
Even more broadly, the Tidelift Subscription monitors over 3.3 million open source packages across 37 different ecosystems.
To make this actionable for your organization—the managed open source part—we’ve launched new software tools that include an overview of security vulnerabilities, licensing issues, and technical concerns across dependencies, at-a-glance metrics that help developers gauge how package updates impact their applications, and recommendations on when to upgrade key frameworks and libraries.
Those capabilities are all powered by Tidelift’s network of participating open source maintainers, who work to resolve security, maintenance, and licensing problems on your behalf, freeing up your developers’ time.
Want to see it in action? Try a free self-serve dependency analysis for one of your applications today, or read on for a detailed walkthrough of how it all comes together.
To do anything useful with your open source dependencies, step one is to know what they are!
When we talk to application development teams, most say "we don't even know what we use." So that's our starting point—this is a problem Tidelift can help with.
The Tidelift Subscription is about application libraries. If you're building an application, at the top you have your code; at the bottom you have an operating system, database, and other services that you run it on. In the middle, you have a big pile of open source libraries and frameworks that ship with your application. These are pulled in from package managers like npm, Maven, or PyPI. This big middle layer has no vendor around it, no support from cloud providers—today, application development teams manage their dependencies on their own.
We understand the open source you use at the level of packages, not at the level of source code. We don't require source code access. Ultimately, for each application you're building, we only need a list of package names and versions.
Here's how your dependency catalog looks in our subscriber dashboard:
We offer a couple of ways to set this up.
When we have an integration with your source hosting platform such as GitHub.com, we can scan for your package manager files and extract the dependency list from them.
When we don't have an integration or you'd prefer not to use it, we have an API allowing you to upload your dependencies yourself. Good places to call this API could be from your CI system, or in a regularly scheduled cron job or equivalent.
We can also help with "boots on the ground" consulting to get this stuff set up, if you need it.
Remember, the benefit is continuous monitoring and regression-avoidance. Once set up, you can rapidly reply to requests like "what are the licenses on all the stuff we use?" You’ll know when you have security vulnerabilities, and you can continuously improve your technical choices.
We have an export capability to generate reports from your new catalog of the open source you use:
Next, let's look at how the Tidelift Subscription will improve your stack of libraries, now that we know (on an always-updated basis) what your stack is!
Tools aren't enough. Using our software tools, we smooth out and automate the connection between your team and the many open source projects you rely on. But if we only did that, the result would be a bunch of new issues filed with open source projects—when most popular projects are already overwhelmed and behind on their to-do lists.
That's why we also partner directly with independent open source maintainers, including providing them with financial compensation for the work they do on behalf of our subscribers. So far, the maintainers of over 1,000 open source projects have partnered with us to participate in our network and resolve issues affecting our subscribers.
So we're automating through tools what teams would ideally do: identify and monitor issues in their dependencies, work with open source project maintainers to resolve them, and then update to improved releases. The automation is effective because we also pay the maintainers to give them the time and incentive to help out. Without paying the maintainers for doing their part, automating this would be futile and even counterproductive.
Let's follow a single issue through the software, starting on the subscriber side and moving to how it shows up for maintainers and how a subscriber would ultimately get the fix.
Suppose you depend on version 1.0.3 of a package C transitively—by way of packages A and B:
A 1.2.1 ⇨ B 2.1.5 ⇨ C 1.0.3
Let's further suppose that C 1.0.3 has a new security vulnerability. We'll show this to our subscribers as follows:
The first hurdle for you, as a subscriber, could be that this is a zero-day and there's no new release of C that fixes the problem. We'll tell you about the vulnerability in that transitive dependency in the Tidelift dashboard, but won't mark it as an actionable update yet.
Now we get to work with our network of maintainers to get a release done that addresses the issue.
Once there's a new C 1.0.4 available, you might still have a problem, if either A or B has version constraints that prevent upgrade to C 1.0.4. This is the dreaded dependency hell. But we're going to show the maintainers of A and B the same security vulnerability we're showing you, and we'll flag this as an issue for them to fix.
In other words, now you need a release of A or B that's compatible with the updated C, and we've asked the maintainers of A and B to make that happen.
When those releases are made, at last we have an actionable update for you to your direct dependencies, and you can apply the fix.
The same scenario plays out with other kinds of problems, too. In addition to vulnerabilities, we flag issues with critical bugs, unmaintained packages, missing or policy-incompliant licensing information, and deprecated packages. We show each issue to the entire chain of involved packages rather than only to our subscribers, and we work with our network of maintainers to get issues resolved.
The end result? You get a set of open source packages that are consistently maintained and vetted to work with each other—so your own team doesn’t waste time hammering together raw open source components, or quality-assuring software they didn’t even write in the first place.
When developers adopt or upgrade a package, most have some "due diligence" steps they go through—for example, looking over the package's GitHub repository to see whether it's seen recent activity.
With our comprehensive database of information about each package, plus the advice of our network of maintainers, we speed this up with at-a-glance information about any package you're using—or considering. In the Tidelift dashboard, developers can search for a package to quickly locate key facts and concerns about it:
Tidelift's maintainer network helps fix issues reactively, but we're also signing maintainers up to proactively maintain their packages with commercial concerns in mind. Four examples are to establish coordinated security policies, set up two-factor authentication, write release notes in a standard format, and follow standard licensing practices.
Typical small open source projects have nowhere to report security vulnerabilities confidentially. This results in zero-days when vulnerabilities are reported via tweet or public GitHub issue, resulting in a frantic global scramble by every organization that uses that software. To bring order to this chaos, we help our maintainers post secure reporting instructions on their project pages, and then walk them through a coordinated disclosure process to ensure there's a fix available at the same time the vulnerability is announced.
Here's the task we ask our maintainers to fill in:
Maintainers in our network write release notes in a standardized format that’s actually digestible by your application development team, and we make it easy to browse them via the Tidelift subscriber dashboard, so you can keep track of what’s changing in the specific packages your application relies on.
In the past, packages have been replaced with malicious code after their maintainers' accounts were hacked. We require all our participating maintainers to set up two-factor authentication on GitHub and package repositories such as npm, to lower this risk.
Our maintainers clean up license data for their own and transitive packages, plus make actual legal commitments to work with you to fix any license violations, and attest Developer Certificate of Origin-style that they are the author of contributions to the project. Because of the legal diligence done by our maintainers, we're able to offer organizations intellectual property indemnification as an option when they subscribe.
In addition to fixing issues in your dependency stack, our tools can help you avoid introducing new ones. We also give you metrics to monitor your overall progress.
Our advice is to block changes to your application which introduce dependencies with serious problems. By default, we'll block builds that add dependencies with security vulnerabilities, or dependencies without licenses. But you can configure your own custom policy as well.
For dependency problems you already have, we give you a few top priority updates to apply right away—so you know where to start.
And we keep track of how many issues you still have outstanding in your stack, so you can get a sense of whether this number is decreasing over time.
If you want a working operating system, you could go buy a bunch of tools to help you build your own operating system image—or you could let Red Hat or Amazon do that and just subscribe to the result.
With the Tidelift Subscription in place you have what you need to deal with all your package managers, across all important dimensions—security, legal, and technical. We're giving you software tools, yes, but also services—including help directly from upstream projects.
Our goal is to "take care of it for you"—to give you ready-to-use, continuously monitored, always cared-for software. Managed open source, rather than open source that needs management.