How to build a modern DevSecOps culture: Lessons from Jaguar Land Rover and Asda

People, processes, and tooling all impact an organization’s ability to maintain a strong AppSec program. In a recent panel at Black Hat Europe, Snyk spoke with two customers — Jaguar Land Rover (JLR) and Asda — about the unique challenges they face managing development teams, onboarding new security tools, and building a modern DevSecOps program throughout their organizations. 

JLR began manufacturing cars in 1935. After several mergers and acquisitions — and almost a century of technological innovation — the company now employs 3,000 developers worldwide who work on various software projects. Mike Welsh, Lead Enterprise Security Architect of DevSecOps at JLR, is tasked with maintaining enterprise-wide strategies to ensure secure development practices and connecting disparate teams under unified processes. 

In contrast, Asda is in the early stages of building its DevSecOps program. Though it’s an established brand, the company’s recent split from Walmart has left Asda to operate as “the biggest startup in Europe.” Ruta Baltiejute, the DevSecOps lead at Asda, is in the process of building the company’s DevSecOps culture from scratch, onboarding new tools, and working cross-functionally with engineers and security personnel to lay a foundation for the company’s approach to secure application development.

Though the two companies are at vastly different stages of maturity when it comes to building a DevSecOps culture, there are some commonalities in the lessons each has learned along their journey.

1. Make developers part of the decision-making process

During the panel, Mike and Ruta agreed that developer buy-in is critical to success when it comes to building a strong DevSecOps culture. Both speakers encourage other DevSecOps professionals to ensure that engineers are part of all decisions — from suggesting new development tools to executing a proof of concept. This collaboration is essential so engineers don’t resist security mandates or ignore tools forced upon them. Mike suggests that “it makes it a hell of a lot easier to actually convince people to adopt and move forward using the tooling you’ve selected if they were embedded in the process of that selection.”

Without buy-in, the adoption of new processes or tools will suffer and create a massive problem for the integrity of your program. For Mike and JLR, this is a huge concern. The company employs thousands of engineers across EMEA, APAC, and the Americas. Mike needed to find tooling that worked for everyone — and that everyone was willing to use — so the company could get 100% visibility into their codebase and understand relevant vulnerabilities. As Mike said, “There’s no point in just seeing 10% of your codebase and understanding if it’s secure or not.”  

Snyk was the perfect fit. It’s an industry-recognized solution and was frequently suggested by members of JLR’s developer community. With Snyk Open Source, Snyk Container, and Snyk Code, Mike was able to standardize the team on the same policies and processes and envelop Snyk into them. Now, every developer can use Snyk to identify vulnerabilities. Thanks to a lot of automation that they built using Snyk’s API, JLR can effectively scan a massive 14,000 projects in its code management system. It’s a solution that allows developers to be more efficient and produce more secure code. 

2. Approach process changes with a “benefits-first” mindset 

Before introducing anything new, it’s important to ensure the process changes or new tools you plan to implement will provide a practical benefit to your engineering team. After all, to adopt a new process with open arms, engineers must understand how it will positively impact them. 

Ruta suggests doing your research to understand developer pain points, and communicating those findings back to your developers so they also understand. Spend time observing your developers in action and reflect aloud about what you notice. Watch their process and point out different pain points throughout their day (e.g., a time-consuming process). Sometimes, it’s a well-known pain point that developers will happily elaborate on, and sometimes, it’s something they may not have even noticed themselves — or didn’t realize was an opportunity for improvement.

Once you understand how a mandate will benefit developers, you must communicate those benefits. Explain to your developers how and why a new process will make their life easier, more secure, or more efficient in their day-to-day work. 

At Asda, Ruta specifically faced some resistance to new tooling and processes from more tenured employees and contractors. After separating from Walmart, the company was caught in an interesting gray area operating as a new entity in some ways and an old company in others. Combine that with rapid scale (actually tripling engineering program), and it’s natural to face resistance from engineers. 

Ruta and the team took advantage of the unique opportunity to grow the engineering and security team from the ground up at the same time, encouraging collaboration with developers as they looked at many solutions on the market. Ultimately, Snyk proved to be the best option for Asda, who adopted the full Snyk platform (Snyk Open Source, Snyk Code, Snyk IaC, and Snyk Container), providing engineers with practical benefits in their day-to-day work and satisfying the security team’s concerns and mandates.

Dealing with a particularly resistant team? If all else fails, Mike suggests resorting to gamification. The proof is in the numbers, and engineers love seeing the concrete difference between one way and another. Be transparent about results from different teams who implore varied processes to communicate the benefits of one versus the other effectively.

3. Simplify the onboarding process 

No matter how beneficial a new process may be, developers will only listen to your pitch and adopt a new process or tool if it’s easy for them to do so. 

As Ruta reminded attendees, “You’re never going to get a developer to read a 50-page document on how they are meant to do something in the company. If you give them the tooling and a way to do that in a simplified way, they will adhere to those policies in the correct fashion.” 

4. Learn from past experiences — collectively 

Collaboration is great, in theory. But to hold yourself accountable, it’s best to formalize a collaboration process to ensure all voices are heard. You likely have a lot of collective knowledge and experience on your team. What better place to mine for new ideas or feedback about tooling and processes? 

At JLR, Mike and the team created a DevSecOps Guild, made up of representatives from different parts of the company with various professional experiences. The representatives meet to discuss tools they’ve used in the past or others that might be worthwhile to vet. The collective knowledge across the guild helps JLR formalize collaboration efforts and whittle down priorities in a sea of industry tools. 

In a DevSecOps culture, collaboration is essential

At their core, each lesson learned highlights the importance of cooperation between security and developer teams. No matter where you are on your DevSecOps journey, the strength and continuity of your program relies on the buy-in of all those involved. Check out the full Black Hat session to dig deeper into these lessons.

Looking for a tool that your developers and security teams will love? Check out Snyk’s modern developer security platform.