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