David Ulloa sees value in the shift-left strategy, which embeds security at the earliest stages of software development. Like other security chiefs, Ulloa believes that this approach can effectively and efficiently boost the organization’s security posture.
But he concedes: not everyone shared his perspective when he first proposed using the strategy.
So, Ulloa, CISO with US drayage firm IMC Companies, set out to convert skeptics, promoting the strategy as a way to create more secure code from the start and highlighting it as a practice that studies have shown can create that increased security more cheaply than addressing security needs at later stages.
Ulloa also demonstrated the need to make the move, hacking a noncritical application to illustrate that code wasn’t as secure as it could be. “I showed what I could have done if I was a malicious actor. It helped make the case to have security as part of development,” he adds.
The tactic worked, getting Ulloa over that initial resistance to adopting a shift-left approach. The company’s security and IT teams moved to DevSecOps, automating more security checks into the developers’ CI/CD pipeline, training workers in shift-left principles and adding security professionals to the development process.
“It’s paid off. It’s day and night,” he says. However, even with those steps in place, Ulloa continues to sell the value of shift-left to help ensure its ongoing success.
Getting security in early saves stress
“There is a message that I typically bring up when I have meetings with development groups: Bring us in early and save yourself a lot of stress; bring us late to the process, you’ll have to do everything over. Because we have to make sure everything we do is secure,” he says.
Ulloa’s experience illustrates only some of the challenges that organizations face when adopting and even advancing a shift-left security strategy.
CISOs, researchers and security consultants say enterprise security teams face multiple obstacles when adopting and evolving a shift-left strategy, any one of which can stymie the efforts to bring security in as early as possible. But those same security experts say the obstacles aren’t insurmountable — and they’re worth working to overcome because the payoff with a successful shift-left strategy can be significant.
“In the world of security, earlier in the process is better,” says Melinda Marks, practice director for cybersecurity at Enterprise Strategy Group (ESG), a research and advisory firm.
Growing adoption and the ‘burden’ on developers
Security has been moving into earlier stages of the development process for years, with an increasing number of development teams bringing security into their fold.
GitLab’s 2023 Global DevSecOps Report, which surveyed more than 5,000 IT leaders, CISOs and developers in multiple industries, confirmed that “DevSecOps teams are becoming more broadly aware of security as a shared responsibility.”
According to the survey, 38% of security professionals reported being part of a cross-functional team focused on security. That’s up significantly from the 29% who reported being part of a cross-functional team in 2022.
In another move in the right direction, 71% of security professionals said that a quarter or more of all security vulnerabilities are being captured by developers, up from 53% of respondents in 2022.
Proponents of shift-left point to multiple studies showing that the strategy delivers results.
A shift-left approach reduces vulnerabilities
Russell Jones, a partner at professional services firm Deloitte, said he has helped organizations implement the approach and has seen up to a 90% reduction in identified vulnerabilities over a product’s lifecycle compared to software that undergoes security reviews later in the development process.
Others note that security costs are also lower in shops that have implemented shift left, noting that it’s cheaper and faster to address security issues earlier than later.
However, despite such findings and the growing adoption of the shift-left strategy, challenges remain.
Consider, for example, some of these figures from the 2022 Global C-Suite Security Survey Report from CloudBees, a maker of a DevSecOps platform: 83% of surveyed C-suite executives agreed that shifting left was important for them as an organization, but 58% said the approach was a burden on their developers. That experience, along with other challenges, can slow adoption and limit the value that the shift-left strategy can bring, security experts said.
“Shift-left is more in practice today than it was, but is it as deep as it could be? Probably not?” says Jon France, CISO of ISC2, a nonprofit training and certification organization.
Implementation is a top challenge
Embedding security earlier into software development is easier said than done; nonetheless, security advisers and researchers say they’ve seen some organizations try to make that shift without enough planning or adequate support for their teams.
“It’s hard for organizations to succeed if they haven’t implemented shift-left programmatically,” Jones says. “You have to have intentional practices, guidelines and playbooks for your entire team because you’re melding together your development and operations teams with security, and if they’re not on board with things like threat modeling and security testing, it’s not going to just magically happen – even with tools in place.”
He advises security leaders to create a “roadmap that outlines the building blocks that need to be in place” – one that, for example, addresses the DevSecOps architecture and policies required by teams to effectively address security early on and that creates repeatable practices.
Jones also recommends that organizations take an iterative approach to their shift-left program, starting with a pilot, then expanding the number of teams and software going through the process, and also tweaking the processes as teams learn from their shift-left work.
Another challenge: dumping security on developers
William Dupre, a senior director analyst with research firm Gartner, says he tends not to use the term shift left because it can create “this idea that you’re shifting security to the development teams, which is not what you’re really trying to do. You want the development team to play their role, but you’re not shifting the onus for security onto them.”
It’s not just that the term leaves that impression with developers: Dupre says he has seen cases where the enterprise shift-left program does, in fact, dump security onto the developers.
“Developers [are told], ‘Now you take responsibility for security,'” Dupre says. “So if you use that term ‘shift-left,’ you might get some cultural strife.”
Dupre prefers the term DevSecOps, which he sees as not only interchangeable with shift-left but a better representation of what the concept is trying to accomplish — which is to have developers and operation teams work jointly with security to ensure secure, quality software products.
He adds: “It’s more about putting security into the process.”
Fears that shift-left will slow down development
Another concern that can stymie the adoption of an effective shift-left strategy is the fear that security will slow down the creation and release of software products, new capabilities and feature upgrades.
It’s not just developers who think that way, experts say; the business leaders clamoring for software products often share that feeling, too.
France says their concerns are rooted in past experiences, where code had to pass through security reviews at the end of development — a schedule that can, in fact, create delays. As France notes, “Security left to the end does slow things down because security then has to retrofit. So, if you’ve always seen security come in at the last moment, then security is, of course, seen as something that slows down the process. That’s an experiential lived lesson for many. And it’s an entrenched position that we have to overcome.”
France says CISOs must prove that a shift-left approach can support both security and speed. He has seen CISOs work with CIOs to introduce elements of the approach and demonstrate with those small wins the potential that could come with a full-scale shift-left strategy.
“It’s working in a low and slow approach and then showing the benefits,” France says.
No incentives for this shift
Developers, security practitioners and their managers don’t just have to overcome concerns about speed; they also must overcome entrenched ways of working.
“This is a big mindset shift for teams,” Marks says, explaining that they have to adopt new processes and tools as they move to DevSecOps.
As such, Marks and others say enterprise executives should give these teams the right incentives to work differently and to embed security into the development process at the earliest possible point.
Security should be incented to “scale and keep pace,” Marks says.
At the same time, developers should have KPIs around security – something they traditionally haven’t had.
“Developers don’t have KPIs around security, because it isn’t their main responsibility. But if you’re not incentivized as a developer to spend more time on security, it will limit the willingness to spend time on security,” says Ankit Gupta, practice director with Everest Group, a research firm.
Gupta says he advises organizations to think about “integrated KPIs,” so all members of product teams and DevSecOps teams as well as any other stakeholders share accountability for meeting expectations around a software product’s speed to market, performance and security.
A lack of the right talent, training
Getting the right talent in place is another essential part of getting DevSecOps/shift-left to deliver success.
That, though, is not always done, says Keatron Evans, vice president of portfolio and product strategy at cybersecurity training company Infosec, part of Cengage Group.
Although developers should not have ownership of security as part of a shift-left approach, Evans says they still should understand what the risks are and how code is being exploited so they can collaborate effectively with security practitioners throughout the development cycle.
He and others say the fix is straightforward: commit to delivering adequate training.
Dupre also advocates for CISOs to look for and enable security champions – “a tester, developer, analyst, project manager, anyone who is bringing up the question ‘Are you thinking about security?'” and find a way to cultivate, nurture and reward that security mindset and evangelism.
At the same time, Evans says organizations need to commit security practitioners to the process – otherwise, it’s just DevOps. “DevSecOps works best when you have a security professional, not just a developer who has a little bit of security knowledge. That’s not the same as having a security person on the team,” he adds.
Without this attention to talent, experts say development, security and operations will likely revert to working in their own siloes.
Trouble with tools
CISOs have a growing list of technologies that can support a shift-left approach, with tools for threat modeling, static application security testing, dynamic application security testing and all sorts of scans available.
Such technologies, along with automation, certainly make it easier for DevOps teams to successfully bring in security.
But it’s not enough to implement such technologies, experts say. Rather, the security function needs to select tools that will work well with the platforms which developers are already using – or even opt to use the security functions already embedded within those development platforms.
The security function also needs to smooth the use of these tools in the development process, especially to start, as alerts could quickly swamp DevSecOps teams and dissuade some from the shift-left process as a result.
“Sometimes organizations will just throw tools at the team and say, ‘You deal with it,'” Dupre says. “And if you do it for the first time, the scanning tools will report a lot of vulnerabilities; especially if products have been around for decades, you’ll get mountains of vulnerabilities, and that can produce anxiety in teams.”
To counter that, security leaders need to give those DevSecOps direction so they know how to triage the vulnerabilities based on enterprise risk factors, Dupre says. Leaders also need to ensure that the teams have a clear understanding that security is responsible for prioritizing vulnerabilities to fix and developers are responsible for fixing them.
Thinking only shift-left, and not the entire lifecycle
As more enterprise development teams adopt a shift-left strategy, security leaders are advocating for them to extend security even further.
“Now it’s not just shift left. It’s shift right, too,” Gupta says. “So once testing is done and the application is in production, how can you move to continuous testing and observability? Basically [it’s about] how comprehensive can you be to make sure the product quality improves over time and to ensure my product is robust post-deployment.”
Marks shares that perspective, similarly advocating for CISOs and their teams to think not shift left or shift right but instead to think of security as “infinite, continuous, more like a circle.” She adds: “Developers are rushing to create and deploy apps and then it’s update, update, update. So how does security keep up with that? To do that, you need a strategy program in place that encompasses the entire lifecycle.”