5 Steps to Getting Developers and Security Seeing Eye-to-Eye

DZone 's Guide to

5 Steps to Getting Developers and Security Seeing Eye-to-Eye

Security and development teams have been at odds for a long time, but with security risks continuing to grow, here are some changes you can make to help everyone get along.

· Security Zone ·
Free Resource

As the CEO of WhiteSource, a company whose central focus is helping organizations better manage their open source usage, I’ve spent a lot of time working with both software engineering and security executives. However, one of the issues that keep popping up is the different mindsets of the two teams.

For many, this might not be that surprising. Because isn’t engineering’s goal of building functional products fast pulling in the opposite direction to security’s, who wants to ensure all products are secure? Well, not necessarily.

So, here are my top tips on how you can enable your engineering and security teams to deliver secure products together.

#1 Make Security a Top Priority

First things first, if you want developers to make software security more of a priority, management needs to lead the way.

In today’s market, where companies are under constant pressure to deploy products as fast as possible, management teams need to set clear security priorities. Changing developers and security pros perception of each other can only start at the top. Both teams need to understand that only if they work together, they can identify and fix security issues early in the software development lifecycle (SDLC) and so improve their products while reducing costs and saving precious deployment time.

Consequently, once management puts security at the center of development, all teams will know security expectations have changed, and current processes and common practices need to be re-evaluated and improved. This should always be the first step towards defining new ways of working collaboratively.

#2 Getting Engineers to Care More About Security

Management may now be pushing for more security, but for developers to really get involved, they need to understand how increased security helps them do their jobs better.

The earlier developers find vulnerabilities, the easier those issues are to fix, and so the amount of unplanned work in later stages will be reduced. Once developers understand this, the more likely they’ll be to modify their development practices and implement new tools to shift left security testing.

Another thing that can help developers hop on the security train is slightly modifying the language security uses for defining KPIs and goals, so developers can relate. Creating a common language is always a crucial step when bridging between two cultures and, especially when talking about security and engineering, it can help teams realize they’re both pulling in the same direction

A great place to start is ensuring developers have the right tools to code securely, and that both teams have free access to those tools. In many discussions I’ve had with companies about  OWASP A9, which highlights the importance of detecting known vulnerabilities in software products, I often find out that security is under the misconception that developers can block the usage of vulnerable components with their current tools and environments. However, in most cases, this is unfortunately not true.

#3 Training Engineers to Code Securely

A great way of enabling developers to code more securely is providing training. Simple as that. I’ve witnessed time and again how running a short series of security workshops/training sessions can help developers implement new processes practices that lead to more secure products and better day-to-day communication between the two teams.

In order to get the most out of these sessions, security pros need to approach the security risks from the developer’s perspective, and provide insights into how developers can secure their code without having to overhaul their current development practices.

For example, many enterprises still demand their developers get approval for each new open source component they wish to integrate, but they usually only check license compliance. Therefore, if security training teaches developers how to check if an open source or commercial component is vulnerable, as well as the activity level (number of commits) of each component’s project, developers will be more likely to add higher quality components in the future.

Furthermore, training needs to grab developers’ attention. It’s a good idea for sessions to include details of high-profile data leaks, cyber-attacks and other security events which made waves in engineering circles. Trust me, as a longtime developer who has sat through many security sessions, if training isn’t interesting, the audience will trail off and start thinking about other pressing matters, such as why the Empire built the Death Star’s exhaust port leading straight to the reactor system, instead of the task at hand.

However, when it comes to getting developers more involved in doing security, not all skills need to be learned in the classroom.

#4 Making Security Fun

A neat way to get developers involved in security is via Gamification.

Gamification is all about applying game principles (rewards, levels, competition, points) to solve real-life challenges, like software security. And a great example of how Gamification has helped developers code more securely is Microsoft.

The tech-giant came up with their own card-based Elevation of Privileges (EoP) game as a way to get their developers more engaged in threat modeling IT systems. And guess what. It worked. The game was so successful that it’s now part of Microsoft’s development process, and it can even be downloaded so other development teams can give it a try as well. After all, who said doing security couldn’t be fun?

However, the real trick in getting developers open to software security is assuring them their coding practices won’t need to be drastically changed for the sake of increased security.

#5 Implementing Automated Security Tools

To get developers and security on the same page, security needs to have a constant, but almost invisible, presence throughout the SDLC.

The best way to do this is by automating security testing throughout your CI/CD processes. You can do this by configuring your CI server (like Jenkins or Microsoft TFS) to run automated security tools like OWASP Zap and Gauntlt every time someone pushes a commit.

Additionally, you can integrate SAST, DAST or open source security tools to detect vulnerabilities in your code in real-time. These tools also provide security teams with control and visibility over the build, which reduces friction between the teams.

It’s a win-win. Security is happy because they know exactly what’s the status of each product, while developers can concentrate on coding, without security hovering over their shoulders asking for reports and analysis.

Developing Securely

And there you have it. A short guide to getting your security and engineering teams seeing eye-to-eye.

If you have any strategies that have worked for you, it would be great if you could share them in the comments section below!

collaboration, culture, devops, security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}