In an earlier post on the Tidelift blog, Donald Fischer described how software alone can’t solve the current challenges of the open source software supply chain, and how a more people-focused approach is needed. In that post he concluded:As organizations, what we shouldn’t do is:
- Inundate maintainers with complaints, false positives, and noise that adds to their stress and takes the joy out of their work.
What we should do is:
- Pay the maintainers to create the capacity for them to address these important challenges and get compensated well for their efforts.
But what does that look like in practice? How does paying maintainers, and creating that capacity, work to address challenges in the open source software supply chain?
At Tidelift, we’ve been paying maintainers for years. Here are just some examples of how Tidelift working directly with the maintainers has helped bring benefits to the software supply chain that spread well beyond just the individual packages they maintain.
How one new library can help secure an entire ecosystem
Regular expression denial of service (ReDoS) is an entire class of vulnerabilities that affects software. By carefully controlling input that is sent to a website or service, an attacker can cause that service to use an excessive amount of computing resources which effectively makes it unresponsive to further requests.
How to ensure things don’t slip through the cracks at scale
There are many guidelines for how to set up your repositories securely to prevent attacks on your software supply chain. Examples include the CIS Software Supply Chain Security Guide (section 1), and OpenSSF Best Practices. But the more repos you manage, the harder it is to make sure you’ve done the right checks on each one, and that each repository’s configuration is up to standard. Any missed configuration presents an opportunity for trouble to slip in.
In late 2021, Jordan created repo-report—a tool that checks that all the GitHub repositories you have access to are configured properly. Just give it a read-only token, and it will show all the repositories you have access to, and note any discrepancies in configuration—for example, if you forgot a branch protection setting, or didn’t properly set up the security policy.
This makes it easy to find outliers, and figure out what settings may need to be changed. Regular runs of this tool can ensure that a maintainer's entire estate remains in a secure configuration.
How maintainers’ input can help improve security guidelines
OpenSSF scorecards is a cross-industry initiative to score packages based on how well they apply certain security best practices. Seth and his fellow maintainers saw recent scores for urllib3, and did some work to improve those scores—recently it became the first Python project to reach a Scorecard score of 9.0 out of 10.
Tracking the scores and improving them for your own project is great. But where working with experienced upstream maintainers can show benefits is how to move beyond that to improve the entire ecosystem.
Seth started tracking the OpenSSF scorecard results for the entire PyPI ecosystem, and tracking trends in the data.
He then used that data and his experience to help make the scores themselves more meaningful, by:
- Working with OpenSSF to tighten up checks for pinned action dependencies
- Helping extend SLSA provenance to the OpenSSF scorecard checks
- Prototyping adding SLSA provenance generation in python build processes
How a few additional checks can secure build pipelines
Having a build process that pulls binary artifacts can be a security risk. If the repository you’re pulling from has been hijacked, or if you’re subject to a man-in-the-middle attack, you could end up running untrusted code, inside your network, in your build pipeline. That’s one of the reasons that OpenSSF scorecards checks for binary artifacts in a repo.
However, many Java build processes rely on prebuilt artifacts. So Rafael built a Maven build extension that allows for verifying all artifacts used in the build process against trusted signatures, ensuring that builds can be done with confidence.
And that’s just some of it…
These are just a few examples of how paying maintainers a consistent income for their important work leads to improvement in the software ecosystem as a whole. When we make maintainers’ lives better, all of us who build software can benefit. If you’d like to hear more about success and challenges of open source maintainership, check out the Tidelift maintainer survey.