Lettre ouverte demandant à NHS England de maintenir son code public

 (keepthingsopen.com)
1 points par GN⁺ 2026-05-03 | 1 commentaires | Partager sur WhatsApp
  • S’oppose à la décision de la direction technologique de NHS England de rendre le code source de ses dépôts privé, et réaffirme le principe selon lequel le code financé par des fonds publics doit être accessible au public
  • Il est demandé à NHS England de retirer la ligne rouge SDLC-8 et de réaffirmer son engagement envers le principe 12 du NHS Service Standard, « Make new source code open »
  • Publier en open source demande plus de travail que de garder le code privé, mais cela impose des standards de qualité plus élevés, la détection et la correction préalables des vulnérabilités, ainsi que la mise en place de barrières pour limiter les dégâts
  • Le code source fermé peut conduire à sauter des tâches de sécurité nécessaires, s’appuie sur l’obscurité plutôt que sur une défense en profondeur, et semble offrir très peu d’avantages face à des attaquants suffisamment motivés
  • 402 personnes ont signé depuis le 1er mai 2026 ; les signataires peuvent fournir leur nom, leur e-mail et indiquer s’ils ont contribué à des logiciels du secteur public britannique, et pour les signatures anonymes les données personnelles sont supprimées dans les 24 heures après vérification

Exigences clés de la lettre ouverte

  • S’oppose à la décision de la direction technologique de NHS England de masquer le code source de tous les dépôts, et réaffirme le principe selon lequel le code financé par des fonds publics doit être accessible au public
  • Ce principe figure dans les UK Government Design Principles et le NHS Service Standard, et il est considéré comme étant actuellement remis en cause
  • Il est demandé à NHS England de retirer la ligne rouge SDLC-8 et de réaffirmer son engagement envers le principe 12 du NHS Service Standard, « Make new source code open »
  • 402 personnes ont signé depuis le 1er mai 2026, et les signatures sont affichées sur la page après vérification manuelle

L’argument selon lequel l’open source impose des standards de qualité plus stricts

  • Rendre le code open source demande plus de travail que de le garder privé
  • Cette difficulté même est considérée comme essentielle
  • La publication en open source impose des standards de qualité plus élevés et nécessite des processus pour détecter, corriger et surveiller les vulnérabilités en amont
  • Il faut identifier les risques et mettre en place des barrières pour limiter les dégâts en cas de problème
  • Cela est comparé au système immunitaire humain : l’exposition aux menaces renforcerait la surface d’attaque

Critique du code source fermé

  • Le code source fermé permet de passer à côté de travaux de sécurité nécessaires
  • Cette approche privée est considérée comme s’appuyant sur l’obscurité plutôt que sur une défense en profondeur
  • Lorsqu’il existe des attaquants suffisamment motivés, les avantages apportés par cette obscurité semblent très faibles

Modalités de signature et traitement des données personnelles

  • Les signataires peuvent fournir leur nom, leur adresse e-mail, indiquer s’ils ont contribué à des logiciels du secteur public britannique, ainsi que, de manière facultative, leur rôle et leur organisation
  • Les contributions à des logiciels du secteur public britannique peuvent inclure des contributions techniques ou non techniques, publiques ou privées
  • En cas de contribution, un commit ou un lien de profil suffit, et ces informations ne sont pas rendues publiques
  • Si la signature anonyme est choisie, la signature est affichée comme « Anonymous » et, si un rôle et une organisation sont fournis, ils peuvent être affichés avec elle
  • Dans le cas des signatures anonymes, les données personnelles sont supprimées dans les 24 heures après vérification
  • L’adresse e-mail n’est utilisée que si un contact est nécessaire au sujet de la signature et n’est pas rendue publique
  • La base légale du traitement des données personnelles est le consentement, qui peut être retiré
  • Pour toute question liée aux données, il est possible de contacter signatures@keepthingsopen.com
  • Une plainte concernant le traitement des données personnelles peut être déposée auprès de l’Information Commissioner’s Office

Ressources et liens de soutien

À lire aussi

1 commentaires

 
GN⁺ 2026-05-03
Commentaires sur Hacker News

  • La réponse à la menace Mythos ressemble entièrement à une mesure de façade, et dès qu’un peu de transparence et d’ouverture apparaît, on voit qu’ils sont prêts à revenir en arrière avec n’importe quel prétexte bancal
    Cela ressemble davantage à une décision prise par des non-techniciens qui pensent : « il y a ne serait-ce que 0,1 % de chances qu’on nous reproche de ne pas être passés en source fermée et de ne pas en avoir fait assez lorsqu’une vulnérabilité a été découverte »
    Il faut aussi garder à l’esprit qu’en 2026, la cupidité et l’égoïsme extrêmes rendent ce type de décision facile à prendre, même au détriment du bien public, et que le secteur privé n’est pas vraiment meilleur sur ce point

    • La seule exception, ce serait si le code avait subi des changements importants après la fermeture, et que les attaquants ou les grands modèles de langage n’avaient pas pu lire ces modifications
      En utilisant en interne de grands modèles de langage pour chercher des bugs sans publier le code source, on pourrait garder une longueur d’avance sur les attaquants
      On a aussi vu récemment, avec le désastre public de Copy.fail, le cas d’une vulnérabilité trouvée par quelqu’un utilisant un grand modèle de langage, puis publiée en zero-day sans correctif clair, plongeant la communauté dans la confusion et la panique
      Dans une situation où des grands modèles de langage puissants existent à la fois avec des poids ouverts et fermés, imposer que tout soit open source sans exception, surtout pour des logiciels utilisés dans les hôpitaux, paraît moins défendable ; il faut trouver un équilibre

  • Si vous suivez ce fil parce que la qualité des services numériques du NHS vous préoccupe, ce serait bien aussi de signer la pétition visant à empêcher les fournisseurs du NHS d’acheter des surcouches d’accessibilité qui nuisent réellement à l’expérience des utilisateurs handicapés et gaspillent l’argent qui pourrait servir à améliorer des services essentiels : https://petition.parliament.uk/petitions/765480/

  • Je ne peux pas signer, le système de vérification de Cloudflare affirme que je ne suis pas humain

  • Il y a une vidéo qui explique bien la situation : https://youtu.be/XNLUfqtgBUk
    Si c’est votre domaine d’expertise, ce serait bien de signer la lettre ouverte

  • Même si le NHS était d’accord et voulait l’appliquer, rien que l’élaboration des directives prendrait au moins un an
    Ensuite, si on demande à l’équipe technique actuelle de mettre de l’ordre là-dedans, cela risque encore de prendre dix ans

  • Article lié : NHS Goes to War Against Open Source
    https://shkspr.mobi/blog/2026/05/nhs-goes-to-war-against-ope... (https://news.ycombinator.com/item?id=47973710)

  • J’ai parlé de ce sujet ces dernières semaines avec des CISO, des CTO, des mainteneurs et des collègues, dont certains travaillent dans des entreprises du Fortune 50, et leur plan de base est de suspendre les contributions et l’usage de l’open source jusqu’à ce que les équipes de sécurité applicative puissent vérifier et corriger facilement un problème en une journée
    Historiquement, le temps de réponse de bout en bout était plutôt de 8 à 10 jours, mais à ce rythme, ce n’est plus tenable aujourd’hui
    Je n’y vois pas la mort de l’open source, mais cela montre que l’économie de l’open source s’est transformée en tragédie des biens communs faute de fournir aux mainteneurs des ressources d’exploitation durables
    C’est aussi l’aveu que les organisations n’ont pas fait de la sécurité une priorité, ni dans l’ingénierie ni au niveau organisationnel, depuis des décennies, mais vu le niveau de la discussion ici sur HN, cela mérite sans doute un débat séparé
    Si les gens qui aiment l’open source s’en soucient vraiment, ils doivent arrêter l’idéalisme abstrait et y mettre de l’argent ; il faut envisager l’open core, ou des mécanismes formels de financement et de sponsoring
    Il est aussi important d’adopter des licences bien plus restrictives tout en permettant la commercialisation par les propriétaires de projets. La plupart des projets de style GNU qui reposent sur la bonne volonté de quelques personnes partageant la même idéologie auront du mal à survivre, et les contributeurs doivent aussi être rémunérés
    À la question « on ne peut quand même pas arrêter Linux/Kubernetes/Chrome (y compris Edge)/presque tous les langages de programmation/nginx, etc. », cela veut dire geler toutes les dépendances et bibliothèques utilisées à l’avenir, et ne pas publier le code source tant qu’une correction de vulnérabilité de bout en bout en moins de 24 heures n’est pas possible
    Les équipes envisagent aussi sérieusement de forker en interne les projets et dépendances critiques, puis de ne plus contribuer en amont par crainte que les contributions upstream soient compromises ou introduisent de nouvelles vulnérabilités

    • Comme le dit simonw, je suis plutôt d’accord avec l’idée que l’open source devrait au contraire devenir plus précieux
      « Le résultat intéressant, c’est que les bibliothèques open source prennent plus de valeur, parce que le coût en tokens consacré à la sécurité peut être mutualisé entre tous les utilisateurs. C’est une réfutation directe de l’idée selon laquelle les substituts aux bibliothèques open source pourraient être produits à bas coût par du vibe coding, ce qui réduirait l’attrait des projets open source existants »
      Je comprends le réflexe qui consiste à vouloir forker le code et l’internaliser, mais je doute de la viabilité de cette approche si cela signifie plus de code à gérer et plus de vulnérabilités à atténuer pour les équipes d’ingénierie
      [0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
    • Je ne comprends pas ce que signifie exactement « suspendre les contributions et l’usage de l’open source »
      On ne peut quand même pas arrêter Linux/Kubernetes/Chrome (y compris Edge)/presque tous les langages de programmation/nginx, etc., donc je me pose la question