What I learned securing Sniffnet with the GitHub Secure Open Source Fund

I’ve always built Sniffnet with a security-first mindset, and today I’m thrilled to announce a major milestone<br>faithfully aligned with that philosophy: Sniffnet recently took part in the GitHub Secure Open Source Fund!

Backed by industry giants like Microsoft, Stripe, 1Password, and Shopify,<br>it’s a dedicated initiative focused on improving the security and sustainability of critical open-source software.

In this blog post, I’ll share how the program made Sniffnet more secure, and walk you through the steps you can follow to do the same.

After all, one of the most important lessons I’m taking away from this experience is that security is a joint effort of the whole<br>community: each project is a tiny piece of a bigger puzzle and no one can be completely safe if the rest of the ecosystem isn’t.

The GitHub Secure Open Source Fund program

The program’s mission is to secure open source software that is widely used and critical to the modern stack.

It consists of an immersive 3-week sprint that provides each onboarded project with $10k in funding, hands-on training, and mentorship to help maintainers<br>understand that security is a baseline requirement, not a nice-to-have.

The sprint is curated by the GitHub Security Lab and delivered by a team of security experts.

Sniffnet and other 49 projects joined the fourth session of the program this past April,<br>and selected participants were asked not to share the news until today’s official announcement,<br>to avoid any potential exposure and to focus on securing our codebases.

The best part?

The program isn’t only about learning and theory: it’s designed as a series of practical steps<br>that have to be taken to satisfy outcome-driven goals and verified security requirements, having a tangible impact on the project and its users.

Security as a priority

As mentioned in the introduction, I’ve always cared about securing Sniffnet:<br>this website’s homepage states that “one of the top priorities is to protect data privacy and system integrity”,<br>and not long ago the project underwent an independent security audit.

And… can you guess the specialization of my Computer Science Master’s degree?

Cybersecurity, of course!

Despite having been in the field for a while,<br>I had never been exposed to a structured security program like the Secure Open Source Fund,<br>and I was amazed by the number of tools that GitHub natively offers to make code more robust.

Unfortunately, the reality is that too often security is deferred to the end of the development cycle or,<br>even worse, only considered in a moment of panic after a vulnerability is discovered.

A shift in mentality is therefore needed to proactively design and plan security,<br>rather than downgrading it to a mere reactive countermeasure.

I feel a responsibility to amplify security awareness by sharing the knowledge and best practices I learned,<br>so that other developers can take inspiration and apply similar measures in their own projects.

Incident response planning and threat modeling

Before even worrying about concrete measures, the first step is to define a clear security plan.

Planning is crucial for two main reasons:

when something bad happens (it will happen, sooner or later), having a robust strategy ready will let you act calmly and effectively even under pressure

outlining the most critical assets of your project before they are compromised will help you focus your efforts on what really matters

Point 1 is addressed by incident response planning (IRP), which consists of defining the roles, responsibilities, and an ordered set of actions to follow in case of a security incident.

The goal is to have a procedure in mind to contain the effects of the incident and restore normal operations as quickly as possible.

For a detailed IRP document, you can check out Sniffnet’s INCIDENT_RESPONSE.md.

Point 2 is instead a matter of threat modeling , the process of cataloging the threats that specific assets of your system may be exposed to.

To identify common types of threats, we used the STRIDE framework, which classifies threats into six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

A truly exhaustive threat model would come up with a huge two-dimensional matrix of threats × assets, which is something complex to do and hard to maintain, especially for large projects.

For this reason, rather than postponing the process indefinitely, it’s advisable to start by analyzing the most critical assets of your system, ranked by likelihood and impact of exploitation, and gradually expand the coverage over time.

If you are curious to see how this turned out for Sniffnet you can have a look at our first THREAT_MODEL.md.

The two documents mentioned above are even more effective if paired with a security policy that describes how to report vulnerabilities and how the maintainers handle them, so...