Securing Open Source Software

This is a presentation that I gave as part of my class on Humanitarian Free and Open Source Software (HFOSS) about tools and techniques that FOSS maintainers can use to secure their projects.

I began my presentation by talking about Log4J. Log4J's Log4Shell vulnerability is one of the most severe vulnerabilities in recent history. It allowed for people to run code on most servers that included Log4J, a very popular Java library. Most concerning was that figuring out which software used Log4J was immensely difficult. Out of this experience came an increased focus on securing open source libraries.

Research Goals

I wanted to understand the difference between open source and commercial application security, how the application development process can be secured, and how release management can be secured.

FOSS vs the Enterprise

I began by looking at how enterprises do application security, and then comparing that to a FOSS project. There were a couple of major differences that I noticed:

• FOSS projects rely extensively on external contributors, meaning that the barrier to contribution has to be low
• FOSS projects do not have the internal resources to have a dedicated application security team
• FOSS projects do not have as much control over deployment
• FOSS contributors are not paid

The biggest difference comes down to money. Good security is expensive, and the contribution dynamics of unpaid contributors is very different from paid contributors. There is a reason why many high profile FOSS projects, like the Dotnet framework, rely so heavily on paid, internal contributions.

Fundamentally, FOSS maintainers have less control over their contributors than enterprises. They have to keep the barrier to contribution low, and while enterprises can fire noncompliant employees (making compliance a very self-interested behavior), FOSS projects cannot.

Application Development

Ideally, you want to secure software as early in the process as possible. This means that you want secure designs and implementations, but both can be hard to validate. Security baselines, like the OWASP Top 10 can narrow what developers have to think about as they write code, and can help alleviate the most common issues without significant security training.

Intentional dependency choices are also important. While dependencies are a very effective way to make development easier, it also expands the trust boundary for an application. There have been historic cases of small library developers using their position in codebases to disrupt the products that use them, so there is always risk, even with small things. Tools like Trusty and OpenSSF Scorecards can help developers decide if a dependency is reasonably secure to include.

I then talked about static and dynamic application testing, which can help validate codebases for strong development practices. These can produce a lot of false positives, but may also help identify many security issues without requiring as much proactive security testing.

Release Management

I then talked about release management. Release management is essential for open source libraries, so that downstream developers can have confidence that the library they received is the one they intended. There have been cases in the past where malicious actors attacked the release system to insert backdoors into PHP.

SLSA is an immensely helpful framework for building secure release mangement systems. Dependabot can help maintainers get updates on vulnerable dependencies, and fix them in one click. The OpenSSF Scorecard provides deep insights into how well best practices are followed. Sigstore allows libraries to sign their code, enabling downstream maintainers to validate that the libraries recevied are authentic.

Next Steps

My next steps are to look at how AI will change this, to see if there are any open source alternatives to some of the software mentioned (like Dependabot) and see if there are any ways for maintainers to easily achieve more security in the design stage of the application.