Shortcut, the collaborative home for modern software teams, announced new Team-to-Workflow functionality.
In the world of evolving technology, the delivery of secure and reliable software has never been more important. To compete in today's digital market, organizations must deliver excellent software capabilities as quickly and efficiently as possible, but cannot sacrifice security for speed. The cost of security breaches, the ramification of exposing confidential, personal or credit data to attackers, can have severe consequences for a business. It is both a corporate responsibility and a business imperative. Because when applications are not secure, neither are the various initiatives they have been designed to support.
Guaranteeing the security of applications while maintaining organizational agility can be achieved through strong DevSecOps practices. By automating application security scanning into the CI/CD process, companies can achieve their security objectives in the most efficient way. This allows engineering team to achieve continuous visibility of their services' security posture and remediate vulnerabilities as soon as they are discovered. As a result, productivity gains include more room for innovation, greater on-time delivery and improved product quality.
That said, moving toward DevSecOps isn't necessarily an easy process. Organizations first need to adjust their culture to embrace security and define enterprise-wide application security policies and standards to be enabled through automation. Then, they can invest in the required integration of such techniques in the CI/CD processes, including the means to report on discovered issues as would happen for any other software defects.
But what does this really mean?
To answer this question, and others related to the state of DevSecOps, now and into the future, ZeroNorth surveyed 250 security professionals, engineers, developers and IT professionals from different organizations involved in some form of application development. What we found suggests the journey to DevSecOps is not only on the horizon — it's here.
High Hopes for DevSecOps
One of the main attractions of DevSecOps lies in its ability to significantly reduce application risk, a point clearly reinforced by the ZeroNorth research. When asked about the three greatest benefits to be expected from the move to true DevSecOps, 74% of respondents noted fewer security vulnerabilities in production software, while 56% said fewer flaws discovered in late stages of development.
Both these answers suggest organizations are primarily concerned with mitigating risk throughout the SDLC, from code commit to build to deployment. While this is an excellent goal, many confess they are having trouble reaching it, hampered by a variety of issues. Across people, process and technology, the move to DevSecOps can be a slow one.
What is standing in the way?
Nearly half of respondents (49%) cited pressure to release new applications quickly as a main deterrent, while 56% said the sheer number and overall complexity of AppSec vulnerabilities to remediate hinders their progress to DevSecOps.
Both of these concerns can be countered with a digital solution that simplifies the remediation process while still maintaining the velocity of software development. Through the integration of open source scanning tools, with commercial ones always available, it is possible to stand up an effective AppSec program with comprehensive scanning coverage across applications—quickly, easily and affordably. Finding this capability translates into better AppSec visibility through analytics and reports, as well as seamless integration and orchestration of these tools into DevOps pipelines.
Who Owns Security?
Because security and development professionals must collaborate to implement and run an AppSec program, the question of ownership and accountability remains valid.
Who ultimately "owns" the responsibility of application security and how will that collaborative relationship evolve down the line?
With this question in mind, the ZeroNorth survey asked respondents, "How likely is it that AppSec responsibility will be owned primarily by DevOps in the next three years?"
A majority of 66% felt this move was very likely to occur, while only 7% felt it was not at all likely. Even so, embracing this perspective depends a lot on the role of the participant.
For example, just over half of the AppSec respondents felt the shift to a shared model is likely, followed by 62% of corporate/IT security professionals. But a high majority of 76% of developers and engineers said DevOps will eventually assume the primary responsibility for AppSec in three years' time.
These results tell us that the future ownership model is still being ironed out, but it's likely that both AppSec and DevOps teams will have a role to play in secure software development. More specifically, they point toward a likely scenario where a shared responsibility model emerges, with both teams having clear and defined roles in DevSecOps.
While a full shift of responsibility for AppSec to DevOps is unlikely, the industry will continue to see an emerging model of shared responsibility to enable DevSecOps. Across the board, most people in the field today believe DevOps teams will experience an increasing amount of accountability for AppSec over the next three years, a point that clearly highlights the reality of a growing DevSecOps mindset.
A Vision for the Future
For Security and DevOps teams to successfully evolve toward true DevSecOps, leadership on both sides must be effective. The research delivers good news on this front, as most respondents to the survey stated their organizational leaders understand the need for change and have a clear vision for the future of AppSec. In fact, 63% of participants agreed that both security and development leaders in their organizations have a strong vision for the transition to DevSecOps. Only 5-8% of respondents felt their leadership was failing in this regard, a number that suggests leaders are well on their way to better DevSecOps practices.