Si vous connaissez le terme de "nightly build", il y a de fortes chances que vous ayez eu recours à cette pratique au moins une fois. Un nighlty build est un code compilé durant la nuit à partir d'un autre code automatisé et préalablement vérifié. IL s’agit d’un moyen redoutable d’identification des failles qui surviennent à la suite de modifications apportées au cours de longs processus de compilation. Pourtant, bien qu'il s'agisse d'un élément essentiel du DevOps, les nightly builds présentent également des inconvénients : si de nouveaux bogues sont découverts le lendemain matin après une nuit de compilation, tout ralentit. Pis, cette pratique incarne parfaitement la partition entre le développement et la sécurité, puisqu’elle compartimente les tâches que les développeurs et les professionnels de la sécurité doivent entreprendre chaque jour (ou, en l’occurrence, chaque nuit).
L'histoire du clivage entre sécurité et développement ne repose pas uniquement sur les nightly builds, bien au contraire. Elle trouve son origine dans un ensemble de malentendus, à travers lesquels les développeurs voient souvent les responsables de la sécurité comme des bloqueurs systématiques à la production, chaque fois qu’une vulnérabilité est mise en lumière. Dans ce contexte, les responsables de la sécurité ne détiennent pas les connaissances nécessaires à la compréhension du jargon, des processus ou des objectifs des développeurs. Historiquement, les deux parties ont ainsi toujours travaillé dans leurs propres départements cloisonnés, sans aucune volonté de rapprochement.
Comment unifier la sécurité et le développement ?
Etablir un pont efficace entre les deux équipes permettrait pourtant d’élaborer un code plus sûr sans sacrifier la vitesse nécessaire au respect des délais. Mais il s’agit là d’un problème culturel. Les équipes de développement et de sécurité doivent donc trouver un terrain d'entente afin de travailler ensemble, comprendre exactement le fonctionnement de chacun et interagir efficacement.
Du côté des développeurs, cela implique de mieux apprécier la valeur de la sécurité et d’aiguiser les compétences dont ils ont besoin pour concevoir un code plus robuste. Du côté de la sécurité, cela signifie comprendre les délais, les outils et les processus des développeurs, puis travailler de concert avec la hiérarchie pour trouver comment intégrer les outils de sécurité.
Selon un récent rapport de Sécurosis, cette mutualisation doit rassembler des membres de toutes les équipes nécessaires. Dans cet objectif, le DevOps ne suffit pas, car il traite uniquement des questions relatives à l'infrastructure, aux tests de sécurité, et au code. Il doit prendre en considération le fait que le développement (Dev) et l’opérationnel (Ops) offrent pléthore de résolutions possibles à la plupart des vulnérabilités, lorsqu’elles intègrent les équipes de sécurité suffisamment tôt dans le cycle de vie du logiciel. Ainsi, une fois que les membres de ces équipes se réunissent et dialoguent ouvertement au sujet des vulnérabilités actuelles et les objectifs commerciaux, ils peuvent mettre en place des processus et outils qui amélioreront l’état de la sécurité de leurs applications, sans nuire à la vitesse de déploiement.
Savoir par où commencer pour corriger les vulnérabilités
La dette de sécurité est un écueil qui s'accumule au fil du temps et qui devrait être traité avec un plan d'action visant à la réduire et prévenir les risques. Mais toutes les vulnérabilités ne sont pas critiques, qu'elles se trouvent au sein d’une dette de sécurité ou qu'elles aient été découvertes dans un lot de nouvelles failles à la suite d'une analyse récente. Or, seul, un développeur ne peut hiérarchiser ces menaces comme il se doit.
Décider quelles vulnérabilités doivent être traitées en priorité est une problématique commune pour les équipes de développement. De nombreux professionnels de la sécurité affirment ainsi que toutes
les vulnérabilités tendent à apparaître comme des priorités pour les développeurs, alors qu’il est en réalité très difficile de différencier une faille ayant un impact sur l'ensemble de l’écosystème informatique d'une autre plus anecdotique.
Etablir des priorités peut donc accélérer l'ensemble du processus de développement. Tout en aidant à fixer des priorités, les équipes de la sécurité ont la possibilité d'aider les développeurs à comprendre quelles failles doivent être traitées immédiatement au cours de la phase de développement, et quelles menaces possibles sont liées à des vulnérabilités non surveillées. L’objectif final étant que les développeurs aient une meilleure compréhension de la façon de hiérarchiser les failles éventuelles.
Les entreprises de développement informatique doivent donc être à la fois agiles et sécurisées. Dans cette perspective, le DevOps ne suffit plus. C’est pourquoi les équipes de sécurité et de développement doivent travailler à l'unisson, afin de produire un code conforme aux réglementations, plus robuste et moins coûteux. Il s’agit d’une communication interne essentielle qui ne sacrifie ni l’innovation, ni la vitesse de déploiement, bien au contraire.
Par Nabil Bousselham, Principal Solutions Architect chez Veracode
