The lack of standard practices in the DevOps communities is causing growing friction as security teams line up against developers. This internal friction leaves software they develop and organizations that use the apps vulnerable to attacks and breaches.
A report released Sept. 30 by open source security and license management company WhiteSource explores various factors contributing to the siloed software development culture and what steps are needed to achieve agile, mature, DevSecOps practices — which involves integrating IT security as a shared function among all DevOps teams.
The report shows feelings of increased pressure among software development teams to overlook security features to meet short development lifecycles.
That finding is especially significant in light of revelations that more than half of all developers polled in the report said they have either no secure coding training or only an annual event. Add to this lack of security training among software coders the finding that fewer than one-third of organizations have a defined, agreed-upon vulnerability prioritization process.
The DevSecOps Showdown
Perhaps an even more alarming dilemma is that on average just half of the organizations have an AppSec champion on their teams. More evidence of the security divide between teams is that even when security professionals say there is one, developers do not always agree, according to the report entitled “WhiteSource DevSecOps Insights, Security vs. Developers: The DevSecOps Showdown.”
“If developers feel they are neglecting security to stay on schedule, something in the DevSecOps process is broken,” warn the report writers.
WhiteSource surveyed over 560 application security professionals and software developers. Those results show that while most security professionals and developers believe that their organizations are in the process of adopting DevSecOps, most organizations still have a way to go, according to Rami Sass, CEO and co-founder of WhiteSource. The distance yet traveled is especially significant when it comes to breaking down the silos separating development at security teams, he noted.
“Full DevSecOps maturity requires organizations to implement DevSecOps across the board. Processes, tools, and culture need to evolve in order to break down the traditional silos and ensure that all teams share ownership of both security and agility,” Sass said.
Other Key Findings
The WhiteSource report took aim at gaining a better understanding of the level of DevSecOps maturity inside organizations. Much of the results indicate that the DevSecOps process is till immature and insecure.
The report found that in order to meet short deployment cycles, 73 percent of security professionals and developers feel forced to compromise on security. In addition, companies purchased AppSec tools to ‘check the box’, disregarding developers’ needs and processes. This practice results in tools being purchased but not used.
A significant “AppSec knowledge and skills gaps” challenge exists in many organizations teams. The report found that organizations largely neglect this knowledge gap.
Security professionals’ top challenge is prioritization, at least in theory. But in practice, organizations lack the standardized processes to streamline vulnerability prioritization, according to the report.
Deep Dive Into DevOps Culture
TechNewsWorld discussed with David Habusha, vice president of product at WhiteSource, the state of DevSecOps in light of the report.
TechNewsWorld: How is siloed culture different from other software cultures?
David Habusha: The siloed approach is a legacy leftover from the waterfall methodology. In siloed culture critical elements in the software development lifecycle, like security, are treated as a specialized field, placed under the responsibility of a dedicated team and addressed in one specific phase in development. When it came to security, that was dealt with towards the end of the software development lifecycle.
The term “waterfall methodology” is often applied to the software development process. It follows a linear project management approach in which stakeholder and customer requirements are gathered at the beginning of the project. Then the development team applies a sequential project plan to accommodate those requirements.
Most organizations today understand that security needs to be dealt with throughout the DevOps pipeline, starting from the earliest stages of development. In order to do this, the silos need to be broken down and responsibility for application security needs to be shared across teams. That way, security issues are not addressed only in late stages of development, when they are more costly to fix and often delay the release.
TNW: What factors contribute to a siloed culture?
Habusha: Siloed culture is a persistent inherited legacy approach. While most organizations understand that the walls between development and security need to be broken down, many are struggling to put that understanding into practice.
There are many factors contributing to organizations’ difficulty to completely abandon siloed culture. In order for organizations to successfully shift security left and help development teams share ownership over security, they need to address organizational culture, update their processes, and implement automated tools.
Currently, developers still lack the AppSec knowledge and skills that they need in order to address security. They also need security tools that integrate into their development processes and environments, so that they can easily detect, prioritize, and fix security issues without slowing down development.
Lack of communication between teams is also a huge barrier to security and development teams working together, sharing responsibility and ownership over application security throughout the DevOps pipeline.
TNW: What steps are needed to achieve agile, mature DevSecOps practices?
Habusha: There is no magic switch to achieving DevSecOps maturity. It requires a lot of changes and adjustments to the traditional approaches to the software development lifecycle. This includes updating our attitudes, skill sets, processes, the tools we use, the way we communicate, the structure of our teams, and more. DevSecOps maturity is a marathon, not a race.
One of the main steps that help achieve DevSecOps maturity is to bridge the application security knowledge gap by providing developers with continuous AppSec training, including secure coding. This is a great way to address AppSec right from the start, by teaching developers how to avoid application security issues from the earliest stages of coding.
Placing AppSec champions in development teams is another smart and effective strategy for bridging the gap between the security and development teams. This boosts developers’ AppSec knowledge and skills and opens lines of communication between teams.
A third important step is to integrate AppSec security tools throughout the DevOps pipeline. When choosing these tools, it is crucial that decision-makers purchase tools that integrate seamlessly into developers’ environments and that will be easy for developers to adopt.
TNW: How does this create a sense of shared ownership among competing factors among teams?
Habusha: In order to cultivate a culture of shared ownership over security, it is important for organizations to create a comprehensive application security policy to be maintained among all teams. That helps all teams share a sense of responsibility for application security.
TNW: How is this impacting on DevOps development?
Habusha: When organizations invest in taking steps towards DevSecOps maturity, security is integrated into the DevOps pipeline from the earliest stages of development. That means that security and development teams work together to address security issues from the start.
Integrating security into DevOps development means providing developers with all of the support that they need to address application security tasks without slowing down development. That includes automated security tools that help developers address security throughout development, having a shared application security policy across teams, and enabling and encouraging open communication between security and development teams.
TNW: What are the most significant takeaway from the latest WhiteSource DevSecOps Insights Report?
Habusha: The most significant takeaway from our DevSecOps Insights Report are that while most organizations feel that they are in the process of achieving DevSecOps maturity, they still have a way to go. This is evident from the fact that most security professionals and developers — 73 percent of the 560 plus AppSec professionals and developers that we surveyed, feel forced to compromise on security. When we look at the data from the report, it is easy to see the many barriers to DevSecOps adoption.
TNW: What role can specialized security tools play in overcoming friction on teams related to building in better security?
Habusha: We found that security professionals barely consider developer adoption when choosing AppSec tools. This explains another concerning reality that we discovered: many of the AppSec tools purchased are not used by developers. When DevSecOps tools are purchased just to “check the box” rather than encourage developer adoption, security cannot be successfully integrated throughout development.
TNW: Can DevOps automated tools coexist with more attention to reliable software security?
Habusha: The best automated DevOps automated tools offer security solutions so that teams can easily bake security into development, from the earliest stages of the DevOps pipeline. These are the new generation of DevSecOps tools.
DevSecOps tools can be seamlessly integrated into developer environments so that they can address security easily, throughout development. Today’s DevSecOps tools can go much further than detecting vulnerabilities.
Rather than just presenting security and development teams with an overwhelming list of security vulnerabilities that they need to address, advanced DevSecOps tools integrate into the DevOps pipeline and offer developers and security prioritization technologies.
Automated prioritization helps teams avoid friction and ensures that they are addressing the most critical issues first so that they do not waste valuable time debating what to fix first, or addressing issues that do not impact their projects.
In addition to automated prioritization, advanced DevSecOps tools can also offer actionable remediation insights and automated version updates, further helping organizations ensure that security does not slow down development.
TNW: What other barriers do DevOps teams have to overcome?
Habusha: An additional barrier we found to DevSecOps was that most developers are not getting the AppSec training that they need, even though security professionals stated that one of the top challenges they are dealing with is lack of skilled AppSec personnel.
TNW: Why is it important for organizations to have a defined and agreed-upon vulnerability prioritization process?
Habusha: Vulnerabilities prioritization is a top challenge for security professionals. Most development and security teams still lack a standardized process. Teams often rely on ad-hoc practices or separate guidelines.
Lacking an agreed-upon process for vulnerabilities prioritization delays remediation of security vulnerabilities. It also causes further friction between security and development teams.
TNW: Why is software security still considered secondary to development speed?
Habusha: Most organizations understand the need to invest in application security. Unfortunately, many still believe that integrating security into the DevOps pipeline will slow down development.
That does not need to be the case. One of the main reasons for this misperception is the way security vulnerabilities were addressed per the waterfall methodology. Then, after development, the security team would come in, analyze and test the project, and get back to development with a long list of security issues that needed to be addressed before releasing the product.
This process of detecting security vulnerability late in the software development lifecycle was very costly and slowed down development. The DevSecOps approach offers a quicker, cheaper, more secure, and all-around more efficient way to address security throughout development while sticking to increasingly shorter release cycles.