Why shift left alone can't manage your software risk

Application security wouldn’t be what it is today without “shift left,” the concept that security practices should be handled much earlier in the software development lifecycle (SDLC). Shift left brought about new era strategies such as DevSecOps that made security a priority for developers as well as AppSec teams, pushing some security responsibility to software engineers.

Although threats to the software supply chain have made shift left lose its shine in some eyes, the practice is thriving in 2024. GitLab’s 2024 Global DevSecOps Report found that nearly three-quarters of security professionals say they've shifted left or plan to do so in the next year. But there are obstacles to making shift left a reality.

At the recent Elephant in AppSec Conference, leaders shared their takes on the state of AppSec, and shift left was a hot topic. The consensus: Modern software threats demand an all-in risk management strategy.

Get White Paper: Assess & Manage Commercial Software RiskPlus: See the Webinar

1. Development teams should adopt secure coding practices

A key element of shifting left is adopting secure software development practices. This doesn’t remove the onus of securing software from the AppSec teams, but modern software engineering teams must play their part by spotting threats and vulnerabilities that would be harder to detect later in the SDLC. Cassie Crossley, vice president of supply chain security at Schneider Electric, likened the level of responsibility to the concept of duty of care, the legal obligation to adhere to a standard of reasonable care and so avoid careless acts that could result in harm to others.

[Developers] need to be responsible for that duty of care … the same as an engineer building a bridge.

Cassie Crossley

That means, she said, that software developers should not only feel responsible for writing code, managing it, and delivering it by the release deadline; they should also take ownership of designing their software products safely, before the stress of a product rollout.

[Developers] have a responsibility and a duty … that supersedes deliverable deadlines.

Cassie Crossley

2. Shifting left by itself is not enough

One of the founding leaders of the shift left concept, Tanya Janca, recalled teaching others about its importance at conferences worldwide. But Janca, founder of the We Hack Purple community and head of education and community at Semgrep, said it was never meant to be the be-all and end-all for minimizing threats to software supply chains.

Shift left was never a replacement for a real AppSec program.

Tanya Janca

Janca stressed that shifting everywhere — before, during, and after the software development and release process — is necessary to meet today’s threats.

3. Obstacles remain

Dustin Lehr, co-founder and chief product and technology officer at Katilyst, kicked off his presentation by stating that developer culture is in need of great change because it lacks both motivation and ability when it comes to secure software development.

Lehr said developers are not innately security-driven. He advocates starting on the right by creating a sense of understanding about and urgency for shift left among AppSec and SecOps teams, who could then encourage developers to follow clearly outlined “proactive activities” to securely develop software. He said that preventing bad software security outcomes ...

... actually takes action by people, specifically non-security people

Dustin Lehr

Semgrep's Janca said security teams have to put in the effort to build a working relationship with software engineering and release teams.

We cannot change our culture with silence. … [Security folk] need to talk to developers.

Tanya Janca

4. Measure first, then hold accountable

Among the leaders at the conference who are down on shift left was Chris Romeo. The co-founder and CEO of the threat modeling firm Devici said early on in his presentation, “That term is banned from this talk.”

Romeo said he believes that rather than focusing on shifting focus to developers, organizations should be creating a road map to improving their secure software development practices.

An example of a good road map, he said, is the U.S. Cybersecurity and Infrastructure Security Agency’s Secure by Design initiative and related pledge, which ultimately aims to hold commercial software producers responsible for software security. But Romeo dislikes that the initiative serves only as a checklist and lacks a guide for tracking measurable growth in key software assurance areas.

What is measurable improvement? Who defines it? Nobody’s really specified what it is.

Chris Romeo

Worse for him is the voluntary nature of Secure by Design. Signing the pledge isn’t required of major software producers, a sign, Romeo said, that the initiative has a “just do your best” mentality. He believes that by not making the pledge mandatory, the initiative will not greatly improve software supply chain security efforts.

Shift left — and everywhere else

Making software more secure from the get-go is a good goal, but software supply chain attacks are thriving, and there are many points of access across the software supply chain that need attention. Open-source project leads, commercial software development companies, and internal enterprise software engineering teams all must battle against AppSec inertia. But the battle won't be won if developers stick with ingrained software development patterns and AppSec pros are stuck with legacy tool sets built for a more reactive approach to security testing.

A recent RL Blog post on legacy AppSec tools holding back Secure by Design noted:

Software security practices are mired in after-the-fact application security testing (AST) and scan-and-fix cycles, fixations on legacy vulnerability management programs, and endless patch cycles. Additionally, some security pundits believe that CISA's Secure by Design guidelines don't yet address the complexity of the modern software supply chain.

Saša Zdjelar, chief trust officer at ReversingLabs and a longtime security practitioner, said Secure by Design helped mature industry conversation about software security. But he stressed that there's still a lot of work needed before these principles — and the practices around them — can address the complexity of securing software today.

For Secure by Design to deliver on its promise, Zdjelar said, organizations need more holistic application security testing (AST) tools that work for both producers and consumers of software. He explained what he means by "holistic AST" by describing what crash tests did for ensuring the safety of cars.

You crash-test it, and then you provide the insights into how it did from various angles at various speeds, airbags, crumple zones, all those sorts of things that we have agreed are the characteristics of a secure vehicle or a safe vehicle. But you wouldn't crash-test a radio volume knob and a windows up-down button and a seatbelt separately and a rear car seat separately and a visor separately. You crash-test the vehicle when it's been fully assembled so that you know how the system as a whole operates or will perform in that type of environment.

Saša Zdjelar

One of the big problems with the shift-left movement of recent years, Zdjelar said, is that it focuses too intently on component views to the detriment of understanding the context of how it all operates in the completed software package. When Secure by Design is fully realized, the benefit will be early analysis while also doing integrity checks that ensure the crash-worthiness of software before it is shipped.

The Elephant in AppSec Conference is available to watch on-demand here.