- Les attaques de la chaîne d’approvisionnement consistent à faire entrer des mises à jour malveillantes dans le code open source, et Obsidian utilise pour les réduire au minimum une stratégie qui consiste à réduire les dépendances externes elles-mêmes
- L’application implémente directement la plupart de ses fonctionnalités ou, si nécessaire, inclut et gère du code forké dans sa propre base de code
- Pour les grandes bibliothèques indispensables (
pdf.js, Mermaid, MathJax, etc.), la sécurité est assurée via un gel des versions, et les mises à jour ne sont effectuées avec prudence qu’en présence de correctifs de sécurité
- Toutes les dépendances sont figées via un lockfile, et les scripts
postinstall ne sont pas exécutés, ce qui bloque l’exécution de code arbitraire à l’installation
- Grâce à cette procédure de mise à jour prudente et à cette stratégie de temporisation, Obsidian peut réagir avant que des menaces potentielles ne soient détectées par la communauté
Qu’est-ce qu’une attaque de la chaîne d’approvisionnement ?
- Une attaque de la chaîne d’approvisionnement consiste à injecter des mises à jour malveillantes dans le code distribué au sein de l’écosystème open source
- Comme de nombreuses applications utilisent du code open source, une seule mise à jour malveillante peut avoir un effet en cascade sur plusieurs applications
- Obsidian réduit cette surface d’attaque grâce à une stratégie de minimisation des dépendances et conçoit ainsi l’application de manière plus sûre
Stratégie de minimisation des dépendances : Less is Safer
- Obsidian dépend d’un très petit nombre de bibliothèques externes par rapport aux autres applications de sa catégorie
- Les fonctionnalités principales (par ex. Bases, Canvas) sont développées en interne plutôt que via l’intégration de bibliothèques externes
- Cela permet d’obtenir un contrôle total sur le code exécuté
- Les petites fonctions utilitaires sont presque toujours développées directement par l’équipe
- Les modules de taille intermédiaire sont forkés et intégrés à la base de code lorsque la licence le permet
- Les grandes bibliothèques (
pdf.js, Mermaid, MathJax, etc.) sont intégrées en restant fixées sur des versions validées, avec des mises à niveau minimales uniquement lorsqu’un problème de sécurité important est découvert
- Toutes les modifications externes sont examinées en détail et soumises à une procédure de test rigoureuse
- Cette approche réduit aussi au minimum le nombre de sous-dépendances, ce qui diminue le risque primaire d’introduction de code malveillant
Ce qui est réellement inclus dans l’application
- Dans l’application réellement exécutée par l’utilisateur, seuls quelques paquets comme Electron, CodeMirror et
moment.js sont inclus
- Les autres outils de développement ne sont utilisés que lors du processus de build de l’application et ne sont pas livrés à l’utilisateur final
Gel des versions et gestion du lockfile
- Toutes les dépendances externes sont gérées via un version pinning strict et le commit du lockfile
- Cela garantit des installations toujours reproductibles et facilite le suivi des modifications
- La politique de non-exécution des scripts
postinstall bloque à la source toute possibilité d’exécution de code arbitraire pendant l’installation
Une procédure de mise à jour lente et prudente
- Lorsqu’une mise à niveau de dépendance est nécessaire, Obsidian applique une procédure de revue systématique comme suit
- examen minutieux du changelog ligne par ligne
- vérification des nouvelles sous-dépendances ajoutées dans la nouvelle version
- en cas de changements importants ou de facteurs de risque, vérification directe du diff avec la source upstream
- exécution de tests automatiques et manuels sur les parcours critiques et les principales plateformes
- commit du lockfile uniquement après validation de toutes ces étapes
- La plupart des dépendances n’ayant pas besoin d’être modifiées fréquemment, la fréquence des mises à jour est elle-même faible
- L’introduction de nouveau code externe est examinée et gérée au même niveau qu’une nouvelle dépendance existante adoptée
Une « marge temporelle » pour la stabilité : Time is a buffer
- Les différentes mises à niveau ne sont pas déployées immédiatement, mais retardées pendant une certaine période
- Pendant ce délai, la communauté open source et les chercheurs en sécurité peuvent détecter d’éventuelles versions malveillantes, ce qui crée une fenêtre de réaction préalable
- Au moment du déploiement effectif, il est donc plus probable que les problèmes aient déjà été identifiés, ce qui réduit efficacement le risque
Conclusion
- Une mesure de sécurité unique ne peut pas éliminer complètement le risque d’attaques de la chaîne d’approvisionnement
- Cependant, Obsidian réduit fortement ce risque en combinant minimisation des dépendances, graphe peu profond, gel des versions, interdiction de
postinstall et mises à jour lentes centrées sur la revue
- Ces procédures permettent aussi d’obtenir un délai bien plus important pour détecter les risques avant que le code n’arrive jusqu’aux utilisateurs
- L’approche globale d’Obsidian en matière de sécurité et l’historique de ses audits de sécurité sont disponibles sur la security page officielle
1 commentaires
Commentaires sur Hacker News
Beaucoup de commentaires semblent oublier que la plupart des utilisateurs d’Obsidian utilisent des plugins communautaires tiers ; en réalité, le modèle de sécurité des plugins d’Obsidian est très faible, puisque les plugins ont accès à tous les fichiers du vault. Si Obsidian avait intégré directement davantage de fonctionnalités, le risque de sécurité aurait été réduit ; sinon, il serait aussi possible d’améliorer la situation avec une architecture comparable à celle des extensions de navigateur, où les permissions utilisées par les plugins sont explicitement déclarées et les accès non autorisés bloqués. Tout cela offrirait une sécurité bien plus concrète aux utilisateurs que la logique consistant à dire qu’il y a « moins de dépendances tierces »
Autrefois, certaines figures du monde du logiciel parlaient de la manière dont des idées issues du game design se diffusaient vers les autres types de logiciels, mais on n’entend presque plus ce discours aujourd’hui. Si des vétérans de studios comme Blizzard écrivaient un livre détaillant le fonctionnement, les problèmes et le durcissement progressif du système de plugins de World of Warcraft pendant sa première décennie, cela serait d’une grande aide pour tout l’écosystème logiciel. Les systèmes de plugins de nombreux projets sont un mélange de bricolage fragile et de naïveté
Les plugins Obsidian peuvent accéder non seulement aux fichiers du vault, mais aussi à tous les fichiers de l’ordinateur. J’avais déjà signalé ce point sur Discord par le passé, mais cela avait été ignoré
Je vois cela un peu comme Arch Linux : même quand des ingénieurs gèrent eux-mêmes des logiciels via l’AUR, la sécurité reste difficile à maîtriser. Il est déraisonnable d’attendre des utilisateurs ordinaires qu’ils en portent la responsabilité
Je pense qu’un cas d’exfiltration de données finira par apparaître bientôt parmi les plugins Obsidian ; à ce moment-là, l’équipe introduira sans doute des garde-fous de sécurité. Il faudrait au minimum un système d’éditeurs certifiés
Je développe commercialement des plugins Obsidian, et j’aimerais qu’il existe un processus de revue plus exigeant pour les plugins au-dessus d’un certain niveau. Comme pour l’AUR d’Arch Linux, avoir à la fois un dépôt communautaire et un dépôt soumis à une revue plus stricte aiderait à améliorer la vitesse de validation des plugins et la sécurité
Il est dit que « les attaques de la supply chain consistent à glisser une mise à jour malveillante dans du code open source utilisé par de nombreuses applications », mais n’importe quel code source, pas seulement du FOSS, peut être visé par ce type d’attaque. L’idée que le FOSS serait forcément plus vulnérable est problématique
La politique consistant à « ne pas exécuter de scripts postinstall pendant l’installation » part d’une bonne intention, mais si le paquet est déjà compromis, l’absence de postinstall ne rend pas le code restant sûr pour autant. Si le paquet est sain, un postinstall peut aussi faciliter une installation légitime. En pratique, les incidents proviennent plus souvent de correctifs de vulnérabilités ordinaires que d’attaques de la supply chain, donc bloquer les mises à jour peut au contraire augmenter le risque
Aujourd’hui, l’analyse de sécurité se fait généralement après l’installation. Mieux vaut empêcher qu’on exécute quoi que ce soit pendant l’installation. J’aimerais voir davantage de fonctions de scan ou de restrictions au stade de l’installation à l’avenir. Certains outils commerciaux le proposent, mais ce n’est pas courant
Cela reste malgré tout utile pour protéger les machines de build : on n’a pas à s’inquiéter de voir des scripts arbitraires s’exécuter à travers des dizaines de dépendances
Le développeur est responsable de tout le code qu’il distribue aux utilisateurs ; ne pas épingler ses dépendances revient à « télécharger du code aléatoire depuis Internet et espérer que tout se passe bien »
Épingler les dépendances peut faire manquer ensuite des correctifs de sécurité ; c’est aussi un risque, donc il faut absolument disposer d’un système permettant de savoir quand de nouveaux correctifs de sécurité sont publiés. Il faut alors soit rétroporter le correctif, soit mettre à jour vers une nouvelle version
Même des dépendances épinglées embarquent elles-mêmes d’autres dépendances ; au final, on est toujours dans une logique de « télécharger du code aléatoire et espérer », surtout avec les applications basées sur Electron, qui traînent une quantité vraiment énorme de code
Parmi les conseils qu’on voit souvent récemment, il y a l’idée de ne pas mettre à jour ses dépendances même quand une patch release sort, et je ne comprends pas bien. Ne pas faire la mise à jour peut réduire le risque d’installer un malware, mais en général les patchs servent justement à améliorer la sécurité. Je me demande donc si ne pas appliquer les derniers correctifs est vraiment un choix judicieux
L’essentiel est de comprendre pourquoi on applique un patch et ce qu’il change. On n’a pas le temps de lire tout le code source, donc j’utilise les principaux outils et services comme Npm Audit pour consulter des résumés de vulnérabilités. J’adopte une stratégie consistant à retarder les mises à jour sauf nécessité absolue, car elles sont à la fois un vecteur d’attaque et une source majeure de bugs. En revanche, je vérifie régulièrement à quelles vulnérabilités je suis exposé. Si une faille concerne une fonctionnalité que je n’utilise pas, je peux repousser la mise à jour ; je n’applique immédiatement que les défauts vraiment critiques. La sécurité est un processus actif et continu, et la réponse doit varier selon le niveau de risque acceptable de l’organisation. La solution n’est ni « toujours mettre à jour » ni « ne jamais mettre à jour »
En ce moment, chaque mise à jour de Z-WaveJS UI entraîne une nouvelle salve de mises à jour de dépendances. À cause de ce schéma frustrant, je vérifie tout moi-même. Aujourd’hui, tout le monde dépend de dépendances, donc « il n’y a pas de fin », et un simple auto-update peut être risqué
Il existe toujours un risque d’amélioration ou de régression lors d’une mise à jour, et ce risque est bien plus élevé dans l’écosystème npm, auquel Obsidian appartient. npm nécessite une intervention humaine pour retirer les paquets malveillants, donc l’assainissement est lent. Retarder volontairement certaines mises à jour permet au moins de se défendre un peu
Récemment, la tendance est d’attendre un peu après une patch release avant de l’installer. De nos jours, les incidents sont souvent détectés en quelques heures. Plusieurs entreprises surveillent npm et en ont même fait un business de sécurité. pnpm peut être configuré pour n’installer que des paquets publiés depuis plus de X minutes ; j’attends personnellement au moins 24 heures réglage minimumreleaseage de pnpm
Il y a deux semaines, l’attaque subie par mon paquet visait justement une patch release. Ce n’était pas un script postinstall. Les scans automatisés la détectent rapidement, donc ce problème n’est plus tellement au premier plan aujourd’hui. Lorsqu’une vulnérabilité de paquet est découverte, les alertes arrivent immédiatement et la situation est claire. Utiliser des version ranges est ce qu’il y a de pire pour se défendre contre les attaques de la supply chain
J’ai du mal à être d’accord avec l’idée que le paquet ne serait pas si gros en ne comprenant que Electron, CodeMirror et moment.js. Electron est un logiciel d’une complexité énorme fondé sur des webviews, et moment.js a déjà de meilleures API de remplacement. Le niveau de gestion des dépendances d’Obsidian me semble plutôt relever d’un minimum syndical que d’une politique de sécurité particulièrement impressionnante. Cela dit, le fait qu’ils mènent régulièrement des audits de sécurité est positif
J’utilisais d’autres applications qu’Obsidian, mais je commence aussi à m’y intéresser. Le fait que ce soit une application Electron me gêne un peu : ça consomme beaucoup de ressources, ce n’est pas natif, et JavaScript m’inspire toujours une certaine inquiétude. Je me demande si je ne suis pas simplement trop old school
JavaScript est un langage très sûr. Les navigateurs web sont un exemple réussi d’exécution sûre de JavaScript à l’échelle mondiale : chaque site ne peut pas lire les données des autres. Electron isole lui aussi JavaScript dans le moteur v8. Tant qu’on évite d’exécuter du code fourni par l’utilisateur, c’est très sûr. Le problème des attaques de la supply chain vient de npm lui-même, pas du langage JS ; c’est à npm d’imposer des politiques de sécurité plus strictes lors de la publication des paquets
Quel que soit le critère retenu, JavaScript est l’un des langages les plus utilisés au monde. Il tourne sur pratiquement tous les ordinateurs et smartphones, donc il est logique que des problèmes de sécurité y soient découverts plus souvent. Il n’existe pas de preuve qu’une application native soit plus sûre pour autant
Les applications Electron ne sont pas un problème en soi : GitHub, VS Code, Slack, Discord et Postman reposent tous sur Electron. J’ai souvent envie de demander : quelles tâches faites-vous donc dans une appli de prise de notes Markdown pour que les performances deviennent vraiment un problème ? On finirait presque par se demander si certains consultent leurs notes en texte seul via le navigateur Lynx sur un très vieux portable
Je n’aime pas tellement Electron non plus (c’est pour ça que j’aime bien Tauri), mais Obsidian lui-même est excellent et il n’y a pas de raison de l’écarter uniquement à cause d’Electron. Je le recommande aussi pour l’utiliser comme base de connaissances personnelle en l’intégrant avec MCP
Electron est effectivement lourd. Sur PC ce n’est pas vraiment un souci, mais sur mobile, quand on accumule des milliers de notes, le démarrage de l’application devient lent même sans plugin. Les utilisateurs contournent cela avec des plugins ou des applis dédiées à la capture rapide, mais on aimerait quand même un Obsidian natif plus léger
Obsidian repose sur Electron, et cela implique par nature un certain poids ainsi qu’un risque accru de vulnérabilités de sécurité
J’utilise Emacs et Org-Roam dans une VM sans connexion réseau (un Qube sous Qubes OS), mais je ne peux pas non plus auditer moi-même tout le code exécuté dans Emacs
Si l’on veut une application native et réduire davantage le risque lié à la supply chain, Zim Wiki, basé sur GTK et empaqueté dans les principales distributions Linux, peut être une alternative aller à Zim Wiki