48 % estiment que la sécurité est un frein majeur à la livraison rapide de logiciels
28 janvier 2020
0 minutes de lectureAlors que les équipes et les entreprises s’empressent d’intégrer la sécurité à toutes les étapes du cycle de développement logiciel (SDLC), les difficultés prennent de nombreuses formes. Pour faire face à l’accélération de la livraison logicielle et au manque de ressources disponibles en sécurité, les entreprises doivent prendre des décisions en matière de culture, de processus et d’outils : façonner leur culture interne, trouver les bons outils à intégrer aux workflows d’ingénierie pour aider les développeurs à gagner en autonomie, tout en réduisant les interruptions et les tâches imprévues.
À chaque annonce de fuite de données, les entreprises prennent davantage conscience qu’il faut intégrer la sécurité dès le début et tout au long du cycle de développement logiciel (SDLC), afin de protéger la vie privée et les actifs des clients, de sécuriser les fonctionnalités et de préserver la rapidité de livraison. Pour y parvenir, le DevSecOps doit être guidé par la sécurité, mais porté par les développeurs.
Bien maîtriser le DevOps est essentiel pour mettre en place le DevSecOps
Plus une entreprise progresse dans son parcours DevOps, plus elle est susceptible d’adopter des pratiques de sécurité. Lorsqu’elle adopte largement les outils et la culture DevOps, elle est bien placée pour renforcer les pratiques de sécurité et mettre en œuvre le DevSecOps. Dans ce contexte, l’automatisation constitue un socle et les ingénieurs de toute l’entreprise sont encouragés à collaborer entre services et à agir pour améliorer la sécurité.
Nous avons récemment mené une étude sur l’adoption du DevOps et du DevSecOps. L’un de ses principaux enseignements : 48 % des répondants estiment que la sécurité est un frein majeur à la livraison rapide de logiciels.
Télécharger le PDF DevSecOps Insights 2020
La sécurité est-elle vraiment une responsabilité partagée ?
Tout le monde parle de la sécurité comme d’une responsabilité partagée dans l’ensemble de l’entreprise. Alors, pourquoi est-il si difficile de concrétiser ce principe ? Le rapport Puppet State of DevOps propose une explication cynique, mais assez répandue : les préoccupations liées à la sécurité sont souvent perçues comme un moyen d’éviter d’être tenu responsable, plutôt que comme une façon d’améliorer de manière mesurable le niveau de sécurité global de l’entreprise.
Autre question cruciale : la sécurité des applications relève-t-elle uniquement de l’équipe sécurité ? Le rapport Snyk State of Open Source Security 2019 révèle que 81 % des répondants estiment que les développeurs devraient être responsables de la sécurité, mais qu’ils ne disposent pas des compétences ni des moyens nécessaires.
Selon cette enquête, les développeurs sont responsables de la sécurité de leur code et de leurs applications.
Comment les aider à mieux réussir ? Comment donner à ces champions de la sécurité les moyens d’intégrer davantage la sécurité à leurs workflows ? Une question peut-être encore plus controversée serait : qui doit appliquer les correctifs de sécurité, et qui doit les trouver ?
À mesure que le DevSecOps s’impose, certains se demandent si la sécurité ne freine pas les cycles de développement rapides. Contrairement au DevOps, salué pour accélérer la livraison logicielle des équipes agiles, la sécurité est perçue comme un facteur de ralentissement. Les équipes subissent une pression constante des parties prenantes de l’entreprise, qui réclament la livraison urgente de nouvelles fonctionnalités et la placent systématiquement avant la dette technique et les problèmes de sécurité. Souvent laissés sans solution, ces problèmes risquent de ralentir le développement logiciel et représentent un risque majeur pour l’entreprise.
En effet, selon le rapport Puppet, 48 % des répondants estiment toujours que la sécurité est un frein majeur à la livraison rapide de logiciels.
Les pratiques de sécurité traditionnelles interviennent tard dans le SDLC, par exemple au moment de passer une version en assurance qualité (QA). Même pour les équipes qui adoptent la livraison logicielle agile par sprints courts, les revues de sécurité restent ponctuelles, par exemple trimestrielles, et ne sont pas intégrées au développement ni aux étapes automatisées de build et de test.
L’intégration des outils est essentielle
Les logiciels « dévorent le monde » et cette tendance ne ralentit pas. On voit de plus en plus de technologies traditionnelles migrer vers le logiciel : du réseau défini par logiciel aux fournisseurs cloud, qui transforment la gestion de services traditionnels en Infrastructure as Code (IaC).
À mesure que les logiciels prennent le contrôle d’une part croissante de notre environnement, les développeurs jouent un rôle clé dans la gestion efficace des enjeux de sécurité, car ils ont un impact direct sur le code et sa sécurité. Les principaux écosystèmes de développeurs adoptent cette évolution, comme en témoignent les intégrations de sécurité proposées sur GitHub, l’une des plus grandes plateformes d’hébergement de dépôts de code.
Pour répondre à l’agilité exigée par le DevOps, les outils doivent intégrer l’automatisation, de la détection des risques jusqu’à leur correction. Les ingénieurs peuvent ainsi traiter les problèmes de sécurité de manière proactive et réduire rapidement les risques. Les outils efficaces doivent aussi fournir le contexte nécessaire pour aider les développeurs à évaluer et hiérarchiser les risques. À tout moment, le volume des _risques potentiels_ est immense, ce qui génère du bruit pour les équipes de développement comme pour celles de sécurité. Pour réduire efficacement les risques liés aux applications et aux services, il est essentiel de savoir où se situent les risques les plus élevés.
Cela permet non seulement aux ingénieurs de traiter les problèmes de sécurité, mais aussi de réduire la période pendant laquelle les vulnérabilités sont exposées, diminuant ainsi le risque global pour l’entreprise et ses actifs.
79 % des entreprises sont à mi-parcours de leur évolution DevOps
Le rapport Puppet State of DevOps fait le point sur l’adoption du DevOps et son niveau de maturité dans différentes entreprises, ainsi que sur les conséquences pour l’adoption de la sécurité.
Le rapport révèle notamment que 79 % des entreprises se situent à un niveau intermédiaire de maturité DevOps. Elles rencontrent également des difficultés pour faire évoluer leurs outils, leur culture et leurs pratiques afin de concrétiser les promesses et les avantages du DevOps.
Pour accompagner les entreprises aux premières étapes de leur adoption du DevOps, Puppet recommande de mesurer les résultats métier et d’utiliser des indicateurs liés au DevOps. Cette approche reflète la situation actuelle et indique les prochaines étapes à suivre pour parvenir à une adoption plus mature du DevOps.
Poursuivez votre lecture avec notre étude DevSecOps Insights 2020 :