Le facteur le plus important ayant un impact sur l’évolution de la sécurité des applications est la vitesse à laquelle la technologie change. Cela est dû en grande partie à la consumérisation généralisée – les gens s’attendent à ce que les nouvelles technologies et les mises à jour soient disponibles rapidement car ils s’attendent à une expérience client transparente.
Cette tendance, combinée à l’introduction plus large du logiciel en tant que service (SaaS), a conduit à des cycles de développement rapides et itératifs dans lesquels des modifications sont apportées au logiciel chaque semaine, chaque jour et même chaque heure. Les pratiques traditionnelles de sécurité des applications ne peuvent pas suivre le rythme. C’est là qu’intervient DevSecOps.
DevSecOps est un état d’esprit et une façon de travailler dans le domaine de la sécurité des applications dans lequel la sécurité fait partie du travail de chacun, pas seulement d’une équipe. Il aide la sécurité à évoluer au même rythme que les nouveaux cycles de développement tout en élevant l’importance de la sécurité à celle des indicateurs de réussite commerciale plus traditionnels, tels que la disponibilité ou la qualité des produits.
Cependant, les entreprises ont toujours eu du mal à mettre en œuvre DevSecOps au sein de leurs organisations. L’un des obstacles les plus persistants est qu’il peut s’agir d’un grand changement culturel pour les équipes technologiques et implique souvent un changement d’outillage. Mais lorsqu’il est bien fait, DevSecOps peut avoir un impact significatif sur le renforcement de la sécurité des applications. Et même si cela peut sembler contre-intuitif, la meilleure stratégie consiste à faire de DevSecOps la responsabilité de ingénierie – pas de sécurité.
Qu’est-ce qui rend DevSecOps si difficile à adopter ?
Les récents incidents de cybersécurité tels que Log4j et SolarWinds ont montré aux équipes de direction qu’elles ne pouvaient plus se permettre de garder la sécurité dans un silo. Au lieu de cela, ils doivent en faire le fondement de la stratégie de l’entreprise, de la salle de conférence au centre de développement de logiciels.
Du jour au lendemain, la faille Log4j est devenue un problème pour des milliers d’entreprises utilisant le framework de journalisation open source Log4j dans leur logiciel. Bien que la vulnérabilité ait été corrigée avant que les acteurs de la menace ne puissent causer des dommages majeurs, elle a révélé tout ce qui est encore inconnu sur les nombreux logiciels qui font partie d’un large éventail de systèmes.
Et bien que l’attaque de SolarWinds ait affecté les chaînes d’approvisionnement, elle met en évidence un problème de visibilité similaire : trop d’entreprises ne comprennent pas pleinement l’étendue de leurs opérations logicielles ou l’impact de leur code sur leur profil de menace global, offrant aux cybercriminels la possibilité de cibler en arrière- fin des outils d’infrastructure et d’autres vulnérabilités non surveillées.
DevSecOps peut être difficile à mettre en œuvre car il implique un changement de mentalité pour les équipes de sécurité, les ingénieurs et les développeurs. L’analyse de code – une approche courante mise en œuvre dans le cadre de DevSecOps – peut souvent signaler des faux positifs. Ceci, à son tour, crée un travail inutile pour les développeurs et peut les amener à ne pas vouloir suivre les procédures de sécurité appropriées pour vérifier leur code.
Pendant ce temps, les équipes de sécurité sont souvent aux prises avec une perte de contrôle perçue. Les entreprises doivent trouver un meilleur mécanisme pour intégrer l’automatisation à l’expertise humaine afin d’intégrer la sécurité dans le processus de développement sans ralentir les opérations ni minimiser la posture de sécurité globale de l’entreprise.
Comment les entreprises peuvent-elles mettre en œuvre DevSecOps ?
La mise en œuvre de DevSecOps commence par comprendre la culture de l’entreprise et le fonctionnement des développeurs. En raison de leur structure d’incitation actuelle, de nombreuses équipes d’ingénierie se concentrent sur la disponibilité et la qualité des produits, mais la sécurité a également un impact direct sur ces mesures commerciales. Lorsque les entreprises limitent la sécurité à l’équipe de sécurité et délèguent tous les autres travaux de développement à l’ingénierie, elles ratent l’occasion de faciliter une collaboration véritablement productive.
Si les organisations veulent que leurs développeurs intègrent la sécurité dans leur travail quotidien, elles doivent d’abord comprendre les processus, les points faibles et les motivations de leurs développeurs. Répondre à ces questions peut aider les équipes à mieux intégrer la sécurité dans le processus DevOps pour travailler pour leurs développeurs, et non contre eux.
Cela indique également pourquoi DevSecOps doit devenir la responsabilité de l’équipe d’ingénierie. S’assurer que l’ingénierie a une voix dans le processus DevSecOps leur donne un sentiment d’appropriation de la sécurité et leur permet de choisir les outils qui fonctionneront le mieux dans leur environnement spécifique.
Mettre la responsabilité au sein de l’ingénierie est le changement clé pour adopter un état d’esprit DevSecOps.
Et après?
La vitesse à laquelle la technologie évolue ne fera que s’accélérer. Par conséquent, les entreprises doivent donner la priorité à la visibilité sur la sécurité des applications pour suivre ces changements.
Le volume augmente déjà sur la façon dont les entreprises peuvent améliorer leur visibilité pour comprendre où déployer des ressources pour renforcer leur posture de sécurité – et ce volume ne fera qu’augmenter avec le temps. Une nomenclature logicielle (SBOM) est-elle la solution ? Si oui, quel est le meilleur moyen de créer et de publier ce SBOM ?
En fin de compte, la sécurité des applications consiste à faire ce qui est bon pour les clients. Si les entreprises créent et commercialisent des produits non sécurisés, cela nuit à leur réputation commerciale et clients. DevSecOps intègre la sécurité au cœur du succès de l’entreprise afin que les entreprises puissent faire le bien par leurs utilisateurs finaux et par elles-mêmes. Pour accroître l’adoption de DevSecOps au sein d’une organisation, les entreprises doivent faire peser la responsabilité de la sécurité sur les équipes qui élaborent leurs solutions.
Mandy Andress est responsable de la sécurité des informations chez Elastic, une société de recherche d’entreprise, et possède plus de 25 ans d’expérience dans la gestion des risques et la sécurité des informations.
:quality(70):focal(636x359:646x369)/cloudfront-us-east-1.images.arcpublishing.com/elfinanciero/VUUFCUONARCAHL6SLBHDSBXSLU.jpg)
