Beefing up Two.js Thanks to Session 3 of Github’s Secure Open Source Fund
Last fall I joined Github and dozens of other maintainers for a month of security workshops, milestones, and learnings preparing our open source libraries for worst-case scenarios.
In 2022 I started trying to increase my revenue through Github Sponsors.1 It is a platform for open source maintainers to receive remuneration for their contributions. It can be a one-time donation or recurring. Since logging sponsorships, it has been a modest. The more support means the more I can focus on Two.js during my workdays. So, when I received an email from Gregg and Kevin from Github last year, I was ecstatic. They were looking for maintainers and contributors for Github’s third session to secure open source: a month’s long series of virtual talks, workshops, and milestones for the cohort of around 100 maintainers to challenge themselves and their projects in service of strengthening open source and its community. I applied and luckily got in. Below you can find my application “interview”, a short video explaining why I want to join. The session kicked off a couple weeks later in September. Having never taken a traditional computer science course, I did not have a lot of expectations. It was challenging, but extremely rewarding. I was often the beginner in the room, but a few times was ahead of the pack. Here are my thoughts on the experience as whole.
What does security have to do with drawing on the web?
Two.js runs entirely in the browser, so I had not historically framed it as high risk software. But during the workshop Licensing and Security Compliance, I learned that your audience can also be an attack surface. Many developers who use Two.js are newer to programming, and security issues often arise not from direct attacks but from misunderstandings between a developer and an API. In reviewing the codebase with automated scanning tools introduced in the session, I revisited Two.js’s SVG interpreter, which renders markup into the DOM using innerHTML so the browser can parse it. It is practical, but it is also a dangerous parsing pattern if misused.2 There has not been an incident to my knowledge, but the possibility itself is instructive. I am not interested in restricting expression simply because misuse is possible. What matters, however, is transparency. If something carries risk, that risk should be visible and documented. This way the developer using the library can decide for themselves and make informed decisions.
You can never be too prepared
Another workshop focused on responding to security incidents, and the takeaway was less about fear and more about preparedness. When expectations are documented and a disclosure process is clear, project maintainers can operate with more ease because responsibility has been framed in advance. Before this session, Two.js did not have a formal security policy. Now it does. There is a SECURITY.md in the repository and on the website outlining how vulnerabilities can be reported and addressed.3 Nothing dramatic prompted it. But preparedness is a tool to use in an emergency and a tool to build trust with your community.
Here is how Two.js grew
Over the month I updated dependencies so the development environment reflects current standards, enabled automated vulnerability and dependency monitoring, formalized publishing workflows so releases are signed and traceable, and updated documentation to make potential attack surfaces explicit in public issues. None of these changes alter how you draw a shape or animate a scene, but they strengthen the scaffolding around the library. Looking at the project through a security lens also made me more aware of how durable early design decisions become. Like law in a democratic society, once a precedent is set, there is very little momentum to change it, and that durability carries responsibility.
Two.js can continue leveling up with your help
The cohort of maintainers in the program was generous and humbling, reinforcing how much modern software depends on open source and how much trust is embedded in that dependency. Two.js is sustained primarily through client work, and sponsorship represents only a small portion of its support. If it were better funded, I would focus on expanding its portability so the API can be used across a variety of environments and contexts; in mobile apps for instance. For now, the most meaningful contribution is participation. If you have thoughts on the new security policy or how risks are documented, I welcome that conversation on Github.4 That month I was reminded that maintaining open source is not primarily about bugs, but about community, trust, and leading by example.
I want to take the final moments of this reflection to thank Github and the dozens of people and partner organizations that make Github’s Secure Open Source Fund possible. I also want to thank the other maintainers and projects. It was so inspiring to see so many projects (many of which I have used in my own projects) and pull the curtain back in their own journeys in the breakout rooms. It was a truly global presence. My last thought on all this: security gets a bad rap. In my experience, security is an unspoken term that slows the velocity of building. I tried to avoid it or at least only engage at towards the end of a project’s lifecycle. The Session opened my eyes to how security can be a mindset. One that does not only protect the work you make, but challenge it to make it better.
—Jono