Le code hors de la cage : Pourquoi les développeurs sécurisés peuvent travailler sans limites

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

‍

La vérification des compétences fait partie de notre vie depuis la majeure partie de l'ère moderne, nous conférant une validité et nous ouvrant des portes qui ne seraient pas accessibles autrement. La conduite, par exemple, est un rite de passage important pour la plupart des gens, et nous sommes censés passer une série d'évaluations standardisées pour confirmer que nous pouvons avoir confiance en une machine de quatre mille livres, capable de rouler à plus de 160 km/h. Les erreurs, en particulier à grande vitesse, peuvent vous coûter ce privilège, voire un être humain. Les erreurs, surtout à grande vitesse, peuvent vous coûter ce privilège, voire une vie humaine.

Mais que se passerait-il si, pour certains, la conduite était plus qu'une commodité quotidienne et devenait une profession d'élite ? Une personne peut poursuivre son parcours de perfectionnement et devenir pilote de F1, où elle est autorisée à conduire des machines qui vont plus vite qu'aucun civil ne pourrait le faire de manière réaliste, sans qu'il y ait un risque énorme d'erreur à grande vitesse. 

À cette fin, il semble déconcertant que la plupart des développeurs qui travaillent sur le code qui alimente les infrastructures critiques, les automobiles, la technologie médicale et tout ce qui se trouve entre les deux, le fassent sans d'abord vérifier leurs prouesses en matière de sécurité. D'autre part, pourquoi les développeurs compétents en matière de sécurité, qui ont prouvé à maintes reprises qu'ils savaient comment construire des choses sûres, doivent-ils faire la queue avec tous les autres dans les pipelines de développement toujours plus lents à cause de toutes les barrières de sécurité ? L'industrie ne considère pas cela comme un oubli, c'est la norme. 

Des recherches approfondies nous ont appris que la plupart des développeurs n'accordent tout simplement pas la priorité à la sécurité dans leur code et qu'ils n'ont pas reçu la formation régulière nécessaire pour résoudre un grand nombre de bogues de sécurité courants. C'est en partie à cause d'eux que la sécurité à grande vitesse semble être une chimère et que de nombreux développeurs spécialisés dans la sécurité ont l'impression d'être coincés sur la voie lente de l'autoroute, derrière un groupe d'apprentis conducteurs. 

Malgré cela, le monde de la sécurité avance lentement et il existe une demande croissante de développeurs ayant des compétences vérifiées en matière de sécurité et capables d'être opérationnels. Le décret de l'administration Biden sur l'amélioration de la cybersécurité nationale demande spécifiquement l'évaluation des pratiques de sécurité des fournisseurs - et de leur cohorte de développeurs - pour tout fournisseur de la chaîne d'approvisionnement en logiciels du gouvernement américain. Il va de soi que l'importance accordée aux compétences des développeurs en matière de sécurité ne fera que croître dans la plupart des secteurs, mais avec peu d'offres en matière d'évaluations standard de l'industrie, comment les organisations peuvent-elles prouver que leur programme de sécurité développe des compétences vérifiables en matière de sécurité des développeurs d'une manière qui ne mettra pas la livraison à genoux, ou n'empêchera pas les développeurs conscients de la sécurité de déployer leurs ailes ?

Contrôle d'accès basé sur le mérite : Cela pourrait-il fonctionner ?

Les contrôles de sécurité à moindre privilège sont un pilier dans de nombreuses organisations, avec l'idée que chaque rôle se voit attribuer l'accès aux logiciels, aux données et aux systèmes sur la base du besoin de savoir dans le contexte de leur travail, et rien de plus. Cette méthode - en particulier lorsqu'elle est associée à des principes d'autorisation de confiance zéro - permet d'appréhender toute l'étendue de la surface d'attaque. En réalité, nous devrions appliquer cette même stratégie aux autorisations d'API et à d'autres cas d'utilisation de logiciels en tant que norme. 

La plupart d'entre nous, dans le domaine de la sécurité, sont très conscients du fait que les logiciels sont en train de dévorer le monde, et que le code des systèmes intégrés qui fait fonctionner votre friteuse n'est pas vraiment différent du code qui maintient le réseau électrique en état de marche, en ce qui concerne son potentiel d'exploitation. Nos vies et nos données critiques sont à la merci des acteurs de la menace, et chaque développeur doit comprendre le pouvoir qu'il a de fortifier 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 du rôle qu'ils jouent, et le moyen le plus rapide de changer leur état d'esprit serait peut-être de lier l'accès au dépôt de code à des résultats d'apprentissage du codage sécurisé.

Si nous prenons l'exemple d'une organisation du secteur BFSI, il y a de fortes chances qu'il y ait des référentiels hautement sensibles contenant des données sur les clients ou stockant des informations précieuses telles que des numéros de cartes de crédit. Dans ce cas, pourquoi devrions-nous supposer que chaque ingénieur auquel l'accès a été accordé est sensibilisé à la sécurité, qu'il respecte les exigences strictes de la norme PCI-DSS et qu'il est en mesure 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 délicats jusqu'à ce que ces connaissances soient prouvées.

Le problème est que, dans la plupart des entreprises, la mise en œuvre d'un scénario de "licence de codage" serait ardue et, en fonction de la solution de formation, un peu trop manuelle pour soutenir tout type d'objectif de sécurité à grande vitesse. Cependant, la bonne combinaison d'une formation intégrative et d'outils peut être au cœur d'une stratégie de sécurité défensive axée sur les développeurs. 

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

Trouver des solutions de perfectionnement des développeurs qui complètent à la fois les objectifs commerciaux à grande vitesse et leur flux de travail est la moitié de la bataille, mais faire un effort supplémentaire pour aller au-delà de la formation de conformité de type "one-and-done" est la seule façon de commencer à voir une réduction significative des vulnérabilités au niveau du code. Et pour les développeurs qui réussissent à faire leurs preuves ? Le monde du codage leur appartient et ils n'ont pas à être paralysés par des contrôles de sécurité qui supposent qu'ils ne savent pas naviguer dans les bases. 

L'amélioration des compétences pratiques qui s'intègre 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, en veillant à ce que ceux qui excellent dans leurs résultats d'apprentissage travaillent sans entrave sur les tâches sensibles de la plus haute priorité. Il est également plus facile de mettre en place des récompenses et une reconnaissance, en veillant à ce que les développeurs ayant acquis des compétences en matière de sécurité soient considérés comme une aspiration au sein de leur cohorte. 

Comme beaucoup de choses dans la vie, la fortune sourit aux courageux, et rompre le statu quo pour adopter une approche originale de la vérification des compétences des développeurs est exactement ce dont nous avons besoin pour relever les normes de demain en matière de qualité acceptable du code, sans sacrifier la rapidité.