https://www.jvt.me/posts/2026/02/17/oapi-codegen-github-secure/ Jamie Tanna | Software Engineer * /now * Blog * Popular Posts * Archives * Search * Salary History * Open Source Projects I Maintain * Support Me * Hire Me (CV/Resume) Written by Jamie Tanna on February 17, 2026 CC-BY-NC-SA-4.0 Apache-2.0 6 mins Lessons learned from oapi-codegen's time in the GitHub Secure Open Source Fund Featured image for sharing metadata for articleTable of Contents * + Why did we join the fund? o Extending the maintainer pool + Understanding our gaps + Access to more of a community + Can an inactive project be more secure? + Great teachers + Looking forward 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: * Setting up a security policy for the organisation + Including explicitly documenting which versions are supported, how to report a security issue, and how we treat vulnerabilities that aren't exploitable * Tightening branch protection rules and/or migrating to Repository Rulesets * Setting up govulncheck with GitHub Code Scanning alerts * Setting up collection of OpenSSF Security Scorecard reports data * Enforcing GitHub Advanced Security checks As well as these concrete steps, we have also made less outwardly visible steps, like work towards a threat model for the project. Access to more of a community 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! This post's permalink is https://www.jvt.me/posts/2026/02/17/ oapi-codegen-github-secure/ and has the following summary: . Sharing some thoughts about the GitHub Secure Open Source Fund and how I spent the time with `oapi-codegen`. The canonical URL for this post is https://www.jvt.me/posts/2026/02/ 17/oapi-codegen-github-secure/ . Written by Jamie Tanna's profile image Jamie Tanna on Tue, 17 Feb 2026 19:16:50+00:00, and last updated on Tue, 17 Feb 2026 19:27:48+00:00. Content for this article is shared under the terms of the Creative Commons Attribution Non Commercial Share Alike 4.0 International, and code is shared under the Apache License 2.0. #oapi-codegen #github #supply-chain-security. Has this content helped you? Did it solve that difficult-to-resolve issue you've been chasing for weeks? Or has it taught you something new you'll be able to re-use daily? Please consider supporting me so I can continue to create content like this! This post was filed under articles. Interactions with this post Interactions with this post Below you can find the interactions that this page has had using WebMention. Have you written a response to this post? Let me know the URL: [ ] [Send Webmention] Do you not have a website set up with WebMention capabilities? You can use Comment Parade. Due to laziness, this site uses client-side JavaScript to render the webmentions, rather than them being rendered server-side. If you do not wish to enable JavaScript, that's fair enough, but you won't be able to automagically see what Webmentions I've received - sorry! - - Top Other links that may be of interest: * /slashes * Follow This Blog (i.e. via RSS feed) * Talks * Blogroll * Why is my site www.jvt.me? * Archives * Post Visualisation * Manual of Me * Typography * My name and pronounciation * RSVPs * Links * Post by Kind This site is part of an IndieWeb Webring * Previous site * Next site Want to get in touch? Drop me an email at hi@jamietanna.co.uk. I try to get back to everything, if I don't reply in a couple of weeks, feel free to give me a nudge! You can also check out a list of all the places /elsewhere you can find me. (c) 2026 Jamie Tanna. Post content and code snippets licensing is detailed on respective pages, otherwise default to Creative Commons Attribution Non Commercial Share Alike 4.0 International and Apache License 2.0. Site design released under the MIT License. Proudly hosted on AWS using S3 + CloudFront, deployed by GitLab CI, and generated by 44f04ac4d4 on Tue, 17 Feb 2026 19:27:48 +0000.. Piwik tracking image