Slow down and sit with it - Yao Yue

Slow down and sit with it

yaoyue.org

Artificial Intelligence Floods Court Dockets with Home-Brewed Lawsuits

nytimes.com

NASA's Artemis II Live Views from Orion

YouTube video by NASA

youtube.com

Introducing the Agent Governance Toolkit: Open-source runtime security for AI agents | Microsoft Open Source Blog

Discover how the Microsoft Agent Governance Toolkit brings policy, identity, and reliability to autonomous AI agent systems.

opensource.microsoft.com

Eyes on the Solar System - NASA/JPL

Explore the 3D world of the Solar System. Learn about past and future missions.

eyes.nasa.gov

NASA's Artemis II Crew Launches To The Moon (Official Broadcast)

YouTube video by NASA

youtube.com

Lessons learned from oapi-codegen's time in the GitHub Secure Open Source Fund

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 **??**. * 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!

jvt.me