Réponse au guide ESF sur la sécurité à l’intention des développeurs

Chez Snyk, nous avons inventé la sécurité pensée pour les développeurs. Nous sommes convaincus que les associer aux pratiques de sécurité est essentiel pour créer et exploiter des applications modernes. C’est précisément pourquoi la récente publication intitulée Recommended Practices Guide for Developers, rédigée par la National Security Agency (NSA), la Cybersecurity and Infrastructure Security Agency (CISA) et le Bureau du directeur du renseignement national (ODNI), a retenu notre attention. Nous étions ravis de voir le gouvernement publier un tel document. Son contenu nous a semblé pertinent, mais il ne constituait pas un guide pratique à l’intention des développeurs, surtout au vu de cette citation du communiqué de presse : « Le développeur a une responsabilité essentielle dans la sécurité de nos logiciels. »

Le Practice Guide aborde les bons sujets en matière de sécurité de la chaîne d’approvisionnement logicielle. Il est vaste et traite de la nécessité d’une conception sécurisée, de tests de sécurité complets tout au long du cycle de développement logiciel, de nouveaux outils permettant d’extraire les nomenclatures logicielles (SBOM), des nouvelles menaces liées aux environnements de compilation et de développement, et bien plus encore. Le document contient de nombreux conseils utiles.

Le guide présente toutefois quelques défauts qu’il convient de relever, en particulier dans sa présentation. On compte aujourd’hui environ 27 millions de développeurs dans le monde, et il faut tenir compte de la diversité des langages de programmation, des outils et des environnements dans lesquels ils écrivent leur code. Il n’existe pas un seul profil de développeur, mais une multitude. D’après mon expérience, la plupart des développeurs ne liront probablement pas un guide PDF de 64 pages, dont l’annexe de 24 pages contient deux pages entières d’acronymes. Et pour beaucoup de développeurs en dehors du gouvernement (et certains qui y travaillent), l’emploi excessif du mot « cyber » donne souvent l’impression que le document ne leur est pas destiné.

Comparez cela aux documents qui ont marqué l’ensemble de la communauté des développeurs : le Twelve-Factor App (qui a codifié les architectures modernes et contribué à les faire évoluer), les 4 valeurs et les 12 principes du développement logiciel Agile, ainsi que l’OWASP Top Ten. Plus récemment, peut-être, les quatre niveaux du SLSA Supply chain Levels for Software Artifacts framework.

Voici quelques suggestions pour améliorer les futurs guides de ce type lorsqu’ils s’adressent aux développeurs.

1. Allez à la rencontre des développeurs là où ils se trouvent. Les développeurs sont naturellement curieux, avertis et efficaces. La plupart préfèrent consulter la documentation dans des formats adaptés au Web, qui leur permettent d’intégrer le contenu à leurs outils de lecture favoris. Les PDF sont pratiques, mais rigides et moins faciles à utiliser.

2. Communiquez d’une manière qui parle aux développeurs. Trop souvent, le défi que rencontrent les experts en sécurité lorsqu’ils travaillent avec les développeurs ne tient pas à un manque de connaissances, mais à la communication. Ce sont les difficultés de communication (et souvent des motivations divergentes) qui alimentent l’opposition entre « nous » et « eux », que DevSecOps cherche à éviter. Comme indiqué plus haut, nous pensons que le Practice Guide aborde les bons sujets. Mais présenter ces informations dans un format accessible aux développeurs, comme ces fiches pratiques, renforcerait son impact auprès du public visé.

3. Proposez des exemples concrets. Les développeurs aiment expérimenter et tester de nouvelles idées. Ils veulent disposer d’exemples de code et de nouveaux outils qu’ils peuvent tester et essayer par eux-mêmes, comme nous l’avons fait dans notre récent article de blog sur les paquets malveillants PyPI. Leur donner des exemples concrets à explorer est probablement le meilleur moyen de les inciter à aller au-delà de la simple lecture d’informations et à les mettre en pratique.

Chez Snyk, nous nous engageons à communiquer sur des sujets de sécurité comme celui-ci de manière à les rendre accessibles aux développeurs. En voici quelques exemples : une leçon de Snyk Learn sur la modélisation des menaces et une fiche pratique sur la revue de code sécurisée, deux sujets abordés dans le Practice Guide. Consultez régulièrement ce blog et Snyk Learn : d’autres contenus destinés aux développeurs sur la sécurité de la chaîne d’approvisionnement logicielle arrivent bientôt.