Le code source, un vecteur de risque sous-estimé

Avec les évolutions technologiques actuelles, le code source est omniprésent. Tout, désormais, est décrit sous forme de code : les applications, bien sûr, mais aussi les réseaux, la sécurité, les tests… Dans le cloud, pour mettre en place une infrastructure, on développe du code qui sera interprété pour provisionner et déployer les ressources demandées. Autrement dit, celui qui connaît le code connaît tout du SI, qu’il peut dès lors espionner, paralyser, détourner ou endommager à sa guise. Il est donc grand temps d’aborder enfin la sécurité du code avec toute la rigueur qu’elle mérite.

Un développement s’appuie sur du code développé (rédigé manuellement ou généré automatiquement), du code importé (briques open source ou propriétaires), de la configuration (gestion des accès, management des secrets, etc.) et des tests (unitaires, d’intégration, de sécurité, etc.). Dans les approches DevOps, l’ensemble du code est géré au travers d’une chaîne d’intégration et de déploiement continus (CI/CD) qui est largement automatisée, et qui repose elle-même sur du code. La sécurité du code va par conséquent nécessiter la sécurisation du contenu (les développements proprement dits) et celle du contenant (la plateforme de CI/CD) à travers la mise en place de contrôles spécifiques et réguliers tout au long de la chaîne de développement.

À ce stade, l’erreur serait de considérer que ce n’est finalement qu’une affaire d’outils. Il suffirait d’intégrer au pipeline une solution qui analyserait le code au fur et à mesure de son élaboration et le renverrait au développeur, assorti d’une alerte, si les critères de sécurité n’étaient pas remplis. En réalité, si cet outillage n’est pas l’aboutissement d’une démarche globale et concertée, c’est l’assurance d’un échec.

Une priorité : une gouvernance adaptée

En effet, il y a autant de codes que de projets, mais leurs risques métiers associés seront bien différents en fonction de leur criticité, de leur exposition et des données manipulées une fois les projets déployés. Aussi, il est impossible d’avoir une batterie unique de contrôles qui serait pertinente dans tous les cas. Pour ne pas surcharger de contrôles superflus les processus de développement, dont on souhaite conserver l’agilité et la vélocité, il est donc primordial de mettre en place une gouvernance adaptée au contexte de l’entreprise. Celle-ci va définir la stratégie, les standards de sécurité, l’architecture organisationnelle, humaine et technique du dispositif, ainsi que ses conditions et ses modalités de déploiement. L’objectif est de bâtir un cadre suffisamment abstrait et générique pour que les équipes puissent se l’approprier et le décliner, en fonction des risques qui leur sont propres.

Cette organisation a, par ailleurs, la responsabilité de maintenir la cohérence entre les projets et de garantir le respect d’un certain nombre de règles incontournables (par exemple, s’assurer que l’utilisation des licences préserve la sécurité juridique du code). Elle met aussi en place des indicateurs de performance permettant d’évaluer le niveau de sécurité et la pertinence de la stratégie. Chacun doit comprendre que la sécurité a un coût, mais qu’elle est aussi un vecteur d’accélération métier. La gouvernance doit  également prendre en compte l’aspect dynamique de la sécurité du code car tout évolue : les menaces, les failles, la sensibilité des données, les applications elles-mêmes, l’environnement sur lequel elles fonctionnent, etc. Il faut donc adapter les contrôles et leur mise en œuvre tout au long du cycle de vie, jusqu’au décommissionnement. Enfin, la gouvernance permettra de faire évoluer la stratégie afin d’éviter de reproduire des erreurs de manière récurrente au moyen de formations ou de tests contextualisés.

Une règle d’or : le pragmatisme

Si la gouvernance pose un cadre commun, la règle d’or doit ensuite être le pragmatisme. Chaque équipe doit sélectionner les contrôles les plus essentiels pour elle, quitte à les étoffer ultérieurement.  Tout va dépendre des risques et du niveau de sécurité visé, mais aussi de la capacité des Devs et des Ops à s’approprier ces nouvelles exigences. C’est pourquoi la solution doit être co-construite avec les équipes. On pourra par exemple déterminer avec les développeurs si les contrôles doivent être systématiques ou optionnels sur des parties non impactées par la modification à valider. Par nature, la sécurisation du code est collaborative, car le code vit entre les mains de nombreux acteurs qui le font évoluer et l’utilisent. C’est la philosophie du DevSecOps que chacun participe à intégrer la sécurité de bout en bout et ce, de manière collaborative.

Un point de vigilance : la dimension humaine

C’est pour cette raison qu’il est fondamental pour le succès de la démarche d’accorder une attention prépondérante à sa dimension humaine. Au-delà des processus et des outils, il va falloir inlassablement former, sensibiliser, acculturer, afin que chacun ait conscience de ses responsabilités et que la sécurité devienne un réflexe, qu’on le nomme Shift left ou Security by Design. Il appartient à l’équipe Sécurité, qui a conscience des enjeux et des risques, de les partager aux autres en s’investissant dans un rôle inédit pour elle de coaching et d’accompagnement. Pour faire passer son message, il lui faudra revenir au dénominateur commun : le business. À travers la sécurité, l’objectif reste de fournir aux métiers un service sûr, fiable et créateur de valeur.

Sécuriser le code doit impérativement figurer parmi les priorités des organisations informatiques, mais ce ne sera possible que si, à tous les niveaux, on prend conscience que c’est l’affaire de tous. Ce n’est qu’en changeant les pratiques vers davantage de responsabilités individuelles et collectives, que l’on parviendra à garantir des niveaux de sécurité satisfaisants sans pour autant brider la capacité d’évolution et d’innovation de l’entreprise. Ce discours doit être porté et appuyé au plus haut niveau, afin d’être décliné dans une feuille de route qui capitalise sur l’existant et cible les risques prioritaires. L’effectivité et la durabilité des gains apportés pourront alors être facilement quantifiées.

3 points à retenir :

1. Avec les évolutions technologiques récentes, l’ensemble du système d’information (applications, infrastructures, réseau, sécurité…) repose sur du code. Être capable de le sécuriser est donc un impératif.
2. Pour que la sécurisation du code ne nuise pas à la vélocité et à l’agilité des développements, la priorité est de mettre en place une gouvernance qui va permettre une approche unifiée et durable, et qui sera adaptée de façon pragmatique pour chaque projet.
3. La sécurisation du code doit être une démarche globale s’inscrivant dans la durée et portée au plus haut niveau. Ce n’est pas seulement une question d’outillage mais une évolution des pratiques, de l’organisation et de la mise en place d’une culture de responsabilité collective.