- Développement
- Sécurité
Mettre la sécurité et la conformité au cœur du développement logiciel
8 décembre - 23
Pendant de nombreuses années, l'obstacle à la création de produits numériques n'a fait que s'aplanir. N'importe qui peut rédiger rapidement quelques lignes de code sur un serveur de fournisseur de services infonuagiques et se targuer de faire de la création d'applis, peu importe son niveau d'expertise et la qualité de ses processus (ou le manque de ceux-ci).
Cependant, les choses ont bien évolué depuis. Et elles ont évolué à grande vitesse depuis quelques années, surtout pour ce qui est de la sécurité et de la conformité des données (GDPR, Loi 25 au Québec, ISO 27001, SOC 2).
On s'attend désormais à ce que les logiciels soient 1) libres de failles de sécurité et 2) conformes aux diverses réglementations mises en place par les autorités et les établissements. L'influence de la sécurité ne constitue pas seulement une tendance, mais bien une transformation fondamentale de la façon dont on aborde le développement logiciel.
Comme une grande partie de nos vies dépend des plateformes numériques, les enjeux sont plus élevés que jamais. On peut rapidement perdre la confiance des utilisateur·trice·s à la suite d'une brèche de sécurité ou d'une violation de la conformité des données, tandis que les entreprises peuvent se voir infliger des amendes pour ne pas avoir respecté les réglementations.
Aujourd'hui, les développeurs et développeuses créent des logiciels à l'aide de langages de haut niveau, low-code, no-code ou avec un code généré par une IA. Dans cette situation, les équipes de développement peuvent disposer de connaissances moins approfondies pour éviter ces problèmes, haussant ainsi le risque d'insérer des failles ou des modèles non conformes dans les codebases. Par ailleurs, bien que les paradigmes de la technologie moderne comme la décentralisation et l'immutabilité présentent de nouveaux moyens de stocker et de distribuer les données, ils apportent leurs lots de préoccupations quant à la sécurité, à la confidentialité et à la conformité des données à long terme.
Dans un monde interconnecté en croissance constante, le nombre de points d'extrémité vulnérables aux attaques s'est accru de façon exponentielle. Les technologies font de plus en plus partie de la vie quotidienne, on les retrouve dans les maisons intelligentes et les véhicules connectés. Les conséquences potentielles des atteintes à la sécurité s'étendent donc bien au-delà des brèches de données et ont des implications réelles et tangibles, comme la sécurité et le bien-être. De plus, à mesure que la base d'utilisateurs·trices de produits numériques se diversifie, il existe un besoin croissant de veiller à ce que les logiciels ne soient pas uniquement sécurisés et conformes, mais également équitables et inclusifs pour tous et toutes, peu importe leur maîtrise de la technologie ou leur groupe démographique.
Quelles conséquences découlent de cette nouvelle réalité pour les équipes d'ingénierie?
Les équipes de développement qui auront du succès dans l'avenir seront celles qui ont cultivé une mentalité de « bien faire les choses ». Elles créeront des produits numériques en tenant compte de la sécurité, des données et de la confidentialité parce que c'est la chose à faire et non pas parce qu'elles doivent le faire.
Cela ne signifie pas qu'elles s'empêcheront d'utiliser les technologies de pointe (ex. IA, immutabilité, décentralisation, etc.) pour obtenir un avantage concurrentiel sur le plan de l'efficacité. Elles établiront un bon équilibre entre l'adoption rapide des nouvelles technologies et l'adaptation de leur usage à la bonne mentalité.
Cependant, ce n'est pas assez d'adopter la bonne mentalité. Les équipes devront s'assurer d'avoir les processus et outils nécessaires en place. Avertissement : ce sera comme une sonnerie d'alarme pour les organisations qui accordaient peu d'importance à la sécurité et aux préoccupations concernant les données.
Et il ne s'agit pas d'une action ponctuelle, car de nouvelles failles de sécurité sont découvertes toutes les semaines et de nouvelles spécifications de conformité entrent régulièrement en vigueur. Les entreprises devront donc s'assurer que le code qu'elles rédigent et envoient demeure sécurisé et conforme.
Comme les consommateurs et consommatrices sont plus au fait de leurs droits numériques et des complexités liées à la confidentialité des données, ils et elles attendent davantage des fournisseurs de logiciel. Si la réputation d'une entreprise est entachée par des atteintes à la sécurité ou à la conformité, elle peut prendre des années à se rebâtir, et parfois ce n'est pas possible d'y arriver. En outre, étant donné la nature mondiale de nombreux produits numériques, les brèches ou la non-conformité peuvent entraîner des répercussions, touchant ainsi les relations internationales, les ententes commerciales et même la stabilité géopolitique. De plus, à l’heure actuelle, les considérations éthiques du domaine technologique se retrouvent souvent sous les feux de la rampe. Non seulement les équipes d'ingénierie doivent affronter des défis techniques, mais elles doivent aussi faire face aux implications morales de leurs décisions liées au code.
« Si la réputation d'une entreprise est entachée par des atteintes à la sécurité ou à la conformité, elle peut prendre des années à se rebâtir, et parfois ce n'est pas possible d'y arriver. »
Que peuvent faire les équipes d'ingénierie pour aborder ces préoccupations?
Automatisation
L'automatisation représente la pierre angulaire d'une équipe efficace d'ingénierie. En utilisant des flux de travail automatisés pour aborder ces nouvelles préoccupations dans le cadre de leur SDLC (cycle de développement logiciel), les équipes pourront tirer parti d'outils pour éviter l’ajout de friction aux processus existants.
Pour détecter rapidement des failles potentielles, il faut des outils d'analyse de sécurité (statique et dynamique). Les agents régulateurs seront déployés dans les environnements à risque pour s'assurer que les infrastructures et les codebases sont testés par rapport aux politiques renforcées. Les outils Infrastructure-as-code serviront à apporter des changements explicites et révisables à un nombre sans cesse croissant de composants.
Les équipes de développement qui ont adopté l'automatisation comme citoyens de première classe seront en mesure de s'adapter rapidement aux changements, sans qu’il y ait d’incidence sur leur rapidité d'exécution.
Au-delà de l'environnement immédiat de développement, la surveillance automatisée et les systèmes d'alerte deviennent indispensables, assurant une détection et une réponse en temps réel à toute activité inhabituelle ou malveillante. De plus, l'utilisation de l'apprentissage machine dans l'automatisation peut prédire davantage de failles potentielles et y remédier de façon préventive, transformant ainsi des mesures réactives en solutions proactives. Avec l'approche DevSecOps propulsée par l'IA, le génie logiciel peut progresser vers un avenir où les mesures de sécurité évoluent en tandem avec les menaces émergentes. Ainsi, la couche de protection devient plus intelligente à chaque itération.
Participation des développeurs·euses lors des phases de définition de produit
Mais bien sûr, on ne peut pas tout régler à l'aide de machines, d'algorithmes et de processus automatisés. Comme il faut aborder davantage de préoccupations concernant la sécurité et les données des produits numériques, l’implication de l’équipe de développement s’avère de plus en plus nécessaire dans les phases de découverte et de définition.
Étant donné que ces préoccupations devraient être considérées comme des exigences de base (et non de simples fonctionnalités), elles mènent souvent à des décisions majeures sur le plan de l'architecture, qui doivent être prises en compte le plus tôt possible dans le processus. Ces décisions auront une incidence sur la cueillette, le traitement et la subsistance des données ainsi que sur l'endroit où ces actions sont effectuées. Les préoccupations liées au développement peuvent aussi influer sur le produit en tant que tel, car la complexité de la mise en œuvre constitue un facteur important dans ces décisions.
Fonctionnement et maintenance
Même si, à l'étape de développement de produit, les équipes de développement font de leur mieux, tout peut s'effondrer après coup lors de l'étape du fonctionnement. Les préoccupations concernant la sécurité et les données ne sont pas des éléments dont on tient compte une seule fois. Les équipes doivent être proactives pour dominer la situation, car des failles de sécurité sont découvertes tous les jours.
En effectuant des vérifications régulières (aussi automatisées que possible - on l'espère), elles peuvent cerner les problèmes aussitôt qu'ils surviennent et les régler rapidement par la suite. En maintenant leurs dépendances et leurs temps d'exécution à jour, si des problèmes de sécurité se produisent, elles évitent d'avoir à rattraper le temps perdu.
Toutefois, on peut réduire le niveau de conséquences sur les opérations lors de l'étape de développement. Les équipes peuvent démarrer des projets à l'aide de fondements réutilisables et se servant d’ensembles de dépendances cohérents. Elles diminuent ainsi leur temps de maintenance et les coûts, car les changements peuvent être propagés à l'échelle de divers projets.
Changement de mentalité
En s'occupant du SDLC et en essayant de constamment l'améliorer, ce cycle en accomplira plus pour votre équipe sans toucher la vitesse d'exécution et de déploiement. Il peut être également bénéfique de tirer parti d'outils automatisés de balayage de sécurité (statique et dynamique) dans votre analyse manuelle de la sécurité et dans les services de vérification. Par exemple, chez Mirego, dans nos projets gabarits, nous disposons de modèles sécurisés par défaut que nous utilisons pour créer de nouveaux projets. Nous nous assurons ainsi que tous les nouveaux projets comportent des paramètres sensés et sécurisés par défaut, des réglages renforcés et des outils automatisés préconfigurés.
Le dédoublement par rapport à la sécurité peut aussi signifier qu'une équipe est dédiée à la maintenance et au soutien. Elle peut donc s'assurer de rapporter de manière proactive les changements nécessaires dans divers codebases dès l'intégration de nouvelles pratiques optimales dans les projets gabarits. On devrait avoir la même mentalité, qu'on explore de nouvelles technologies ou qu'on travaille avec celles qui existent déjà. Il ne faut jamais faire de compromis sur la sécurité au nom de l'innovation.
Ce n'est plus assez de faire le strict minimum
Non seulement les utilisateurs·trices s'attendent à plus des produits numériques sur le plan de la sécurité et de la confidentialité, mais les autorités feront en sorte qu'il en soit ainsi. Il en découlera de véritables conséquences si l'on ignore ces préoccupations.
Cela peut faire toute la différence si l'on agit de manière proactive plutôt que réactive lors de menaces de sécurité.
Les équipes d'ingénierie qui possèdent déjà la bonne mentalité tireront grandement parti de la situation. Elles adoptent déjà la sécurité comme priorité et utilisent l'automatisation pour l'intégrer à leur processus SDLC. Et elles traitent déjà les renseignements sur les utilisateurs et utilisatrices comme des données sensibles et conçoivent des architectures à la fois rigoureuses et souples selon les exigences de confidentialité. Elles perçoivent également les produits numériques comme des éléments logiciels en constante évolution qui dureront très longtemps. Elles disposent de processus rigoureux pour garder les codebases et les infrastructures à jour.
Lorsque de nouvelles technologies se présentent, elles établissent l'équilibre idéal entre elles, leurs possibilités et aussi le contexte qui leur est extérieur. Elles traitent ce contexte non pas comme un ensemble de limites, mais plutôt comme un cadre de travail dans lequel doivent s'insérer les produits qu'elles développent.
On ne peut pas prédire l'avenir, et il est impossible de prédire les types de failles de sécurité que l'on découvrira. Il s'avère difficile de prédire quelles nouvelles réglementations seront mises en application au cours de la prochaine décennie.
En revanche, les préoccupations de sécurité et de confidentialité ne feront que croître avec les années. Ce que l'on peut faire, c'est de s'assurer que notre mentalité, nos processus et nos outils s'alignent avec ce fait. Selon Bruce Schneier, « la sécurité est un processus et non un produit ». Du point de vue de la sécurité et de la conformité, l'avenir du génie logiciel sera défini par plusieurs éléments. Il faudra adopter des processus, cultiver une mentalité et accorder une valeur accordée à l'intégrité des données ainsi qu’à la confiance des utilisateurs et utilisatrices. Il s'agit d'un processus continu, mais avec la bonne méthode, on peut le mener à bien avec succès.