Beaucoup trop d’organisations exécutent des applications Web et mobiles qui sont vulnérables aux attaques ciblées. Ils peuvent utiliser des bibliothèques et des composants logiciels non corrigés, ils peuvent accéder à des informations personnelles identifiables (PII) non cryptées, ou ils peuvent simplement avoir été développés de manière à ce que la sécurité n’ait pas été intégrée au pipeline de développement logiciel.
Selon Bola Rotibi, directeur de recherche chez CCS Insight, la raison pour laquelle les applications web sont si souvent vulnérables dépend du mode de fonctionnement des équipes de développement. “Il y a trop vulnérabilités de sécurité de base parce que les équipes de développement, et, soyons honnêtes, leurs auditeurs de sécurité, se laissent ouvertes », dit-elle.
Par exemple, ne pas couvrir les pistes vers les emplacements de dossiers communs où des informations sensibles sont conservées revient à laisser la porte ouverte aux hackers. « Se déconnecte dans le posture de sécurité entre les différentes équipes présentent des écarts qui peuvent être exploités. Pour trop d’organisations, il y a encore trop peu de partage des politiques de sécurité ou de la liste de contrôle des vulnérabilités communes sur lesquelles les équipes sont régulièrement piégés », explique Rotibi.
Besoin de vitesse
Si Dernière enquête de GitLab auprès de 4 500 développeurs de logiciels est quelque chose à faire, les tests sont la principale raison des retards dans la publication du nouveau code. Mais des tests approfondis sont essentiels si les organisations veulent minimiser le risque de publier du code non sécurisé qui pourrait être exploité par un acteur malveillant.
Pour l’anecdote, les développeurs qui ont participé à l’enquête ont estimé qu’ils devaient « virer à gauche » en termes de sécurité. En d’autres termes, les développeurs commencent à reconnaître la nécessité de devenir plus avertis en matière de sécurité et appliquer les meilleures pratiques de sécurité à leur codage.
Encourager les développeurs à passer plus de temps à réfléchir à la sécurité du logiciel qu’ils écrivent ne peut pas se faire isolément, surtout si les exigences de l’entreprise exigent une cadence élevée dans les versions de nouvelles fonctionnalités numériques – mais les attitudes changent
Les tests de vulnérabilités dans le code doivent être intégrés à toutes les phases du processus de développement logiciel. Certains experts recommandent de soumettre le code à des tests externes avant de lancer de nouvelles fonctionnalités.
« Si vous ne [carry out] tests d’intrusion externes, vous vous dirigez vers la catastrophe », prévient Roy Castleman, directeur général d’EC-MSP, une société londonienne d’assistance informatique pour les petites et moyennes entreprises (PME).
Encourager les développeurs à passer plus de temps à réfléchir à la sécurité du logiciel qu’ils écrivent ne peut se faire isolément, surtout si les exigences de l’entreprise nécessitent une cadence élevée dans les versions de nouvelles fonctionnalités numériques. Mais les mentalités changent.
Priorités commerciales
« En tant que propriétaires d’entreprise, nous en savons très peu sur le fonctionnement interne de nos systèmes. Il est important de faire confiance à votre équipe – et, dans ce cas, il est plus important de vérifier. Votre équipe est peut-être d’excellents spécialistes du marketing et des concepteurs, mais la sécurité est un tout autre jeu de balle. Même lorsque vous avez une équipe de sécurité qui travaille pour vous, il est essentiel de vérifier les choses », explique Castleman.
Une étude de l’analyste Forrester révèle que si sécurité des applications les défauts sont prolifiques, la direction reconnaît au moins le problème. Les organisations ont commencé à se rendre compte que la solution ne réside pas seulement dans les équipes de sécurité, mais aussi dans les développeurs, notent les auteurs de Forrester État de la sécurité des applications, 2021 rapport.
L’étude de Forrester montre que pour 28 % des décideurs en matière de sécurité, l’amélioration de la sécurité des applications est une priorité de sécurité informatique tactique pour l’année à venir – il s’agit de l’initiative la plus souvent citée. Selon l’étude, 21 % des décideurs en matière de sécurité prévoient de donner la priorité à l’intégration de la sécurité dans les processus de développement.
Forrester affirme que des outils de sécurité des applications bien implémentés peuvent réduire le fossé entre les développeurs et les professionnels de la sécurité. Cela permet aux développeurs de résoudre de manière transparente les problèmes de sécurité sans quitter leurs propres pipelines de développement. Un exemple de pipeline de développement et de déploiement de logiciels avec sécurité intégrée est utilisé chez Domino’s Pizza pour maintenir une qualité de code élevée et garantir que la sécurité informatique n’entrave pas le rythme du développement logiciel.
Un pipeline pour le développement, le déploiement et les opérations de logiciels sécurisés
Domino’s Pizza adopte une approche hybride du développement de logiciels, ce qui signifie que la sécurité des applications relie le code développé en interne et les logiciels développés en externe.
S’adressant à Computer Weekly avant la conférence virtuelle de cette année Infosécurité Europe événement, Lee Whatford, directeur de la sécurité de l’information (CISO) chez Domino’s Pizza, a décrit le processus DevSecOps de l’entreprise, qui repose sur un modèle de sécurité qui offre une surveillance et une visibilité sur le pipeline de développement et de déploiement de logiciels, tout problème étant résolu lors des tests de produit.
“Nous avons des développeurs de plate-forme internes et un tiers qui fait le développement d’applications”, dit-il, ajoutant que si le code est développé en interne ou par la société de développement de logiciels externe, les développeurs internes sont habilités à garantir que le code produit est sécurisé.
L’entreprise a développé un modèle de sécurité qui offre surveillance et visibilité. Le modèle couvre les conteneurs et les infrastructures de sécurité, et intègre la gouvernance, les compétences et la visibilité. En offrant un niveau de visibilité, Whatford affirme que les développeurs sont en mesure d’améliorer leurs connaissances et leur sensibilisation à la sécurité, ce qui leur permet de coder de manière plus sécurisée.
Discutant du défi d’intégrer un état d’esprit de sécurité dans le processus de développement logiciel, il déclare : « Dans le pipeline de développement logiciel, l’étape la plus importante est de travailler aussi près que possible du processus de développement logiciel. Les développeurs doivent être agiles pour l’entreprise, nous devons donc travailler à un rythme soutenu, tout en conservant des freins et contrepoids sur la façon dont ils exécutent l’infrastructure et déploient le code.
Whatford dit que ces freins et contrepoids garantissent que les développeurs ne publient pas accidentellement du code au mauvais endroit. Le modèle de sécurité fournit effectivement un terrain de jeu dans lequel développer et déployer du code en toute sécurité, sans empiéter sur le processus agile de développement et de déploiement de logiciels.
L’automatisation est largement utilisée dans la phase de développement logiciel, pour tester les vulnérabilités des applications et rejeter automatiquement le code qui échoue à certains critères de test. Ces analyses automatiques évaluent les risques de sécurité. Par exemple, le code testé peut présenter un niveau de risque de vulnérabilité moyen. Pour Whatford, ce rejet automatisé contribue à renforcer le message de formation à la sécurité. « Cela signifie que le code du développeur ne peut pas traverser le pipeline de développement logiciel et l’environnement de production », dit-il.
Du côté de l’infrastructure informatique, la publication du code est automatisée via un autre pipeline. Cela garantit que les équipes de développement d’applications et d’infrastructure peuvent travailler efficacement avec les équipes d’exploitation informatique. Une telle séparation des tâches en termes de contrôles de sécurité est requise par Domino’s Pizza pour se conformer aux Norme de paiement par carte PCI DSS.
Whatford dit que Domino’s Pizza est en train de faire mûrir son modèle de sécurité, en ajoutant des processus plus détaillés. L’objectif est d’avoir un ensemble de règles d’un point de vue opérationnel qui applique un sécurisé par conception approcher.
« Si nous avons une visibilité sur ce qui se passe et si nous avons une base de référence sur ce qui est bien, nous pouvons rapidement détecter les anomalies et les mauvaises configurations », dit-il, ajoutant que cela permettra à Domino’s Pizza de hiérarchiser les problèmes et de corriger rapidement les risques de sécurité graves. « Quand il y a un million de choses à faire, il s’agit de gouvernance et de gestion des risques de l’entreprise. Nous devons prioriser les correctifs », ajoute Whatford.
Domino’s Pizza a maintenant commencé à déployer la résolution automatique des problèmes de configuration informatique, sur la base d’une base de référence minimale de configurations hautement prioritaires.
Changer les mentalités
De par sa nature même, lors du codage manuel d’applications, il est plus probable que le programmeur introduise de nouvelles vulnérabilités. Mais si l’enquête GitLab peut être considérée comme un test décisif des attitudes des développeurs, les développeurs de logiciels commencent à assumer une plus grande responsabilité en matière de sécurité.
« Pour tous ceux qui se soucient de répondre aux attentes des clients, qu’ils soient internes ou externes à l’organisation, l’une de vos principales priorités devrait être de réduire les risques dans les applications Web que vous développez »
Bola Rotibi, CSC Insight
Pour les développeurs avec lesquels GitLab a parlé, les méthodes courantes utilisées pour améliorer la sécurité du code incluent les revues de code, l’analyse de code statique et la surveillance des applications en direct, ainsi que les analyses de sécurité des bibliothèques et conteneurs open source, et l’analyse des risques dans la phase de conception du projet.
Pour Domino’s Pizza’s Whatford, le codage sécurisé commence par un modèle de sécurité, que les développeurs peuvent utiliser parallèlement aux tests automatisés, pour s’assurer qu’ils écrivent un code propre et sécurisé et qu’ils comprennent pourquoi la suite de tests rejette le logiciel qu’ils soumettent. Il s’agit d’un processus d’apprentissage : à mesure qu’ils développent des applications plus sécurisées, les outils sont moins susceptibles de rejeter leur code.
C’est cette idée de s’efforcer de réduire les erreurs de codage dont les développeurs de logiciels doivent tenir compte. Rotibi de CCS Insight déclare : « Pour tous ceux qui se soucient de répondre aux attentes des clients, qu’ils soient à l’intérieur ou à l’extérieur de l’organisation, l’une de vos principales priorités devrait être de réduire les risques dans les applications Web que vous développez.
