# CRA : les entreprises doivent mieux collaborer avec les projets open source

_Publié le 3 novembre 2026 — https://ip73.fr/2026/11/03/cra-les-entreprises-doivent-mieux-collaborer-avec-les-projets-open/_

Le Cyber Resilience Act (CRA) redéfinit le rapport entre les entreprises et les projets open source. Les éditeurs de logiciels commerciaux, désignés comme « Fabricants » par le CRA, doivent désormais évaluer la sécurité des composants open source qu'ils utilisent. Cette diligence raisonnable, imposée par l'article 13 (5) du règlement, doit être menée lors de l'évaluation initiale et lors de chaque mise à jour de ces dépendances. Pour cela, une interaction directe avec les mainteneurs des projets est inévitable.

En parallèle, le CRA exige que les fabricants partagent les correctifs de sécurité avec les projets en amont (upstream), conformément à l'article 13 (6). Ce changement confronte les méthodes d'entreprise, habituées aux contrats et aux niveaux de service, aux normes sociales des communautés open source. L'Open Source Security Foundation (OpenSSF) alerte sur le risque de friction : une approche purement corporative peut engendrer des incompréhensions, même si les intentions sont bonnes.

Pour aider les équipes commerciales, OpenSSF a publié un guide pratique. Il rappelle que les projets communautaires ne sont pas responsables de répondre aux exigences de conformité du CRA pour chaque utilisateur. De plus, le règlement ne crée pas d'obligations pour les développeurs bénévoles qui maintiennent un projet sans monétisation commerciale ou sans commercialisation sur le marché de l'Union européenne.

## Les règles d'engagement dans les communautés open source

Ce guide propose une série de comportements essentiels structurés selon le cycle de vie de l'engagement. Le premier réflexe est de lire la politique de sécurité du projet, souvent dans un fichier nommé `SECURITY.md`, pour éviter toute divulgation publique non autorisée d'une vulnérabilité. Il faut aussi étudier le guide de contribution (`CONTRIBUTING.md`), car ignorer ces instructions techniques est souvent perçu comme un manque de respect et est la raison la plus fréquente de rejet de contributions.

La question du droit d'auteur est centrale : les contributeurs doivent vérifier la politique de copyright. Si le projet utilise un CLA (Contributor License Agreement), le contributeur doit s'assurer d'avoir les droits nécessaires, ce qui implique souvent une signature par un représentant légal de l'entreprise.

## L'exemple PHP et la nécessité d'un investissement soutenu

Si l'aspect légal prend de l'ampleur, les enjeux techniques continuent d'être prégnants. Les récentes actualités autour de PHP illustrent cette dynamique. Le projet a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux failles critiques. Ces vulnérabilités, CVE-2026-109618 et CVE-2026-109619, permettaient, sous certaines conditions, à un attaquant non authentifié d'exécuter du code sur des serveurs PHP. Ces failles provenaient de problèmes dans la gestion de la mémoire et du traitement des erreurs.

L'impact de ces failles, qui touchent des zones centrales du langage utilisé par environ 70 % des sites web serveur, a nécessité un travail de longue haleine. La Fondation PHP a admis que le processus décisionnel, freiné par des contraintes de ressources et la complexité des choix entre compatibilité et sécurité, a entraîné des retards structurels sur la résolution de l'OOM.

Cette expérience montre que l'investissement doit dépasser la simple détection. L'OpenSSF souligne que si les mainteneurs fixent les problèmes en amont, les entreprises doivent assumer la responsabilité du déploiement en aval, en intégrant les correctifs et en rendant les mises à jour pratiques pour leurs utilisateurs. L'IA accélère la découverte de failles, mais comme l'ont montré les cas récents de PHP, elle ne remplace pas l'expertise humaine ; chaque décision finale repose sur un jugement humain.

## Sources

- [wg-best-practices-os-developers/docs/Concise-Guide-for-Collaborating-with-Open-Source-Projects.md at main ·…](https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Concise-Guide-for-Collaborating-with-Open-Source-Projects.md), github.com
- [Today's PHP Security Release, and How We're Strengthening PHP Security](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/), thephp.foundation
- [The PHP Security Wake-Up Call: Fixes Are Only the Beginning](https://openssf.org/blog/2026/11/03/the-php-security-wake-up-call-fixes-are-only-the-beginning/), OpenSSF, 3 novembre 2026
- [The ‘Vulnpocalypse’ is coming for the internet’s aging code, says Wiz’s CTO](https://techcrunch.com/podcast/the-vulnpocalypse-is-coming-for-the-internets-aging-code-says-wizs-cto/), TechCrunch, 28 octobre 2026
- [Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619 (Updated October 29)](https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/), Unit 42, 29 octobre 2026

## Crédits photo

- Image en une : [DHL Netherlands local site computer room server racks (2) - IMG 3299](https://commons.wikimedia.org/wiki/File:DHL_Netherlands_local_site_computer_room_server_racks_%282%29_-_IMG_3299.jpg), par Jemimus, [CC BY 2.0](https://creativecommons.org/licenses/by/2.0), via Wikimedia Commons (recadrée)