Argument #1: The Slowdown
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.
How does DevSecOps speed the application development process? When you build an application and then wait until the end to integrate security elements, you have to find a way to fit these vital components into the existing infrastructure. It’s like building a tower and then trying to insert a girder into the center after it’s done. It might be possible but you’ll have to disrupt everything you’ve already done. If, on the other hand, you opt to shift-left and build in security as you go, you end up with a stronger system and pieces that fit neatly together.
Argument #2: More Breaches
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.
Argument #3: Expensive Implementation
Changes in business practices can be costly. Whether you’re transitioning from an older set of programs or changing coding languages, any significant change can put business on hold and cause your business to lose out on contracts and profits. Is this also true when it comes to shifting to DevSecOps? While, in the short term, supporting team members in learning new systems can hold things back, over a longer period of time, DevSecOps can maximize your ROI.
How can a DevSecOps approach make your company more profitable? Certainly, it’s financially beneficial to prevent major security issues before they happen, and to be able to act quickly when under attack, but that’s not the only reason. Recall the above argument that DevSecOps actually creates a more agile system, one that launches and updates more quickly than would be possible with a DevOps approach. Expert support can also help businesses automate their security infrastructure, simplifying a time-consuming, highly technical process.
Argument #4: Process Siloes
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.
Generally, application developers and security professionals have worked on projects separately, because security features were added to applications later in the coding process. When the basic development and security features are built simultaneously, though, these previously siloed teams need to come together. To do this successfully, leadership needs to facilitate communication between teams and encourage cross-training. Security experts may not be professional coders, but they can provide guidance for developers. And, conversely, developers need to recognize that security is a functional priority.
Increasing communications between developers and security professionals is especially important because the current tendency to isolate information into siloes is responsible for a lot of cloud security breaches. In fact, recent research suggests that 60% of breaches occur in the public cloud – the user side of applications – because of improper deployment. Developers just don’t make good configuration decisions when it comes to cloud deployment, at least not without support, and that leaves businesses open to attack. Shifting to a DevSecOps perspective bridges that gap, but it can also raise the defenses of developers who think they’re already using best practices.
Getting To DevSecOps
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.
Feedback