DevOps et les équipes de sécurité ont longtemps été en conflit les unes avec les autres sur le pipeline de livraison d’applications logicielles. Les équipes DevOps ont en fait traditionnellement considéré les équipes de sécurité comme le « service de prévention des versions » avec des approches trop conservatrices de l’atténuation des risques. Pendant ce temps, les équipes de sécurité pensent que les versions accélérées de logiciels présentent un trop grand risque pour la gouvernance, la sécurité et les contrôles réglementaires. Pour résoudre les deux, de nombreuses organisations ont en fait tenté de déplacer la sécurité et la conformité en exécutant des étapes plus tôt dans la procédure de développement.
Bien que cette technique DevSecOps restreinte améliore la qualité et la livraison de l’application logicielle, cela ne résout pas tout le problème. Les entreprises avant-gardistes ont en fait compris qu’il est inadéquat de déplacer la sécurité et la conformité vers la gauche ; ils doivent les déplacer partout.
En incluant les processus de sécurité et de conformité dans l’automatisation de bout en bout, les services peuvent sécuriser les logiciels tout au long de la chaîne d’approvisionnement des applications logicielles, améliorer considérablement l’expérience des concepteurs et accélérer la sécurité des livraisons. Pour y parvenir, les entreprises doivent se débarrasser de ces 7 mythes DevSecOps typiques qui les empêchent de faire le changement.
7 mythes DevSecOps
Mythe 1 : la sécurité et la conformité constituent un point unique dans le processus de livraison de logiciels.
Vérité : la sécurité et la conformité sont plus efficaces lorsqu’elles sont constantes tout au long du pipeline. Les entreprises qui considèrent la sécurité et la conformité comme des occasions, doivent souvent éloigner des groupes entiers d’avancement des activités créatrices de valeur pendant des durées tout au long de l’année pour gérer les exigences d’audit. Cette méthode augmente considérablement la « taxe de conformité » d’une entreprise. Si la sécurité n’est pas intégrée dès le départ, les groupes de sécurité passent plus de temps à revenir en arrière et à résoudre les problèmes, temps qui n’ajoute aucune valeur productive à l’entreprise.
Idée reçue 2 : L’ajout d’outils supplémentaires aidera à résoudre les obstacles en matière de sécurité et de conformité.
Réalité : bien que les outils puissent certainement contribuer à la sécurité et à la conformité, des options uniques ne résoudront normalement pas le problème global. Plus de personnes sont généralement nécessaires pour utiliser les outils et évaluer les résultats. Les responsables de l’avancement doivent alors consommer les résultats et se concentrer sur les actions des concepteurs. Alors que plus d’outils peuvent aider, plus d’outils peuvent également simplement indiquer une complexité accrue. Trouver un service unique et complet, plutôt qu’un ensemble d’outils, sera plus fiable et produira moins de points de défaillance potentiels en donnant une vue globale de la position de sécurité et de danger d’une entreprise.
Mythe 3 : former les développeurs à devenir des professionnels de la sécurité et de la conformité permettra d’éviter la non-conformité.
Réalité : vos concepteurs souhaitent très probablement innover, et non effectuer des tests ou décoder les structures réglementaires. Les concepteurs doivent absolument s’inquiéter de la sécurité – nous disons ici que la sécurité est l’affaire de tout le monde – mais s’attendre à ce que les groupes d’avancement s’occupent de la sécurité en plus de leur description de tâche est un bon moyen d’étouffer le développement et de taper l’amertume.
Idée reçue 4 : intégrer des professionnels de la sécurité dans les équipes DevOps résoudra la difficulté.
Vérité : disposer d’un expert en sécurité dédié au sein du silo d’avancement peut être utile pour libérant les développeurs pour innover. Néanmoins, cette méthode peut encore déclencher des interruptions chez les concepteurs et creuser le fossé entre les deux équipes.
Idée reçue 5 : mon entreprise est trop petite ou obscure pour être la cible d’un cyber-attaque.
Réalité : Le coût moyen d’une violation de données pour une entreprise se chiffre en millions et augmente rapidement. Aucune organisation ne devrait se sentir à l’aise de jouer avec ce type de profit. Chaque entreprise, de toutes tailles et de tous secteurs, est en danger et doit prendre la sécurité au sérieux.
Idée reçue 6 : si j’automatise, je suis en sécurité et conforme.
Vérité : l’automatisation est essentielle à la sécurité et à la conformité, mais de nombreux outils d’automatisation sont des solutions ponctuelles au lieu d’une automatisation de bout en bout. Si vous publiez des outils pour automatiser des points uniques de votre pipeline, ces parties seront plus sécurisées. Si vous publiez des outils pour automatiser l’ensemble de votre pipeline, l’ensemble de votre pipeline sera mieux protégé.
Idée reçue 7 : adopter DevSecOps suffit.
Réalité : il ne suffit pas de réorganiser votre pipeline d’expédition de logiciels pour réparer les silos dans entre les groupes de développement et de sécurité. La culture de votre organisation doit également être remaniée. Oui, la sécurité doit être l’affaire de tous ; mais le développement et la productivité doivent également être une priorité pour toutes les équipes.
Sécurité de bout en bout
Déplacer la sécurité de bout en bout grâce à un service d’expédition de logiciels de bout en bout vous permet d’intégrer la sécurité dès le départ et tout au long du pipeline. Fini le temps des audits de sécurité d’un mois qui freinent les progrès et les performances. Advanced DevSecOps permet un contrôle automatisé de la sécurité et de la conformité tout en imposant l’utilisation d’éléments approuvés.
L’automatisation de bout en bout limite l’introduction de failles de sécurité dues à une erreur humaine, et si quelque chose ne fonctionne pas, il est beaucoup plus facile de découvrir et de réparer le problème avant que le code compromis ne soit livré. L’accès aux contrôles est automatisé pour gérer qui peut apporter des modifications et quand, en s’assurant que personne ne modifie par erreur des parties critiques sans être observé.
Éliminer les silos grâce au pipeline partagé
Avec un partage plate-forme de pipeline qui couvre l’avancement, l’assurance qualité et les opérations, les entreprises ont un contrôle et une présence avancés sur l’ensemble de la procédure de développement du système. Les groupes de sécurité, d’avancement et d’exploitation obtiennent une compréhension holistique partagée de l’ensemble du domaine numérique, ce qui leur permet d’innover avec un point de vue éclairé.
Un pipeline partagé permet de capturer la pré-version du code de problème. Plutôt que de réparer les vulnérabilités après la livraison, des réparations incrémentielles peuvent être déployées pour résoudre les problèmes au fur et à mesure qu’ils surviennent. Une plus grande exposition implique une bien meilleure compréhension du pipeline pour tout le monde, ce qui à son tour améliore l’interaction et aide à se débarrasser du blâme.
Activer la livraison progressive
Un envoi de logiciel de bout en bout permet une expédition progressive de votre logiciel pour accélérer les versions sûres et protégées. La livraison progressive présente un tout nouveau code sur une base continue, plutôt que via des versions « énormes ». Cette méthode atténue les risques en filtrant le code à petite échelle avec la possibilité d’annuler rapidement tout code problématique qui apparaît (gestion des fonctionnalités). La livraison progressive transforme une version d’application logicielle en un processus progressif à faible risque avec une gouvernance de confiance et fournit un « interrupteur d’arrêt d’entreprise » si quelque chose de grave se produit en production.
La livraison progressive donne également aux développeurs plus de liberté pour innover. Dans l’environnement de publication de logiciels à faible risque, ils peuvent expérimenter davantage avec moins de risques et sur un calendrier plus polyvalent. Les équipes de développement ont besoin d’espace pour produire ; InfoSec nécessite sécurité et gouvernance. Un pipeline logiciel de bout en bout satisfait les deux, ce qui se manifeste par une commercialisation plus rapide des produits.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
