This blog is part of a 10-part series that dives into the RSAC 2023 Submissions Trends pulled from our record number of Call for Speakers submissions in 2023. In this blog, we focus on open source and software development.
The speed of software development and the pressure to deliver features quickly has encroached on the time required for comprehensive security testing and code review. In addition to faster development cycles, the increased use of open source and cloud computing has reinvigorated the “shift left” and “shift right” dialogue.
The shift left, shift right question in software development remains ongoing as developers debate when key activities should be incorporated into the development lifecycle. Those in favor of a shift left approach argue security should be integrated early in the lifecycle with a focus on addressing vulnerabilities and other potential security risks. Those in favor of a shift right approach support testing under real-world conditions once an application is already in production. The question was up for debate at RSA Conference 2023.
In Hacking Exposed: Hacking the Sec into DevOps, Stuart McClure and Chetan Conikee of Qwiet AI started out by reminding us why the debate exists in the first place with a simple statement: code is the new attack vector. Recalling his days as a developer, McClure said, “I used to think very linearly. I used to think a to b to c to d in terms of code. Things are changing and attackers are now changing along with it. They are thinking geometrically about how every single condition in any section of code can be exploited.”
McClure and Conikee focused their session on exposing weaknesses in source code through the demonstration of hacks on real systems, and more importantly, how threat actors think. Most often, it is not a single vulnerability that enables a successful attack but rather a chaining of exploits that must occur to compromise a target. McClure stated, “This is what threat adversaries are coming after. They are pulling together a whole bunch of different pieces to make a whole campaign work.”
In a separate session, Mike Rothman, Chief Strategy Officer of Techstrong Group, shared results of research he conducted on the trends in DevOps is Now DevSecOps. Surveying thousands of global businesses, Rothman stated his research found the definition of what the term DevSecOps means will vary depending on who you ask.
From a DevOps perspective, Rothman shared the standard thought process tends to be, “We need to do things faster. We need to roll out more software. We need to do it with higher velocity.” But the problem with this is attention is not being paid to how the whole environment is changing which raises the debate of when to insert security into the development process.
Perhaps the shift left, shift right debate should start not with timing but rather ensuring the resources and training are available to do it right. Among respondents in Rothman’s research, about half (49%) stated time and resources is their biggest roadblock to implementing DevSecOps. “Here is the irony to all of this. DevSecOps is supposed to save us a whole bunch of time and make it more efficient for us to do stuff, yet we don’t have the time and the resources to make that happen,” observed Rothman.
So where are organizations currently focusing their time? According to the research, while 43% of organizations are identifying and remediating security issues in the coding stage (shift left), still nearly 20% state that this is happening when the software is rolled in production and already running live in the environment (shift right).
With developers under intense pressure to push out new products and updates in shorter timeframes, Rothman stated that adding security considerations into that process leads to pushback, and he recognizes their objections are valid. Rothman advocates for better partnerships between security and developers as early in the software development process as possible. Rothman said, “Developers know how to develop code, but they don’t know about some simple things that they can do to ensure the applications they are rolling out aren’t Swiss cheese.”
Security professionals can make the life of their developer counterparts easier by building secure design patterns or templates that integrate security in ways that make their job easier and assures some level of security before going live. He also suggests that providing the proper training and tools to developers is imperative. However, most organizations are not quite there yet. In his research, Rothman found that 55% of developers responded that the security resources they needed are only somewhat available or lacking most of the time.