How Mulesoft fosters a developer-first, shift-left culture with Snyk

While shifting security left has been a hot topic for around a decade, many organizations still face issues trying to make it a reality. There are many misconceptions about what shift left means and what it looks like for development teams to take ownership of security without derailing their existing workflows. For instance, many teams tend to pass security issues to developers earlier in the software development lifecycle (SDLC) without giving the teams the proper context or tools to fix these issues actionably. 

Mulesoft’s team wanted to do something different than just throwing security alerts at developers. They believed that true DevSecOps success lies in prioritizing the developer experience.  But to make these goals a reality, Mulesoft needed to embark on a journey with the right solutions and processes to make these goals a reality. 

In a recent fireside chat, Clinton Herget, Field CTO at Snyk, and Martin Adolfi, Sr. Engineering Manager at Mulesoft, discussed Mulesoft’s DevSecOps journey. They dove into the true definition of developer security for today’s fast-paced organizations and covered the challenges and wins that Mulesoft experienced in achieving shift left goals. 

Mulesoft’s challenge in making “shift left” a reality

When Adolfi and his team began digging deeper into their DevSecOps initiatives, they had a specific vision of shifting left and what it wasn’t. The team noticed a disconnect between security expectations and the typical developer’s mindset. Adolfi described it as “throwing left” instead of shifting left — sending alerts/reports to developers without deeper context or guidance, then expecting them to fix it. This approach ultimately costs the developers time and mental capacity, forcing them to shift context and step away from a state of flow and productivity. It takes them away from what they love to do — coding and innovating — which reduces job satisfaction and causes tension between development and security teams. 

Incentivizing developers to succeed in security and, ultimately, become security champions starts by giving them a path of least resistance to follow. According to Adolfi, the key is empowering the developers to fix issues within their existing feedback loops. He said, “If the issue gets to a ticket, it's already too late…you want to create tooling that lives inside the developer's loop instead of saying, ‘We have this new dashboard, or this new report, and you need to look in this tool for the information you need’... [As a developer], I'm constantly being stopped from doing what I want and what is engaging for me. I have to look in seven different data sources to do my job.”

The team knew they wanted to integrate security feedback loops into their developer’s existing workflows but needed to solve a few challenges to get there.

First, they had to respond to developer feedback that there was “too much bureaucracy” in the application security process. Mulesoft’s development teams felt the pressure of maintaining existing projects through regular patching and meeting compliance and SLAs in new applications. They needed a security approach that wouldn’t add to this bureaucracy problem.

In addition, the development team’s pipelines were drastically different from each other, but the developers appreciated this level of freedom and didn’t want to give it up. This variety in languages, frameworks, and microservices made establishing a consistent security process across the entire organization challenging. 

Mulesoft’s DevSecOps successes 

To respond to these challenges, Mulesoft needed a developer-first security partner. The team chose to use Snyk’s platform because it aligned closely with their DevSecOps goals.

Adolfi said, “Snyk follows our mindset of shifting left, delivering more value, delivering insights, and telling developers how to fix by having all the information there to understand the impact, understanding the criticality — all of that.”

Because Snyk sits inside the developers’ various native environments and provides instant feedback and fix suggestions, Adolfi and his team have successfully streamlined the process of finding and fixing vulnerabilities for Mulesoft developers. 

Adolfi said, “The main reason the developer experience team focused on Snyk and not the rest of our tech stack is that Snyk is closest to the developer.”

Snyk + Mulesoft: Looking ahead

As the Mulesoft team continues to secure the SDLC with a DevSecOps mindset, they will continue to lean on the principle of shifting left by empowering developers. This empowerment comes from giving development teams the tools and processes they need to successfully fix vulnerabilities in real time and avoid context-shifting as much as possible. 

As the next stage of their development journey, the Mulesoft team plans to incorporate more AI tooling into their pipelines. They see opportunities to use AI to both write and review code. 

To learn more about Mulesoft’s developer security journey and DevSecOps successes, listen to Adolfi and Herget’s entire conversation.