Attaques contre la chaîne d’approvisionnement logicielle représentent une menace de plus en plus préoccupante. Selon une récente étude de BlueVoyant, 97 % des entreprises interrogées ont été négativement touchées par une faille de sécurité dans leur chaîne d’approvisionnement, et 38 % déclarent n’avoir aucun moyen de savoir si un fournisseur tiers présente des problèmes potentiels liés à la cybersécurité d’un fournisseur tiers.
Ankur Shah, vice-président senior chargé des produits Prisma Cloud chez Palo Alto Networks, a déclaré à eSecurity Planet que les menaces très médiatisées comme les vulnérabilités Log4j et Spring4Shell sont restées au premier plan des préoccupations — et qu’elles deviennent de plus en plus fréquentes, pour trois raisons principales, selon Shah.
3 causes de l’aggravation des menaces contre la chaîne d’approvisionnement
Premièrement, a expliqué Shah, il y a quelques années, lorsqu’il était développeur, rien de ce qu’il concevait n’était déployé avant d’avoir fait l’objet de tests approfondis de sécurité et d’assurance qualité. « Aujourd’hui, les développeurs peuvent pratiquement, depuis leur IDE, cliquer sur un bouton et faire tester, sécuriser et déployer l’ensemble en quelques minutes », a-t-il déclaré. « Les clients déploient des applications toutes les heures, tous les jours, quand ils le souhaitent, et les entreprises adorent cela. C’est une tendance qui s’auto-entretient et elle ne va pas changer : les développeurs ne vont pas ralentir pour des raisons de qualité ou de sécurité. »
Deuxièmement, le nombre de développeurs a rapidement dépassé celui des professionnels de la sécurité, rendant quasiment impossible pour ces derniers de suivre le rythme. « Tout le monde est développeur aujourd’hui », a déclaré Shah. « Il y a plus de 33 millions de développeurs, contre 3 millions de professionnels de la sécurité. C’est donc un combat que la sécurité ne peut pas gagner. »
Troisièmement, a expliqué Shah, lorsqu’il était développeur, son code représentait généralement environ 80 % du total, contre 20 % pour les bibliothèques open source — alors qu’aujourd’hui, c’est souvent l’inverse. « Téléchargez du code open source depuis hack me dot com : il fait désormais partie de votre image de conteneur, quelle qu’elle soit — et ensuite, qui sait ? Il est déployé dans des centaines de milliers de workloads et c’est le chaos », a-t-il déclaré.
Et cela ne vient pas forcément d’un site web quelconque : Log4j n’est pas un simple composant fourni par un petit éditeur tiers inconnu. « Il s’agit d’Apache », a déclaré Shah. « Leur notoriété repose sur le fait qu’ils sont l’Open Source 101 — un fournisseur de confiance, un composant de confiance — et pourtant quelqu’un a découvert une vulnérabilité assez facile à exploiter. »
À lire également : Une nouvelle initiative de sécurité open source ciblant les attaques contre la chaîne d’approvisionnement
4 étapes pour sécuriser le code
Selon Shah, les entreprises doivent sécuriser l’ensemble du cycle de vie des applications, du code à l’exécution, ce qui implique de surveiller activement la sécurité à au moins quatre étapes clés du processus.
La première étape intervient pendant le développement : il faut s’assurer que tout code open source utilisé est sûr. « Lorsque les développeurs écrivent leur code dans l’IDE, s’ils disent simplement : “Importe ce composant open source”, ils devraient immédiatement voir apparaître la question suivante : “Êtes-vous sûr de vouloir faire cela ? Car ce composant open source présente une vulnérabilité connue” », a déclaré Shah.
Sensibiliser davantage les développeurs à ces problèmes est un bon début, a-t-il ajouté, même si chaque entreprise doit déterminer sa propre tolérance au risque. Une entreprise de technologie financière, un organisme de santé ou une administration devra probablement être plus prudente concernant les composants open source que les acteurs d’autres secteurs, qui peuvent rechercher un équilibre différent entre sécurité et rapidité de déploiement.
Le domaine suivant à prendre en compte est l’infrastructure as code. « Souvent, les acteurs malveillants exploitent les faiblesses de l’infrastructure — des groupes de sécurité trop permissifs, etc. — ; l’autre élément à sécuriser, en plus du code open source, est donc l’infrastructure as code », a déclaré Shah.
Il est tout aussi important de sécuriser le dépôt de code, troisième étape du processus de Shah. « Assurez-vous que votre VCS, votre dépôt Git, ne présente pas de faiblesses — par exemple, est-il exposé à l’Internet public ? Dans le cas de Capital One, le dépôt de code était exposé et quelqu’un a pu l’exploiter — assurez-vous d’avoir une authentification multifacteur, que vous ne pouvez y accéder que via votre VPN, et qu’il n’est pas accessible depuis l’Internet public. »
Enfin, un contrôle supplémentaire doit être effectué avant le déploiement. « Analysez vos registres de conteneurs, analysez votre pipeline CI/CD, assurez-vous d’effectuer un contrôle supplémentaire à ce stade », a déclaré Shah. « Ensuite, l’étape finale consiste à passer en production. »
À lire également :
- Les meilleures solutions de sécurité des conteneurs
- Les meilleurs outils de débogage et de sécurisation du code
La défense en profondeur
Selon Shah, l’ensemble de ce processus vise à garantir une défense en profondeur. « Il ne suffit pas de réaliser une seule étape », a-t-il déclaré. « Vous effectuez ces contrôles et contrepoids de sécurité à chaque étape : au moment du codage, de la compilation, du déploiement et de l’exécution. Si vous faites cela, les risques d’erreur sont minimes. »
Grâce à des contrôles tout au long du processus, on aboutit, selon Shah, à une approche du code comparable au concept de jidoka de Toyota, qui permet à n’importe qui d’arrêter la chaîne de montage s’il détecte un défaut. « L’idée est que plus la voiture avance sur la chaîne de montage, plus le problème s’aggrave — il faut donc le corriger le plus tôt possible. Effectuez des contrôles qualité à chaque étape. »
Enfin, Shah estime que, pour de nombreuses entreprises, il vaut mieux envisager une solution de plateforme plutôt que d’assembler des solutions disparates. « Avoir davantage d’outils de sécurité ne vous rend pas plus sécurisé », a-t-il déclaré. « Cela vous rend moins sécurisé. En adoptant une approche basée sur une plateforme pour votre sécurité, vous bénéficiez d’une visibilité globale et n’avez pas à assembler une multitude d’éléments disparates. »
Pour aller plus loin :