{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigb5xqy7jd7d4hgkjnwzo2mlc64mwt7m4ecw6zxibjrexj4nds4be",
    "uri": "at://did:plc:wszrgoqdwy3i2dfeub2mt3wf/app.bsky.feed.post/3mf3cbj5mmkd2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreievwecepl6ksl5cqo4k3o7aqe6bk2ayelwnbjxvyjuaogp2lt42cu"
    },
    "mimeType": "image/jpeg",
    "size": 986681
  },
  "description": "Sharing some thoughts about the GitHub Secure Open Source Fund and how I spent the time with `oapi-codegen`.",
  "path": "/posts/2026/02/17/oapi-codegen-github-secure/",
  "publishedAt": "2026-02-17T19:16:50.000Z",
  "site": "https://www.jvt.me",
  "tags": [
    "oapi-codegen",
    "github",
    "supply-chain-security",
    "GitHub's post",
    "`oapi-codegen`",
    "GitHub Secure Open Source Fund",
    "commit to your project",
    "I've written about",
    "a couple of times",
    "middleware for request/response validation",
    "conversions between types at runtime",
    "Renovate",
    "we recommend pinning to commits off `main`",
    "the OpenSSF Best Practices \"passing\" grade badge",
    "Setting up a security policy for the organisation",
    "`govulncheck` with GitHub Code Scanning alerts",
    "GitHub maintainers community"
  ],
  "textContent": "As noted in GitHub's post, `oapi-codegen` was one of the projects taking part in the third GitHub Secure Open Source Fund session.\n\nI'd like to take a moment to reflect on the program, and some learnings I've taken from it.\n\nOne of the quotes I shared at the end of the program summed up my time:\n\n> Having time dedicated to following best practices has been invaluable☆(well, $10k)\n\n## Why did we join the fund?\n\n`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.\n\nGiven 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.\n\nAs a code generator, `oapi-codegen` can generate a fair bit of code for you to commit to your project.\n\nBut 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.\n\n### Extending the maintainer pool\n\nOn 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.\n\nAdditionally, `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.\n\nThe project is sufficiently complex, led by user examples, and has a lot of usage that can make it hard to maintain for $0/month.\n\nOver 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.\n\nWhile 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.\n\nThis 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.\n\nFor 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.\n\nAlternatively, 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.\n\nI 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.\n\nHaving 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.\n\nWith this in place, we are much more able to take on additional collaborators and maintainers.\n\n## Understanding our gaps\n\nOver 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.\n\nI 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.\n\nBut 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.\n\nSince 2024, I've been working towards the OpenSSF Best Practices \"passing\" grade badge for `oapi-codegen`, and working towards following best practices there.\n\nAs 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.\n\nDuring 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).\n\nHaving the time to work on the program meant that we could address some of the security gaps, not limited to:\n\n  * Setting up a security policy for the organisation\n    * Including explicitly documenting which versions are supported, how to report a security issue, and how we treat **??**.\n  * Tightening branch protection rules and/or migrating to Repository Rulesets\n  * Setting up `govulncheck` with GitHub Code Scanning alerts\n  * Setting up collection of OpenSSF Security Scorecard reports data\n  * Enforcing GitHub Advanced Security checks\n\n\n\nAs well as these concrete steps, we have also made less outwardly visible steps, like work towards a threat model for the project.\n\n## Access to more of a community\n\nIt's also been nice to have a place to chat, complain and brainstorm with other maintainers who are in a very similar position.\n\nWithin 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.\n\nAlthough 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.\n\n## Can an inactive project be more secure?\n\nThis 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 🤓\n\nWith 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.\n\nThat's not where we want to be, however, as we want to be both secure _and_ well maintained!\n\n## Great teachers\n\nThe 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.\n\nWorking 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!\n\nThanks again everyone 💜\n\n## Looking forward\n\nNow we're able to talk about our time in the program publicly, expect to see some more learnings shared!\n\nIf you're interested in hearing about anything in particular, let me know!",
  "title": "Lessons learned from oapi-codegen's time in the GitHub Secure Open Source Fund",
  "updatedAt": "2026-02-17T19:16:50.000Z"
}