Changing Mindsets.
Historically developers have prioritized functional requirements over security when building software. While secure coding practices important, they have often fallen 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 as a result of successful adoption of automated security into DevOps practices.
The DevSecOps Community survey revealed that 24% of all participants believe is now a top concern for developers. However, in organizations with self-described mature DevOps practices, 38% of respondents stated that security was a top concern and that 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 overall survey results also revealed that 67% of developers didn’t have enough time to spend on security or believed it to be the responsibility of others.
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 dicated 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 enable developers to learn more about how what they are building can be exploited. 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 offering them a better understanding of the challenges faced by developers to meet deadlines and yet keep their code secure. This practice helps to create empathy and also results to more secure software being built.
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 that 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 0-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 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 a lot more flexibility when it comes to 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 to development teams earlier and therefore enables faster remediation approaches. It is easier for developers who are 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 implemented correctly, developers will benefit from having the right tools and right 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 of the blogs in this series and the survey report, please visit: www.Sonatype.com/2017survey.
