Skip to main content

Trois conseils d’experts pour instaurer des pratiques de développement logiciel sécurisé

Écrit par
blog feature snyk iac cli enhancements

1 mars 2023

0 minutes de lecture

On entend souvent parler de l’importance de DevSecOps — l’intégration de la sécurité aux processus DevOps. Mais comme le savent de nombreux professionnels de la sécurité, c’est loin d’être aussi simple qu’il n’y paraît. Instaurer des pratiques de développement logiciel sécurisé implique de travailler aux côtés de développeurs aux opinions, aux priorités et aux particularités diverses. Et tout processus impliquant des personnes est complexe.

Alors, comment les équipes de sécurité d’aujourd’hui surmontent-elles ces difficultés et concrétisent-elles les pratiques de développement logiciel sécurisé ? Snyk a interrogé certains des responsables de la sécurité les plus innovants au monde pour le découvrir. Découvrons leurs principaux enseignements pour favoriser l’adoption de la sécurité au sein des équipes de développement.

Commencez par faire preuve d’empathie

L’empathie jette les bases de pratiques de sécurité bénéfiques pour toutes les parties. Nicholas Vinson, responsable DevSecOps chez Pearson, explique que si les équipes de développement « ne comprennent pas la valeur de la sécurité, elles n’ont aucune raison de la faire passer [avant] leurs travaux sur les fonctionnalités. »

Comment susciter cette motivation pour adopter des pratiques de développement sécurisé ? Tim Crothers, vice-président directeur et directeur de la sécurité chez Mandiant, affirme : « [La sécurité] doit être un partenariat. L’une des principales raisons de nombreux échecs en matière de sécurité, c’est que nous essayons d’imposer nos décisions au lieu de véritablement collaborer avec les équipes que nous cherchons à aider à réussir. »

Il a également souligné que la clé du succès de Mandiant était de « simplement comprendre les pratiques privilégiées par nos équipes d’ingénierie. Quels sont leurs modèles, afin que nous puissions collaborer pour mettre en place des garde-fous plutôt que des contrôles ? Si l’on simplifie vraiment, il s’agit toujours de repérer les lacunes — dans nos processus, dans notre [collaboration]. »

Les équipes de sécurité doivent aussi aborder cette démarche avec humilité et se rappeler que la sécurité n’est pas la seule tâche au programme des équipes de développement. Jason Chan, vice-président de la sécurité chez Netflix, explique que les équipes de sécurité doivent « comprendre que [les développeurs] ont beaucoup d’autres responsabilités. Ils doivent créer des fonctionnalités et des produits. Ils doivent se soucier des performances et de la fiabilité. Nous voulons rendre leur participation à la sécurité aussi simple que possible. »

Misez sur l’accompagnement

À mesure qu’elles comprennent mieux le quotidien des développeurs, les équipes de sécurité doivent aussi leur apporter le niveau d’accompagnement approprié.

Vinson attribue le succès de l’équipe de Pearson au soutien de la direction : « Dès le sommet de l’organisation, la nécessité de la sécurité était comprise. Pour la mise en œuvre, vous dépendez de l’organisation d’ingénierie logicielle et de ses dirigeants. »

Par ailleurs, l’automatisation est essentielle pour soutenir les pratiques de développement logiciel sécurisé. Yashvier Kosaraju, vice-président de la sécurité, de la conformité et de l’informatique chez Sendbird, a constaté les effets considérables de l’automatisation dans son organisation. Après le lancement discret et sans annonce de ses initiatives d’automatisation de la sécurité, Sendbird a observé qu’« environ 65 % des PR que nous avons créées jusqu’à présent ont été fusionnées et clôturées, ce qui est remarquable sachant que nous n’avions communiqué aucune information à ce sujet aux développeurs. Cela montre que tout le monde veut bien faire, mais n’a peut-être pas le temps. Quand on simplifie les choses au maximum, les gens font ce qu’il faut. »

Installez une culture de responsabilité partagée

Les réussites de nombreuses personnes que nous avons interrogées sont le fruit d’un changement d’état d’esprit. Les développeurs ont commencé à se considérer eux-mêmes comme les acteurs clés du développement logiciel sécurisé. Nos experts en sécurité suggèrent plusieurs façons d’y parvenir.

Kyle Randolph, RSSI chez Verkada, valorise les contributions pour encourager la responsabilité partagée. Il explique qu’ils « distribuent des tee-shirts sur lesquels il est écrit “Security Hero”. Cette distinction est plus exclusive, ce qui incite les gens à se dépasser et à contribuer davantage à la sécurité. Par exemple, vous avez éliminé une faille de cross-site scripting… vous l’avez intégrée au framework utilisé par votre équipe. Vous méritez alors un tee-shirt “Security Hero”. Et vous êtes mis à l’honneur devant toute l’entreprise. »

Rinki Sethi, vice-présidente et RSSI chez Bill.com, recommande de mettre en place une structure officielle de formation et de responsabilisation afin que les développeurs et les autres parties prenantes de la sécurité assument leurs responsabilités. Elle explique qu’ils « créent un tableau de bord dont ils sont responsables, qui présente concrètement les mesures prises pour sécuriser correctement notre produit ou notre fonctionnalité. Les ingénieurs peuvent échanger avec l’équipe centrale de sécurité lorsqu’ils en ont besoin, et nous leur proposons également les formations les plus récentes et les plus complètes. »

Et, bien sûr, il faut revenir à l’importance de l’automatisation. Ryan Ware, architecte de sécurité et directeur de l’équipe Intel Products Assurance and Security Tools, explique : « Il faut pouvoir signaler à un développeur, de manière automatisée et le plus tôt possible, un problème dans son code. Il faut le faire au moment où le code est soumis, afin qu’il en prenne connaissance à ce stade, ou même grâce à un outil qui signale immédiatement un problème dans son IDE pendant qu’il écrit son code. »

2023 sera-t-elle l’année de la sécurité des développeurs dans votre organisation ?

Lorsque vous comparez les réussites de ces organisations à votre propre situation, n’oubliez pas que vos pratiques de développement logiciel sécurisé doivent s’articuler avec les processus et les workflows déjà en place dans votre organisation. Chaque situation est différente : il s’agit donc de comprendre les particularités de votre activité et d’élaborer le plan le mieux adapté.

Si vous faites du développement logiciel sécurisé une priorité cette année, découvrez notre livre blanc « Guide des RSSI pour instaurer la sécurité des développeurs ». Vous y trouverez d’autres conseils et astuces de professionnels de la sécurité du Fortune 500, ainsi que des recommandations pratiques de l’équipe d’experts de Snyk.