Secure Open Source Fund bolstering Gitoxide security in the supply chain #2439
EliahKagan
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
TL;DR: We took part in Session 3 of the GitHub Secure Open Source Fund, which is a GitHub program that provides training and resources to projects, to improve supply chain security. We've benefited in multiple ways and continue to benefit. We plan to include the main announcement about this in an upcoming monthly report, but I wanted to post this now so people can read about it and also so people can see the other 66 amazing projects Gitoxide was honored to participate alongside.
The "Thanks, GitHub!" section of Gitoxide's 2025 Retrospective (#2323) mentioned:
There are actually multiple ways this has happened. The most long-standing of these is probably the work of people at the GitHub Security Lab who review advisories, handle most of our CVE requests, and even make improvements (such as adding references) for the version hosted in the global GitHub Advisory Database. This is available to all projects on GitHub--it integrates with security advisories and Private Vulnerability Reporting.
But there's also a more recent and intensive way we've gotten help: GitHub has something called the Secure Open Source Fund, which provides direct funding to projects, multiple channels of communication to ask questions of members of the GitHub Security Lab, an intensive 3-week training sprint, and a number of other resources. They've done this three times, and Gitoxide has been honored to be part of Session 3!
This has helped us to improve security in multiple concrete areas, including hardening our GitHub Actions workflows, making greater use of static analysis, and adopting mitigations such as dependency cooldown periods to make it less likely that we use or pass on a dependency on a version affected by a supply-chain attack.
Those are just a few examples; there's quite a bit more. I've been busy this month and I haven't had a chance to write up anything nearly comprehensive. I'm looking forward to saying more soon and @Byron plans to include information about it in a near future monthly report. But I wanted to post this now, since the big GitHub announcement for SOSF Session 3 came out today.
Beta Was this translation helpful? Give feedback.
All reactions