# Renforcer la sécurité avec le GitHub Secure Open Source Fund > En février 2026, nous avons dressé le bilan de notre participation au GitHub Secure Open Source Fund, un programme de sécurité mené avec le GitHub Security Lab. À la fin de l’été dernier, GitHub nous a proposé de participer au [Secure Open Source Fund](https://github.com/open-source/github-secure-open-source-fund). Nous avons postulé, le comité nous a retenus, et nous avons rejoint 98 mainteneurs de 67 projets open source pour un programme de sécurité intensif. ## Le programme La phase approfondie s’est déroulée en septembre 2025 : une vingtaine de sessions, toutes en direct sur Zoom, avec des créneaux en soirée plutôt confortables pour les participants européens, même si les participants se connectaient depuis tous les fuseaux horaires. Les sessions étaient animées par des experts du [GitHub Security Lab](https://securitylab.github.com/) et couvraient un large éventail de sujets. Entre les sessions, nous avions des tâches concrètes à réaliser. Des devoirs, mais de ceux qui servent vraiment. Le vrai intérêt, cependant, était d’entendre ces sujets expliqués par des personnes qui y sont confrontées au quotidien et d’en discuter en groupe. ## La sécurité, c’est un entraînement, pas une case à cocher Un concept m’a particulièrement marqué : *Improving Our Security Posture*. La sécurité n’est pas une case qu’on coche une fois pour toutes. C’est plutôt comme la forme physique. Il n’y a pas de ligne d’arrivée. On prend des habitudes, on continue à s’entraîner, on devient peu à peu plus fort. Le programme nous a donné un plan d’entraînement structuré. Les sujets étaient très variés. Nous avons travaillé sur la clarté et la compatibilité des licences, en ajoutant des vérifications de licence pour nos dépendances Go et NPM et en publiant des SBOM. Nous avons rédigé un [SECURITY.md](https://github.com/evcc-io/.github/blob/main/SECURITY.md) et un plan de réponse aux incidents. Nous avons découvert le processus d’attribution des CVE. Je n’ai pas encore eu à m’en occuper, mais mieux vaut être préparé. Nous avons abordé la modélisation des menaces, les principes de sécurité dès la conception et les aspects UX du développement de logiciels sûrs. Côté outils, des sessions portaient sur l’analyse statique avec CodeQL et sur le fuzzing. La [sécurité de GitHub Actions](https://docs.github.com/fr/actions/how-tos/secure-your-work) s’est révélée un sujet bien plus profond que je ne l’imaginais. Les workflows peuvent être exploités de nombreuses manières subtiles, et nous avons fini par renforcer nettement nos propres actions avec des outils comme [actions-permissions](https://github.com/GitHubSecurityLab/actions-permissions). Une session m’a surpris : celle consacrée à la sécurité de l’IA. GitHub nous a présenté le [Secure Code Game](https://github.com/skills/secure-code-game), un défi pratique dans lequel on cherche des vulnérabilités dans une base de code. Les premiers niveaux couvrent des problèmes OWASP classiques comme l’injection SQL et le XSS. Terrain connu. Mais la dernière saison consiste à amener par la ruse des logiciels dotés de fonctions LLM intégrées à faire ce qu’ils ne devraient pas. J’ai pris conscience que c’est là le nouveau front, et que beaucoup s’y préparent activement. ## Des projets différents, des perspectives différentes Ce qui rendait le programme particulier, c’était la diversité des projets réunis. Il y avait des applications comme evcc, [Thunderbird for Android](https://github.com/thunderbird/thunderbird-android), [Mattermost](https://github.com/mattermost/mattermost) et [Mastodon](https://github.com/mastodon/mastodon). Des bibliothèques comme [GoReleaser](https://github.com/goreleaser/goreleaser) (que nous utilisons pour publier nos versions), [Mermaid](https://github.com/mermaid-js/mermaid) (que nous utilisons dans notre documentation) et [Node.js](https://github.com/nodejs/node). Et des outils fondamentaux comme [curl](https://github.com/curl/curl) et [ImageMagick](https://github.com/ImageMagick/ImageMagick). La sécurité recouvre des réalités très différentes selon ce que l’on développe. Une application qui tourne chez les gens fait face à d’autres menaces qu’une bibliothèque intégrée dans des milliers de projets. Entendre comment curl et Mastodon abordent chacun la sécurité a été vraiment précieux. Et au-delà du contenu, il reste le réseau tissé avec les autres mainteneurs. ## GitHub Universe En octobre 2025, j’ai été invité à la conférence GitHub Universe à San Francisco ([en savoir plus](https://www.linkedin.com/posts/michael-geers_homeassistant-githubuniverse-opensource-activity-7391032971517992960-a9V8)). J’ai participé à une table ronde sur le Secure Open Source Fund lors du Community Day. C’était super de rencontrer d’autres mainteneurs en personne après des semaines de sessions Zoom. Avec [Gregg Cochran](https://www.linkedin.com/in/greggcochran/) (GitHub), [Christian Grobmeier](https://www.linkedin.com/in/grobmeier/) (Log4j), [Camila Maia](https://www.linkedin.com/in/cmaiacd/) (ScanAPI) et [Carlos Alexandro Becker](https://www.linkedin.com/in/caarlos0/) (GoReleaser), j’ai enregistré un épisode de podcast sur la sécurité open source. Vous pouvez [le regarder sur YouTube](https://www.youtube.com/watch?v=XmCSHr12CO0) ou [écouter la version audio](https://the-github-podcast.simplecast.com/episodes/live-from-github-universe-inside-the-github-secure-open-source-fund-EV0GufSU). ![Photo de groupe à GitHub Universe](/_astro/universe.BBaBsHXA_Z2nEeAs.webp) ## Participer **Si vous maintenez un projet open source :** pensez à postuler au programme. Le tour d’horizon des sujets de sécurité est large, et le réseau de mainteneurs que vous vous constituez est tout aussi précieux. **Si votre entreprise dépend de l’open source** (et c’est presque certainement le cas) : pensez à soutenir financièrement vos dépendances critiques. Ou soutenez le [Secure Open Source Fund](https://github.com/open-source/github-secure-open-source-fund) pour aider l’écosystème dans son ensemble. Un écosystème open source plus sûr, ce sont des logiciels plus sûrs pour tout le monde.