As noted in GitHub's post, oapi-codegen was one of the projects taking part in the third GitHub Secure Open Source Fund session.

I'd like to take a moment to reflect on the program, and some learnings I've taken from it.

One of the quotes I shared at the end of the program summed up my time:

Having time dedicated to following best practices has been invaluable☆^{(well, $10k)}

Why did we join the fund?

oapi-codegen is a project that takes an OpenAPI specification and generates Go code for either interacting with that API via an autogenerated client, or generates scaffolding for a number of HTTP servers and web frameworks to reduce the implementation burden, as well as generating types for API request/responses.

Given the project is in a fairly privileged position - interacting with every HTTP request/response on either client or server-side, and likely exposed to sensitive data and credentials - securing the project is very important.

As a code generator, oapi-codegen can generate a fair bit of code for you to commit to your project.

But does everyone review the generated code? Hopefully yes 🫣 But given we can't guarantee it, we want to make sure that nothing dodgy could land in folks' codebases.

Extending the maintainer pool

On top of this, for the last ~2 years, I've been effectively maintaining oapi-codegen on my own. As I've written about a couple of times, maintaining a large project like this is fairly time consuming and difficult, especially if it's only you.

Additionally, oapi-codegen isn't a single project, and other child projects, such as middleware for request/response validation, or conversions between types at runtime, also need maintenance.

The project is sufficiently complex, led by user examples, and has a lot of usage that can make it hard to maintain for $0/month.

Over the last few years I've been very appreciative of a few companies sponsoring the work, but the project requires more hours of work, especially given the many large companies using it, but giving nothing back.

While looking at options for increasing the number of folks who maintain the project, a key area I wanted to focus on was to make sure that the security of the project would not be compromised.

This was, in fact, the key reason I submitted oapi-codegen to the program - I wanted support in making sure that I'd done my due diligence to make sure we were setting the project and its users up for success as we introduced new members to maintain the project.

For instance, adding a new collaborator with Write access onto the repository would, by default, allow the pushing of a Git tag, which would then be a released Go version that automated tools like Renovate would happily start upgrading folks to.

Alternatively, the new collaborator able to approve a PR and merge it onto the main branch would also be treated as a version that's ready to be used, as we recommend pinning to commits off main to get changes before a release.

I love that Go provides a straightforward process for users to get updates, but making sure there was a level of control and protection for our users was important, as I've worked hard to build confidence with our users.

Having dedicated time (and money) to fund the work to focus on security was a very big mentally, as it meant I didn't feel "guilty" for not looking at PRs or Issues raised by users, and instead focussing on security as a dedicated pool of time.

With this in place, we are much more able to take on additional collaborators and maintainers.

Understanding our gaps

Over the years, I've worked in and around supply chain security, and on efforts to ensure the enterprise I worked for has had good security posture.

I would say I have a fairly good understanding of good GitHub permissions models, areas to focus to make sure that bad actors can't leverage lax permissions, and experience with some of the tools to help audit usage.

But the reality of only having one human maintaining the project was at odds with this - enforcing code review of all PRs worked for external contributor PRs, but when I needed to make changes, I didn't have a second reviewer.

Since 2024, I've been working towards the OpenSSF Best Practices "passing" grade badge for oapi-codegen, and working towards following best practices there.

As with many parts of the industry, there's often multitudes contained in a single area, and security is absolutely not the exception to the rule. Naturally there were gaps we had in other areas that we knew we were lacking in, and areas that we didn't know we were lacking in.

During the program, we got a chance to dig into different areas with a mix of talks, workshops and Q&A sessions, looking at areas like threat modelling, fuzzing and how to handle a security advisory (which may then become a CVE).

Having the time to work on the program meant that we could address some of the security gaps, not limited to:

As well as these concrete steps, we have also made less outwardly visible steps, like work towards a threat model for the project.

It's also been nice to have a place to chat, complain and brainstorm with other maintainers who are in a very similar position.

Within the group, there was a good spread of projects' security levels, and everyone was at different points along the spectrum - more secure in some ways, but with gaps in other areas, leaving everyone feeling fairly equal overall.

Although there is the GitHub maintainers community, which I've used in the past to field questions from other maintainers, it's quite a large group, and especially when talking about slightly more sensitive things like security, it's been nice to have a small trusted group.

Can an inactive project be more secure?

This is a slightly tongue-in-cheek comment, but I thought it'd be worth noting that given oapi-codegen has recently received slightly less maintenance it could be argued that we're more secure for it 🤓

With reduced merging of community contributions (while still keeping an eye on security updates) it's meant that we're at least not merging potentially risky code changes.

That's not where we want to be, however, as we want to be both secure and well maintained!

Great teachers

The team at GitHub were great in taking us through the program in a mix of different formats - synchronous and asynchronous Q&A, workshops, presentations - and were all greatly knowledgeable and there was so much to learn.

Working to upskill folks at a range of experience levels and security understanding is a tough job, but they made it seem like it was straightforward!

Thanks again everyone 💜

Looking forward

Now we're able to talk about our time in the program publicly, expect to see some more learnings shared!

If you're interested in hearing about anything in particular, let me know!