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.
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.”
