DevSecOps: In Time for Security

By Hasan Yasar

4 minute read time

Historically, developers prioritize functional requirements over security when building software. While secure coding practices are important, they often fall into secondary or tertiary requirements for teams building applications against a deadline.

"Software security" often evokes negative feelings among software developers, because it has been associated with additional programming effort, uncertainty, and roadblocks that hinder fast development and release cycles. Lately, that mindset has been changing in large part due to successful adoption of automated security into DevOps practices.

The DevSecOps Community survey revealed that 24% of all participants believe it is now a top concern for developers. However, in organizations with self-described mature DevOps practices, 38% of respondents stated security was a top concern, and their developers spend a lot of time on it. This means that security practices in development have a 60% greater adoption rate in DevOps teams.

The survey results also revealed that 67% of developers didn't have enough time to spend on security or believed it was the responsibility of others.

hasan yasar1.jpg

Encourage New Thinking

There is little doubt that developers will continue to prioritize tasks required by business and market demands. This is where the adoption of DevOps practices can help change the mindset and behaviors of development. DevOps practices can shift the paradigm from dictated rules and guidelines that developers must follow to creatively determining new, easier, and automated ways to absorb secure coding practices early and everywhere throughout the SDLC.

Emphasizing a set of DevOps principles, such as culture, automation, and infrastructure, as code, can help developers learn more about how to exploit what they are building. Rather than just blindly following the required security practices and controls, the DevOps culture encourages developers to think about making their applications secure as part of daily coding activities.

In some organizations, developers are encouraged to think like an attacker who might exploit vulnerabilities in their code. In other organizations, security professionals are encouraged to code, giving them a better understanding of the challenges faced by developers to meet deadlines and yet keep their code secure. This practice helps create empathy and also results in more secure software.

From Reactive to Proactive

Changes to how software is being built can also help development and security teams evolve from reactive to proactive stances. In the past, software security focused on anticipating where and how the attacks would come, and putting up barriers to prevent those attacks, a time consuming process. It is also important to note that most attacks, especially sophisticated attacks, can't be anticipated, which means fixes are often bolted on as new attacks are discovered. The inability to anticipate attacks is why we often see patches coming out in response to new zero-day vulnerabilities.

With DevSecOps approaches, the effort of securing software can be proactively focused on surviving an attack. For example, some organizations are building software with a reduced attack surface that is both quick to deploy and restore. In other words, developers worry less about being hacked, and more about preventing predictable attacks and then quickly recovering from a cyber incident.

Developers are also pursuing creative ways to enable their software to absorb the attacks and continue to function. In other words, the software should bend but not break. This shift in thinking from a prevent to a bend-don't-break mindset allows for more flexibility in dealing with attacks.

Low Drag Coefficients

The burgeoning concepts of DevSecOps focus on increasing the security of applications, while not creating drag on release and deployment cycles. These include adding automated security testing techniques, such as fuzz testing and software penetration testing, to the software development cycle.

Other techniques include automating security analysis within continuous integration platforms to limit the introduction of vulnerable code earlier in the SDLC. This approach enables security concerns to be surfaced earlier to development teams, and therefore faster remediation approaches. It is easier for developers actively working on the code to fix problems that arise in real-time, rather than be alerted to them weeks or months later.

Applying these and other DevSecOps principles can have a big impact on creating an environment that is resilient and secure. When these principles are correctly implemented, developers will benefit from the right tools and insight at the right moment. When security is built into the SDLC early and everywhere, they can build even better software faster.

Want to Learn More about DevSecOps?

This blog is one of seven in a series, providing expert commentary and analysis on the results from Sonatype's 2017 DevSecOps Community Survey.

For access to all the blogs in this series and the survey report, please visit: www.Sonatype.com/2017survey.

Written by Hasan Yasar

Tags