Les mauvaises pratiques de codage peuvent entraîner de graves problèmes de sécurité… alors pourquoi les encourageons-nous ?

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

‍

Depuis une éternité, semble-t-il, nous discutons du « shift left » dans le cycle de vie du développement logiciel (SDLC), en intégrant les meilleures pratiques de sécurité dès le début du développement. Le DevSecOps a constitué un grand pas en avant, en grande partie grâce à l'accent mis sur la responsabilité partagée en matière de sécurité et sur la capacité d'un développeur sensibilisé à la sécurité à contrer les vulnérabilités courantes au moment même où il écrit son code. 

Nous savons également — là encore, depuis des lustres — que le type de formation au code sécurisé choisi pour impliquer et faire monter en compétences les développeurs fait toute la différence. Les solutions à faible effort, motivées uniquement par la conformité réglementaire, ne permettent pas de former les esprits brillants de la sécurité de demain, et la plupart des professionnels de la sensibilisation à la sécurité l'ont bien compris. Un apprentissage dynamique et contextuellement pertinent est préférable, mais il est crucial d'en comprendre les nuances. 

Si nous voulons avoir une chance de lutter contre les acteurs malveillants — qui ont toujours une longueur d'avance sur une organisation — les développeurs ont besoin d'un environnement de formation holistique, avec un apprentissage par paliers qui renforce continuellement les compétences fondées sur les meilleures pratiques.

Les mesures de sécurité défensives pilotées par les développeurs ne sont pas une victoire automatique.

Notre philosophie repose sur le fait que le développeur est au cœur d'une stratégie de sécurité préventive, dès le niveau du code. C'est une évidence, et les développeurs compétents en sécurité constituent le moyen le plus simple de contrer les types de failles de sécurité courantes qui apparaissent dans les mauvaises pratiques de codage (comme Log4Shell, pour citer un exemple récent et dévastateur).

Cependant, les techniques défensives que nous pouvons utiliser pour faire monter les développeurs en compétences varient, même si elles peuvent légitimement figurer dans la même catégorie de formation. 

Par exemple, imaginez qu'on vous apprenne à faire un gâteau en utilisant uniquement des instructions sur ce qu'il ne faut pas faire. « Ne faites pas trop cuire » et « n'oubliez pas les œufs » laissent place à l'interprétation et à un risque énorme d'erreurs qui donneront un résultat digne de Nailed It!. Il en va de même pour l'éducation à la sécurité défensive ; ce qu'il ne faut pas faire ne constitue qu'une partie très limitée de la conversation et n'offre aucun conseil pratique pour agir réellement avec un état d'esprit défensif. Vous pouvez dire aux développeurs : « ne configurez pas mal cette API », mais sans comprendre ce qui constitue une configuration correcte et sécurisée, il y a beaucoup de place pour l'erreur.

Les développeurs ne pourront pas réduire efficacement les vulnérabilités sans une compréhension fondamentale de leur fonctionnement, de leur dangerosité, des modèles qui les provoquent et des pratiques de conception ou de codage permettant de les corriger dans un contexte qui leur est familier. Une approche structurée permet d'acquérir des connaissances par étapes pour obtenir une vision globale de ce que signifie coder de manière sécurisée, protéger une base de code et s'affirmer en tant que développeur sensibilisé à la sécurité. Et oui, une partie de cet apprentissage par paliers doit être consacrée à l'offensive et à la compréhension de l'état d'esprit d'un attaquant ; c'est essentiel pour affiner les capacités de pensée latérale, qui sont inestimables dans la modélisation des menaces et la stratégie défensive. 

Renforcer les mauvaises pratiques de codage est un piège que nous ne pouvons ignorer.

Une réalité malheureuse avec certaines méthodes d'apprentissage pour les développeurs est que la partie « défensive » — même lorsque la formation est structurée avec des techniques offensives — peut renforcer de mauvaises habitudes, même si elles valident techniquement la sécurité du code. 

La production de code de haute qualité devrait être la norme dans tout développement logiciel, mais la définition de la « qualité » semble encore faire débat. La réalité est qu'un code non sécurisé ne peut être considéré comme un code de qualité, même s'il est par ailleurs fonctionnel et élégant. Le hic, c'est qu'un code sécurisé n'est pas non plus intrinsèquement de haute qualité. En d'autres termes, de mauvaises pratiques de codage peuvent résoudre un problème de sécurité, mais en introduisant un autre, ou en risquant de casser complètement le logiciel. 

Examinons un exemple de code de mauvaise qualité sous la forme d'une correction pour une authentification défaillante, ainsi que la version la plus sécurisée selon les meilleures pratiques :

‍

using System;

using System.Collections.Generic;

using System.Linq;

using System.Threading.Tasks;

using Microsoft.AspNetCore.Authorization;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

‍

namespace BadFixesAPI.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    public class AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext();

‍

        [HttpGet(Name = "GetAlerts")]

        // Ne vérifie pas si l'utilisateur est authentifié

        public IEnumerable<Alert> Get()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Vérifie que l'utilisateur est authentifié, mais ne contrôle aucun rôle

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Vérifie que l'utilisateur est authentifié ET possède le rôle « Administrator »

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            return context.GetAlerts();

        }

    }

}

‍

Le premier extrait ne vérifie pas si l'utilisateur est authentifié, ce qui est extrêmement risqué. Le second, bien que meilleur car il effectue une vérification d'authentification, omet de contrôler les rôles assignés et si les permissions sont suffisantes pour les informations demandées. Le troisième vérifie à la fois l'authentification de l'utilisateur et son rôle « Administrator ». À une époque où le principe du moindre privilège devrait être la norme, il est crucial de configurer et de vérifier les rôles pour garantir que l'accès aux informations repose sur le besoin d'en connaître. 

La priorité absolue des développeurs est de créer des fonctionnalités. Bien que la sécurité ne soit pas délaissée intentionnellement, ils ne possèdent pas nécessairement les compétences pour éviter les mauvaises pratiques de codage à l'origine de failles de sécurité, et la maîtrise du code sécurisé est rarement un critère d'excellence pour un ingénieur. Nous encourageons indirectement ces mauvaises habitudes si les fonctionnalités sont suffisamment impressionnantes, et c'est cette mentalité qui doit changer. Le problème est que certaines méthodes d'apprentissage encouragent une remédiation du code qui, bien que sécurisée, est de qualité médiocre. En appliquant une évaluation binaire « sécurisé / non sécurisé » plutôt que d'analyser si l'approche est réellement optimale pour résoudre le bug et maintenir l'intégrité du logiciel, des détails critiques passent inaperçus. 

Sans accompagner les développeurs tout au long du processus pour leur offrir une vision globale du codage sécurisé, cette approche perpétue les problèmes qu'elle tente de résoudre. Imaginez si nous obtenions notre permis de conduire uniquement sur notre capacité à atteindre une destination ; nous serions reçus même si nous avions grillé des feux rouges, traversé une haie et manqué de renverser un piéton. L'objectif est atteint, mais c'est la manière d'y parvenir qui compte le plus. 

Les développeurs doivent être encouragés à accorder plus d'importance à la création de logiciels sécurisés.

Le développeur moderne doit jongler avec de nombreuses responsabilités, et il n'est pas surprenant qu'il trouve la formation à la sécurité fastidieuse, surtout lorsqu'elle n'est pas adaptée à son quotidien et l'éloigne de ses priorités. Il est également injuste de modifier ses objectifs de performance pour mettre l'accent sur le codage sécurisé sans lui offrir les compétences issues d'un apprentissage régulier et d'outils adaptés. Toutefois, l'importance du développement logiciel sécurisé est capitale, et il est crucial d'impliquer les développeurs dans cette démarche. 

En tant qu'ancien développeur, nous voulons généralement faire du bon travail, et être reconnu pour la qualité de son code est très motivant. Inciter les développeurs à renforcer leurs compétences en sécurité est une évidence, et ils devraient être récompensés pour leur engagement. Les programmes de « security champions », les primes aux bugs et les hackathons sont d'excellentes occasions de bâtir une culture de sécurité positive, et ceux qui s'impliquent activement méritent d'être valorisés.