In response to market and competitive forces, many companies have turned their attention to developing higher quality and more secure software. Whether that software is their product or is a component of their product, quality and especially security have become required vs optional. To accommodate the security requirements, some companies have adopted DecSecOps overlays to their software development process that can and has caused significant disruption to their process. This blog series is aimed at helping to understand how the transition to DevSecOps need not be traumatic and that a cautious approach that leverages state of the art tools and techniques can be helpful. Consider this blog series a practical approach to DevSecOps.
This first post discusses some of the road blocks that software organizations are facing with their transition to DevSecOps. Click here for the other posts in the series.
Barriers to DevSecOps Adoption
The main barrier to the transition from DevOps to DevSecOps is organizational rather than technical. Many companies are already employing special security teams tasked to ensure application are secure and policies are being following. However, they tend to act as gatekeepers to the release process – nothing gets released without security testing. This approach is prone to be “too little too late” as the security team is usually involved near the end of the development lifecycle and then attempt to “test in” security, something that rarely succeeds. Security needs to be built in from the start, “shifted left” so that security is fully integrated into the process from the start. Let’s break down these barriers:
- Lack of motivation and awareness with security and the risk and impact of security vulnerabilities are to the organization both in terms of liability and reputation. Vulnerability statistics make it clear that many companies are still not taking security seriously enough. This remains so even when 63% of companies had or nearly had vital data breaches in 2019 and each breach cost an average of $3.9 million to deal with.
- Distrust between teams is expected in most organizations but it’s particularly problematic between software developers and security teams. Developers view security as impeding their success and security teams view developers as incapable of delivering secure software.
- Poor Perception of security in that it’s difficult to implement and somebody else’s problem. If security teams are solely responsible for security then it’s easy for developers to delegate to them. Companies often think that security can be tested into the product at the end of development – to disastrous results. Vulnerabilities discovered at this late stage are more difficult to debug with subsequent impacts on time to market, budgets, and product quality and reputation.
- Gatekeeping of release candidates by the security team is source of friction between developers, testers and security experts. Placing security as a last QA-like step before delivering a release is too little too late. Developers also don’t like other teams imposing restrictions on their work which is an issue when trying to put security controls like secure coding practices in place.
- Lack of integration of security practices and tools into the whole development process prevents a security improvement initiative from getting off the ground. In fact, the key tenet of DevSecOps is to integrate security practices into each phase of development.
These barriers might seem daunting but it’s not unlike other corporate cultural shifts. Security teams need to delegate security to development teams as they integrate secure practices as early as they can in their work. Developers need training and understanding of how critical security is to their work. Developers already have an appreciation for safety and quality but lack some of the basics of good security practices.
It doesn’t need to be this way. However, removing these barriers won’t happen overnight so a practical and gradual approach to improving security is needed. The next post in the series introduces the practical approach by starting small before moving onto a larger adoption.
Summary
DevSecOps is a way to build in security into an application and the transition from an existing CI/CD and DevOps process is made easier with right approach. Successful transition depends on breaking down the resistance to security practices that exist in many organizations. Despite the risk and impact that security lapses costs organization there isn’t enough motivation to make the transition to building in security.
For organizations that are motivated, a practical approach is needed to help make the transition smoother and more successful. The following blog posts will detail how…
