<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=705633339897683&amp;ev=PageView&amp;noscript=1">

How Tidelift helps maintainers build using secure by design principles

Jeremy Katz
by Jeremy Katz
on May 30, 2024

Don't miss the latest from Tidelift

Tidelift was honored a few weeks ago to join a number of other technology companies in signing and committing to CISA’s Secure By Design pledge. This effort by CISA to catalyze the technology leaders to build security into their projects proactively instead of bolting it on as an aftermarket capability feels like an important moment of change for the industry. 

What’s been particularly interesting about the pledge at Tidelift is that, in addition to thinking about these commitments in the context of our own software development, we also see how many of them equally apply to the open source components that make up the vast majority of the code in modern applications. Luckily, this set of commitments lines up well with things that we have been paying our open source maintainer partners to do for years. Here’s a few ways we work with open source maintainers to help ensure their projects are being built using secure by design principles.

Multi-factor authentication (MFA)

Within one year of signing the pledge, demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer’s products.

Tidelift’s product has had MFA on the source repo and package manager (where available) as a requirement for our maintainer partners since 2017. MFA is a critical risk vector, as evidenced in the coa and rc case, as well as ua-parser. The size of software supply chains mean that any node present in the chain can present this risk. We ensure that MFA is turned on and stays on. While this is increasingly becoming the norm, requiring maintainers to do so without compensating them for the extra work has led some of them to abandoning their software in the past (see our story about how we helped stop the popular minimist JavaScript package from being deleted for one example), which increases consumers’ risk from under or unmaintained open source packages.

Vulnerability disclosure policy

Within one year of signing the pledge, publish a vulnerability disclosure policy (VDP) that authorizes testing by members of the public on products offered by the manufacturer, commits to not recommending or pursuing legal action against anyone engaging in good faith efforts to follow the VDP, provides a clear channel to report vulnerabilities, and allows for public disclosure of vulnerabilities in line with coordinated vulnerability disclosure best practices and international standards.

Every partnered maintainer working with Tidelift is required to have a vulnerability disclosure policy. We monitor and ensure that their vulnerability disclosure process is working, and we also provide a first line of research and response for many of the maintainers we work with to help them sift through some of the noise and false reports that they are getting (which is becoming a more and more pervasive problem for maintainers).

Reducing entire classes of vulnerability

Within one year of signing the pledge, demonstrate actions taken towards enabling a significant measurable reduction in the prevalence of one or more vulnerability classes across the manufacturer’s products.

It is a central feature of Tidelift’s product that our maintainer partners are contracted to acknowledge and respond to security vulnerabilities as they are reported. Maintainers must have a coordinated disclosure policy, respond to any security report, and issue a fixed release—or dispute the research as a false positive, with documentation to back that claim up.

For cross-site scripting (XSS) vulnerabilities, we have examples where our maintainers have performed a post-mortem review of the CVE. As part of this process, the maintainers not only describe how the vulnerability impacts their package but also provide sensible advice to our customers on how to optimize use of the package to avoid these kinds of attacks.

While not explicitly mentioned in the CISA pledge document, remote code execution is another class of software supply chain attacks that can be quite critical to patch. For example, our maintainer partner for jackson-databind, a foundational Maven package, completely re-architected the project to eliminate this entire class of vulnerabilities, which there were many of just a few years prior, and credits the income they receive from Tidelift for being able to take on this extra work. 

What’s next?

While we can’t provide income today for all maintainers to ensure that they follow these best practices and guidelines, we continue to expand the set of packages for which income is available based on usage within our subscriber base. 

If you are an open source maintainer, take a look to see if there is currently income available for your package. 

Or if you work for an organization seeking to ensure that your organization is doing everything possible to follow the Secure by Design framework, sign up for a Tidelift subscription to ensure that the maintainers of the open source software that you use have the income they need to help them meet the Secure by Design requirements in their projects.

New call-to-action