Cal.com passe de l’open source au closed source face aux menaces de sécurité liées à l’IA

• Après 5 ans d’exploitation en open source, Cal.com a décidé de passer au closed source en raison de la hausse des menaces de sécurité basées sur l’IA
• Nous sommes entrés dans une ère où l’IA analyse automatiquement les bases de code pour y trouver des vulnérabilités, ce qui fait du code public un indice direct pour les attaquants
• L’entreprise a choisi de privilégier le second terme du dilemme entre maintien de l’open source et risque sécuritaire afin de protéger les données des clients
• Pour préserver l’esprit open source, le projet Cal.diy est publié sous licence MIT, avec une version auto-hébergée destinée à la communauté
• À mesure que l’IA progresse à une vitesse qui dépasse les dispositifs de sécurité existants, Cal.com affirme vouloir revenir à l’open source une fois la sécurité stabilisée

---

La décision de Cal.com d’abandonner l’open source et les menaces de sécurité liées à l’IA

• Cal.com fonctionnait en open source depuis 5 ans, mais a décidé de passer au closed source en raison de la forte augmentation des menaces de sécurité basées sur l’IA
  • La protection des données clients est devenue la priorité absolue, et l’entreprise estime qu’il n’est plus sûr de maintenir l’open source
  • Elle précise que « ce n’était pas une décision facile »
• Par le passé, exploiter les vulnérabilités d’une application demandait du temps et des efforts à des hackers expérimentés, mais nous sommes désormais dans une ère où l’IA scanne automatiquement les bases de code pour trouver des failles
  • Le code open source est décrit comme « l’équivalent de fournir le plan d’un coffre-fort aux attaquants »
  • À mesure que des startups de la sécurité IA commercialisent ces capacités, elles détectent des vulnérabilités différentes, rendant difficile l’établissement d’un référentiel de sécurité unique et fiable
• Cal.com explique avoir dû choisir entre deux options
  • maintenir l’open source tout en acceptant un risque pour les données clients, ou
  • passer au closed source pour réduire ce risque
  • Même si ce n’est pas une solution parfaite, l’entreprise considère qu’il s’agit d’une décision inévitable pour protéger les utilisateurs
• Pour faire perdurer l’esprit open source, un projet distinct nommé Cal.diy a été publié sous licence MIT
  • Cal.diy est une version ouverte pour les développeurs et les passionnés, une version communautaire auto-hébergeable
  • Le code de base du service principal a été fortement modifié dans ses structures clés, notamment l’authentification et le traitement des données, et se trouve techniquement séparé de Cal.diy
• L’IA transforme rapidement l’environnement de sécurité, et l’article cite aussi un cas où l’IA a trouvé en quelques heures une vulnérabilité vieille de 27 ans dans le noyau BSD et a généré un exploit
  • Cette vitesse et cette précision dépassent les capacités des dispositifs de réponse à la sécurité traditionnels
  • Cal.com affirme prendre toutes les mesures possibles pour protéger ses clients, ses applications et ses données sensibles, et exprime sa volonté de revenir à l’open source lorsque l’environnement de sécurité sera stabilisé

Orientation à venir et message

• Pour l’instant, la réduction des risques de sécurité et la protection des utilisateurs sont les priorités absolues
• La relation avec la communauté open source sera maintenue via Cal.diy
• À long terme, l’entreprise laisse ouverte la possibilité d’un retour à l’open source selon l’évolution de l’environnement de sécurité
• Cette décision montre que la réalité de la sécurité à l’ère de l’IA a désormais un impact direct sur les modèles de distribution logicielle

[GN⁺]

Réactions sur Hacker News

• Drew Breunig est arrivé hier à la conclusion inverse dans ce billet
  Maintenant que les failles de sécurité sont devenues une ressource qu’on peut trouver avec des tokens, l’open source a au contraire encore plus de valeur
  En open source, plusieurs projets peuvent mutualiser le coût des audits, alors qu’en closed source il faut trouver toutes les vulnérabilités seul

  • Le billet a été reposté ici. Son titre est Cybersecurity looks like proof of work now
  • La vraie raison semble plutôt être d’empêcher l’IA de blanchir le copyright du produit. La sécurité donne l’impression de servir de prétexte
  • Cette conclusion paraît plus convaincante. Mythos n’existe que depuis quelques semaines, donc changer de principes aussi vite est étrange. Il y avait sans doute des raisons business, et maintenant ils semblent avoir trouvé une justification plus facile à vendre au public
  • C’est aussi une conclusion économiquement cohérente. Au final, il faut soit créer assez de valeur pour absorber le coût des tokens, soit réduire l’intérêt économique de la découverte de vulnérabilités
    C’est possible en réduisant le périmètre de déploiement ou en abaissant les privilèges système.
    À l’avenir, cela pourrait évoluer vers un modèle « open specs + génération de code par modèle ». La sécurité et la gouvernance se feraient alors au niveau de la couche modèle
  • Dire qu’« il faut dépenser plus de tokens que l’attaquant pour durcir le système » semble étrange. Si le logiciel est stable, la surface d’attaque diminue, et Mythos ne produit pas de nouvelles vulnérabilités. Les défenseurs devraient avoir l’avantage sur le plan des tokens

• Je dirige le projet Thunderbird. Notre outil de planification Thunderbird Appointment restera toujours open source
  Invitation à le construire ensemble via le dépôt GitHub. Ils comptent aider à en faire une alternative à Cal.com

  • Ce serait bien d’ajouter des captures d’écran dans le README ou sur l’écran avant connexion. L’outil a l’air bien, mais je me demande combien coûte la version hébergée
  • Mais sur un vieux laptop Linux, Thunderbird est trop lourd. Il faudrait aussi penser aux utilisateurs sur petites configs. Demande de garder un Internet utilisable à une échelle raisonnable
  • Je suis allé sur le site, j’ai saisi mon e-mail, j’ai été envoyé sur une liste d’attente, puis au final mon e-mail a été bloqué. L’expérience utilisateur n’était pas terrible
  • En réponse au « construisons-le ensemble », quelqu’un a plaisanté en demandant : « alors, il faut un appointment ? »
  • Il y a aussi eu des réactions positives disant que cela semblait être une bonne alternative

• Si les LLM trouvent si bien les vulnérabilités dans le code, il suffit peut-être de lancer un pentest LLM interne avant chaque release, non ?
  On a l’impression que la loi de Linus (lien) devient enfin réelle

  • Mais après la release, les attaquants peuvent analyser le code avec un temps illimité et des LLM de plus en plus intelligents.
    Pour se défendre, il faut faire à l’avance à chaque release tout ce que les attaquants pourraient faire
  • À mesure que les LLM progressent, la maintenance du FOSS voit ses coûts en temps et en main-d’œuvre exploser.
    Les issues et PR de mauvaise qualité générés par l’IA augmentent, ce qui réduit l’intérêt de maintenir de l’open source.
    Ce type de bascule pourrait devenir plus fréquent quand des produits commerciaux reposent sur un cœur FOSS
  • En closed source, on peut utiliser les LLM en interne pour renforcer la sécurité.
    Mais on peut aussi comprendre l’idée de fermer pour ne pas laisser de possibilités d’attaque ouvertes vers l’extérieur
  • Dans un environnement avec des commits fréquents, il faut rescanner toute la codebase avec un LLM à chaque fois, donc le coût explose.
    Même des plateformes comme GitHub ont déjà des coûts élevés en analyse statique
  • Au final, certains estiment qu’il vaut mieux écrire un code simple et faire aussi des tests de sécurité LLM au niveau du compilateur

• Cette décision ressemble davantage à un choix business qu’à un sujet de sécurité.
  Grâce à l’IA, l’auto-hébergement devient plus facile, ce qui réduit les revenus d’hébergement payant des projets open source

  • Les gens utilisent des LLM pour implémenter eux-mêmes des « fonctionnalités pro » ou trouver des points d’extension. La sécurité n’est qu’un habillage
  • Accuser l’IA est un prétexte. L’IA a déjà appris à partir du code. En combinant algorithmes génétiques + fuzzing, on apprend bien plus vite qu’un humain
  • En ce moment, on met tout sur le dos de l’IA. Les réductions d’effectifs, l’arrêt de produits, la fermeture du code source, tout serait à cause de l’IA
  • Le produit est déjà en train de devenir commoditisé, comme l’outil de réservation de Google Workspace
  • Au final, certains parlent carrément de « sellout »

• En tant que client potentiel, je suis déçu par la décision de Cal.com.
  L’open source peut inspirer confiance grâce à un SSDLC transparent, alors qu’en closed source on n’a d’autre choix que de faire confiance au fournisseur
  Je ne suis pas d’accord avec l’argument de Drew Breunig. Le nombre de bugs est fini, et si un modèle assez puissant scanne régulièrement le code, la probabilité de vulnérabilités restantes chute fortement

• « Si l’IA peut scanner le code open source ? » → alors il suffit de corriger les bugs.
  Cette logique n’est pas du tout convaincante

• Dire « on ferme parce que l’IA a accès au code » n’est qu’un prétexte

  • La vraie raison n’est ni l’IA ni la sécurité, mais le fait que les projets clones sont devenus trop nombreux et ont réduit les revenus

• Ce genre de décision finit par ressembler à de la sécurité par l’obscurité (Security through obscurity).
  Difficile de comprendre depuis quand c’est devenu le bon modèle

  • L’obscurité n’est valable que comme moyen de dissuasion secondaire, pas comme défense principale
  • Réduire la surface d’attaque n’est pas de l’obscurité, c’est une stratégie de minimisation des vecteurs d’attaque
  • Mais certains estiment quand même que c’est mieux qu’une « sécurité sans obscurité »
  • L’un des cofondateurs a déclaré qu’« un ado de 16 ans du voisinage peut pirater ça en 15 minutes pour 100 dollars »
  • Ils semblent avoir oublié pourquoi le principe « ne pas faire reposer la sécurité sur l’obscurité » est apparu.
    Ce n’est pas parce que les générations précédentes étaient stupides, mais parce que c’était une approche séduisante en apparence qui a échoué

• Quand Cal.com dit « nous croyions en l’open source », cela sonne creux.
  Si c’était sincère, ils n’auraient pas sorti ce prétexte sans substance

• C’était déjà un prétexte possible avant l’IA.
  Cela ressemble surtout à une tentative de protéger les revenus d’un produit principal insuffisamment différencié.
  Au final, ce n’est qu’une mesure de protection du chiffre d’affaires