Code libéré : pourquoi les développeurs sécurisés peuvent livrer sans limites

Cet article a été initialement publié dans SD Times. Il a été mis à jour et syndiqué ici.

‍

La vérification des compétences est une facette de notre vie depuis la majeure partie de l'ère moderne, nous conférant une légitimité et nous ouvrant des portes qui nous seraient autrement fermées. Conduire, par exemple, est un rite de passage important pour la plupart d'entre nous, et nous devons réussir une série d'évaluations standardisées pour prouver que l'on peut nous confier une machine de près de deux tonnes, capable de rouler à plus de 160 km/h. Les erreurs, surtout à grande vitesse, peuvent vous coûter ce privilège, voire une vie humaine.

Mais que se passe-t-il si, pour certains, la conduite est plus qu'une commodité quotidienne et devient une profession d'élite ? Une personne peut poursuivre son apprentissage et potentiellement devenir pilote de F1, où elle est autorisée à manœuvrer des machines qui vont plus vite que ce qu'un civil pourrait gérer sans une probabilité élevée d'erreur à haute vitesse.

À cet égard, il semble déconcertant que la plupart des développeurs travaillant sur le code qui alimente les infrastructures critiques, les automobiles, les technologies médicales et tout ce qui se trouve entre les deux, le fassent sans vérifier au préalable leurs compétences en sécurité. D'un autre côté, pourquoi les développeurs qualifiés en sécurité, qui ont prouvé à maintes reprises qu'ils savent concevoir des systèmes sécurisés, doivent-ils faire la queue avec tout le monde dans des pipelines de développement de plus en plus lents à cause des verrous de sécurité ? L'industrie ne considère pas cela comme une lacune, c'est la norme.

Des recherches approfondies nous apprennent que la plupart des développeurs ne donnent tout simplement pas la priorité à la sécurité dans leur code et manquent de la formation régulière nécessaire pour gérer de nombreuses failles de sécurité courantes. Ils contribuent souvent au fait que la sécurité à haute vitesse semble être un rêve inaccessible, et beaucoup de développeurs sensibilisés à la sécurité ont l'impression d'être coincés sur la voie lente de l'autoroute derrière des conducteurs novices.

Malgré cela, le monde de la sécurité progresse lentement, et la demande pour des développeurs aux compétences vérifiées, capables d'être opérationnels immédiatement, ne cesse de croître. Le décret présidentiel sur l'amélioration de la cybersécurité nationale de l'administration Biden appelle spécifiquement à l'évaluation des pratiques de sécurité des fournisseurs — et de leurs équipes de développement — pour tout prestataire de la chaîne d'approvisionnement logicielle du gouvernement américain. Il est logique que l'accent mis sur les compétences en sécurité des développeurs ne fasse que croître dans la plupart des secteurs. Mais avec peu d'évaluations standardisées disponibles, comment les organisations peuvent-elles prouver que leur programme de sécurité développe des compétences vérifiables sans paralyser la livraison ou freiner les développeurs avertis ?

Contrôle d'accès basé sur le mérite : est-ce viable ?

Les contrôles de sécurité basés sur le moindre privilège sont un pilier dans de nombreuses organisations, avec l'idée que chaque rôle se voit attribuer un accès aux logiciels, aux données et aux systèmes uniquement en fonction des besoins professionnels. Cette méthode — surtout lorsqu'elle est associée aux principes d'autorisation « zero-trust » — est utile pour réduire la surface d'attaque. Et, en réalité, nous devrions appliquer cette même stratégie aux permissions API et à d'autres cas d'usage logiciels par défaut.

La plupart d'entre nous dans le secteur de la sécurité sommes parfaitement conscients que le logiciel dévore le monde, et le code des systèmes embarqués de votre friteuse n'est pas différent de celui qui maintient le réseau électrique en état de marche en termes de vulnérabilité potentielle. Nos vies et nos données critiques sont à la merci des cybermenaces, et chaque développeur doit comprendre le pouvoir dont il dispose pour renforcer son code lorsqu'il est correctement formé. Cela nécessite une mise à niveau sérieuse de la culture de sécurité d'une organisation, mais pour une véritable responsabilité partagée de type DevSecOps, les développeurs ont besoin d'une raison de se soucier davantage de leur rôle. Peut-être que le moyen le plus rapide de changer leur état d'esprit serait de lier l'accès aux dépôts de code aux résultats d'apprentissage en codage sécurisé.

Si nous prenons une organisation dans le secteur bancaire et financier, par exemple, il est fort probable qu'il existe des dépôts hautement sensibles contenant des données clients ou stockant des informations précieuses comme des numéros de carte bancaire. Pourquoi devrions-nous alors supposer que chaque ingénieur ayant reçu un accès est sensibilisé à la sécurité, conforme aux exigences strictes PCI-DSS et capable d'apporter des modifications à la branche principale rapidement et sans incident ? Bien que cela puisse être le cas pour certains, il serait bien plus sûr de restreindre l'accès à ces systèmes sensibles tant que ces connaissances ne sont pas prouvées.

Le défi est que, dans la plupart des entreprises, mettre en place un scénario de « permis de coder » serait ardu et, selon la solution de formation, un peu trop manuel pour soutenir des objectifs de sécurité à haute vitesse. Cependant, la bonne combinaison d'éducation intégrative et d'outils peut être le cœur d'une stratégie de sécurité défensive pilotée par les développeurs.

Une intégration efficace de la formation n'est pas impossible.

Trouver des solutions de montée en compétences qui complètent à la fois les objectifs commerciaux à haute vélocité et le flux de travail des développeurs est la moitié de la bataille. Mais aller plus loin pour dépasser la formation de conformité « unique » est le seul moyen de réduire significativement les vulnérabilités au niveau du code. Et pour les développeurs qui font leurs preuves ? Le monde du code leur appartient, et ils ne seront plus entravés par des contrôles de sécurité supposant qu'ils ne maîtrisent pas les bases.

Le perfectionnement pratique des compétences, intégré de manière transparente à l'environnement de développement, fournit le contexte nécessaire pour que les ingénieurs comprennent et appliquent réellement les concepts de codage sécurisé. Ces mêmes intégrations peuvent être utilisées pour gérer efficacement l'accès aux systèmes critiques, garantissant que ceux qui excellent travaillent sur les tâches les plus sensibles sans entrave. Cela facilite également la mise en place de récompenses et de reconnaissance, valorisant les développeurs compétents en sécurité.

Comme beaucoup de choses dans la vie, la fortune sourit aux audacieux. Rompre avec le statu quo pour adopter une approche innovante de la vérification des compétences est exactement ce dont nous avons besoin pour élever les standards de qualité du code sans sacrifier la vitesse.