Nous ne développons pas. Avons-nous quand même besoin de sécurité du code ?
La question la plus fréquente des PME, avec une réponse honnête : qui n'utilise que des logiciels exploités par d'autres n'a rien à analyser. Qui héberge lui-même des applications achetées a des dépendances et des configurations qui vieillissent. Et qui a des scripts, des intégrations et de petits outils dans un dépôt développe depuis longtemps, sans le nommer ainsi.
Une question légitime
Elle revient dans presque chaque premier entretien : nous construisons des machines, nous transportons du fret, nous sommes un cabinet. Nous achetons des logiciels, nous n'en écrivons pas. À quoi bon la sécurité du code ? La question mérite une réponse précise, pas une réponse commerciale. Notre page consacrée à la sécurité du code en donne la version courte. Voici la version longue, en trois paliers, parce que la vérité dépend de ce qui tourne réellement dans l'entreprise, pas de l'idée qu'elle se fait d'elle-même.
Palier un : tout tourne chez des tiers
Si chaque application de l'entreprise est un service exploité par un fournisseur, comptabilité, messagerie, CRM et stockage de fichiers depuis le cloud, sans qu'il existe nulle part un serveur ou un dépôt en propre, alors la réponse est simplement non. Il n'y a pas de code que nous pourrions connecter, et nous n'en inventerons pas. La sécurité de ces services incombe à leurs fournisseurs, et les risques de l'entreprise sont ailleurs : dans des identifiants déjà en circulation, dans des comptes encore utilisés après une fuite.
Pour ce cas, notre surveillance du dark web est le bon point d'entrée, et nous le disons en entretien avant qu'une offre ne soit rédigée. Une analyse de code pour une entreprise sans code serait du chiffre d'affaires sans utilité.
Palier deux : des logiciels achetés sur vos propres serveurs
Le cas le plus fréquent dans les PME est différent. L'ERP tourne sur le serveur de l'entreprise. Le système de gestion des stocks a été introduit il y a six ans et adapté deux fois depuis. La boutique en ligne est un produit standard avec quelques extensions. Personne dans la maison n'en a écrit une ligne, et pourtant chacun de ces systèmes se compose d'éléments qui vieillissent : des bibliothèques open source dont des failles deviennent publiques, et des configurations aux réglages par défaut que plus personne ne vérifie.
C'est précisément la partie de l'analyse qui fonctionne sans développement interne. Le passage complet compare chaque dépendance aux vulnérabilités connues et vérifie la configuration pour ses réglages par défaut non sécurisés. Que l'application ait été achetée ou écrite ne change rien pour la bibliothèque qu'elle contient. Et au titre de l'article 30 du BSIG, exploiter des systèmes achetés relève aussi de la maintenance dont les vulnérabilités doivent être gérées ; les preuves que cela produit sont décrites dans notre article sur la constitution des preuves NIS2 au quotidien.
Palier trois : le code que personne n'appelle du code
Presque chaque entreprise qui dit ne pas développer a un dépôt quelque part. Dedans : le script qui pousse la nuit les exports vers la comptabilité. L'intégration entre la boutique et l'entrepôt qu'un ancien collègue a construite. L'outil interne avec lequel les commerciaux génèrent les devis. Quelques automatisations, un connecteur, une extension pour l'ERP. C'est du développement, même si personne ne l'a jamais nommé ainsi.
Et ces morceaux ont une propriété qui les rend plus dangereux que l'ERP lui-même : ils ont rarement été écrits avec la sécurité en tête. D'expérience, c'est exactement là que se trouvent les identifiants codés en dur, parce que le script ne tourne qu'en interne, et les entrées non contrôlées, parce que seul un collègue s'en sert. Le contrôle immédiat trouve les deux dès qu'ils se trouvent dans un dépôt connecté. Pourquoi un secret validé une fois doit être renouvelé, nous l'expliquons dans notre article sur les secrets codés en dur.
Comment trouver son propre palier
La question à se poser n'est pas de savoir si l'on emploie des développeurs. Elle est : y a-t-il dans l'entreprise un serveur sur lequel tourne une application que nous avons installée nous-mêmes ? Et y a-t-il quelque part un dépôt, un dossier de scripts ou un outil que quelqu'un a construit pour nous ? Deux non signifient le palier un. Un oui signifie que l'analyse de code gratuite a quelque chose à examiner : connexion, analyse de l'existant, constat priorisé, dans votre propre environnement sur demande, sans engagement. Le constat dira ensuite honnêtement si cela en valait la peine.
Questions fréquentes
Nous n'utilisons que des services cloud. Que devrions-nous analyser ?
Rien. Sans dépôt en propre et sans application exploitée par vous-mêmes, il n'y a pas de code à connecter. Pour vous, la surveillance du dark web est le bon point d'entrée, parce que le risque se trouve dans les identifiants, pas dans le code.
Notre ERP a été livré par l'éditeur. Pourquoi l'analyser ?
Parce que l'éditeur ne met pas à jour les bibliothèques qu'il contient sur votre serveur et ne vérifie pas la configuration pour vous. Ces deux choses vieillissent, et ce sont exactement ces deux choses que vérifie le passage complet, sans que personne n'écrive une ligne.
Nos scripts sont purement internes. N'est-ce pas inoffensif ?
Interne est l'argument par lequel des identifiants finissent dans des scripts. Un attaquant qui est une fois dans le réseau lit d'abord les scripts internes, parce que c'est là que sont gardées les clés de tout le reste. Si les scripts se trouvent dans un dépôt, l'analyse les trouve.