InCyber Forum Europe recap: 4 tips from DevSecOps experts

As your organization considers how to shift security left and facilitate shared responsibility for fixing issues, it can be tricky to know where to start. Which tooling will work best with your existing processes? What are the best ways to spread the word about the importance of application security? And once you’ve chosen tools, how do you actually get developers to use them?

Three experts came together to answer these questions at the InCyber Forum in Europe. The speakers included Grace Law from Manulife, a Snyk customer; Eric Fourrier from GitGuardian, a Snyk partner; and Chaaban Barakat from Snyk itself. Each expert brought a unique perspective on choosing the right tools/processes, spreading awareness, and driving actionable DevSecOps adoption. Here are their biggest tips and tricks for organizations who want to take DevSecOps from an idea to a reality.

Choose security tools that are a good culture fit

Choosing the right tooling is one of

the most significant challenges for organizations that want to enable a DevSecOps approach. As many security teams know, procuring application security tools is one thing, but getting development teams to actually use these tools is a whole other endeavor. 

According to Chaaban Barakat, developer adoption becomes a huge challenge when the tools aren’t a good fit for the organization’s culture and don’t enable ownership for security-related tasks. He said, “Very often, there are already [security] tools in place, but they're not adopted…and there are two reasons why these tools are not adopted. Either it's a tool problem — the tool is too hard to integrate, too hard to use, too slow, has too many false positives, or makes remediation difficult…or it's a culture or people problem in the sense that there is no ownership of DevSecOps.”

To answer this challenge, organizations must strategically choose tooling that works with existing workflows and doesn’t produce unnecessary noise. In Grace Law’s words, “There are a lot of tools that can identify 100 vulnerabilities but also give us 1000 false positives. In the end, this means that no one will take the report seriously. And it also adds a lot of pressure for the security teams to actually validate the vulnerabilities one by one.”

Not only should the tooling be accurate, but it should also work seamlessly with existing workflows to promote ownership. According to Eric Fourrier, compatibility with development workflows is paramount to fostering a shared responsibility approach. When a tool can integrate seamlessly into existing development pipelines, it ensures that developers don’t have to leave their state of flow to run security tests. 

He said, “Today’s developers need to master so many technologies — front-end, back-end, infrastructure. Also, we ask them to be security engineers and champions. And on the other end of the spectrum, you have one security engineer for 100 developers. So you really need to make them work together…[by] actually orchestrating security policies and giving tools to developers that can be in their workflows.”

Snyk’s solutions exemplify these principles by offering developer-first security tools that integrate effortlessly into existing development environments. Manulife’s adoption of Snyk demonstrates how selecting the right tool can significantly enhance security practices without disrupting workflows.

Communicate, communicate, communicate

After selecting a security tool, it’s essential to strategically roll out security awareness and education to the development teams across your organization. In Law’s words, “Awareness is super, super important. Communication is super, super important. We need to change the mindset of developers and remind them that security is here to help. Security is not someone who will stop you from deploying your application…so we give them a lot of communication ahead of time. And we present ourselves as a team that can actually work with them.”

However, your specific plans for educating and spreading awareness among development teams should depend on your organization’s history with security tooling. Barakat said, “It depends on the maturity of the company. Sometimes we have companies that are used to having security tools…[communication is] harder when developers are not used to fixing issues or dealing with security tools. And then we have to introduce them to something new and drive some awareness. That can be driven inside of the company itself. You can have security champions driving the programs.

We also like to raise awareness by doing live hacking.”

Snyk supports these communication efforts by providing clear and actionable insights into vulnerabilities. This approach helps teams like Manulife educate their developers on the importance of security and how to address issues effectively, ensuring that security becomes a shared responsibility across the organization.

Measure the right KPIs

The speakers also emphasized the importance of tracking the right KPIs as you begin your DevSecOps journey. Fourrier recommended a “stop the bleeding” approach to start with, which focuses on keeping “new secrets and new vulnerabilities from entering your codebase. And you can achieve that with what we talked about — shift left developer adoption and education. And that's the

first KPI we try to optimize.”

But at the end of the day, your organization’s key security metrics should reflect its unique priorities and structure. Barakat said, “Every company has its own first objectives. If you come as a company, and you've never really managed to scan all of your repos because the tool that you had was too slow or too hard to implement…maybe the first objective is to scan every repo that you have.”

Watch out for new trends in AppSec

The reality of DevSecOps is that the job will never be done. There will constantly be emerging technologies and processes you can leverage to improve your overall approach. The speakers covered a few of the top trends that they believe will change application security for the better, including:

• Application security posture management (ASPM), in which leadership gets a big-picture view of how they are mitigating risk across the organization

• Increased focus on developer experience, in which organizations take a good look at how security controls affect the daily workflows of development teams and ensure that security causes minimal disruption to existing practices. 

• Remediation versus just reporting, in which organizations empower developers to actionably fix code issues, rather than just compiling a list of vulnerabilities to check a compliance box. 

How Snyk supports DevSecOps adoption

Manulife uses Snyk Open Source, Snyk Code, and Snyk Container to enhance their DevSecOps practices. Snyk’s developer-first security approach helps organizations implement tools that work alongside existing development practices and reduce risk at scale. Our solutions integrate easily into existing IDEs, repositories, and CI/CD pipelines, enabling developers to test and fix their own code at pull request. We offer actionable fix advice within the CLI so that developers can remediate vulnerabilities within minutes.

By leveraging Snyk Open Source, Manulife can identify and fix vulnerabilities in their open source dependencies. Snyk Code allows their developers to catch security issues in their proprietary code early in the development cycle, while Snyk Container ensures their containerized applications are secure from the start.

In addition, our ASPM offering, Snyk AppRisk, provides leaders with a complete picture of application risk, enabling them to proactively mitigate the most pressing threats to their business-critical applications and operations. 

Check out the full InCyber presentation to learn more about kicking off an effective DevSecOps program.