Lever le voile sur les cybervulnérabilités dans les chaînes d'approvisionnement gouvernementales

Une version de cet article a été publiée dans TechCrunch. Il a été mis à jour et syndiqué ici.

‍

Comme si nous n'avions pas eu assez de perturbations durant cette année que l'on ne saurait nommer, 2021 a commencé par un choc retentissant pour le gouvernement américain, sous la forme de l'une des pires violations de données jamais enregistrées. L'incident SolarWinds fut une attaque sophistiquée et dévastatrice menée par un État-nation, plongeant plusieurs ministères et grandes organisations dans la panique alors qu'ils tentaient de sécuriser leurs terminaux. Pratiquement tous les utilisateurs finaux du logiciel SolarWinds ont été compromis, rendant ainsi évidente la nécessité critique de la cybersécurité et de la défense dans les chaînes d'approvisionnement logicielles.

La cybersécurité est manifestement importante, mais que signifie-t-elle réellement dans le contexte des chaînes d'approvisionnement ?

L'état de la cybersécurité au sein d'une équipe de développement moyenne

Une quantité colossale de logiciels est produite chaque jour, représentant des milliards de lignes de code par an, et ce chiffre ne fait qu'augmenter avec la demande générée par nos modes de vie de plus en plus numériques. La population mondiale de développeurs devrait atteindre près de 29 millions d'ici 2024, et il n'existe actuellement aucune certification officielle pour évaluer et attester de leur capacité à coder de manière sécurisée. Cela ne signifie pas que chaque développeur produit ou réutilise du code non sécurisé, mais il existe indéniablement un risque persistant que des faiblesses de sécurité élémentaires soient introduites dans les logiciels auxquels nous confions nos données.

Les développeurs sont évalués sur leur capacité à créer des fonctionnalités et à livrer du code le plus rapidement possible. Dans la plupart des organisations, la sécurité n'a pas été un critère de réussite, mais cette mentalité commence à changer à mesure que les entreprises prennent conscience du rôle qu'ils peuvent jouer pour prévenir les failles de sécurité courantes dès les premières étapes de la création logicielle. Cependant, prise de conscience et mise en œuvre sont deux choses différentes ; comme la plupart des formations supérieures en développement omettent le contexte du codage sécurisé, c'est souvent à l'entreprise de combler cette lacune. Si le renforcement des compétences et le partage des connaissances sont rares ou inadaptés, ils seront probablement inefficaces. Ainsi, le cycle des vulnérabilités récurrentes dues à un manque de formation perdure.

Il ne revient évidemment pas au développeur moyen de résoudre tous les problèmes de cybersécurité mondiaux ; après tout, les organisations embauchent ces professionnels de la sécurité très coûteux pour une bonne raison. Les experts en sécurité sont toutefois rares, et les développeurs peuvent certainement contribuer à réduire cette pression.

Mais où cela nous mène-t-il, nous et les fournisseurs créant des logiciels pour les infrastructures critiques et les organisations sensibles, en matière de prévention des cyberattaques dévastatrices ? Cela exigera, à tout le moins, un changement dans le statu quo des achats de logiciels.

Les pièges qui entravent la sécurité de la chaîne d'approvisionnement logicielle

Le vieil adage selon lequel une chaîne n'est aussi forte que son maillon le plus faible est malheureusement tout aussi vrai pour l'approvisionnement logiciel. Peu importe que votre entreprise adopte des pratiques de sécurité renforcées, investisse dans la montée en compétences de ses développeurs et s'oriente vers un environnement DevSecOps fonctionnel (où chacun partage la responsabilité de la sécurité du code) : si vous utilisez le logiciel d'un fournisseur présentant des failles, vous les hériterez dans votre écosystème et en subirez les conséquences.

Certes, l'équipe de sécurité devrait aider à évaluer la sûreté des ajouts tiers à la pile technologique, mais les décisions peuvent être dictées par des besoins métier avec peu d'alternatives. À ce stade, c'est un exercice de confiance. Le fournisseur se soucie-t-il de la sécurité autant que votre entreprise ? Peut-il évaluer les risques comme vous seul pourriez les comprendre, ainsi que les actifs que vous devez protéger ?

La transparence est un facteur primordial pour évaluer la viabilité sécuritaire des logiciels tiers. Sont-ils transparents sur leurs propres pratiques de sécurité ? Ils devraient être fiers de leur approche en matière de protection des données, et cela devrait être une priorité absolue. Si aucune pratique de sécurité n'est publiée ou si aucune information n'est disponible, il est fort probable que la sécurité ne soit pas leur priorité. Le fournisseur doit pouvoir répondre aux questions techniques, et des certifications indépendantes comme ISO27001 et SOC2 ne seraient pas de trop. De plus, si vous ne pouvez pas « regarder sous le capot » et analyser les vulnérabilités dans le cadre de votre propre diligence raisonnable, oubliez.

Avec une demande imposant une mise en œuvre si rapide des besoins logiciels, surtout si le code d'un fournisseur est intégré à des systèmes existants pour effectuer des actions dans un nouveau contexte, le fournisseur comme l'acheteur doivent être au sommet de leur art, et tous deux devraient s'appuyer sur leurs développeurs pour détecter les bugs et failles de sécurité courants avant la mise en production. Des centaines, voire des milliers de dépendances pourraient être compromises si un nouvel élément est ajouté à la toile d'araignée des solutions technologiques existantes, et une seule défaillance peut mener à un effondrement catastrophique.

Quelle est donc la solution ? Tout coder en interne, à partir de zéro ? En 1998, cela aurait pu avoir du sens. Cependant, tout comme nous ne demandons plus à un annuaire où se trouve la station de lavage la plus proche, nous devons mettre en place des garde-fous réalistes adaptés au contexte actuel.

Il n'existe toujours pas de solution miracle, mais des alternatives existent

Pour les acheteurs, l'évaluation de la sécurité des logiciels et des pratiques de développement des fournisseurs doit être une priorité du programme global de sécurité et du plan d'atténuation des risques. Posez des questions sur leurs certifications, leurs pratiques et la réputation de leurs développeurs en matière de sécurité.

Les fournisseurs (et toute entreprise créant des logiciels) doivent être prêts à démontrer que la sécurité est une priorité et se concentrer sur la montée en compétences. Les développeurs formés à la sécurité sont très demandés et, avec les bons outils et le bon soutien, ils peuvent être formés au sein de votre équipe actuelle et habilités à se défendre contre les attaques résultant de vulnérabilités courantes. Mais ne leur imposez pas n'importe quelle formation. Donnez-leur le temps de s'épanouir avec des outils de sécurité complémentaires à leurs flux de travail. Facilitez-leur la tâche et regardez ces bugs agaçants diminuer dans le code qui alimente votre activité.

En fin de compte, tout risque logiciel est immédiatement exacerbé s'il fait partie de la chaîne d'approvisionnement, affectant tous les utilisateurs et les systèmes utilisant des composants vulnérables. Si les fournisseurs ne prennent pas la sécurité aussi au sérieux que les entreprises qui déploient leurs logiciels - ou si les deux parties manquent de rigueur dans leur programme de sécurité - alors des attaques de chaîne d'approvisionnement plus dévastatrices et étendues, comme SolarWinds, deviendront inévitablement la norme. C'est un problème critique pour tout le monde.