The concept of "shifting security left"—integrating security practices earlier in the development lifecycle—is a core tenet of modern software development. However, many organizations get it wrong. They treat it as an exercise in responsibility-dumping, pushing tasks onto already overloaded development teams and ultimately slowing down velocity.
The goal of security shouldn't be to slow down the train; it should be to lay the track so the train can go faster and safer. Here is a framework for achieving effective, frictionless security integration, straight from industry experts.
Stop saying "Security is everyone's responsibility"
The biggest hurdle to a successful Shift Left strategy is a fundamental misunderstanding of accountability.
It's common to hear the mantra that "security is everyone's responsibility." While this sounds good on a poster, it often translates into the security team identifying a problem, throwing it over the fence to the developers, and then "walking away".
This approach is flawed for several reasons:
- Accountability Must Be Clear: If you are a security engineer or a member of the security team, you should be the person held accountable for security outcomes.
- Respect Specialization: When you hire a highly paid, specialized engineer (like a machine learning expert), you hire them for their core skills, not to spend a significant portion of their day on security maintenance.
- Security as a Center of Excellence: Security must act as a center of excellence that delivers solutions, not just a team that reflects responsibility.
Security needs to lead the change by providing the expertise, the automation, and the tools that enable secure development, rather than simply requiring it.
The golden rule: Make it easy, effective, and delightful
To successfully shift security left, you must make the processes "so easy they can’t say no". This means offering solutions that developers cannot refuse.
The key to achieving this is reducing friction and maximizing context:
Reduce friction with seamless tools
- No Slow Tools: Any security tool introduced must be fast, tested, and verified. A tool that slows down the build pipeline or development process is a non-starter.
- Integrate, Don't Interrupt: The tools must seamlessly integrate with the developer's workflows. For instance, if developers are adopting new coding assistants (like Cursor), the security team needs to be aware and figure out how to integrate security rules directly into that environment.
- Good Security is about Flow: The principle to follow is that good security is about "making the right thing easy and the wrong thing hard".
Measure success by reduction
If you want to track the success of your Shift Left program, look at the developer experience metrics:
- Reduce Meetings: Track the amount of time developers are pulled into security-related meetings, and strive to eliminate them.
- Reduce Documents: Minimize the amount of dense security documentation developers are required to read.
Context is king 👑
When vulnerabilities are surfaced to developers, they must be relevant and actionable. This requires sophisticated context engineering.
- Be Conservative: The security team must be conservative in what they send to developers, ensuring that only vulnerabilities that are truly important (such as those that are reachable in production) are prioritized.
- Build Trust: By only raising alerts that matter, you build trust with the development team. This ensures that when an alert is sent, they know it is important and worth acting on.
Reducing "outer loop" activities and building defense-in-depth
Effective Shift Left also requires looking at the broader context of a developer's day and the overall architecture.
Automate the "Outer Loop"
Studies show that developers spend a significant portion of their time (anywhere from a 1/3rd to 60%) on what are called "outer loop tasks." These are non-core duties like maintenance, remediating vulnerabilities, and dealing with infrastructure. If you want to free up your talented engineers for feature development, you must intentionally reduce and automate these outer loop tasks.
Paved paths with platform engineering
This is where Platform Engineering becomes a critical partner to DevSecOps. Platform engineering is consistently prioritized by organizations as a way to implement security and compliance guard rails. A mature platform can abstract away the complexity of security, making it frictionless for the developer and ensuring security is baked into the default path.
Defense-in-depth buys you time
Finally, remember that shifting left is not the entire solution. You must maintain a continuous security loop that includes runtime protections.
- A developer's priorities are constantly competing with business and feature directives. Even a critical CVE might not be the top thing they can work on immediately.
- Tools like a Web Application Firewall (WAF) or other runtime protections can serve as a defense-in-depth layer that buys you time. This allows the development team to balance security fixes with business priorities, ensuring that everything doesn't feel like a constant fire drill.
Transcript from LeanAppSec Live Q&A with panel
[00:00] - Jenn Gile: What's the best approach for shifting security left without overwhelming devs or slowing velocity? How much time do you have? [laughter] I know. Um, we've got about, you know, uh, 10 minutes or so that we can talk about this question. And I think, you know, Ammar and Katie both have very different backgrounds to be able to talk about this and talk about what you've seen, um, people doing. So Ammar, maybe you could start us off. Um, what are some, like if you had to say three things, you know, as a former developer and now as a security program owner, what do you need to do to like meaningfully shift security left?
The misperception of shifting left
[00:46] - Ammar Alim: Yeah, um, so security, shift security, so I, I lead DevSecOps for Adobe, so that's my thing, um, how to shift it left. But it's, uh, sometimes it's misunderstood, um, as, "Hey developers, do all of it." Um, "Here you go. Like I, I identified a problem and I tell you about the problem and I walk away. Um, this is we shifted the problem left, it's done, um, developers are responsible." And this is usually paired with security is everyone's responsibility. Um, so I slightly disagree with that. I think if you in security engineering or any, anywhere in security, you should be the person that is to be held accountable for security. So accountability is a big thing. You can't say security is everyone's responsibility and walk away. Uh, HR is not everyone's responsibility. Legal is not everyone's responsibility. There is a specialist and expert, and when you hire a very expensive machine learning engineer, you do not want security to be a big part of their day. Like when you hire them, you do not hire them for security. You hire them for machine learning. So, um, I think we need to be very careful with like just throwing words around around this.
Making security easy, effective, and delightful
[02:18] - Ammar Alim: So, I think I've seen like I've seen multiple iterations of shift security left, um, and the incentive structure for developers needs to be right. They should, you should be, you should make it so easy, they can't say no. Like, um, make them an offer they cannot refuse. And the offer is in the following: how could you just make it where the the tool you introduce are not slow and tested and verified. You don't know anything, you just purchased a tool and then you put it on CICD. That most people, um, think when they think about DevOps or DevSecOps, they think about deployment and delivery in CICD pipelines. I think DevOps is more than than that. Like you need a continuous security intelligence program. Like you need to understand what's happening all the way to the right to be able to inform you left practices. So you need to talk to your SIM people, your security operations, what they're seeing and bake that into your shift left strategies. Again, um, if you need them to do something, make it easy, effective, and delightful. Um, reduce their number of meetings. That's, that should be a goal. Like if you want to measure the success of your program, the amount of meetings they are required at the end is one. Another metric is the amount of documents they have to read. Um, and if you could eliminate those using information, using things that seamlessly integrate with their workflows.
[03:59] - Ammar Alim: For example, um, all of your developers starting going crazy about cursor, that's where you need to pay attention to. Like 40, 50%, maybe now it's 80% for most organizations. How can I talk to cursors directly now using cursor rules, right? And you have to be smart about it. You cannot bring so many rules that distract the context. You really need to know what you're doing. So go and figure out what is context engineering. Understand that, study that. So to really secure a thing, you need to know a little bit about it, so you can seamlessly integrate it and just make it so easy. Um, easy said than done. Uh, that's why we ended up with security being somewhat broken in some many, many, like the security opportunity now is huge, just because, you know, it's easier to automate things. It's easier to to create a workflow. Um, yeah, I, I, in short, figure out to make it easy, effective, and delightful by reducing the amount of time, being the sent, like the experience, um, the center of excellence as far as security. Do not, um, reflect responsibility and say responsibility is everyone responsibility and not bringing something to the table. Uh, these are areas where I would start.
Distinguishing inner and outer loop tasks
[05:22] - Jenn Gile: Yeah, there's two things I would say to that. First, I think I've said it just about every LeanAppSec, uh, good security is about making the right thing easy and the wrong thing hard. Um, and then the other thing I'll add is, well, I've been here in Raleigh I got to know the team at Intuit, uh, a bit and they told me about an internal study they did looking at the amount of time their engineers are spending on various tasks. And they found that basically a third of their software engineers' time was spent on what they call outer loop tasks, which are, you know, maintenance tasks. It's upgrading, it's dealing with infrastructure, whereas a third was spent on inner loop tasks—that's the actual writing of the code—and then another third was spent on, uh, you know, architectural kind of fork, like things that you do before you start building. And they're very intentionally trying to reduce and automate the things in that outer loop because, you know, to your point, Ammar, about, you know, you hire this really talented machine learning engineer and then what you're going to have them go do a bunch of stuff that's not machine learning work. So, you know, looking for ways to reduce that outer loop while still being secure is what I think good looks like.
[06:42] - Jenn Gile: Katie, you have been covering DevOps and DevSecOps, so I'm sure you have, uh, plenty of things to say on this topic.
[06:50] - Katie Norton: Yeah, we could be here for, I could do a whole webinar on this. But, the, um, the one thing, first I'll add, um, to do what I do as an analyst, validate third-party through, uh, some of the survey research I've done, um, the actually, so I sit as an analyst with all our application development analysts. Not, I don't sit with the security, cyber security people. I, so my colleagues in my team are the people that cover developers and open source and testing and DevOps and all those things. And I cover DevSecOps along with application security for the first two years that I was here. So I had some unique, my lens on the market's always been from sort of that SDLC perspective rather than from sort of the cyber security point of view. And, um, one, we also found in a survey we did of like over a thousand developers that it was like roughly 60% we calculated of their tasks were like the non-like feature development, innovative work. So those outer loop and architectural things you're kind of referring to, right? So our numbers were, were pretty similar to what Intuit found internally.
Defense-in-depth and buying time
[08:14] - Katie Norton: Um, and then the thing I'll say is I totally agree with you, Ammar, that like, you have to think about application security as an entire loop and things like a WAF and your runtime stuff. All of that needs to work together, right? And so when you have maybe a vulnerability that needs to be addressed, there's all so many competing priorities that a developer has that even like a critical CVE, that might not be at that moment the top priority. And when you have more defense-in-depth and you have protections that can buy you time and say like, "Okay, well, we have a WAF or we have some sort of run ADR or runtime protection or a WAF in place," that can allow us to prioritize when we have time to, to work on these things and and balance them with say like the the features and the business, you know, directives that we have. That allows everything to feel like less of a fire. So I think it's important that while, you know, I think shift left and and the more you can do things early, I think is the ultimate underlying message there that like, if there are things you can build things securely from the start, it prevents more of those fires from hap- happening and being having to be put out. It doesn't mean make developers do all the security, right?
The importance of context and trust
[09:37] - Jenn Gile: Yeah, I think that's been a bit of a misperception with shift left, right? That just give it to to developers. Um, I, I would be a bad AppSec platform person if I didn't also add that it's really context. You know, if you're going to be shifting things earlier in the process, um, it's even more important, um, to make sure that the only things that are surfacing to your developers are the things that are actually important. Whether that's the vulnerabilities that are reachable or like what Adam was talking about earlier, how many features don't have any, uh, you know, threat modeling ramifications for security, like be be very, um, conservative in what you're sending to developers to ensure that you build that trust that when I do send you something, it it's important and it's worth acting on.
