How We Built Security Into Nasiko Before We Needed It

The last post in our GitHub Secure Open Source Fund series: what changed once we started treating security as something you prepare, not something you improvise.

The first two posts in this series were about security surfaces we could point at directly: How We Hardened Nasiko's Software Supply Chain and How We Strengthened Agent and MCP Security In Nasiko. This last one is about something less visible. It is about what happens before there is anything to respond to.

If we had to name the change from those three weeks that we expect to last longest, it would not be a feature we turned on. It would be this: we did the security groundwork while nothing was on fire. That sounds obvious once it is written down. It is also the easiest thing in the world to keep deferring.

The document you want during an incident is the one you wrote before it

Before the program, our honest answer to "what happens when someone reports a vulnerability" was mostly "we would figure it out." That is a fine answer right up until the moment it is not, and that moment is the worst possible time to be figuring it out.

And we wrote and committed an incident response plan: who does what, in what order, when a report comes in. The program's session on responding to incidents was the nudge that moved both from "someday" to done.

Neither document is interesting to write. Both are already enormously valuable.

A plan written during a crisis inherits the crisis, and its gaps become gaps in your communication and triage at exactly the moment you can least afford them.

The security document you most want during an incident is the one you wrote before it.

When did you last read your own? Do you have one?

Private by default

One specific change is worth calling out because it is easy to copy. We made private vulnerability reporting the default way to reach us about a security issue, rather than a public issue tracker.

The reasoning is simple. A vulnerability filed as a public issue is a disclosure before a fix is available. It tells everyone, including whoever might exploit it, at the same moment it tells you, and it starts a clock you did not choose. A private report gives maintainers time to investigate, prepare a fix, coordinate an advisory, and disclose the issue without exposing users before a remediation is available. GitHub provides private vulnerability reporting for exactly this, and it is straightforward to enable.

The part that does not fit in a checklist

Most of the value was not a lecture. It was three weeks in a room with other maintainers and the GitHub Security Lab, watching how people who ship software that millions of teams depend on actually handle this: how they think about disclosure, what their incident plans look like, where they have been burned before. The security buddies from the Lab answered the specific, slightly embarrassing questions you do not want to ask in public.

Somewhere in there, security stopped being the thing we meant to get to and became a baseline we build from. That is a smaller-sounding shift than "we fixed a pile of vulnerabilities," and it is the one that actually lasts.

Passing it on

The program asks maintainers to pay this forward, and the reason is not sentimental. Security scales one-to-many. Every project that publishes a clear disclosure process, a useful security policy, or one hard-won lesson saves the next team from learning it the expensive way. An incident plan itself may stay internal. The lessons behind it do not have to.

What we are still working on

We are not finished, and we would rather say so than imply otherwise. Two things are on the near list. We want to run a tabletop exercise against a mock advisory, so the first time we execute the incident plan is a drill rather than a real report. And we want to formalize how we coordinate disclosures with the teams that depend on us, so that an embargo is a process rather than an improvisation.

If you maintain a project

The shortest version of what we would tell another maintainer, in the order we would do it:

• Write a SECURITY.md that states your supported versions, how to report privately, and what a reporter should expect back.
• Turn on private vulnerability reporting and make it the obvious path.
• Write an incident response plan before you need one, even if it's short.
• Once you have a plan, rehearse it against a fake advisory before a real one arrives.
• Publish what you learn so the next maintainer starts ahead of where you left off.

None of the first three requires a security incident to begin. That is exactly why the time to do them is now, while it is calm.

Thanks to GitHub, the GitHub Security Lab, and the funding and ecosystem partners behind the Secure Open Source Fund. And thank you to the other maintainers in our cohort, who were generous with hard-won lessons and made three weeks of security homework feel like a shared project rather than a solo grind.

If you build with agents, we hope the five defaults save you a step. If you see a gap in how we described any of this, tell us. That is the whole point.

Read the full announcement on GitHub: https://github.blog/open-source/maintainers/what-50-open-source-projects-taught-us-about-security-in-the-ai-era/