sdecoret - stock.adobe.com
Boost application security in DevOps with DevSecOps
Without DevSecOps, application security can end up on the back burner during application development. Learn how DevSecOps can bake security back into the process.
Software developers have a lot to contend with when it comes to keeping their skill levels current. features are constantly to integrated development platforms, and programming languages evolve frequently, as do development methodologies, like Waterfall. On top of these moving parts, developers have to deliver projects on time and in budget, follow security coding best practices and remain compliant with industry regulations.
Many developers have adopted DevOps, the principle of integrating development and IT operations under a single automated umbrella, which streamlines frequent feature releases and increases application stability. However, it can be difficult for security and compliance monitoring tools to keep up with this pace of change, as they weren't built to test code at the speed DevOps requires. Security is largely regarded as the main obstacle to rapid application development, and as a result, application security in DevOps has suffered.
In the long term, applications with security built in from the beginning are far more likely to resist attack and avoid potentially devastating interruptions to daily operations. This is why the DevSecOps application security movement is so important -- and why developers need to understand its relevance to their work and how it can improve their output.
Ryan O'Leary, former chief security research officer at WhiteHat Security said: "Our average customer takes 174 days to fix a vulnerability found when using dynamic analysis in production. However, our customers that have implemented DevSecOps do it in just 92 days." Likewise, he added: "If we look at vulnerabilities found in development using static analysis, an average company takes 113 days, while the DevSecOps companies take just 51 days."
The concept of shifting security left assumes everyone is responsible for security, in contrast to incident response, where the security team is called in at the end. Adding more automation from the start reduces the chance of misadministration and mistakes. Automated security functions, such as identity and access management, firewalling and vulnerability scanning, can be enabled throughout the DevOps lifecycle.
Security and risk management leaders need to adhere to the collaborative nature of DevOps to create a seamless and transparent development process. To do this, developers need to ensure security is included in all decisions and lifecycle processes.
This is very much a two-way street. Software developers need to fully understand current and proposed security processes and lifecycles. For example, where are the shortcomings in regard to adding security in?
Likewise, consider what is already in place to ensure application security in DevOps, as well as tools and skills that will need to be used and learned. For example, do developers have tools to check for vulnerabilities during the local build process, or do they do this in the continuous integration/continuous delivery process? Also, do company development processes mandate a security element check the code is secure at each build process?
Most organizations have clear governance of risk, and derived security policies are a product of that. Newer ways of thinking, such as making a transition to DevSecOps, require implementing processes to bake those security policies into DevOps processes. In order to produce positive results when baking application security in DevOps, organizations should combine development, security and operations teams, shorten feedback loops, reduce incidents, and define and emphasize shared security responsibilities.
The time it takes to fix a vulnerability is a good measure of whether your DevSecOps application security program is effective enough. This time frame reflects security team agility, as well as how they handle and prioritize issues that come up.