How does your business approach application development? If you’re like many companies, DevOps is your watchword, and with good reason. Historically, a strong DevOps program allowed for agile operations, shortened the development lifecycle, and gave customers consistent access to the immediate solutions they demand. DevOps has been a powerful solution for tech companies of all sizes – but the problem is that it’s not enough.
Over the last several years, industry experts have encouraged businesses to shift left, taking a DevSecOps approach to application development. Security, these experts argue, needs to be part of the initial development process if applications are actually going to be secure. Why, then, are so many companies hesitant to deploy a DevSecOps approach? It’s a complicated problem, but one that, with proper examination, can be solved to everyone’s advantage.
Téléchargez le livre blanc DevSecOps Sécurité du cloud Guide
When the concept of DevSecOps was first introduced, one of the first arguments that companies offered against it was that, instead of encouraging agility, foregrounding security would slow application development down. This can happen, but only if companies don’t sufficiently automate the security code review process. As long as that happens, though, DevSecOps doesn’t actually make application development and deployment slower. It can even be faster than the older DevOps model.
Comment le DevSecOps accélère-t-il le processus de développement application ? Lorsque vous créez une application et que vous attendez la fin pour intégrer des éléments de sécurité, vous devez trouver un moyen d’intégrer ces composants vitaux dans l’infrastructure existante. C'est comme construire une tour et essayer d'insérer une poutre au centre une fois terminée. C'est peut-être possible, mais vous devrez perturber tout ce que vous avez déjà fait. Si, par contre, vous optez pour le décalage vers la gauche et que vous renforcez la sécurité au fur et à mesure, vous vous retrouvez avec un système plus solide et des pièces parfaitement emboîtées.
It may sound ridiculous, but if you talk to some DevOps-focused businesses, you’ll occasionally hear people say that a DevSecOps approach leads to more security breaches, not fewer. Like other assertions about DevSecOps, though, this one is also rooted in serious misunderstandings of the practice. While top DevSecOps users report more breaches than their DevOps counterparts, experts agree that this is only because they’re aware of those breaches, not because they actually experience more of them. DevOps-based companies simply can’t detect security breaches.
Obviously, it’s better for businesses to be aware of potential or actual security risks because that enables them to actually address and remedy their weaknesses, but many businesses are hesitant to admit that they’re at risk. It’s important for companies to acknowledge that DevSecOps enables risk detection, and that acknowledging breaches is less likely to damage a company than being oblivious to digital attacks.
La modification des pratiques commerciales peut coûter cher. Qu'il s'agisse de passer d'un ancien ensemble de programmes ou de changer de langage de programmation, tout changement significatif peut suspendre vos activités et vous faire perdre des contrats et des profits. Est-ce également vrai lorsqu’il s’agit de passer au DevSecOps ? Si, à court terme, aider les membres de l’équipe à apprendre de nouveaux systèmes peut freiner les choses, sur une plus longue période, DevSecOps peut maximiser votre retour sur investissement.
Comment une approche DevSecOps peut-elle rendre votre entreprise plus rentable ? Il est certain qu'il est financièrement avantageux de prévenir les problèmes de sécurité majeurs avant qu'ils ne surviennent et de pouvoir agir rapidement en cas d'attaque, mais ce n'est pas la seule raison. Rappelez-vous l’argument ci-dessus selon lequel DevSecOps crée en fait un système plus agile, qui se lance et se met à jour plus rapidement que ce qui serait possible avec une approche DevOps. L'assistance d'experts peut également aider les entreprises à automatiser leur infrastructure de sécurité, en simplifiant ainsi un processus très technique et chronophage.
DevOps highlights two main elements of the application creation process – the development side and the operations, or customer-facing, side – but despite the shorthand conjunction of the two, it doesn’t really connect them. A DevOps approach still allows professionals to work within their familiar siloes. Developers build apps that enable smoother operations, and operations teams may provide guidance and feedback, but they don’t really have to work together. That all changes when companies shift-left to DevSecOps, and that’s a key reason why businesses have been reticent to make the change.
En règle générale, les développeurs application et les professionnels de la sécurité ont travaillé sur des projets séparément, car les fonctionnalités de sécurité ont été ajoutées à l’application plus tard dans le processus de codage. Mais lorsque les fonctionnalités de base de développement et de sécurité sont développées simultanément, ces équipes auparavant cloisonnées doivent se réunir. Pour y parvenir, la direction doit faciliter la communication entre les équipes et encourager la formation polyvalente. Les experts en sécurité ne sont peut-être pas des codeurs professionnels, mais ils peuvent fournir des conseils aux développeurs. Et inversement, les développeurs doivent reconnaître que la sécurité est une priorité fonctionnelle.
Il est d’autant plus important d’accroître les communications entre les développeurs et les professionnels de la sécurité, car la tendance actuelle à isoler l’information en silos est responsable de nombreuses failles de sécurité dans le cloud. En fait, des recherches récentes suggèrent que 60 % des violations se produisent dans le cloud public – le côté utilisateur de l’application – en raison d’un déploiement inapproprié. Les développeurs ne prennent tout simplement pas les bonnes décisions de configuration lorsqu’il s’agit de déploiement dans le cloud, du moins pas sans assistance, ce qui expose les entreprises aux attaques. Le passage à une perspective DevSecOps comble ce fossé, mais peut également renforcer les défenses des développeurs qui pensent qu’ils utilisent déjà les meilleures pratiques.
These four arguments are just some of the reasons that businesses have been slow to shift-left and adopt a DevSecOps approach, but they’re hardly the only ones. Like so many other changes, companies are resistant to change, even when it’s in their best interest. The problem is that sometimes you have to let go of the old ways in order to be successful.
If your business is stuck in the old DevOps mentality, it’s time to move forward – and Check Point can help. Contact us today for a free security assessment and to learn more about how DevSecOps can benefit your company. Making a big change isn’t easy, but with the right support, you’ll see big improvements.