L’open source n’est pas mort

• Cal.com a décidé de fermer l’accès à son code principal, invoquant la menace de détection de vulnérabilités par l’IA, et affirme que nous sommes entrés dans une époque où « la transparence équivaut à l’exposition »
• Strix est un projet open source qui développe des agents de sécurité IA autonomes et a collaboré avec Cal.com pour mettre en place une procédure de divulgation responsable des vulnérabilités
• Strix souligne que fermer le code n’est pas une solution aux menaces de sécurité liées à l’IA et que cela bloque au contraire les possibilités d’examen de bonne foi
• Les attaques par IA peuvent pénétrer en mode boîte noire sans accès au code, et une stratégie fermée reste vulnérable aux attaques automatisées
• La véritable réponse consiste à intégrer des défenses IA dans le processus de développement et à préserver la transparence et la collaboration de l’open source grâce à une validation automatisée continue

---

Le passage de Cal.com à un code fermé et le débat sur la sécurité de l’open source

• Cal.com a annoncé qu’il faisait passer sa base de code principale de l’open source à un modèle fermé
  • Son CEO, Bailey Pumfleet, a expliqué que l’IA peut désormais détecter automatiquement des vulnérabilités à grande échelle, au point d’ouvrir une époque où « la transparence équivaut à l’exposition »
  • Il a notamment avancé que l’IA est désormais capable d’effectuer du scan de code et de l’exploitation à un coût presque « nul »
• Strix est un projet open source qui développe des agents de sécurité IA autonomes et a récemment dépassé les 24k stars sur GitHub
  • Il traite plus de 15 milliards de tokens LLM par jour pour détecter des vulnérabilités logicielles
  • En collaboration avec Cal.com, il a mis en place une procédure de divulgation responsable des vulnérabilités via Strix, sans publier les détails des bugs qui n’ont pas encore été corrigés
  • Strix reconnaît que la décision de Cal.com découle d’une volonté de protéger les utilisateurs
• Mais Strix insiste : « fermer le code n’est pas une solution aux menaces de sécurité fondées sur l’IA »
  • Le projet reconnaît que l’IA transforme la sécurité en profondeur, tout en s’opposant à l’abandon de l’open source

Une IA en boîte noire peut aussi pénétrer du code fermé

• L’idée selon laquelle fermer le code empêcherait les attaquants de le lire ne correspond plus aux modèles d’attaque IA modernes
  • Cela pouvait fonctionner avec les anciens outils d’analyse statique, mais des agents IA autonomes peuvent désormais lancer des attaques même sans accès au code
• Des outils comme Strix sont spécialisés dans les tests boîte noire et boîte grise
  • Ils interagissent avec de vrais endpoints et réalisent des manipulations de l’état du navigateur, de l’analyse du trafic réseau et de la détection de vulnérabilités de logique métier
• Rendre le code privé ne fait que bloquer les possibilités de revue par des développeurs de bonne foi, tandis que la surface d’attaque exposée aux attaquants, comme les API et les webhooks, reste intacte

La stratégie de « sécurité par l’obscurité » est vulnérable aux attaques automatisées

• Un code fermé dépend des équipes de sécurité internes et de tests d’intrusion manuels périodiques
  • Mais les attaquants, eux, s’appuient sur des bots IA pouvant fonctionner sans interruption pour rechercher des vulnérabilités 24 h/24
• Cette approche suppose que les équipes internes peuvent trouver les failles plus vite que les attaques IA externes, ce qui est irréaliste dans les faits
• Par le passé déjà, la « sécurité par l’obscurité » (Security through obscurity) a montré ses limites, et à l’ère de l’IA, la vitesse de cet échec ne fera qu’augmenter de façon exponentielle

La vraie réponse : défendre l’IA avec l’IA

• Il est vrai que la vitesse du développement logiciel a dépassé celle des revues de sécurité humaines
  • Mais la solution n’est pas de cacher le code, elle consiste à intégrer des défenses IA dans le processus de développement
• Une validation continue pilotée par l’IA (continuous validation) est nécessaire
  • Lorsqu’un développeur ouvre une Pull Request, l’IA tente immédiatement une attaque
  • Lorsqu’une modification d’infrastructure survient, l’IA vérifie automatiquement la surface d’attaque
• Les tests de sécurité doivent être automatisés dans le pipeline CI/CD, avec une automatisation interne supérieure à celle des attaques automatisées

L’open source reste pertinent

• Le principe traditionnel selon lequel « avec suffisamment d’yeux, tous les bugs sont superficiels » peut s’être affaibli, mais l’open source lui-même n’est pas mort
• Strix maintient son approche open source avec la conviction que la transparence crée de la force
  • Les outils de sécurité de nouvelle génération doivent être aussi accessibles et ouverts que les outils d’attaque
• Cacher le code ne permet pas d’arrêter les hackers pilotés par l’IA, mais donner aux développeurs des agents de sécurité autonomes augmente les chances de défense
• Strix propose un essai gratuit de ses tests de sécurité continus fondés sur l’IA

[GN⁺]

Avis Hacker News

• Je maintiens un projet open source, et ces derniers mois le nombre de signalements de vulnérabilités de sécurité a explosé
  La plupart concernaient des cas mineurs, mais il y avait aussi de vrais problèmes, et je les ai tous corrigés
  Les logiciels propriétaires ne reçoivent peut-être pas ce genre de signalements, mais il y a un risque d’exploitation via l’IA
  Donc je suis totalement d’accord avec le message de cet article

  • Même si c’est fermé, on peut quand même lancer des scanners IA en interne, non ?
    C’est seulement fermé vis-à-vis de l’extérieur, pas pour les développeurs internes
  • On ne recevra pas de rapports venant de scanners automatisés de dépôts, mais les programmes de bug bounty continuent quand même à générer beaucoup de signalements
    En revanche, avec l’arrivée des outils d’IA, il y a aussi le problème des débutants qui soumettent des faux rapports hallucinés par l’IA
    Les entreprises propriétaires devraient elles aussi mener volontairement des audits de sécurité
  • Du point de vue d’un attaquant, il est bien plus rentable d’utiliser l’IA pour attaquer des dépôts open source
    Je comprends que Cal.com soit passé au propriétaire, mais au final ça ressemble surtout au marketing de Strix
    Plus une entreprise open source reste ouverte, plus elle y perd
  • J’ai moi aussi mis en place des tests d’intrusion automatiques nocturnes sur mon projet open source
    Je pense que publier régulièrement ce type de rapports pourrait permettre de prouver le niveau de confiance en matière de sécurité
    Cela dit, sur les projets existants, il y a déjà un stock de problèmes mineurs et modérés, donc leur résolution risque de prendre du temps
  • Dans notre entreprise, nous combinons en interne scanners IA et tests d’intrusion manuels
    Autrement dit, nous exploitons à la fois la détection de vulnérabilités par IA et une défense multicouche tout en gardant le code privé

• L’argument du CEO selon lequel « l’IA détecte automatiquement les vulnérabilités à grande échelle » ressemble à une excuse
  La vraie raison me semble plutôt être qu’il est difficile de bâtir un modèle économique durable avec l’open source

  • D’accord. Je comprends qu’on passe au propriétaire pour assurer la rentabilité, mais l’excuse sécuritaire n’est pas honnête
  • Nous avons gardé pendant 5 ans une croissance de 300 % et de la rentabilité en open source
    Passer au propriétaire serait au contraire mauvais pour le business, mais nous avons jugé que la protection des données clients était plus importante
  • En ce moment, on a tendance à tout mettre sur le dos de l’IA
    Que ce soit pour des réductions d’effectifs ou des changements de licence, l’excuse « c’est à cause de l’IA » est pratique
  • Désormais, il est trop facile de ne pas utiliser directement le code open source et de n’en extraire que les morceaux nécessaires pour les recomposer
    Des sites comme npmjs pourraient bientôt devenir de simples sites de référence
  • Laisser « cal.diy » ouvert et fermer la partie entreprise, c’est une stratégie open core tout à fait classique
    Rejeter la faute sur les scanners IA n’est qu’un habillage RP

• Cet article ressemble vraiment à un manuel de content marketing

  1. attirer l’attention avec un titre percutant
  2. gagner la sympathie du lecteur en montrant de l’empathie pour la position de Cal.com
  3. proposer une solution sérieuse au problème
  4. puis, au final, enchaîner naturellement sur la promotion de son propre produit
     C’est un cas où sincérité et marketing sont habilement mêlés
  • C’est aussi comme ça que je l’ai lu. L’entreprise qui a rédigé l’article vend un service de scanning de vulnérabilités par IA, donc au fond c’est une incitation à s’inscrire
    Strix a bien scanné le code de Cal.com, mais a raté beaucoup de vulnérabilités
    Aucune plateforme n’est parfaite, et les scanners IA seuls ne suffisent pas
  • Je trouve dommage que cet article ait reçu autant de votes positifs. Sa densité de contenu tient en un seul commentaire
  • Personnellement, je n’utilise pas l’IA. En ce moment, il est simplement facile sur le plan marketing de surfer sur la vague IA, mais je doute qu’il y ait une vraie valeur derrière

• La « security through obscurity » n’est un problème que lorsqu’elle est utilisée seule
  En tant que couche de dissuasion qui augmente le coût pour les attaquants, c’est une stratégie valable
  Au final, la sécurité est une bataille de ressources : tout dépend de qui peut en mobiliser le plus
  L’IA est seulement plus efficace que les humains, mais le calcul fondamental entre ouvert et fermé ne change pas

• Je me demande si Cal.com se soucie vraiment de la sécurité, ou si ce n’est qu’un prétexte pour masquer les difficultés du SaaS open source
  Cet argument a déjà été démontré faux il y a plusieurs décennies

• Je ne crois pas que la « sécurité par l’obscurité » soit la vraie raison
  Ils ont simplement pensé qu’en fermant l’open source, ils gagneraient plus d’argent

  • Exactement. C’est leur produit, ils en font ce qu’ils veulent
    Un des aspects les plus laids de l’open source, c’est que les gens considèrent le travail gratuit comme acquis
    Au lieu de remercier les développeurs qui ont travaillé gratuitement pendant des années, ils se fâchent parce qu’ils ne continuent pas à le faire
    Alors qu’eux-mêmes n’accepteraient pas de travailler sans salaire

• À lire l’article, on dirait que Cal.com a subi des tests de vulnérabilité par bots de red team
  Les bugs ayant été trouvés trop vite, il est possible que le CEO ait trouvé le coût des corrections trop lourd et ait fermé le code
  Cela ressemble presque à une déclaration publique disant que « le code de Cal.com contient beaucoup de vulnérabilités »

  • Ou alors le scanner produisait trop de faux positifs
    En l’ajustant, on risquait de rater les vraies vulnérabilités, et au final le coût de validation augmentait
    Dans l’open source, ces signalements sont publics et peuvent nuire à la réputation, alors que ce n’est pas le cas dans le propriétaire
    C’est peut-être pour cela qu’ils sont passés au propriétaire

• Le vrai risque, ce n’est pas la détection de vulnérabilités, mais la capacité des LLM à réécrire des projets open source dans d’autres langages pour contourner les licences

  • En théorie, la même chose est possible sur des projets propriétaires, mais il y a beaucoup plus de contraintes
  • En pratique, cela arrive souvent. L’IA régénère presque le même code pour créer des projets clones
    Juridiquement, c’est flou. Si un humain étudie puis réécrit, ça passe, mais quand l’IA le fait, cela ressemble en pratique à un copier-coller complexe
    On ne sait pas clairement comment la licence s’appliquerait dans ce cas
  • Beaucoup de licences open source autorisent les forks et la revente
    Publier le code ne suffit pas à faire un business, la capacité d’exploitation compte davantage

• Je suis d’accord avec l’idée que les tests de sécurité doivent être automatisés dans le pipeline CI/CD
  Mais cela ne prouve pas pour autant la nécessité de l’open source

• L’équilibre de l’open source est rompu depuis longtemps
  Le fait que des entreprises utilisent du code open source pour créer des produits payants sans contribuer en retour existe depuis très longtemps
  PHP, utilisé dans le monde entier mais sous-financé, en est un bon exemple