Hands-on security help for open source maintainers

The GitHub Security Lab has been running a Community Office Hours program designed to give open source maintainers direct access to security expertise. After opening the initiative to the community, the lab worked with six projects, and several participants saw immediate, practical improvements to their security posture.

One standout case was Guzzle, a widely-used PHP HTTP client with more than 22k stars and 2.3k forks on GitHub. Where vulnerability handling previously stretched over weeks — from acknowledgment and confirmation through fix implementation, review, and user notification — the team was able to work through five separate vulnerabilities in a matter of hours with the Security Lab’s support. Another maintainer team, inspired by the conversations, went on to publish an article about third-party GitHub Actions, sharing best practices around permission escalation with the wider community.

How the sessions were structured

Projects interested in participating began by completing a short questionnaire covering basic project information and any specific security concerns. GitHub then paired each project with internal security experts, matching based on the topics raised and the programming languages involved.

Before the conversations, experts familiarized themselves with the codebase and prepared preliminary observations about the project’s security practices. That preparation allowed the sessions to move directly into substantive discussion, maximizing the value for the maintainers involved.

Attack surface: the top concern

Across all six projects, the most common question maintainers asked was essentially: how would you hack us? Defining a project’s attack surface — the areas where risk of attack or malicious activity is highest — proved to be a genuine challenge.

Attack surface includes the obvious places where user input enters the codebase or where user-controlled data influences critical operations like code execution or file system access. But it also extends well beyond the code itself. The sessions surfaced countless examples of attack vectors in the supply chain, in confidential information handling, and in CI/CD pipelines. Even maintainers themselves can be vectors, through social engineering and account takeover.

Developers without a security background are unlikely to be aware of the full range of possible entry points. Because every project is different, the first step is identifying the most relevant attack vectors — a practice known as threat modeling. In a threat modeling exercise, team members brainstorm attack scenarios, present evidence of weak points, and explain how those weaknesses could be exploited.

Not all attacks are equal. Each one differs in impact on users, effort required, likelihood of success, and the skills needed to execute it. By weighing these factors, maintainers can make data-driven decisions about where to focus mitigation efforts first. The OWASP Threat Modeling Cheat Sheet is a useful starting point for teams looking to learn more.

Five high-value practices

Several participating maintainers were unaware of simple, low-effort practices that deliver outsized security benefits. The following five came up repeatedly as offering the most value:

  1. Enable two-factor (or multi-factor) authentication to protect against account takeover and impersonation.
  2. Turn on automated code scanning in your CI/CD workflow to catch bugs early in the development lifecycle.
  3. Activate Dependabot to keep dependencies current.
  4. Publish a security policy so users know how to disclose vulnerabilities in your project.
  5. Create security advisories to inform users about vulnerabilities and direct them to the safest updated version once a disclosure is made.

Functionality testing vs. security testing

The final pattern observed was an imbalance between functionality testing and security testing. Some projects focused heavily — or even exclusively — on making sure features worked as intended, while giving little attention to how the software behaved under attack.

One concrete example: a project had implemented input sanitation to prevent injection attacks but never tested whether that protection actually worked. That gap could have been closed with simple unit tests that deliberately feed malicious input into the application. Another option is fuzzing, an automated security testing method that runs the program with invalid, malformed, or unexpected inputs to trigger crashes or information leakage that reveals underlying vulnerabilities.

For maintainers who want to act on these takeaways, the immediate steps are clear: define your threat model, implement the five practices above, and look for gaps between functionality testing and security testing. The Security Lab continues to accept interest from open source projects via its participation form for future office hour sessions.