Protecting your digital infrastructure is hard. Attacks on the supply chain are becoming more frequent, and stakeholders are taking notice. The United States government has pushed for new requirements for cybersecurity in the face of the SolarWinds supply chain attack and other high profile open source software supply chain attacks like Log4Shell. The U.S. Cyber Security Review Board released a report detailing the findings on the fallout from the Log4Shell vulnerability, including this important conclusion:
“[Log4Shell] also called attention to security risks unique to the thinly-resourced, volunteer-based open source community. This community is not adequately resourced to ensure that code is developed pursuant to industry-recognized secure coding practices and audited by experts.”
The technology industry has reacted as well, with multiple companies, foundations, and consortiums rushing to identify best practices and standards that will improve open source software security.
Let’s have a little pop quiz: which of the following is not a real guide or standard aimed at improving software supply chain security?
Trick question: they’re all real.
With all of these emerging sets of open source supply chain security standards getting the vast majority of the media attention, one crucial issue that is often overlooked is, who exactly is going to do the work?
Our recent Tidelift open source maintainer survey found that many open source projects are maintained by volunteers, with only 26% of maintainers earning more than $1000 a year for their work, and 45% earning nothing at all. That means an overwhelming amount of maintainers are earning pizza money or less, and are being burdened with more and more of these standards and policies to meet every day.
As urllib3 maintainer Seth Michael Larson recently wrote on his blog:
“Being a maintainer of an open source project requires running fast just to stay still. Every project requires security responses with fixes, updates to dependencies, and support for new language versions, features, and platforms. When the amount of work demanded from maintainers becomes too much we lose maintainer time to burnout, disinterest, and frustration.”
Organizations shouldn’t have to wade through a sea of alphabet soup trying to get the ROI of having their COTS dependencies covered in SLSA. Maintainers shouldn’t have to be looking at the publications of three separate foundations to find out the next set of unfunded mandates users may ask them to meet.
That’s why Tidelift has constantly worked to cut through the noise and fix this—we partner with (and pay!) maintainers to assess their work against a set of standards that we’ve verified with maintainers as providing real value in improving the security of the supply chain.
Here are some of the examples of the maintainer-verified standards that Tidelift has lifters (that’s what we call our partnered maintainers) apply as part of their development processes.
All open source packages are required to have usage licenses, such as General Public License (GPL), MIT License, Mozilla Public License (MPL) to name a few.
Just as proprietary software licensing, open source components are subject to legal terms and restrictions, based on the type of license being used. In order to control liabilities and legal risk, organizations must make sure they are compliant with license requirements and only use open source components that align with the organization’s legal and compliance standards.
There have been instances when license data is missing, incomplete or inaccurate, making it difficult for organizations to make fully informed decisions on whether or not to use a specific open source component. Tidelift works with open source maintainers to make sure their license information is completely and accurately represented so our customers can make well-informed decisions about the components they use.
Key to the security of your supply chain is knowing you’re not running compromised code. That means developers need to have tight security, which is something Seth Michael Larson has blogged about as well.
Tidelift works with maintainers to certify that they are using two-factor authentication to secure their accounts—both for any source code hosting they use (such as GitHub), and also for the package managers they upload artifacts to (such as NPM or PyPI). Tidelift has paid maintainers to do this for years, and now it is deemed so critical that the package managers themselves are beginning to mandate the adoption of 2FA.
Ensuring one maintainer uses two-factor authentication is only a partial solution to securing a package—the goal is to ensure everyone that has access is following secure practices. This is where it is important to have a trusted release manager to keep code protected from potential threats such as malware or hijacked code.
As part of this standard, Tidelift works with maintainers to verify that all release managers are known and trusted to reduce the risk of problematic code from being pushed. In instances where release manager data is incomplete or unclear, Tidelift works with maintainers to ensure correct and up to date data is made available for their packages.
Nobody wants to scramble to fix a zero-day vulnerability with no warning. End users are best served when there’s a fix in hand and available when the vulnerability is publicly disclosed, and maintainers want to make sure they have the time to provide a proper fix rather than having to rush. Having a public coordinated disclosure plan works to ensure maintainers have time to fix issues properly, and users have fixes when they need them.
Tidelift works with maintainers to ensure that they have a public policy on how their project should be contacted about security issues, and ensure they are handled properly. Tidelift also provides security vulnerability handling services to maintainers of open source projects, providing them the time and space they need to correctly respond to issues.
Vulnerabilities are the classic case for securing your supply chain—you want to know what issues may be present in the software you build on.
But just knowing the vulnerabilities isn’t sufficient. Tidelift works with our partnered maintainers to fix vulnerabilities and ensure the fixes are made available for any currently maintained versions of packages. Maintainers are also asked to provide any mitigation and remediation steps that are needed, so users can clearly choose the action they need to take.
Knowing the provenance of your code is key to having a secure supply chain—you want to be able to, if needed, track every bit of code back to where and when it was introduced. More importantly, the White House Executive Order 14028 requires that any organization wanting to conduct business in partnership with the federal government, maintain “accurate and up-to-date provenance of software code or components”.
Tidelift works with maintainers to ensure there is an accurate record of upstream dependencies. This work also includes ensuring changes to a package are properly recorded— providing an audit trail to help track where code and changes in the code come from. With a record of tracked changes provided by maintainers, organizations have a reference to track updates in their source code.
As noted above, there are more industry standards—standards with more checks for software supply chain security than most people can keep track of, with new ones being created constantly.
It shouldn’t be the job of every organization, or every maintainer, to track the latest developments in security standards. That’s where Tidelift comes in.
Tidelift is constantly evaluating new security standards, in cooperation with our growing community of maintainers, checking both that they are practical for maintainers to comply with, and that they provide real security value versus simply being extra paperwork and security theater. As new standards and checks are validated, Tidelift expands the set of maintainer-validated standards that packages are checked against.
Sounds interesting? Learn more about how Tidelift partners with maintainers to improve the health of the open source software supply chain.