Hardening open-source is unnecessarily hard

Please imagine a security engineer who understands some security problem deeply and wants to solve it for the open-source community as a whole.

Maybe they write some code in Java and integrate it into a framework. It works well, but only for one small corner of the OSS ecosystem, so they translate it into Python, PHP, Go, and JavaScript to cover more frameworks.

They have to understand both the problem they’re solving and also know how to carefully craft code in many languages.

That level of work is heroic, but doable.

Late some stormy night, someone reports an actively exploited vulnerability. The maintainer crawls out of bed and starts editing Java code which they test carefully. They release a fix, push it to module repos, and manage its release into frameworks.

They still have to redo that work for the corresponding libraries they maintain in other languages, while maintaining the same level of focus despite the copy-pastey feel of the work and the fact that they don’t work with some of these languages frequently.

Maybe they do this, and the nth fix is as high quality as the first. (Yay!)

After a good night’s sleep, they wake up still exhausted but proud that their efforts have made the world safer and check their news: “Trends suggest next year 30% of new projects will use CoolNewLang” which they’ve yet to learn.

Our heroic engineer might understandably become a tad discouraged.

A security engineering community can’t scale to the whole open-source ecosystem if security engineers need to fit this:

Wanted: Open source security engineer

Must deeply understand a security problem.

Must be able to carefully craft code in these languages:
C++, Go, a JVM language, JavaScript, a .Net language,
PHP, Python, Ruby, Rust … and next year’s new language.

Must be willing to work for free or for tips from people
who mostly don’t know they had the problem you solved.

Must be available on short notice to deal with zero-days
even when doing so displaces paid work.

Maybe our security engineer is also a skilled manager and finds collaborators who share the burden. As the project matures and feature work gives way to maintenance, it becomes harder to sustain contributors’ commitment to episodic work like incident response which is quiet for a long time until suddenly it’s not.

The supply of such people is limited so the open-source community fails to provide wide coverage and long term support for security-engineering solutions to common security problems.

The goal: A self-sustaining community of OSS security engineers

We’re successful when


Many security engineering problems can be separated into

  1. some complex relationship between inputs of varied trustedness and trustworthy outputs that needs to be carefully written and reviewed but which is independent of the language that an application is written in. For example, an HTML sanitizer relates untrusted HTML to trustedworthy HTML. While that relation depends on the particulars of the HTML language, it doesn’t on those of Java or Python or any other language that a sanitizer might be implemented in.
  2. some straightforward but framework-specific plumbing that connects the complex relationships inputs and outputs into the larger system.

To solve p problems for f frameworks, we currently need O(p × f) people with résumés as above.

Solution sketch

Develop common infrastructure to turn this O(p × f) problem into an O(p) + O(f) problem while lowering the bar to each contributor.

With this in place, our heroic security engineer from above needs only develop, test, and maintain one codebase. They may still need to be familiar with many applications languages to properly advise integrators, but not so intimately as to be able to write defensive code, and the cost of supporting the marginal framework is much reduced.

Creating a common language for libraries that run inside anything requires solving many least-common-denominator problems but experimentation suggests this is doable.